我们正在将单体架构转换为微服务，采用服务网格，并从“分布式和解耦优先”的角度接近世界。我不太喜欢引入新术语，但是企业内部不断出现一个概念：“Cluster Out”。意思就是：清晰的愿景，新鲜的代码，对开源的新承诺。
Cluster Out 不是一个全面的 Kubernetes 架构。它源于解决客户发现的网络和安全漏洞。首先是构建具有安全性的坚如磐石的入口/出口（南/北流量）和服务网格（东/西流量）。在此基础上，它解决了集群内 API 流量以及集群间路由和故障转移中出现的类似网络和安全漏洞。随着我们越来越多的客户在生产中支持 Kubernetes 并沿着云原生路径前进（并且随着 NGINX 为云原生提供服务的能力不断发展），我想扩展 Cluster Out 并进一步开发现代应用程序的故事。
在从 POC Kubernetes 和微服务应用程序过渡到生产部署时，培养广泛的 Cluster Out 意识将减轻很多痛苦和心智负担。Kubernetes 的一大优点是它在小规模和大规模上都同样出色。不幸的是，开箱即用的 Kubernetes 的缺点直到您开始将其投入生产并开始通过集群运行中等或重要的 L7 流量时才会被发现。扩展 Kubernetes 类似于我们在 3 层 Web 应用程序的爆炸式增长中看到的情况。
同样的模式也出现在微服务和 Kubernetes 领域。但是现在我们已经将应用程序的各种需求分解为特定的服务，例如本地负载均衡、WAF、DDoS、身份验证、加密和全局负载均衡。我们在集群中独立运行每个服务。思考和设计 Cluster Out 是一种思维方式和框架，可确保您支持这些领域，这样您就不会在最重要的时候让现代应用程序落在您身上——在生产中同时为现场客户提供服务。理想情况下，您将从一开始就构建 Cluster Out。可悲的是，许多公司只有在没有什么事情可以做以后才会做这些。这就是为什么即使在 POC 和建立在 Kubernetes 上运行的现代应用程序的探索阶段，我们也希望培养一种 Cluster Out 思维方式。
集群输出模式的三个阶段
我们看到 Cluster Out 模式的三个阶段：
- 第 1 阶段：通过解决生产环境中 Kubernetes 的网络、可观察性和安全性奠定基础。
- 第 2 阶段：在集群内外安全地管理和调整 API。
- 第 3 阶段：通过跨多个集群和云进行扩展，使 Kubernetes 具有弹性。
第 1 阶段：建立坚实的 Kubernetes 基础
在我们的数字优先世界中，开发人员的生产力至关重要。容器提高了生产力，因为开发人员可以更快地在生产环境中运行代码。但是当您拥有数千个容器时会发生什么？进入 Kubernetes。随着越来越多的组织开始使用 Kubernetes 和容器，他们经常了解到这个美丽的新世界需要高度的定制和调整。它还需要一种不同的思维方式——所有应用程序都设计为通过 API 进行分布式和松散耦合。虽然 Kubernetes 具有相当通用的用途并且适用于几乎所有用例，但您必须在关键领域添加功能，以保证生产环境的高效和稳定。
第 7 层流量管理
Kubernetes 通过专为第 4 层 (L4) 流量设计的 kube-proxy 提供本地每个连接的负载均衡。尽管 kube-proxy 在没有其他代理存在时多路复用到第 7 层（L7），但这是有风险的，因为 L7 流量管理（负载平衡、流量整形和其他核心功能）应该在每个请求的基础上运行。尝试将 kube-proxy 用于 L7 流量可能会导致性能下降，并且默认使用可能无法映射到应用程序级要求的连接级安全策略。为了实现生产就绪，大多数组织都受益于采用称为 Ingress 控制器的专用 L4-L7 代理。采用生产级 Ingress 控制器提供：
- 弹性，例如蓝绿部署、限流和熔断
- 安全和身份，例如 WAF 集成、集中式身份验证/授权、双向 TLS 和端到端加密
- 监控和可观察性，例如实时仪表盘和 Prometheus 指标
安全和身份
使 Kubernetes 集群足够安全以用于生产需要对开箱即用的安装进行大量修改。Kubernetes 通过 API 进行控制，并使用 API 进行所有内部和外部通信，因此必须通过控制访问和设置身份验证方法来正确保护 API，然后配置 RBAC 以授权 API 访问。特别重要的是控制对 kubelet API 的访问，它可以控制节点和容器。默认情况下，kubelet 允许未经身份验证的 API 访问。
除了 API，在实际运行时控制工作负载或用户的功能也很重要。默认授权和工作负载/用户控制是高级别的，没有针对特定的业务逻辑或安全限制进行配置。同样，在 CPU、内存或永久磁盘的数量或类型上按命名空间创建和应用资源引用限制。这也是限制任何命名空间中可以存在的服务、pod 或卷数量的好方法。其他必要的步骤包括限制未经授权的容器内核模块、限制网络访问以及正确配置日志功能都是必要的步骤。正确保护 Kubernetes 并创建自动化规则以将这些策略和实践应用于您环境中的一些工作。
监控和可观察性
随着更多移动组件的添加，并且这些组件更新得越来越快，现代应用程序需要一种不同的监控和可观察性方法。监控和可观察性层必须为所有微服务和 API 创建一个持久而灵活的视图。为确保应用程序可靠，DevOps 团队需要了解应用程序在部署和扩展时的行为方式。
您可以根据 Cluster Out 方法检查应用程序性能的各种参数；使用 Kubernetes 资源指标和 API，您可以从整体上监控和观察容器、Pod、服务和集群性能。Kubernetes 确实可以轻松利用 Prometheus，这是一个免费的 CNCF 项目，用于监控和可观察性。也就是说，为了获得最佳的监控和可观察性覆盖，您需要 L4-L7 代理、入口控制器和监控之间的紧密集成。这可能需要在 Prometheus 进行大量工作，因此您可能需要探索其他选项。
一旦您的 Kubernetes 部署是稳定的、可预测的、可观察的和安全的，那么开发人员就会看到成功。如果您在任何这些方面都失败了，现代应用程序将需要更长的时间才能推向市场——这会危及收入、客户满意度和您的品牌声誉。
第 2 阶段：在集群内外安全地管理和调整 API
我们已经讨论过设置 API 级别的安全性——这只是成功的一半。API 管理也成为一项关键的扩展技能——如果处理不当，就会成为瓶颈。当开发人员接受您的 Kubernetes Cluster Out 基础时，在您的集群上运行的微服务的数量和类型将呈指数级增长。这是我们在客户身上看到的进步。一旦你建立了坚实的基础（第 1 阶段），开发人员将部署和交付更多容器。大多数时候，这些容器代表了多种微服务。微服务和它们所在的容器必须在集群内进行“东西方”通信。在 Kubernetes（和容器）中，所有内部通信都是通过 API 进行的。
Ingress 控制器管理 Kubernetes 部署中的南北向流量，但对管理这种新模式和东西向流量的爆炸几乎没有任何作用。在大多数情况下，内部通信将使南北交通量相形见绌。这意味着管理东西向流量与管理南北向流量一样复杂，甚至更复杂。由于这只是 API 流量的另一种形式，人们会认为 API 网关是专门为此任务而构建的。事实上，API 网关是必要的，但不足以管理东西和南北流量的组合流量。因为它们最初主要针对南北流量而设计，不一定针对 Kubernetes 的实际情况（多路复用流量、不同的网络拓扑），所以许多 API 网关难以提供它们在 Kubernetes 中大规模宣传的内容。
除了 API 网关，您还需要让开发人员轻松定义、发布和管理这些内部 API 的生命周期。为此，需要 API 管理 (APIM)。传统的 APIM 解决方案不是为快速发展和快速扩展的 Kubernetes 世界和驱动大量 API 使用的东西向流量而设计的。因为它们是为数量较少的 API 而设计的，在动态性较低的基础架构上更改频率较低，因此传统的 APIM 太脆弱且通常太昂贵而无法在 Kubernetes 中有效运行。换句话说，它们不是为 Cluster Out 模式设计的。这种模式很脆弱，很昂贵，或者两者兼而有之。
换句话说，您需要一个旨在处理集群中微服务 API 的规模和粒度的解决方案，但需要一个鼓励创新和迭代的对开发人员友好的系统。值得称赞的是，Kubernetes 使默认情况下使用 HTTPS/TLS 保护所有 API 变得相对简单，选中第一个框。除此之外，APIM 在开箱即用的 Kubernetes 中仍然很大程度上是一项手动任务。这就是为什么您需要建立一个 APIM 平台，以消除 API 的结构化、记录、保护和设置规则的大部分手动工作。该平台还必须是智能的，并且比开发人员的更新速度更快。否则，API 管理团队和平台将成为瓶颈，微服务应用程序的扩展性很差。
这些 APIM 解决方案必须低延迟且易于管理，因为复杂的环境可能有数千个 API。例如，您不希望 API 网关依赖于可能无法以应用程序速度执行的数据库，从而降低应用程序性能。此外，由于大多数现代应用程序仍然必须与遗留应用程序和单体进行交互，API 网关应该足够灵活，可以为任何环境整合 API 管理，并且可以轻松地从一个环境移植到另一个环境。API 网关还需要能够支持范围广泛且不断增长的身份验证功能和通信协议。
简而言之，您的 API 网关功能与您的 L7 代理以及可观察性和监控解决方案的功能越接近和匹配，就越容易在 Cluster Out 基础上进行构建。API 是现代技术的血管系统，就像大脑和心脏管理血流以保持我们的生命一样，管理良好的 API 和管理它们的自主系统对于保持应用程序的健康和自我修复至关重要。
第 3 阶段：使集群具有弹性
实施 Cluster Out 模式的第三个阶段是确保您的基础设施足够灵活以提供弹性。现代应用程序的总体设计模式是创建分布式、松散耦合和弹性云原生应用程序。Cluster Out 必须支持弹性的关键要求。这意味着将环境设计为与云无关（尽可能）。
首先，现代应用程序必须能够跨在不同可用区、数据中心和云中运行的多个 Kubernetes 集群进行通信。这可能具有挑战性，例如，如果您的应用程序在公共云中的两个不同托管 Kubernetes 环境中运行，每个环境都与该云的安全、监控和流量管理工具紧密集成。理想情况下，弹性需要部署一个统一的、整体的管理和编排层，使环境对 DevOps、安全、API 和开发团队来说是透明且不受任何约束的。
通过启用环境多样性和跨环境编排，Cluster Out 通过分散风险和实现快速故障转移来创建更高级别的弹性。根据应用程序或服务的需求，这可能意味着在多个环境中维护实例的正常运行，并能够根据需要在每个环境中进行扩展或缩减。这里的关键是关注服务弹性。在 Kubernetes 中运行的应用程序通常是分布式微服务。从一个站点的一个集群故障转移到一个完全不同的站点的另一个集群应该在服务级别而不是修改应用程序架构。这对于创建和调整旨在满足特定 SLA 的高可用性基础架构非常重要。（注意：这对于可能面临不可预测的扩展事件的应用程序来说非常重要，例如媒体、游戏或金融服务。）弹性基线和交付它所需的控制还可以带来成本控制和性能调整等好处符合地区、国家和行业标准。
开箱即用的 Kubernetes 并不能解决弹性挑战。您需要将 Kubernetes 边界（入口控制器）自动连接到 L4 负载均衡器、应用程序交付控制器、监控和可观察性解决方案以及DNS 服务等外部技术，以路由流量并处理跨环境的故障转移。在此过程中，您需要评估什么级别的托管服务是可接受的，以及在哪里划定管理底层基础设施和优化弹性的界限。这不是一件容易的事——您可能会在具有潜在限制的云之间进行权衡。例如，Kubernetes 集群重启托管服务所需的时间在不同云之间可能会有很大差异。
实际上，大型组织将需要设计适应其全球网络、负载均衡和其他服务的现有环境的弹性和冗余。对于 web 规模的应用程序，这通常意味着 Kubernetes 及其网络层位于外围层或负载平衡器和应用程序交付控制器之后。在您的应用程序的全局视图中，为了获得最终的弹性，您需要为在 Kubernetes 中运行的微服务创建高可用性服务能力。
这转化为一个敏感的故障转移过程，该过程不断探测服务的健康状况，以识别降级或违反 SLA 的迹象。一旦指标达到某个阈值或显示记录的趋势线，服务将自动故障转移到由您的组织管理的另一个集群，无论是本地还是其他地方。实现这一点的技术是 SNI（服务器名称指示）探测，这是 Kubernetes 中相对较新的功能。SNI 功能允许您以安全的方式收集服务运行状况数据，然后使用该数据通知和配置不同集群中的故障转移系统——负载均衡器、ADC、DNS 服务器。这使您可以将集群内部世界连接到外部世界，并在全球范围内创建 HA 配置。
底线？弹性设计——无论是跨云、集群内还是桥接组织中的多个位置——有效地为基于 Kubernetes 的应用程序提供面向未来的证明，并创建多种方法来确保应用程序不会以灾难性方式失败。
遵循 Cluster Out 模式以取得 Kubernetes 的成功
Cluster Out 为平台团队和 DevOps 团队提供了一种在生产环境中强化 Kubernetes 的方法。需要明确的是，Cluster Out 仅与实际部署和实施中的执行和规划一样好。在技术基础设施快速变化的环境中，指导方法可以明确决策和优先事项。众所周知，Kubernetes 的采用具有陡峭的学习曲线——但不一定非要如此。Cluster Out 是实现 Kubernetes 成功的一种行之有效的途径，同时降低了伤害您自己和您的组织的风险。或者，正如我喜欢说的，Cluster Out 让您可以轻松运行并在最前沿进行构建，同时仍然保证您的开发人员和 DevOps 团队的稳定性。
