只要您拥有优秀的生产级 Kubernetes 环境，开发人员就愿意在这里部署更多代码。这就是我们常说的“栽下梧桐树，引得凤凰来”。您会发现，微服务和应用的数量正在快速增长，它们与集群内的其他服务、集群外的客户端和应用进行通信所用的 API 数量也是如此。内部（服务到服务）API 调用次数通常是外部（应用到客户端）调用的 10 倍或更多倍。

随着应用环境的扩张，一系列让 Kubernetes 平台无法应对的新挑战不断涌现，包括要求更复杂的 API 身份验证、授权、路由/整形和生命周期管理等。复杂的环境可能有成百上千个 API，因此拥有可帮助您对 API 进行保护、管理、版本控制和弃用的工具至关重要。在 Cluster Out 的这个阶段，您需要 API 网关、API 管理和 API 安全工具等技术，它们能够随着开发人员做出的调整持续扩展服务，并进一步增强应用功能。

第三阶段    提高集群弹性

实施 Cluster Out 模式的第三个阶段是考虑如何将 Kubernetes 环境与其他环境连接起来，无论这些环境是其他集群还是虚拟机或裸机上的应用部署。毕竟，我们现在设计的是分布式、松散耦合和富有弹性的云原生应用。

现代应用必须至少能够跨多个 Kubernetes 集群进行通信，从而实现更高级别的弹性并实施更智能的策略（例如成本控制策略）。而从广泛意义上来说，现代应用很少是孤岛。它们更有可能被融合到一个由外部服务、存储桶和合作伙伴 API（可能位于其他环境）组成的网络中。即使在内部，复杂的应用也可能需要与不同集群、可用区或数据中心的其他内部应用进行通信。

在这个阶段，开箱即用的 Kubernetes 仍然未能解决其所面临的挑战。您需要将 Kubernetes 边界（即 Ingress Controller）自动连接到外部技术，例如四层负载均衡器、应用交付控制器和 DNS 服务，从而路由流量和处理故障转移。

实际上，Cluster Out 模式只是我们从 Kubernetes 早期采用者身上看到的一个成功秘诀。作为一个优先级框架，Cluster Out 是在企业环境中大规模运行容器的逻辑和方法，能够帮助您更有效地采用 Kubernetes 和现代应用。这种方法的强大之处在于，它为平台团队提供了一种系统方法，支持 Kubernetes 在生产环境中的使用。