平台工程解Kubernetes之痛

让我们来看一下现代云原生环境中的开发人员的处境：无论从数量还是复杂性来看，工具环境都在快速增长。组织的工程设置通常要求开发人员不仅要对Kubernetes有端到端的了解，还要对基础设施供应、部署管道和配置管理有了解。在过去的10年中，开发人员对软件交付过程中越来越多的部分负责。

所有这些转变都给开发人员带来了认知负担。而且，正如许多开发人员现在在Twitter、Reddit和会议上分享的那样，这种认知负荷正在干扰他们执行最重要任务的能力：运送功能。

对于开发人员来说，Kubernetes是这堵复杂性墙中的一块砖。因此，在本文中，我们将讨论组织在Kubernetes中遇到的具体问题，以及它们如何适应平台工程旨在解决的DevOps采用的更大问题。

管理不当的期望

许多Kubernetes的痛苦都是管理不当的预期造成的。一些组织希望Kubernetes易于使用和维护，它将为组织节省资金，并且不受云供应商的限制。他们没有意识到的是，要实现潜在的利益，他们仍然需要先决条件的功能系统和安全专业知识，这些系统和专业知识以前由多个拥有不同职业道路的人所有。

如果没有强大的配置管理、适当的文档以及与CI/CD系统的成熟集成，实现Kubernetes（或任何其他技术）变得非常困难。你必须第一时间获得正确的技术实现细节。

平台工程并不是一根魔杖，它不会使这一基本需求消失。然而，构建平台所需的产品方法可能有助于认清组织尚未完全准备好支持Kubernetes的领域。

如果你还没有采用Kubernetes，那么进行用户研究和建立强大的反馈循环也可能有助于为Kubernete将为组织做什么设定更现实的期望。

缺乏开发人员信心

在一些DevOps设置中，开发人员缺乏信心。他们害怕每次接触Kubernetes相关的交付设置时都会破坏东西。

但如果不想降低速度，则需要为Kubernetes设置实现真正的自助服务。开发者自助服务意味着工程师可以自行调配和使用测试、保护和部署应用程序和服务所需的技术，而无需等待Ops提供资源或启动环境。这并不一定意味着开发人员需要掌握整个工具链。

内部开发人员平台提供了抽象级别，降低了开发人员完成工作所需的Kubernetes专业知识水平。同样，启用开发人员自助服务并不意味着任何开发人员都应该能够影响生产基础设施。事实上，精心设计的平台允许开发人员花更少的时间摆弄基础设施，更多的时间交付功能。

当涉及到重复性任务，如开发新功能或预览环境时，启用开发人员自助服务对于节省团队时间和资源至关重要。如果没有它，组织可能会产生更多的瓶颈和关键人员依赖，这会降低其交付周期、部署频率和新功能和创新周期的上市时间。

在Humanitec的2022年Kubernetes基准研究中，我们发现，在DORA指标方面表现出色的团队也支持开发人员自助服务。在73.4%的团队中，开发人员可以为特性和预览环境提供Kubernetes命名空间。

此外，89.1%的高绩效团队中，开发人员能够根据需要独立部署到开发或staging。而这仅适用于32.9%的低绩效团队。此外，近三分之一的低绩效员工报告说，尽管理论上组织中的每个人都可以部署到他们的Kubernetes集群，但害怕犯错会让很多人无法坚持到底。

在这些设置中，提前期增加，部署频率降低。这些团队需要能够充满信心地部署。内部开发人员平台可以提供开发人员在与Kubernetes交互时更自信所需的支持（以及使Ops更自信的护栏）。

不能一招鲜

平台工程的兴起反映了开发和运维之间的关系出现了一定程度的断裂，这是由组织复制和粘贴一种通用的DevOps方法而导致的断裂。在DevOps拓扑中，Matthew Skelton和Manuel Pais概述了许多组织在尝试实现DevOps时遇到的一些反模式。

当组织决定不再需要专门的Ops角色时，就会出现一种反模式。他们无意中将这些任务传递给有经验的开发人员。这错误地分配了组织中一些最宝贵的资源，并造成了DevOps引入来解决的更多低效问题。Humantec的2021 DevOps基准研究发现，在44.9%的案例中，高级开发人员接管了运维角色，以帮助经验不足的开发人员。

这种所谓的“影子运维”模式造成了各种各样的效率低下。显然，许多组织都在努力以与其团队和现有资源兼容的方式实施DevOps原则。

平台工程通过采用产品方法来避免这种陷阱。对于内部开发平台，开发人员是客户。平台团队通过进行用户研究和定期征求反馈，全面了解其开发人员的需求。这种沟通方式是平台团队如何决定首先构建哪些功能，以及他们需要迭代平台的哪些方面。

产品方法还需要了解不同的利益相关者群体，并向他们推销平台。这确保了平台不会因缺乏采纳或高管支持而失败。如果做得正确，产品方法应该能够揭示开发人员在Kubernetes中遇到的困难，以及他们需要什么样的抽象才能成功。

对于Kubernetes，内部开发平台也可能会缓解开发和运维之间的紧张关系。该平台取代了DevOps工程师所做的大量（但不一定全部）临时工作。这些人有机会过渡到平台工程角色，并将他们的专业知识转化为整个组织更好的开发人员体验。

开发人员可以花更多的时间编写代码，而不必花更多时间摆弄基础设施和其他Ops任务。运维可以向上游转移到更关键的任务，如管理网络或物理硬件。或者，他们也可以成为平台工程师。总体而言，内部开发人员平台使开发人员和运维人员能够专注于其工作的核心职责和优势。DevOps工程师在整个组织中产生更广泛的影响。

结论

当谈到Kubernetes的成长之痛时，平台工程并不是灵丹妙药。然而，平台工程嵌入了实践和方法，可以帮助组织避免或减轻经常出现的挑战。