DevOps 和 Kubernetes：如何利用平台工程实现最佳实践

作者 | Tobi Knaup       译者 | 明明如月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

平台工程（Platform engineering）作为 DevOps 的替代方案已经引起了广泛关注，甚至有一些观点激进的评论家宣称 DevOps 已经过时（链接见文底），引发了一场辩论。

这些观点的出现，主要是因为原本激进的 DevOps 模式与新兴的云原生容器管理模式产生了冲突，而且，过时的 DevOps 模式正在被应用到新的模式中。下面我们来详细探讨一下。

模型的误用

容器编排平台和 DevOps 大约在同一时期出现。DevOps 的诞生是因为像 Java EE 这样的传统集中式平台无法满足希望使用新的语言和开发框架的开发人员的需求。当开发人员想尝试新的编程语言，如 PHP 和 Ruby，他们发现这些应用无法在 Java EE 上运行。这就催生了 DevOps 的基础理念——"You build it, you run it（构建代码的人需要负责让代码在生产环境中运行起来，并负责后续的维护工作）"。

DevOps 的初衷是通过自动化和消除开发到运营的隔阂，来缩短创新周期，提高灵活性，并加快软件的交付速度。然而，容器编排平台的出现，打破了这种共享所有权模型。

DevOps 倡导去中心化，而容器编排平台则是设计为集中管理以获得最大效益。容器编排平台有精心设计的 API，用以区分开发人员和运营人员的关注点。

容器编排平台的设计初衷是，由一个中心团队提供一个安全且稳健的平台，将基础设施的复杂性进行抽象处理，使得每个产品团队都可以专注于尽快地发布和改进他们的产品，而不必担心如何可靠、安全和高效地运营它们。

这与 DevOps 的理念完全相反。在某种意义上，DevOps 试图实现与容器编排平台设计目标相反的事情。那些试图采取极端做法，鼓励每个团队构建并运行自己的基础设施的公司，将会面临困难，无法充分利用这些平台所提供的价值。这样的做法可能并不是最佳选择。

效率低下的根源

传统的 DevOps 与新兴的云原生容器编排模型之间的不匹配，导致了一系列问题的产生：

过度复杂。DevOps 团队难以应对管理安全的云原生平台所需的工作负荷。Kubernetes 本身就相当复杂，要构建一个生产级别的基于 Kubernetes 的平台，我们需要引入众多插件以实现如安全性、可观察性、服务网格、应用等功能，这进一步加大了系统的复杂性。由于需要关注复杂的基础设施，开发人员几乎没有时间来开发应用程序，导致项目延误，甚至永远无法投入生产。

重复造轮子问题。每个 DevOps 团队都有自己的方式来部署和管理基础设施，这基本上等同于重复造轮子。这种缺乏一致性和标准化浪费了资源，阻碍了效率的提升和成本的降低。这种孤立的操作方式阻碍了团队间的知识共享。例如，一个团队解决了一个重要的问题，但是其他团队可能无法从中受益。

安全性和弹性问题。安全和可靠性工程需要专门的技能，许多 DevOps 团队并不具备这些技能，这导致基础设施的安全性和稳定性受到威胁。

人为编码错误高。DevOps 团队花费大量时间建立和维护用于基础设施管理的脆弱的自定义脚本，这为人为错误留下了大量空间，并且维护成本高昂。

在这种环境下，云原生项目进展停滞甚至失败，这种情况会因为多云、混合云和边缘计算环境的复杂性而更加严重，同时人工智能（AI）和机器学习等复杂工作负载也会加剧这种情况。

即使你正在使用托管的云提供商 Kubernetes 服务，这些问题仍然存在。这些服务主要提供基础的 Kubernetes，并提供有限的自动化和集群管理功能。DevOps 团队仍然需要添加大量的 Day-2 插件来创建生产环境，并且他们必须为操作工作流构建自己的自动化。

平台工程：更好的解决方案

平台工程是一个在云原生时代重新焕发活力的旧概念，被视为解决云和集群扩张、资源浪费和成本失控问题的有效手段。

容器和 WebAssembly (WASM) 提供了一个清晰的接口，使开发者可以自由选择他们喜欢的任何语言和框架（不同于 Java EE 的限制），同时也便于核心团队进行平台标准的设定和治理。

Kubernetes 的清晰容器管理接口将开发和运营的关注点分离，从而提升效率和生产力。我知道许多开发者可能会抱怨："平台团队只是想再次控制我们使用的工具，他们总是阻碍我们，拖慢我们的进度，让我们感到困扰。" 但我认为这次情况有所不同。为什么呢？因为有一个简单的约定，那就是只要能放进一个容器，它就能被部署。

云提供商的 Kubernetes 服务是为 DevOps 方法设计的。但是，那些想要为整个组织提供内部开发者平台（IDP）的团队，需要一个 Kubernetes 管理平台，这个平台能为他们管理整个 Kubernetes 集群，无论这些集群是由 Amazon EKS、Microsoft AKS 等云服务提供，还是在云之外运行。

平台工程的最佳实践

要充分发挥平台工程的优势，我们需要将部分流程集中管理，而将另一部分流程分散处理。

需要集中化和标准化的流程包括：

集群生命周期管理。拥有众多不同的集群启动方式并无实际价值，而拥有一种统一的方式则有助于简化新的基础设施提供商（如新的云服务）的接入。

安全性。维护一个安全的 Kubernetes 环境需要专门的技能，这种技能目前供应短缺。将安全专家分散到每个团队并不划算，集中化管理更为有效，可以确保共享服务，如数据库（数据库即服务，DBaaS）得到安全且适当的管理。

治理/政策管理。政策的目的在于保持不同环境的一致性。

可观察性。运维团队需要对所有环境有一个“全局视角”，这对于调试和优化至关重要。他们应希望所有的集群都能像最优秀的集群一样运行。

持续交付基础设施。最好通过声明式 APIs 和 GitOps 实现。

成本管理。最好通过 FinOps 和集成的监控和管理工具实现。

最好分散化并留给开发者决定的流程包括：

编程语言的选择

开发框架的选择

凡是可以容器化的元素，都可以由开发者自主选择和决定

黄金之路引领创新

平台工程在提供集中化平台方式和分散化 DevOps 方式之间，实现了最佳平衡。Kubernetes API 和容器提供了一个稳健的接口，使得工作分工成为可能，让双方都能专注于他们最擅长的事情。

那么，我们是否可以认为 DevOps 已经过时了呢？事实并非如此。DevOps 的理念，如通过持续集成和持续交付（CI/CD）、站点可靠性工程（SRE）和 DevSecOps 实现自动化，仍被视为产品团队的最佳实践。然而，当谈到提供一个安全、稳健、经济有效的平台，让多个团队可以在上面部署他们的应用时，平台工程的方法比 DevOps 提倡的共享所有权模型更具意义。

文中所提到观点链接：

DevOps 已经过时：https://www.cncf.io/online-programs/cncf-on-demand-webinar-devops-is-dead-embrace-platform-engineering/