生产级 Kubernetes 助您降低复杂性

编者按 —— 本文是以下系列博文中的一篇（共十篇）：

您还可以免费下载整套博文集结成的电子书：《Kubernetes：从测试到生产》。

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

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

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

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

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

可扩展的 ingress/egress 层，用于控制进出集群的流量
这是通过 Ingress 控制器实现的。Ingress 控制器是一个专用负载均衡器，能够将 Kubernetes 网络的复杂性抽象出来，并在 Kubernetes 集群内部的服务和外部之间建立了一座桥梁。如果该组件包含有助于提高弹性（例如高级健康检查和 Prometheus 指标）、快速扩展（动态重新配置）和自助服务（基于角色的访问控制 (RBAC)）的特性，它就变成了生产级组件。
内置安全防护，防范整个集群中的威胁
虽然集群外部可能只要有“粗粒度”的安全防护就够了，但集群内部必须要有“细粒度”安全防护。根据集群的复杂程度，您可能需要在以下三个位置部署灵活的 Web 应用防火墙（WAF）：在 Ingress 控制器上、为每个 service 进行代理、为每个 pod 进行代理。通过这种灵活性，您可以对敏感应用实施更严格的控制（例如在计费方面），并对低风险应用放宽控制。
可扩展的东西向流量层，用于优化集群内的流量
一旦 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) 添加到您选择的云中。