借助生产级Kubernetes降低复杂性

NGINX | 2021年2月05日

编者：本文是一个共10篇的系列文章之一：

还可以免费下载包含全套博客文章的电子书《推动Kubernetes从测试走向生产》。

2020年是我们许多人永远难忘的一年。学校、企业和公共服务机构突然关闭，让我们与所在社区骤然隔绝，也让自身安全和经济稳定性变得难以预料。试想一下，如果这一切发生在2000年，甚至2010年，会有什么不同？技术。如果没有我们习以为常的优质数字服务，例如医疗保健、流媒体视频和远程协作工具，疫情期间的生活将截然不同。是什么让2020年的技术与过去几十年如此不同？容器和微服务。

微服务架构通常使用容器和Kubernetes，可缩短数字体验的上市时间，推动业务增长与创新。无论是与传统架构配合使用，还是独立使用，这些现代应用技术都能提供更出色的可扩展性和灵活性，加快部署速度，甚至有助于节省成本。

我们发现，2020 年之前，大多数客户已开始采用微服务，将其作为数字化转型战略的一部分，但疫情确实加快了应用现代化进程。我们的 2020 年调查显示，在受访的 NGINX 用户中，60% 已在生产环境中使用微服务，高于 2019 年的 40%；容器的普及程度是其他现代应用技术的两倍以上。

Kubernetes已成为管理容器化应用的事实标准，这一点可从云原生计算基金会（CNCF）2020年调查中得到印证。调查发现，91%的受访者正在使用Kubernetes，其中83%已将其用于生产环境。采用Kubernetes时，许多组织已为大规模架构变更做好准备，却未预料到规模化运行现代应用技术会对组织产生影响。如果正在运行Kubernetes，您很可能已经遇到以下3项关乎业务的关键障碍：

文化
即使应用团队采用敏捷开发和DevOps等现代方法，通常仍会受到康威定律的影响。该定律指出：“组织所设计的系统会反映其自身的沟通结构。”换言之，分布式应用由分布式团队开发，这些团队独立运作，但共享资源。这种结构有利于团队快速推进工作，但也容易形成孤岛。由此可能导致沟通不畅（并进一步引发其他问题）、安全漏洞、工具泛滥、自动化实践不一致以及团队冲突。
复杂性
要实施企业级微服务技术，组织必须整合一系列关键组件，以提供可观测性、安全性和流量管理。团队通常使用基础设施平台、云原生服务和开源工具来满足这一需求。每种策略都有其适用场景，但也各有不足，可能增加复杂性。同一组织内的不同团队往往会选择不同的策略来满足相同需求，从而产生“运维债务”。此外，团队会在特定时间点选择流程和工具，即使使用容器部署和运行由现代微服务驱动的应用所面临的要求不断变化，也会继续沿用这些流程和工具。CNCF Cloud Native Interactive Landscape充分体现了支持基于微服务的应用所需基础设施的复杂性。组织需要熟练掌握各种不同的技术，这可能导致基础设施锁定、影子IT、工具泛滥，并使负责维护基础设施的人员面临陡峭的学习曲线。
安全性
安全要求对于云原生应用和传统应用而言存在显著差异，因为边界隔离式安全等策略在Kubernetes中并不可行。庞大的生态系统以及容器化应用的分布式特性意味着攻击面大幅扩大，而对外部SaaS应用的依赖也让员工和外部人员有更多机会注入恶意代码或窃取信息。此外，文化和复杂性方面所述的后果，尤其是工具泛滥，会直接影响现代应用的安全性和韧性。在整个生态系统中使用不同工具解决同一问题不仅效率低下，还会给SecOps团队带来巨大挑战，因为他们必须掌握如何正确配置每个组件。

解决方案：生产级Kubernetes

与大多数组织层面的问题一样，要应对Kubernetes带来的挑战，需要将技术与流程相结合。本文接下来将重点介绍技术方面的内容，后续还将发布有关流程及其他主题的博客文章，敬请关注。

由于Kubernetes是一项开源技术，因此有多种实施方式。虽然有些组织倾向于自行搭建原生Kubernetes，但许多组织认为，Amazon Elastic Kubernetes Service（EKS）、Google Kubernetes Engine（GKE）、Microsoft Azure Kubernetes Service（AKS）、Red Hat OpenShift Container Platform和Rancher等服务所提供的灵活性、规范性和支持相结合，能够带来价值。

Kubernetes平台可以帮助您轻松启动并运行，但它们更注重服务的广度，而非深度。因此，虽然您可能可以在一个平台上获得所需的全部服务，但这些平台不太可能提供真正实现大规模生产就绪所需的功能集。具体而言，它们并不专注于高级网络和安全功能，而这正是许多客户对Kubernetes感到失望的原因。

要让Kubernetes达到生产级要求，需要按以下顺序添加另外三个组件：

用于将流量传入和传出集群的可扩展入口和出口层
这通过Ingress控制器实现。Ingress控制器是一种专用负载均衡器，可屏蔽Kubernetes网络的复杂性，并在Kubernetes集群内外的服务之间建立连接。当该组件具备提高韧性的功能（例如高级运行状况检查和Prometheus指标）、支持快速扩展的功能（动态重新配置），以及支持自助服务的功能（基于角色的访问控制［RBAC］）时，即可满足生产级要求。
内置安全功能，防范整个集群中的威胁
集群外部采用“粗粒度”安全措施或许已经足够，但集群内部则需要“细粒度”安全措施。根据集群的复杂程度，可能需要在三个位置部署灵活的Web应用防火墙（WAF）：Ingress控制器、每服务代理和每Pod代理。借助这种灵活性，可以对计费等敏感应用实施更严格的控制，而在风险较低的位置采用较宽松的控制。
可扩展的东西向流量层，用于优化集群内流量
当Kubernetes应用的复杂性和规模超出基本工具的处理能力时，就需要使用这第三个组件。在此阶段，需要部署服务网格。这是一种编排工具，可为集群内的应用服务提供更精细的流量管理和安全防护。服务网格通常负责管理容器化应用之间的应用路由，提供并实施自主的服务间双向TLS（mTLS）策略，以及提供应用可用性和安全性的可观测性。

选择这些组件时，应优先考虑可移植性和可见性。平台无关的组件可以减少团队需要学习和保护的工具数量，从而降低复杂性并提升安全性，同时便于根据业务需求迁移工作负载。可见性和监控的重要性不容低估。通过与Grafana和Prometheus等常用工具集成，可以创建统一的基础设施“单一管理视图”，帮助团队在客户发现问题之前及时检测到问题。此外，还有一些补充技术，虽然不一定是生产级Kubernetes的必备技术，却是现代应用开发不可或缺的组成部分。例如，当组织准备对传统应用进行现代化改造时，首要步骤之一是使用API网关构建微服务。

NGINX如何提供帮助

我们的Kubernetes解决方案不受平台限制，包含实现生产级Kubernetes所需的三个组件：NGINX Ingress Controller作为入口和出口层，NGINX App Protect作为Web应用防火墙（WAF），以及NGINX Service Mesh作为东西向流量层。

Kubernetes环境拓扑图，其中NGINX App Protect WAF与NGINX Ingress Controller并行部署，并包含NGINX Service Mesh

这些解决方案可在以下4个关键领域为您提供支持，让Kubernetes成为得力助手：

自动化：让应用更快、更安全地推向市场
结合使用NGINX Ingress Controller的流量路由和应用接入功能，以及NGINX Service Mesh自动部署NGINX Plus边车的功能，部署、扩展、保护和更新应用。
安全性：保护客户和业务免受现有及新兴威胁
在集群中的任意位置部署NGINX App Protect，以减少潜在故障点；同时使用NGINX Service Mesh和NGINX Ingress Controller管理并强制实施服务间的端到端加密。
性能：提供客户和用户所期待的数字体验
借助性能优于其他WAF、Ingress控制器和负载均衡器的NGINX解决方案，轻松应对流量激增和安全威胁，同时不影响性能。
洞察：推动业务发展，更好地服务客户
通过NGINX Ingress Controller和NGINX Service Mesh获取有关应用性能和可用性的针对性洞察，并利用深度追踪了解请求在微服务应用中的处理过程。