生产环境中Kubernetes 的使用过于复杂，早已不是新闻。在 2023 年——平台工程成为主流的这一年，容器管理的最大价值是灵活性，但其挑战在于运维策略复杂和开发者入门门槛高。（距 Kubernetes 1.0 发布）已过去了八年，使用 Kubernetes 的复杂性（尤其是在生产环境中）仍然困扰着技术人员。

软件公司 Spectro Cloud 与市场调研公司 Dimensional Research 合作发布了2023 年 Kubernetes在生产环境中的使用报告 。该项目的负责人 Spectro Cloud 的 Ant Newman 在外媒The New Stack 的采访中，讨论了Kubernetes最普遍的挑战——在接受采访的 333 位 IT 运维和应用程序开发相关者中，高达 98% 的被访者表示遇到过这些挑战。

“如果您尝试标准化，希冀同一环境中的所有应用程序使用相同的堆栈，这在当下的 IT 环境来说是不现实的，也从来都不现实。”Newman说，“我们的想法应该是如何管理多样性，而非如何限制它。”

事实上， Kubernetes 最具吸引力的功能之一是可扩展性和不同环境下的广泛用例，但其巨大的灵活性也带来了巨大的复杂性。

从企业规范到运维技术人才短缺，再到不同环境中的不一致，Kubernetes 对其用户来说是一把双刃剑，兼备灵活性与复杂性，这两大特性都对内部开发人员的工作体验产生巨大影响。KubeCon + CloudNativeCon北美站召开的同时，让我们共同思考在生产中管理 Kubernetes 的挑战。正如Newman所说，一切都是为了找到Kubernetes不受限制的管理方法。

“Kubernetes 是本人技术职业生涯中使用过的最令人沮丧、痛苦，但又最好用的东西。”

这份对于IT 运维经理的匿名调查，完美总结了用户对Kubernetes（K8s）的态度——又爱又恨。DevOps 团队希望通过这种灵活的方式来管理容器（在云中、在裸机或虚拟机上或在边缘），却很难以安全、可扩展的方式维持这种级别的复杂性。

大多数受访的企业在多个主机环境中拥有超过 10 个 Kubernetes 集群——其中，14% 的企业拥有100 个以上的集群。“（我们）必须意识到，因为每个发行版的使用模型和功能都略有不同，所以复杂性随着 Kubernetes 发行版的数量同步增加。”调查报告显示。

报告发现，83% 的受访者拥有 2 个到 10 个以上发行版本，涵盖服务发行版（如Amazon Web Services EKS-D）、自托管发行版（如Red Hat OpenShift）、特定于边缘的发行版（如 K3s 和MicroK8s）等。累计来看，单个组织约有 20 种不同的Kubernetes 使用路径。除此之外，法规制度或行业要求造成了不同版本之间的差异。

另一个运维难点是，为开发人员提供集群访问。

“我们在采访中发现，开发人员的自助服务原本是为他们提供控制权和速度，”Newman解释道。“然而问题却由此产生，开发人员必须自己维护文档、维护配置，他们不再编写软件功能，转而管理管道。”

由于运维团队无法完成日益增加的特殊需求，Kubernetes 在过去几年推动开发人员的自助服务进步后，现在开始推动规范、最佳实践和标准化的回归。Newman说，无论规模大小，所有公司都试图确定发展重点，以达成不同要求（自助服务的速度与运维控制）之间的平衡，其中可能包括：

每个组织都以不同方式在生产中使用 Kubernetes，但是受访者都在不断思考如何平衡开发人员自助服务的速度与必要的运维控制。

“尽管平台工程在过去几年取得了重要进展，且很多是最佳实践，但从受访者（开发人员）角度来看，仍有问题亟待解决，所以他们正尝试所有声称能解决Kubernetes 复杂性的工具。”Newman 说，“很多人说，他们尝试这些工具后收效甚微，就不再尝试解决这个问题——（这种做法）就像在上方直接添加一个工具，并没有实际解决控制和自助服务之间平衡的根本问题。”

事实上，14% 的受访者至少试用过一种开发者体验工具，但最后都放弃使用。

报告发现，第二大挑战是缺少能应对不断变化的 Kubernetes 环境的运维人才，而这一点又加剧了上述问题。当运维人才试图解决定期升级和修补大量解决方案的需求时，难免产生职业倦怠。

“受访者表示，他们掉进了花费时间进行故障排除和修补的恶性循环中，这意味着他们没有时间去研究最佳实践、自动化及如何简化——因为他们仅在原地踏步。”

此外，报告还发现，DevOps 已经走过了 14 个年头，开发人员仍然不习惯为代码的未来运行情况负责，并认为这会分散他们对传统开发思维的注意力。我们知道，“左移”策略转移了开发人员对流程的注意力，这推动了对Kubernetes辅助工具的“重大需求”，62% 的受访者已经或正在采用帮助开发人员利用Kubernetes的工具。

虽然 92% 的人同意开发人员应该把时间花在编写功能上，而非管理基础设施，但同时 82% 的人认为，运维团队难以为每个开发团队提供符合其偏好的集群。很明显，Kubernetes 需要一项最佳实践，或是多条实现路径，这种自由竞争的混乱局面不能再继续下去了。

尤其是在2023 年这个紧张时期，人人都想花小钱办大事，Spectro Cloud 团队看到了标准化的驱动力，它有助于提高成本效率和安全性。Newman说，只要确保你没有创建制度上的“闸门”（阻碍），就不会扼杀开发人员的创造力和实验。

所以，受访者最常遇到的挑战是如何建立企业规范。今年，这一问题首次登上Kubernetes热门问题的榜首，48% 的受访者对此问题表示不满。该报告表示，这表明 Kubernetes 的使用已经成熟，因为在关键任务、影响业务的用例中开始管理容器时，复杂性就会增加。

随着 Kubernetes 策略的扩展，实现互操作性的难度也不断增加。事实上，四分之三的受访者表示，他们至少偶尔会遇到互操作性问题，例如服务网格、持久存储和机密之间的互操作性问题。

事实上，在生产环境中拥有 20 个及以上集群的企业，由于互操作性而遇到问题的可能性是其他企业的三倍。

企业受访者对基于平台的方法仍有信心。具体来说，86% 的受访者希望将容器化工作负载和虚拟机工作负载统一到同一基础架构平台中。

值得注意的是，这种复杂性随生产集群增加呈指数级增长，拥有 20 多个生产集群的公司报告的复杂性指标明显更高。这些公司更有可能报告其拥有五个以上的分布式系统，以及超过 15 个不同的软件元素，其中包括：

“我们一直认为，Kubernetes 生产集群不仅是对发行版、CNI、CSI 以及底层操作系统的选择，”Newman 说，“80% 的价值和 80% 的复杂性都来自于你对集群中支持应用程序的内容的选择。”

它们也都大大增加了 Kubernetes 互操作性的难度。调查发现，集群越多，构成堆栈的不同元素就越多，这反过来又增加了在整个组织内实现标准化的难度。

“元素越多，出现互操作性问题的可能性就越大，需要配置和保护的工具就越多，需要打补丁和更新的东西就越多。”他继续说，“这就是全栈式声明管理如此重要的原因。”

那么如何解决像 Kubernetes 复杂性这样大规模的问题呢？运维团队如何解决开发、暂存和生产环境各不相同的问题？他们如何花更少时间排除故障，花更多时间维护可用性和应用程序性能？

超过半数的受访者认为自动化将显著提高运维效率。

然而，报告发现，“开发自动化脚本、但不将其视为基础设施重要组成部分的公司，可能会因人员变动和脚本维护知识丢失，造成巨大损失。” 这可能就是，第二个最常见解决方案是简化软件堆栈的原因——这是第二个最常见挑战（熟练运维人员短缺）的合理回应。

“如果你正在部署，就要为不同的团队、应用程序以及环境提供服务，你不一定能简化所有的堆栈。每个团队选择不同的工具或环境都是有原因的，”Newman警告说，“这就好比砍掉自己的手臂以达成减肥目的，并非正解。”

但如果企业能够真正做好自动化工作，并为未来的运维人员记录好原因和方法，就可以保持软件堆栈的多样性，同时继续扩大运维覆盖范围。

这是《Kubernetes 生产环境报告》重点关注Kubernetes 的边缘计算的第二年，边缘计算被确立为未来发展方向。边缘计算有望改进业务流程（如节约成本），并以新颖、有趣甚至超前的方式进行连接。合规性、数据安全性要求，以及只在边缘部署才能运行的新工作负载也推动了边缘计算的应用。此外，边缘人工智能也具有很大潜力。

Newman说：“边缘越发成为最佳的应用场所。”但是，由于许多企业仍在测试边缘用例，因此边缘计算的具体实现仍有待考量。

有趣的是，虽然 93% 使用 Kubernetes 的受访者正在实施边缘计算项目，但约有三分之一的受访者还不确定他们的边缘应用及使用方式。实际上，只有 7% 的受访者在生产环境中完全部署了 Kubernetes，13% 的受访者进行了部分部署，另有 29% 的受访者正在试行边缘项目。这种逐年增长的趋势表明，人们对边缘计算的兴趣可能会持续增长。

Kubernetes 已成为在边缘部署容器的事实标准，但这些发展中的边缘计算战略面临的另一个挑战是 Kubernetes 的复杂性，这一问题显现在更远的边缘。

Newman谈到，有一家客户为数千家医疗诊所提供在边缘运行应用的硬件。由于边缘计算持续宕机，他们难以及时找到技术人员前往现场处理问题。

“这些并不是在实验室（非生产场景）中进行边缘计算时所面临的挑战——穿过实验室按下按钮重启就能解决问题，”他解释说，“这些早期应用所面临的挑战是，如何让边缘计算实现经济可行，也就是边缘计算（在实际环境）应用的下一阶段。他补充道，当然，安全是最重要的。

Newman兴奋地总结道：“今年，我们发现边缘计算吸引了众多关注，这是一个快速增长、快速发展的领域，所以明年我们甚至可能针对边缘计算专门做一份单独报告。”