F5副总裁兼NGINX产品组总经理Rob Whiteley的客座文章
今年八月在NGINX Sprint 2.0上，我讨论了我们看到客户在构建现代应用程序时成功利用云原生技术的模式。他们正在将整体式架构转换为微服务，采用服务网格，并从“分布式和分离优先”的角度接近世界。我不是引入YAT（另一个术语）的忠实粉丝，但是在企业内部不断出现一个概念：“Cluster Out”。我在NGINX Sprint 2.0：Clear Vision，Fresh Code，New Commitments to Open Source中写过它。
Cluster Out不是一个全面的Kubernetes架构。它源于解决客户发现的网络和安全漏洞。它首先构建一个坚如磐石的入口/出口（北/南）和具有安全性的服务网格（东/西）。在此基础上，它解决了群集内 API 流量以及群集间路由和故障转移中出现的类似网络和安全漏洞。随着越来越多的客户在生产中支持Kubernetes，并沿着云原生的道路前进（并且随着NGINX为云原生服务的功能不断发展），我想扩展Cluster Out并进一步开发现代应用程序故事。
因为我们相信，在从 POC Kubernetes 和微服务应用程序过渡到生产部署时，开发广泛的 Cluster Out 感知将节省大量痛苦和心痛。Kubernetes 的一个奇妙之处在于，它在小型和大型规模下都能同样出色地工作。不幸的是，开箱即用的 Kubernetes 的缺点直到您开始将其投入生产并开始通过集群运行中等或重要的 L7 流量时才会显露出来。向外扩展 Kubernetes 类似于我们在 3 层 Web 应用程序的爆炸式增长中看到的情况。网络公司创建了应用程序交付控制器来保护和扩展这些快速扩展且日益重要的 3 层应用程序。
同样的模式也出现在微服务和 Kubernetes 领域。但现在，我们将应用程序的各种要求分解为特定的服务，如本地负载均衡、WAF、DDoS、身份验证、加密和全局负载均衡。我们在群集的单独部分上离散地运行每个服务。思考和设计 Cluster Out 是一种思维方式和框架，可确保你支持这些领域，这样你就不会在最重要的时候让现代应用落在你身上——在生产中，同时为现场客户提供服务。理想情况下，您应从一开始就构建 Cluster Out。可悲的是，许多公司只有在K8流量下降后才会做出反应。这就是为什么我们希望培养一种集群输出的心态，即使在POC和探索阶段建立运行在Kubernetes上的现代应用程序。
集群输出模式的三个阶段
我们在集群输出模式中看到三个阶段：
- 阶段 1：通过解决生产中 Kubernetes 的网络、可观察性和安全性来构建基础。
- 阶段 2：安全地管理和调优进出群集的 API。
- 阶段3：通过跨多个集群和云进行扩展，使 Kubernetes 具有弹性。
阶段 1：建立坚实的 Kubernetes 基础
在我们的数字优先世界中，开发人员的工作效率至关重要。容器提高了生产力，因为开发人员可以更快地在生产环境中运行代码。但是，当您拥有数千个容器时会发生什么？输入 Kubernetes。随着越来越多的组织开始快速使用 Kubernetes 和容器，他们经常了解到这个勇敢的新世界需要高度的定制和调整。它还需要一种不同的思维方式 - 所有应用程序都设计为通过API进行分布式和松散耦合。虽然 Kubernetes 是相当通用的，几乎可以适应任何用例，但你必须在关键领域添加功能，以使其为开发人员做好生产就绪和稳定。
第 7 层流量管理
Kubernetes 通过 kube-proxy 附带了本机的每连接负载均衡，该负载均衡专为第 4 层 （L4） 流量而设计。尽管 kube-proxy 在没有其他代理存在时会多路复用到第 7 层 （L7），但这是有风险的，因为 L7 流量管理（负载平衡、流量整形和其他核心功能）应基于每个请求运行。尝试对 L7 流量使用 kube 代理可能会导致性能下降，并默认为连接级安全策略，这些策略可能无法映射到应用程序级要求。为了实现生产就绪，大多数组织都受益于采用称为入口控制器的专用 L4-L7 代理。采用生产级入口控制器可提供：
- 弹性，例如蓝绿部署、速率限制和断路
- 安全性和身份，例如 WAF 集成、集中式身份验证/授权、相互 TLS 和端到端加密
- 监控和可观察性，例如实时仪表板和普罗米修斯指标
安全性和身份
要使 Kubernetes 集群在生产中足够安全，需要对开箱即用的安装进行大量修改。Kubernetes 通过 API 进行控制，并将 API 用于所有内部和外部通信，因此必须通过控制访问和设置身份验证方法来正确保护 API，然后配置 RBACs 以授权 API 访问。特别重要的是控制对 kubelet API 的访问，它可以控制节点和容器。默认情况下，kubelet 允许未经身份验证访问此 API。
除了 API 之外，在实际运行时控制工作负载或用户的功能也至关重要。默认授权和工作负载/用户控制是高级别的，未针对特定的业务逻辑或安全限制进行配置。同样，按命名空间对 CPU、内存或永久磁盘的数量或类型创建并应用资源报价限制。这也是限制任何命名空间中可以存在的服务、Pod 或卷数的好方法。其他必要的步骤包括限制未经授权的容器内核模块、限制网络访问以及正确配置日志功能都是必要的步骤。底线：正确保护 Kubernetes 并创建自动化规则以在环境中的任何 Kubernetes 集群上应用这些策略和实践确实需要一些工作。
监控和可观察性
随着更多移动部件的添加，以及这些部件的移动速度越来越快，现代应用需要一种不同的方法来监视和可观察性。监视和可观察性层必须为所有微服务和 API 创建持久而灵活的视图。为了确保应用的可靠性，DevOps 团队需要了解应用在部署和扩展时的行为方式。
您可以根据集群输出方法检查应用程序性能的各种参数。使用 Kubernetes 资源指标和 API，您可以监控和观察容器、Pod、服务和集群整体性能的性能。Kubernetes确实可以很容易地利用Prometheus，一个免费的CNCF项目进行监控和可观察性。也就是说，为了获得最佳的监视和可观察性覆盖范围，你将需要 L4-L7 代理、入口控制器和监视解决方案堆栈之间的紧密集成。这可能需要与普罗米修斯进行大量工作，因此您可能需要探索其他选择。特别是，虽然 L4 更易于使用容量的暴力解决方案进行寻址，但 L7 通常难以排除故障。部署一个解决方案，使L7对任何团队来说都很容易进行内省 - 这是Cluster Out基础的重要组成部分。
一旦你的 Kubernetes 部署稳定、可预测、可观察且安全，那么开发人员就会看到成功。如果您在上述任何一个方面都失败了，现代应用程序将需要更长的时间才能推向市场 - 冒着收入，客户满意度和品牌声誉的风险。
阶段 2：安全地管理和性能调整群集内外的 API
我们已经讨论了设置API级安全性 - 这只是成功的一半。API 管理也成为一项至关重要的扩展技能，如果处理不当，则成为瓶颈。当开发人员接受您的 Kubernetes Cluster Out 基础时，集群上运行的微服务的数量和类型将呈指数级增长。这是我们在客户身上看到的进步。一旦您构建了坚实的基础（第 1 阶段），开发人员将部署和发布更多容器。大多数情况下，这些容器代表了多种微服务。微服务及其所在的容器必须在群集内进行“东西向”通信。在 Kubernetes（和容器中），所有内部通信都是通过 API 进行的。
入口控制器管理 Kubernetes 部署中的南北流量，但对管理这种新模式和东西向流量爆炸式增长几乎没有作用。在大多数情况下，国内交通量将使南北交通量相形见绌。这意味着管理东西向流量与管理南北流量一样复杂（如果不是更复杂的话）。由于这只是API流量的另一种形式，人们会认为API网关将专门为此任务而构建。事实上，API 网关是必要的，但不足以管理东西向和南北向流量的组合流量。因为它们最初是为南北流量设计的，而不一定是针对 Kubernetes 的现实（多路复用流量、不同的网络拓扑），所以许多 API 网关都难以在 Kubernetes 中大规模提供它们所宣传的内容。这就是为什么API网关和其他Kubernetes网络组件（Ingress控制器等）的气密集成至关重要的原因。
除了 API 网关之外，您还需要让开发人员轻松定义、发布和管理这些内部 API 的生命周期。为此，需要 API 管理 （APIM）。传统的 APIM 解决方案并非专为快速发展和快速扩展的 Kubernetes 和东西向流量而设计，这些流量推动了大部分 API 的使用。因为它们是为数量较少的API设计的，在动态性较低的基础设施上变化较少，所以传统的APIM太脆弱，而且通常太昂贵而无法在Kubernetes中有效运行。换句话说，它们不是为集群输出模式设计的。这种模式是脆的，昂贵的，或两者兼而有之。
换句话说，您需要一个旨在处理集群中微服务 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 基础必须支持弹性的关键要求。这意味着设计一个与云无关的环境（尽可能）。
首先，现代应用必须能够跨在不同可用性区域、数据中心和云中运行的多个 Kubernetes 集群进行通信。这可能具有挑战性，例如，如果你的应用在公共云中的两个不同的托管 Kubernetes 环境中运行，每个环境都与该云的安全、监控和流量管理工具紧密集成。理想情况下，弹性需要部署统一的整体管理和编排层，使环境对 DevOps、安全性、API 和开发团队透明且非固执己见。
通过启用环境多样性和跨环境编排，Cluster Out 通过分散风险和启用快速故障转移来创建更高级别的弹性。根据应用或服务需求，这可能意味着在多个环境中维护暖实例，并能够在每个环境中根据需要进行纵向扩展或缩减。这里的关键是关注服务弹性。在 Kubernetes 中运行的应用通常是分布式微服务。从一个站点上的一个群集故障转移到位于完全不同站点的另一个群集的故障转移应按服务级别而不是聚合应用进行架构。这对于创建和调整旨在满足指定 SLA 的高可用性基础结构非常重要。（注意：这对于可能面临不可预知的缩放事件（如媒体、游戏或金融服务）的应用非常重要。 弹性基线和实现弹性所需的控制措施还可以带来成本控制和性能调整等优势，以及区域、国家和行业的合规性。
开箱即用的 Kubernetes 并不能解决弹性挑战。您需要将 Kubernetes 外围环境（入口控制器）自动连接到外部技术，如 L4 负载均衡器、应用程序交付控制器、监视和可观察性解决方案以及 DNS 服务，以跨环境路由流量和处理故障转移。在此过程中，您需要评估可接受的托管服务级别，以及在何处划定管理底层基础架构和优化弹性的界限。这不是一件容易的事 - 您可能会在具有潜在限制的云之间面临权衡。例如，托管服务的 Kubernetes 集群重启所需的时间可能因云而异。
实际上，大型组织需要设计适合其全球网络、负载平衡和其他服务的现有上下文的弹性和冗余。对于 Web 规模应用，这通常意味着 Kubernetes 及其网络层位于外围层或负载均衡器和应用程序交付控制器的后面。在应用程序的全局视图中，为了实现最终的弹性，您需要为在 Kubernetes 中运行的微服务创建高可用性服务功能。
这转化为一个敏感的故障转移过程，该过程不断探测服务的运行状况，以识别降级或违反 SLA 的迹象。一旦指标达到某个阈值或显示记录的趋势线，服务将自动故障转移到由组织管理的另一个群集（本地或其他地方）。实现这一目标的技术是SNI（服务器名称指示）探测器，这是Kubernetes中相对较新的功能。SNI 功能允许您以安全的方式收集服务运行状况数据，然后使用该数据通知和配置不同群集（负载平衡器、ADC、DNS 服务器）中的故障转移系统。这使您可以将集群内部的世界与外部世界连接起来，并在全球范围内创建 HA 配置。（在NGINX，我们构建了一个产品来自动发现和配置这种复杂的行为，将微服务从一个全局负载均衡器/ ADC / DNS故障转移到另一个全局负载均衡器/ ADC / DNS。
底线？弹性设计 - 无论是跨云，在集群内，还是在组织中桥接多个位置 - 有效地使基于Kubernetes的应用程序适应未来，并创建多种方法来确保应用程序不会以灾难性的方式失败。
遵循集群出模式，直至 Kubernetes 成功
在 F5，我们很荣幸能与技术领域一些最具前瞻性的组织和开发人员合作。作为这些才华横溢的建筑师和建筑商的合作伙伴，我们可以体验技术的未来，并从他们的经验中学习。我们可以与世界分享这些经验教训，以缩短学习曲线，使更多的组织能够以更少的困难和风险取得成功。
Cluster Out 为平台团队和 DevOps 团队提供了一种在生产环境中强化 Kubernetes 的方法。需要明确的是，Cluster Out的好坏取决于实际部署和实现中的执行和规划。在技术基础设施快速变化的环境中，指导性方法可以澄清决策和优先事项。众所周知，Kubernetes的采用有一个众所周知的陡峭的学习曲线 - 但它不一定是那样的。Cluster Out 是实现 Kubernetes 成功的一条行之有效的途径，同时降低了伤害自己和组织的风险。或者，正如我想说的那样，Cluster Out允许您使用剪刀运行并在最前沿进行构建，同时仍然保持开发人员，安全性和DevOps团队的安全。
