2023年Kubernetes生产环境使用状况报告

在生产环境中使用Kubernetes的企业,仍在努力在灵活性和复杂性之间找到平衡。Spectro Cloud发布的2023年报告为您揭开生产环境Kubernetes使用的现状。

译自 The 2023 State of Kubernetes in Production

生产环境Kubernetes的使用过于复杂,这已经不是新闻。但在2023年,平台工程成为主流的一年中,容器管理领域最大的痛点可能是Kubernetes的灵活性,但在运维的策略和治理以及开发者的入门方面仍存在许多挑战。8年过去了,使用Kubernetes的复杂性,尤其是在生产环境中,仍然是一个巨大的难题。

Spectro Cloud最近与Dimensional Research合作发布了2023年生产环境Kubernetes使用调查报告。Spectro Cloud的项目负责人Ant Newman在接受The New Stack的独家采访时讨论了一些最普遍的挑战——调查的333位IT运维和应用开发相关人士中,高达98%的人表示遇到过这些挑战。

“如果你试图使所有应用程序标准化,拥有相同的技术栈和环境,这在今天的IT环境下是不现实的,也从未现实过,”Newman说,“关键是要找到如何管理多样性的方法,而不是如何限制它。”

的确,Kubernetes最大的吸引力之一,就是它在不同环境下的可扩展性和广泛的使用场景。但伴随巨大的灵活性就是巨大的复杂性。

从企业规范到运维人才短缺到不同环境的不一致性,Kubernetes用户正在处理同一个问题的两面——灵活性与复杂性。这两者都对内部开发者体验有巨大影响。随着KubeCon + CloudNativeCon北美站的召开,让我们反思管理生产环境Kubernetes的挑战。就像Newman所说,关键是找到管理的方法而不限制Kubernetes。

Kubernetes的复杂性带来后果

“Kubernetes是我技术职业生涯中使用过的最令人沮丧、痛苦和美好的东西。”

这份来自一位IT运维经理的匿名但坦率的调查反馈很好地总结了情况。用户与Kubernetes之间有着爱恨交织的关系,或者如果你在互联网的某些地方很酷的话,简称K8s。DevOps团队想要这种灵活的容器管理方式——在云中、裸机或虚拟机上,或者在边缘上,但他们正在努力以一种安全、可扩展的方式维持这种复杂性。

大多数受访企业在多个主机环境中拥有10个以上的Kubernetes集群——14%的企业拥有超过100个集群。“复杂性随着Kubernetes发行版的数量成正比增长,每个发行版都有略有不同的使用模型和功能,需要进行理解,”报告解释道。报告发现,在受访者中,83%的企业在不同的服务发行版(如AWS EKS-D)、自托管发行版(如Red Hat OpenShift)、面向边缘的特定发行版(如K3s和MicroK8s)之间有2到10多个发行版。

这意味着单个组织大约有20种不同的记录在案的 Kubernetes 使用途径。此外,这些差异中的许多都是由于法规或行业要求。

向开发人员提供集群访问是另一个真正的运维痛点。

“我们在访谈中发现,首先要实现开发人员的自助服务,以赋予他们控制权和速度,”Newman对The New Stack说。“然后你会意识到这正在引起问题,或者开发人员现在必须维护文档、维护配置,突然之间他们不再开发新功能了。他们正在管理管道。”

因此,在Kubernetes推动开发人员自治权的进步后,现在它正在推动回归限制、黄金路径和标准化,因为运维团队无法跟上独特需求的步伐。调查发现,所有规模的公司都在努力确定钟摆应该摆放的位置,Newman说,每个公司在控制与自助服务之间决定不同的平衡,这可能包括:

  • 每次启动集群
  • 在运维团队拥有的基础设施上部署
  • 开发人员在云中或家庭实验室中运行集群
  • 多云
  • 通过内部自助门户
  • 向运维团队提出请求

每个组织都有自己的一种或多种在生产环境中使用Kubernetes的方式,但他继续说,他们访问的每个组织都在不断权衡开发人员自助服务的速度与必要的运维控制之间的平衡。

平台工程不是灵丹妙药

“这里仍然存在需要解决的问题。尽管过去几年在平台工程方面取得了重要进展,这被视为黄金道路,但我认为受访者并不认为这个问题已经解决了。这就是为什么他们正在尝试所有这些承诺简化Kubernetes开发人员复杂性的工具,”Newman说。 “但是有相当一部分人说我们正在尝试这些东西,并且由于没有起作用而停止了尝试——几乎就像在顶部添加另一个工具实际上并没有解决控制与自助服务之间平衡的根本问题。”

的确,14%的受访者曾试用至少一个开发人员体验工具,后来停止使用。加剧这一点的是,报告发现的第二大挑战是缺乏能够处理不断发展的Kubernetes环境的运维人才。由于试图跟上对定期升级和修补这些解决方案大杂烩的需求,运维人员的压力是真实的。

“受访者表示,他们陷入了花时间排查故障和修补的恶性循环中,这意味着他们没有时间投资建设黄金路径、投资自动化以及研究如何简化,因为他们只是在原地踏步,”他继续说道。

此外,在DevOps推行14年后,开发人员仍然不习惯对他们的代码未来如何运行负责,并感觉这可能会分散他们的传统开发心态,报告发现。我们知道著名的左移使他们的注意力从流动状态转移。这驱动对帮助开发人员利用Kubernetes的工具有“重大需求”,62%的受访者已经采用或正在采用用于应用程序开发人员的工具。然而,虽然92%的人同意开发人员应该把时间花在编写功能上,而不是管理基础设施上,但82%的人说运维团队为每个开发团队提供定制的集群是很困难的。显然,Kubernetes需要一条黄金路径,或者通往生产环境的几条路径;这种自由放任不能继续下去。

特别是在2023年更加紧张的时期,每个人都在努力以更少的投入做更多的事情,Spectro Cloud的团队看到了对标准化的更大推动,以帮助提高成本效益和安全性。Newman说,只要确保你不要创建障碍,扼杀开发人员的创造力和实验精神。

这就是为什么受访者遇到的最常见挑战是如何建立企业监管措施。这是这个挑战首次排在首位,48%的人抱怨过它。报告说,随着在关键任务和影响业务的用例中管理容器的复杂性增加,这指出了Kubernetes采用的成熟性。

互操作性的挑战

随着Kubernetes策略的扩展,互操作性也变得更具挑战性。事实上,有四分之三的受访者表示,他们至少偶尔会遇到互操作性问题,如服务网格、持久存储和机密之间的互操作性问题。

事实上,拥有20个或更多生产集群的受访者由于互操作性问题遇到故障的可能性要高出3倍。

企业受访者在一些方面仍然确信基于平台的方法是可行的。具体来说,86%的人希望将容器化工作负载和虚拟机工作负载统一到单一的基础设施平台中。

值得注意的是,这种复杂性会随着公司拥有的生产集群数量的增加呈指数级增长。拥有20多个生产集群的公司报告的复杂性指标明显更高。这些公司更有可能报告它们拥有5个以上的发行版,以及另一个挑战,即超过15个不同的软件元素,包括:

  • Ingress
  • 负载均衡器
  • 机密管理
  • 安全工具
  • 服务网格
  • 监控和可观测性

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

所有这些都使Kubernetes的互操作性变得极具挑战性。调查发现,您拥有的集群数量越多,堆栈中包含的不同元素就越多。这反过来使得在整个组织范围内实现标准化变得更加困难。

“元素越多,互操作性问题的机会就越大。需要配置和保护的工具越多。需要修补和更新的东西越多,”他继续说道,“这就是为什么全栈声明式管理如此重要。”

自动化降低复杂性

那么,如何解决 Kubernetes 复杂性规模如此之大的问题呢?运维团队如何解决开发、测试和生产环境不同的问题?他们如何花更少的时间排查故障,更多时间维持可用性和应用性能?

超过一半的受访者认为,自动化可以显著提高运营效率。

然而,报告发现,“开发自动化脚本但不将其视为基础设施必不可少的一部分的公司,在员工变动并丢失了维护脚本知识时,可能会陷入噩梦之中。” 这可能是第二大解决方案是简化软件栈的原因,这是对第二大挑战即运维技能人员不足的逻辑回应。

“如果您正在部署服务大量不同的团队和应用程序以及不同的环境,您不一定能够大幅简化栈。每个团队选择每个不同的工具或环境都有原因,”Newman警告说,“这几乎就像,我们如何减肥?砍掉我们的胳膊。这不是正确的答案。”

但是,如果一个企业真正做好自动化工作 —— 并为未来的运维人员记录为什么和如何 —— 他说,您可以在保持软件栈多样性的同时扩展运维覆盖面。

边缘环境下的Kubernetes管理

这是生产环境Kubernetes报告第二年聚焦边缘计算Kubernetes,这已经确立为发展方向。边缘计算通过降低成本、建立新颖的连接等改进业务流程,还能满足合规性、数据安全要求,并支持只能在边缘部署的新型工作负载。边缘计算在AI方面也有很大潜力。

“越来越多情况下,边缘是最佳选择,”Newman说。但大多数企业仍在实验边缘用例,需要探索实现路径。

有意思的是,尽管93%使用Kubernetes的受访者都在开展边缘计算项目,但约三分之一的受访者对其边缘应用和如何应用还不确定。事实上,只有7%的人已经将Kubernetes完全部署在生产环境的边缘,另外13%部分部署。还有29%的人正在试点边缘项目。与去年相比,对边缘计算的兴趣正在增长,这种趋势可能会持续。

Kubernetes已成为在边缘部署容器的事实标准,但渗透这些新兴边缘计算策略的另一个挑战再次是Kubernetes的复杂性,这次是在远程边缘。

Newman谈到一个为成千上万的医疗诊所提供边缘应用硬件的客户。由于边缘持续出现宕机,他们难以及时派技术人员出勤维护。

“这些不是您在实验室中进行边缘计算时会遇到的挑战——重启只需走过实验室按下按钮,”他解释说。这些早期采用的挑战在于如何使边缘经济上可行——边缘计算采用的下一个阶段,在实际环境中。当然,他继续说,安全至关重要。

Newman兴奋地总结说: “今年,我们看到边缘计算出现了巨大的兴趣,我认为明年的报告我们可能会单独发布一份关于边缘的报告,因为这是我们发展最快、变化最快的领域之一。”

Posted in k8s

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注