翻译自 The Next Kubernetes Management Frontier: Automation 。
投资于 GitOps 就绪的中央控制平面将为组织指明下一个 Kubernetes 管理前沿的正确方向。
Kubernetes 作为核心技术已经成为现代应用架构的基础，并继续扩大其市场份额。由 Pure Storage 旗下 Portworx 进行的最近一项针对 500 名全职 IT 部门员工的调查发现，87% 的受访者预计 Kubernetes 在未来两年内将在其组织中发挥更大作用，79% 的受访者指出，在过去两年中，他们已经增加了 Kubernetes 集群的使用率。
调查结果显示，导致企业越来越依赖 Kubernetes 主要原因是需要提高自动化水平（56%），其次是降低 IT 成本（53%）、需要更快地部署应用程序（49%）以及 COVID-19 疫情推动数字转型倡议（48%）。
初步采用后，许多企业IT组织很快意识到 Kubernetes 同时是有史以来部署和管理最强大但也最复杂的平台。现在这些同样的企业正在尝试管理一系列呈指数级增长、面临前所未有规模网络和安全挑战的 Kubernetes 集群。
虽然将许多工作负载运行在单个 Kubernetes 集群中以便于管理和更好地利用资源可能感觉很直观，但我们观察到部署数量不断增加，无论是由于开发团队自己的选择，还是为了性能优化而在边缘运行工作负载以更接近用户，还是出于组织或法律原因隔离工作负载。
Kubernetes 是由一些世界上最有才华的软件工程师构建的大规模架构。问题在于它的复杂性需要熟练掌握软件工程技能，这在当今竞争激烈的劳动力市场中是一种稀缺资源。 Kubernetes 专业知识不仅难以找到和保留，而且具备这些技能的软件工程师也拥有 IT 行业中最高薪资之一。
部署 Kubernetes 集群数量呈指数级增长，并与吸引和保留内部 Kubernetes 专业知识方面所面临挑战相结合，使得小型至中型 IT 组织难以跟上 Kubernetes 集群扩展速度。市场需要更简单、更可持续地实现规模化 Kubernetes 增长，无论通过中央控制平面、自动化或两者兼而有之。
随着 Kubernetes 集群的不断扩大，需要一个中央控制平面来确保系统的各个组件能够有效高效地协同工作。如果没有中央控制平面，将很难管理和协调不同的 Kubernetes 集群，并确保应用程序从端到端运行顺畅。这也使得 DevOps 和管理员可以集中管理和控制集群。中央控制平面还需要通过以下方式考虑微服务网络：
- 从一个地方管理全球和本地流量，同时提供分布式环境的仪表盘概述，
- 以一致的方式在所有集群中全局应用流量管理规则和安全策略，并
- 提供集中式的全球服务器负载平衡（GSLB）功能，以增加跨公共和私有云覆盖多个区域的应用程序的可靠性并减少延迟。
一个带有简单易用的 Web GUI 的集中式控制计划是启动项目团队快速引导项目的便捷方式。那些刚开始使用 Kubernetes 的组织会发现这非常宝贵，因为他们仍在手工制作单个群集部署。
但是，随着组织加速采用和在生产环境中使用 Kubernetes ，多个群集的手动管理变得不可行。
在大规模部署 Kubernetes 时，有效地进行导航的唯一方法是采用正确的自动化和管理工具。
部署 Kubernetes 的组织必须使其对大多数 IT 团队中存在的管理员小军队可访问。大多数人通过 GitOps （DevOps自动化版本）寻求完全自动化和审计能力，以在多个 Kubernetes 集群上部署和管理基础设施和应用程序。
在其核心，GitOps 促进了声明性基础架构和应用程序定义的使用，这些定义描述了环境所需状态而不是实现它所需步骤。非 GitOps 方法和部署策略来配置集群并部署清单通常是分散且涉及手动干预，这会浪费工程师时间并延长扩展过程。
GitOps 解决了管理和部署基础设施和应用程序的问题，以一致且可重复的方式进行，并具有更容易协作（带有完整审计跟踪）、版本控制和回滚变更的能力。通过利用符合GitOps标准的工具，应用团队可以利用自动化 Kubernetes 集群的自我修复、自动扩展和可观测性，并创建一种将安全性和可观测性标准纳入其中的一致方法。
无论最初采用背后的动机是什么，显然 Kubernetes 现在已成为IT景观中不可或缺的组成部分，因为集群越来越多地部署在从网络边缘到云端等各个位置。投资于一个 GitOps-ready、中央控制平面将指引组织朝着下一个 Kubernetes 管理领域迈进正确方向。