点赞
评论
收藏
分享
举报
生产级 Kubernetes 助您降低复杂性
发表于2022-04-07 14:21

浏览 596

原文作者:Jenn Gile
原文链接:生产级 Kubernetes 助您降低复杂性 - NGINX
转载来源:NGINX 官方网站


2020 年是令人刻骨铭心的一年。学校、企业和公共服务的突然停摆让我们与社会隔绝开来,也让我们的人身安全和财务稳定性充满了不确定。现在我们想象一下,如果疫情发生在 2000 年,甚至是 2010 年,会和现在有什么不同?答案是技术。如果没有医疗、流媒体视频、远程协作工具等我们习以为常的高质量数字服务做保障,疫情对我们来说可能就会是另外一番体验了。是什么让 2020 的技术与过去几十年如此不同?答案是容器和微服务。

微服务架构通常会与容器和 Kubernetes 技术结合,能够缩短业务上市时间、提升数字体验,进而推动业务增长和技术创新。无论是搭配使用传统架构还是独立使用,这些现代应用技术都可以显著改善可扩展性、灵活性和部署速度,甚至节省成本。

在 2020 年之前,我们发现大多数客户已开始采用微服务作为其数字化转型战略的一部分,但疫情极大地推动了应用的现代化步伐。我们在 2020 年 对 NGINX 用户进行的一项调查发现,60% 的受访者在生产环境中使用微服务,较 2019 年 (40%) 有所上升,容器的受欢迎程度是其他现代应用技术的 2 倍多。

Kubernetes 是公认的容器化应用管理标准。as evidenced by the 云原生计算基金会 (CNCF) 在 2020 年进行的一项调查发现,91% 的受访者正在使用 Kubernetes,其中 83% 在生产环境中使用。许多企业在采用 Kubernetes 时已经做好了进行重大架构变更的准备,但大规模运行现代应用技术对组织带来的影响却是他们没有想到的。如果您正在运行 Kubernetes,您可能已经遇到了以下三个攸关业务的障碍:

  • 文化
    即使应用团队采用了敏捷开发和 DevOps 这样的现代方法,他们通常也摆脱不了康威定律,即“组织对于系统架构的设计,往往反映了该组织自身的沟通形态”。换句话说,分布式应用由独立运转但资源共享的分布式团队开发。虽然这种沟通形态能够有效提高团队的工作效率,但同时也容易形成孤岛,进而出现沟通低效(这将导致其他负面结果)、安全漏洞、工具蔓延、自动化实践不一致以及团队冲突等问题。
  • 复杂性
    企业要想实施企业级微服务技术,就必须将一套关键组件组合在一起,以实现可视化、安全性和流量管理。通常,团队会使用基础架构平台、云原生服务和开源工具来满足这一需求。虽然每个策略都各有所用,但也都各有不足,可能会造成出现复杂性。同一组织结构内的不同团队常常会选择不同的策略来满足相同的要求,从而导致“运营债务”。此外,各个团队一旦在某个时间点选择了某个流程和工具,那么无论使用容器部署和运行现代微服务应用的需求如何变化,他们都会继续使用下去

    The CNCF Cloud Native Interactive Landscape(云原生基金会的交互全景图) 清楚地说明了支持微服务应用的必要基础架构的复杂性。企业需要精通各种不同的技术,这会造成基础架构锁定、IT 无处不在、工具蔓延以及基础架构维护人员学习难度加大等。

  • 安全性
    云原生应用和传统应用的安全性需求存在明显不同,因为 Kubernetes 中不存在“围栏”(ringfenced)策略。庞大的生态系统和容器化应用的分布式特性意味着攻击面更为广泛,而对外部 SaaS 应用的依赖则意味着员工和外部人员注入恶意代码或泄露信息的机会大幅增加。此外,文化和复杂性部分(尤其是工具蔓延)中提到的后果将直接影响到现代应用的安全性和弹性。在生态系统中使用不同的工具解决相同的问题不仅效率低下,而且给 SecOps 团队带来了巨大的挑战,他们必须学习如何正确地配置每个组件。


解决方案:生产级 Kubernetes

与大多数组织结构问题一样,解决 Kubernetes 挑战的方法是将技术和流程相结合。接下来我们将主要讨论技术组件,有关流程及其他主题请关注后续博客。

Kubernetes 是一种开源技术,实现生产级 Kubernetes 的方式有很多。虽然一些企业更喜欢配置适合自己的 Kubernetes,但许多企业发现,Amazon Elastic Kubernetes Service(EKS)、Google Kubernetes Engine(GKE)、Microsoft Azure Kubernetes Service(AKS)、Red Hat OpenShift 容器平台 及 Rancher 等服务可提供出色的灵活性、规范性及强大的支持。

Kubernetes 平台支持服务轻松启动和运行,但是它们关注的是服务广度而非深度。您可以一站式获齐所需的所有服务,但无法获得大规模生产所需的所有功能。具体来说,它们不关注高级网络功能和安全性,而这正是许多客户对 Kubernetes 不满意的地方。

要实现生产级 Kubernetes,您需要按照以下顺序添加三个组件:

  1. 可扩展的 ingress/egress 层,用于控制进出集群的流量
    这是通过 Ingress 控制器实现的。Ingress 控制器是一个专用负载均衡器,能够将 Kubernetes 网络的复杂性抽象出来,并在 Kubernetes 集群内部的服务和外部之间建立了一座桥梁。如果该组件包含有助于提高弹性(例如高级健康检查和 Prometheus 指标)、快速扩展(动态重新配置)和自助服务(基于角色的访问控制 (RBAC))的特性,它就变成了生产级组件。

  2. 内置安全防护,防范整个集群中的威胁
    虽然集群外部可能只要有“粗粒度”的安全防护就够了,但集群内部必须要有“细粒度”安全防护。根据集群的复杂程度,您可能需要在以下三个位置部署灵活的 Web 应用防火墙(WAF):在 Ingress 控制器上、为每个 service 进行代理、为每个 pod 进行代理。通过这种灵活性,您可以对敏感应用实施更严格的控制(例如在计费方面),并对低风险应用放宽控制。

  3. 可扩展的东西向流量层,用于优化集群内的流量
    一旦 Kubernetes 应用的复杂性和规模超出基本工具的处理能力范围,就需要使用这第三个组件。在该阶段,您需要一个服务网格,这是一种编排工具,可为集群内的应用服务提供更细粒度的流量管理和安全性。服务网格通常负责管理容器化应用之间的应用路由,提供和实施自动的服务到服务的双向 TLS (mTLS) 策略,并让应用的可用性和安全性变得可视化。

在选择这些组件时,请优先考虑可移植性和可视化。不受平台限制的组件可以降低复杂性并提高安全性,团队需要学习和保护的工具更少,并且能够更轻松地根据业务需求转移工作负载。可视化和监控的重要性已毋庸赘言。通过集成 Grafana 和 Prometheus 等主流工具,您可以获得一个统一基础架构的“单一管理平台”视图,确保您的团队能够先客户一步检测到问题。此外,还有一些互补技术可能对生产级 Kubernetes 来说不一定是必需的,但却是现代应用开发的重要组成部分。例如,当企业和机构准备对传统应用进行现代化改造时,第一步就是使用 API 网关构建微服务。  


NGINX 如何助您一臂之力

我们的 Kubernetes 解决方案不受平台限制,并包含实现生产级 Kubernetes 所需的三个组件:用作ingress/egress层的 NGINX Ingress Controller、用作 WAF 的 NGINX App Protect、用作东西向流量层的 NGINX Service Mesh

这些解决方案可以解决以下四大方面的问题,让 Kubernetes 成为您最好的搭档:

  • 自动化 —— 更快速、更安全地将应用推向市场
    使用 NGINX Ingress Controller 的流量路由和应用配置功能,再加上 NGINX Service Mesh 的 NGINX Plus sidecar 自动部署功能,部署、扩展、保护和更新应用。
  • 安全性 —— 保护客户和业务免受现有和新兴威胁
    在集群的任意位置部署 NGINX App Protect,以减少潜在的故障点,同时使用 NGINX Service Mesh 和 NGINX Ingress Controller 管理和实施服务之间的端到端加密。
  • 性能 —— 提供客户和用户期望的数字体验
    NGINX 解决方案可轻松处理峰值流量和安全威胁,并且不会对性能造成影响,完胜其他 WAF、Ingress 控制器和负载均衡器。
  • 洞察 —— 推动业务发展,提供出色客户服务
    NGINX Ingress Controller 和 NGINX Service Mesh 可为您提供有针对性的应用性能和可用性洞察,并通过深度追踪帮助您理解微服务应用处理请求的过程。


NGINX 助您做好生产准备

NGINX Ingress Controller 提供 30 天 免费试用版,其中包括可以保护容器化应用的 NGINX App Protect。我们建议您添加免费的 NGINX Service Mesh(可在 f5.com 下载),从试用中获得最大价值。并且我们支持您将自带的许可 (BYOL) 添加到您选择的云中。


更多资源

想要更及时全面地获取NGINX相关的技术干货、互动问答、系列课程、活动资源?

请前往NGINX开源社区:


已修改于2023-03-06 07:14
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
171
文章
21
问答
180
粉丝
相关文章
介绍nginx网页配置工具QQ技术交流群1:1106758598QQ技术交流群2:560797506邮箱: cym1102@qq.com官网地址: http://www.nginxwebui.cn码云: https://gitee.com/cym1102/nginxWebUIgithub: https://github.com/cym1102/nginxWebUI功能特点nginxWebUI也可管理多个nginx服务器集群,随时一键切换到对应服务器上进行nginx配置,也可以一键将某台服务器配置同步到其他服务器,方便集群管理.部署此项目后,配置nginx再也不用上网各种搜索配置代码,再也不用手动申请和配置ssl证书,只需要在本项目中进行增删改查就可方便的配置和启动nginx。技术说明本项目是基于springBoot的web系统,数据库使用sqlite,因此服务器上不需要安装任何数据库项目启动时会释放一个.sqlite.db到系统用户文件夹中,注意进行备份本系统通过Let'sencrypt申请证书,使用acme.sh脚本
点赞 6
浏览 3.6k
  前三周学习了陶辉老师的“NGINX基础培训系列课程”,感觉受益良多,在这里想把一些知识点记录一下,和大家分享一下知识点,也方便日后的随手查看,温故知新。  首先,我们了解到了Nginx的版本,Nginx发布版本分为主线版本和稳定版本,区分两个版本也非常简单,主线版本版本号为单数,比如1.19,稳定版本为双数,比如1.18,今天我要说的是稳定版本,这个版本会尽量少的减少Nginx的bug问题,适用于生产环境,这里我不建议使用Nginx和其他软件一样在生产环境中落后一个或多个大版本使用,之前生产环境做过漏扫,发现我们编译自带的Nginx版本为:nginx/1.13.3(查询命令为nginx-V),结果出现了多个漏洞,四个高危和一个中危漏洞:        通过升级Nginx到稳定版最新版本后修复!  其次,是Nginx发行版本的选择,目前比较流行的有:nginx、nginxplus、Tengine、openresty、ope
点赞 1
浏览 2k
本文地址: https://www.laruence.com/2010/05/20/1495.html转载请注明出处现在普遍的Nginx+PHPcgi的做法是在配置文件中, 通过正则匹配(Nginx(PHP/fastcgi)的PATH_INFO问题)设置SCRIPT_FILENAME,今天小顿发现了一个这种方式的安全漏洞.比如,有http://www.laruence.com/fake.jpg,那么通过构造如下的URL,就可以看到fake.jpg的二进制内容:http://www.laruence.com/fake.jpg/foo.php为什么会这样呢?比如,如下的nginxconf:location~\.php($|/){     fastcgi_pass127.0.0.1:9000;     fastcgi_indexindex.php;     set$script$uri;&n
点赞 4
浏览 695