了解构建基于 Kubernetes 的开源内部开发者平台的步骤，以及为何你应该投资平台工程来打败运维散乱。
译自 A Guide to Open Source Platform Engineering 。
毕尔巴鄂 - 2023 年平台工程的兴起是摆脱背离开发人员自治的一部分，但并非完全回归瀑布式命令与控制。我们希望开发人员保留他们的选择感，鼓励这些富有创造力的工作者的问题解决能力。但我们也希望减少工具散乱，以及随之而来的成本和风险。
本周在 Linux 基金会的欧洲开源峰会上，开源社区成员着重强调使用开源栈完成工作的入门方法。这包括 Gedd Johnson，一名在 Defense Unicorns 工作的全栈工程师，这是一家为美国国防部等构建开源 DevSecOps 平台的咨询公司，他讨论了如何跟上这一平台工程的最新趋势。
最重要的是，Johnson 的演讲展示了如何利用开源平台工程的优势，描绘了一个完全基于自由和开源软件构建 Kubernetes 基础平台的示例。
“采用 DevOps 文化意味着团队对整个软件生命周期有完全的所有权，”Johnson 说。“团队在整个技术栈上都很熟练，”他们选择了适合其独特情况的栈。
但是，伴随大自由度和责任而来的是巨大的低效。
“如果你有采用 DevOps 文化的各个应用团队，他们从端到端拥有自己的流程，这些团队有倾向无意中将自己隔离开来，”他说。 “如果发生这种情况，你可以确信多个应用团队将重复解决同样的问题，且不一定局限在应用代码层面。”
他给出了在亚马逊网络服务(AWS)上构建的这样一个组织的例子。
“在 AWS 上部署的一种非常流行的方法是使用弹性容器服务(ECS)。如果你有多个使用 ECS 的应用团队，而这些应用团队相互隔离，你可以确信他们都会以自己的方式解决在 ECS 上部署应用的问题，”Johnson 说。
一些应用团队可能会采用 TerraForm 的基础设施即代码方法。其他人可能只是通过 AWS 控制台“点击操作”，滚动浏览菜单以找到合适的选择。每个团队在其应用前都可能使用负载均衡器，但可能出于不同原因选择不同的负载均衡器。
“即使只看一个 AWS 服务 ECS，也有多种不同的做事方式，我只是谈论 ECS，”他观察到。“在整个 AWS 中，有数百种部署应用的方法，如果没有任何组织级指导和意见，你最终会出现所谓的运维散乱。”
Johnson 将运维散乱定义为云环境过载重复且稍有不同的工作，通常没有选择工具或流程的初衷背景。这种散乱发生在所有这些意外的筒仓之间 - DevOps 诞生的讽刺结果，其目的是打破筒仓。
“这也很可能非常昂贵，因为你的云账户中可能存在大量闲置的资源，”他继续说道。 “最后，如果每个应用团队都有自己独特的部署流程，意味着你的安全和合规工程师必须重新认证这些独特的应用，那么安全性和合规性尤其困难。”
每个人对平台工程的解释都不同。Johnson 说：“平台工程的目标是标准化部署和操作应用以及其基础设施的过程。” 平台策略从发现每个应用团队使用的各种工具和流程开始，然后“对部署应用和操作其基础设施的最佳、最强大和最相关的上下文方法形成意见”，从而确定、实施和自动化通往生产的黄金路径。
除了黄砖块，黄金路径还包括什么？Johnson 说，这可以从创建可重用的持续集成流水线开始，这些管道强制执行静态代码分析和依赖项扫描，一直到通过“将应用程序范围限定为使用运行所需的最少权限集”来简化您的(可能非常昂贵的) AWS 帐户。
现在，如果你已经在 The New Stack 上阅读了一段时间，你会知道内部开发者平台如果是自上而下的举措就不会成功 - 这绝对是制定你的工程师不想要的计划的良方。因此，在内部启动平台作为标准化和意见领导时，您必须小心 - 因为它开始使人们“正当地”担心他们的自治正在被剥夺 - 毕竟，在 DevOps 世界中，他们的团队拥有全部控制权。
“平台工程似乎要夺走这种自由，回到一个其他团队在没有适当的上下文的情况下决定应用团队如何做事的世界，”Johnson 警告说。“事实上，平台工程的关键在于平衡你给予开发者的自由度与平台的基本意见。”
或者，正如 Spotify 所说，标准可以令你自由。
为了让你的 DevOps 驱动的应用团队买入这个新的伪自由，你需要向他们解释什么是平台工程 - 作为一个新兴学科，行业还没有在内部开发者平台(IDP)的单一定义上达成一致。
“简单来说，平台只是应用程序在生产环境中有效运行所需的一组基础服务和功能，”Johnson 说。平台驱动的自动化使做正确的事变得非常容易，做错误的事变得非常困难。
尽管每个 IDP 都应该基于您的运维扩展爬行结果的自然唯一性，但他的团队已经发现了完全免费开源平台工程策略所涉及的一定模式。Johnson 向我们介绍了在前端和后端层面上，您希望您的应用团队专注于为最终用户提供价值时需要构建什么。
监控和可观测性需求在您的组织中可能是相同的，这是开始您的平台之旅的公平之处。
“当这个应用被部署时，工程师会想知道它是否真的被部署了，它是否健康，是否可达，以及这个应用的性能如何，”Johnson 说，这就是为什么在最低要求中，任何抽象都必须包括保证和健康检查、连接监控和“类似 CPU 和网络方面的一些定量洞察应用性能”。
他建议使用 Kubernetes dashboard Metrics Scraper 来实现这一点。
Johnson 说，工程师将希望实时查看日志，以及查询历史日志，这意味着您需要日志栈。 “应用程序会向特定目录发出日志，我们需要日志扒手从该目录获取日志，然后将它们转发到日志数据库。”
Logalyzer 和 OmniSci 是流行的开源日志扒手。
然后，您需要仪表板，以便工程师轻松查看其日志记录和监控。 Johnson 说，为了安全地做到这一点，这需要使用 TLS 进行网络加密。 每个应用程序可以实现自己的 TLS，或者您可以指向某个中心化证书颁发机构或 CA 服务器，然后手动传递证书 — 但任何手动操作都会导致您的运维散乱。 因此，他提供了添加服务网格的替代方法，该服务网格执行相同的功能，而无需接触应用程序代码。
负载均衡器和 DNS 记录将通过创建公共接口使应用程序可供其最终用户访问。
这将决定您的平台工程策略的成败。 此开发者门户应启用自助服务，以便开发人员弄清楚他们需要做什么。 它还应提供一种在一个地方轻松查看所有这些仪表板的方法，并随时为他们提供应用运行状况的快照。 此外，此开发人员门户使他们可以看到其他团队在做什么以及谁拥有什么，为跨组织提供清晰度并启用重用。
内部开发者门户应该让他们相信平台工程是前进的方式，并让他们真正采用它。
“随着更多用户与应用程序和平台进行交互，我们可能想要一些机制来扩展和缩减这些各种资源，”Johnson 说，“以便我们可以有效利用底层计算能力运行它们。” 他建议使用 Kubernetes 资源缩放器。
“在某个时候，应用程序或这些平台组件中的一个会有一个 0-day 关键安全漏洞，这个系统将被黑客入侵，”他警告说。 这要求运行时安全组件来识别此漏洞并警告团队。
选择免费开源软件并不典型的免费，无论是时间还是精力。 “基本上有无数移动部件和技术决策你必须做出来构建你的应用开发者实际想要使用的东西，并且它很容易操作，”Johnson 说。 这就是为什么许多组织选择直接外包给他们的云提供商。
然而，在 Defense Unicorns 正在工作的高度规范化、出口受限的环境中，三大提供商提供的可能还不够，这将迫使您构建自己的平台。
好处是，通过选择开源路线，您能够避免供应商锁定。
Defense Unicorns 选择使用 Kubernetes 构建他们的开源堆栈，他称之为平台工程的基石 - 以及通常触发采用平台路线。
“在其核心，Kubernetes 所做的就是提供一个非常强大和可扩展的 API 来管理容器。这个 API 非常受欢迎，以至于 Kubernetes 已经成为部署容器的事实标准，无论是本地还是云端。” 但 Johnson 警告说：“当您选择采用 Kubernetes 时，您的云提供商曾经为您提供的许多平台组件现在您要拥有、操作和维护并更新它们。”
这就是为什么他建议有一个专门的平台工程师团队来构建和维护-当然还要与他们的内部应用开发客户保持紧密的反馈循环。 但他认为，好处通常超过成本，因为“使用 Kubernetes 作为基础，我们可以使用完全免费和开源软件来构建整个系统”。
Johnson 在峰会上与 OS Summit 共享了国防部的 Platform One DevSecOps 计划创建和外包的 Big Bang。 “Big Bang 是一个开源的基线声明，用于创建一个安全的基于 Kubernetes 的平台，”他说，这是美国空军创造的。
Big Bang 旨在采用最广泛使用和采用的开源组件，并将它们打包成一个可以一起部署的 Helm Chart。 所包含的这些免费开源工具包括:
- 日志记录堆栈 - Promtail 和 Grafana loki。
- 监控栈 - Prometheus。
- 仪表板 - Grafana。
- 服务网格 - Istio 用于保护平台组件之间的流量以及集群的出口流量。
- 运行时安全性 - NeuVector，用于监控集群异常或入侵。
- 资源缩放器 - Kubernetes。
- 持续交付 - Flux，其中具有 Helm 版本的概念。
- AWS EKS 集群。
- EBS CSI 驱动程序。
本质上，Johnson 解释说:“Big Bang 本身就是一个由所有这些各种平台组件的 Flux Helm 版本组成的 Helm Chart。” Big Bang 提供了默认配置，该配置会自动连接许多平台组件。
他在台上进行了现场演示，在几分钟内就能检查不到 50 个 pod 和虚拟服务的运行状况和连接性，包括 CPU 和内存利用率。
“你有所有这些花哨的图表向你的老板展示，我在这里检查的只是确认指标数据确实被计算和收集，我们可以查看它，所以现在对于日志，我们可以做的是转到 Grafana 的这个资源管理器选项卡中，”Johnson 说。 此外，使用此开源平台工程堆栈，您可以查看最新日志并查询历史日志。
您在发现模式下训练 NeuVector 一段时间，然后将其切换到保护模式，“它将使用在发现模式中学习的启发式方法来检测各种异常和入侵，您甚至可以将其设置为自动中和某些行为。”
国防部是一个庞大的组织，这使得它在数百个账户中遇到大量的运维散乱不足为奇，每个应用团队都拥有自己的流程，可以随心所欲地做任何事情。
另外，这些应用程序在高度规范化的环境中运行，处理高度敏感的数据。 任何基线体系结构都必须符合跨数百个应用团队的 NIST 800-53 要求。
“由于这种运维散乱，安全团队需要花费大量时间来认证这些应用在各种规范环境中运行，”Johnson 说。
他们实际上能够在 6 个月内构建和部署他们的开源内部开发者平台。
不过，与大多数 IDP 一样，主要目标是是否被采用。 Johnson 说，内部开发者平台必须具备两点：
- 它应该使开发人员的生活更轻松。
- 它应该增强工作流程。
“如果平台没有做到这一点，那么从根本上说我们错过了目标。”
采用过程中也有一些阻碍。首先，他们意识到，虽然许多团队在云端运行 AWS，但很少实际上是容器化的 - 这是在 Kubernetes 中运行的先决条件。大多数要么在虚拟机中运行，要么完全是无服务器使用 lambda。
因此，在向人们推销平台之前，他们实际上需要团队投入一些工程周期进行容器化 - 大多数团队不愿意这样做。
“在一开始，我们更多地将这个平台营销给安全和合规工程师，并真正突出自动满足所有这些安全控制的价值主张。所以对实际的应用开发者的重视度较低，”Johnson 承认。
为了让应用团队上船，他们决定内部开源工作，“然后邀请他们来与我们一起构建，并鼓励这些社区采用，并对我们正在构建的内容保持透明。”
而与此同时，即使运维散乱开始得到控制，Johnson 的团队仍然必须运行和管理Kubernetes 和 Big Bang 的近 50 个pod。“当我说管理时，我的意思是检查镜像更新等事项，以及重构上游 Helm Chart 的任何重大变更及其值-这种情况比你想象的要常见得多。”
他会发现自己第十次重构 AWS 在多种日志记录方式上的日志记录部分。
“根据团队移动的速度和所做更改的数量，运行自制的基于 Kubernetes 的平台的运营开销可能相当荒谬，”Johnson 说。“所以在那里学到的教训是，在架构平台时，不要忘记权衡运营开销。”
不要假定 Kubernetes 适用于所有组织和所有平台——要有基于数据的明确的对 Kubernetes 的需求。一旦您承诺使用 Kubernetes，就很难抽身出那个技术决策。
最后，最初构建的 6 个月转化为 1 年。他了解到最好的平台来自前期广泛的用户研究，然后构建得更小、失败得更快。
最后，Johnson 建议平台团队关注问题，而不是技术：“所有这些流行词试图解决的核心问题类似于，我们如何使软件开发更轻松，我们如何构建更好的产品？”