解锁你的技术仙境：GitOps、平台与AI的结合

在过去几年里，我见证了各种技术的兴起和消逝，并陪伴许多人和企业走过他们的云原生之路。经常听到这样的问题：“为什么Kubernetes这么复杂？”和“为什么没有一个解决方案能够应对XYZ问题？”与此同时，平台工程和AI正在兴起，我认为这三个话题之间有联系，让我们更深入地探讨一下。

Kubernetes 是一个编排器，它帮助我们构建应用的基础设施，而无需关心基础设施的底层细节。当我们打开一些灯时，我们（尤其是像我这样的老系统工程师）可能会发现很多熟悉的东西。

• 系统中常见的操作流程的抽象： 在 Kubernetes 中创建对象时，我们仅描述过去的操作。例如，在创建一个 ingress 对象时，我们要求系统，“请配置反向代理，将符合此模式的流量转发到此服务。”当创建 pod 对象时，我们给系统指令，创建一个 Unix 命名空间，将进程包裹在其中，并设置一些环境变量，例如环境变量、请求、限制等。
• 容器： 容器的概念并非完全新颖，也没有什么神秘之处。我们熟悉了这一概念通过 BSD jails，使用 OpenVZ 或 LXC 创建了容器，最终 Docker 让容器技术大放异彩。
• 可扩展性和弹性： 作为一名系统工程师，我经常需要让系统更弹性、更可扩展。围绕这些方面，我们构建了一些冒险的结构；我认为我们中许多人处理过集群管理器、负载均衡、复制和心跳机制。虽然它们做得很好，但配置起来却并不总那么简单，而且经常由配置问题引起麻烦。这感觉很熟悉，是吧？

当我开始接触Kubernetes时，我注意到了以往存在的这些问题，并发现它解决了其中许多问题。例如，用一个简单的配置文件就能在多个节点间平衡服务，并且能够自动将基础设施扩展到数百个节点，无需手动操作。事实上，这些背后的许多机制可能看起来有点吓人，但最终，学习和应用它们实际上相当直接。

如图1所示：用一个资源配置很多东西

如上图所示，这段图片展示了使用Kubernetes可以实现的一些自动化。这个例子说明你可以用一个清单文件来指示多个组件完成它们的任务。比如，将会创建一个进入集群的入口路由；一个TLS证书会被颁发，顺便也会为某个主机名创建一个DNS名称。显然，这需要一些配置，但显然，这需要一些配置工作，但老实说，这比之前提到的例子要少得多。最终，它以非常简单的方式使复杂的事情变得容易使用。

几年前，Kelsey Hightower 在一篇帖子中写道：

“Kubernetes 是一个用于构建平台的平台。它更像是一个更好的开始，而不是最终的目的地”。 (Hightower, 2017)

对我来说，这其实意味着我们可以在上面部署应用，使用Kubernetes，但实际上，如果我们把它看作一个帮助我们构建平台的工具，我们能从中获得更多，这就带我们来到了第二个问题：

为什么解决XYZ问题不止一种方法？

随着时间的推移，形成了一个庞大的生态系统，围绕Kubernetes和云原生技术，许多工具帮助人们轻松解决了各种问题。如图1所示，通过ingress对象配置入站网络流量，或者通过Kubernetes控制器请求证书或配置DNS条目如今变得非常简单。随着时间的发展，许多工具加入了生态系统，人们常常会疑惑为什么会有这么多看似解决相同问题的工具。

图2：部分CNCF全景（部分）

在阅读G. Hohpe的《云策略》这本书时，我发现了一段关于为公司找到合适的云服务商的引用：

“因为传统的评分方法不太适用于云服务，更好的办法是将你公司的愿景与供应商的产品策略和方向进行对比。”（霍普，2020）

我觉得对于云原生的领域（见图2），你有很多选择；有些可能更符合你的需求（和战略），而有些则不然。例如，你可以选择一个遵循经过深思熟虑且有明确观点的方法或工具，但同时可能也有工具能更好地支持你的业务，让你可以自行配置或实现自己的想法。此外，这一切可能都与支持有关。因此，即使是最优秀的社区驱动的开源项目，也可能因公司政策要求全天候供应商支持而无法满足你的需求。

我觉得很容易想象我们可以一直这样下去，但每个工具都带来了更多的想法，提供了更多的选择（虽然你并不总是需要它们），并帮助你构建一个坚实的应用基础。说到这里，我想进入我最喜欢的环节：平台工程。

在前两节中，我解释了为什么人们认为Kubernetes非常复杂（在我看来，其实并非如此），以及为什么存在许多工具来解决类似的问题。现在，让我们试着把这些砖块拼在一起，看看为什么在Kubernetes之上构建一个平台是绝对有意义的。

让我们倒退几年，考虑一下公司首次采用 Kubernetes 时的情况。有些人听说了一种叫做 Helm 的包管理器的新技术，想要将其引入他们的技术栈。在这个阶段，人们经历了试错，使用 kubectl 部署应用程序，安装平台组件，了解了 Helm，并开始建立自己的实践。在较大的公司里，这可能由许多团队完成，到了某个时刻，公司决定将这些事情整合。这时，他们可能会遇到一些问题：

• 如何保证应用 A 的资源消耗不会影响到应用 B 的资源消耗？
• 我应该使用 ingress-nginx 还是 traefik 作为 ingress 控制器，谁负责迁移我的资源？
• 在我们选择应用团队当前使用的 5 种机制时，我们应该如何部署应用？
• 作为一名开发者，我希望在我的云环境中使用一个数据库。我该选哪个数据库，谁负责它？

想象每一个独立的应用团队都在他们的工具栈上投入了一些精力，并且对各自工具栈感到满意，大多数团队对它感到满意。另一方面，这样发展下去扩展性不佳，因此，使用一些预定义的构建模块可以使开发团队的工作更轻松，可以让产品经理更满意，可能更有意义。你的平台工程之旅已经开始了。

马丁·福勒和伊万·博特彻（Martin Fowler和Evan Bottcher）这样定义平台。

“一个数字平台是 自助服务的API、工具、服务、知识和支援 的基础，这些被组织成一个有吸引力的 内部产品线。自主交付小组可以利用该平台更快地交付产品功能，同时减少协作。” (Fowler 和 Butcher, 2018)

我们来分一下相关的几个部分。

• 平台是基础： 我们希望减少开发者的运营负担和基础建设，让他们不必从头开始构建一些东西。
• 自助服务API： 开发者应该能够通过自助服务API使用我们的平台。在我看来，这可以是RESTful API，或者也可以是由开发者通过Git仓库提交并经审核的Kubernetes对象。
• 工具： 所有平台所需的工具。
• 服务： 平台上的工具和服务，帮助开发者交付产品，例如密钥管理、数据库服务、交付工具和消息队列等。
• 知识和支持： 帮助使用平台的人们获取信息和服务。

在我多年的IT生涯中，我学到的一点是，我们经常构建东西，有时甚至会反复构建。在许多情况下，我们倾向于使用之前构建的基础设施作为蓝图，并频繁重复很多步骤。不幸的是，这往往包括一些临时办法，有时还包括维护不佳的工具或机制。转向平台方法可以建立一个模式和模板的目录，这些目录可以随着时间推移而改进（可以将每个IaC模板视为一个版本化的服务），很多人对此感兴趣，希望减少在广泛范围内应用的变通方法。可以把平台看作一个工具市场，提供所有你需要的工具和材料，就像建造狗窝一样。此外，可能还会有销售人员和文档来帮助你完成项目。

图3：供狗狗小屋使用的平台

构建平台时，一个关键的话题是部署策略，因为这会从一开始就带来许多问题，这些问题可能会以多种方式塑造你的平台。最初，你需要考虑哪些服务应该在哪些云上运行，以及如何在这些云上运行服务。举个例子，你可以决定将所有应用部署在 Kubernetes 上，并从提供商那里以 PaaS 服务的形式来使用所有相关的支持服务（如数据库）。这将产生一些与平台相关的解决方案：

• 如何提供平台功能
• 如何部署应用和基础设施组件
• 解决方案目录中的第一个条目

你经常使用基础设施即代码（IaC）解决方案和 GitOps 控制器来交付软件。基于这些解决方案，你可能会有更多问题，例如：如何交付密钥（secrets）、如何处理 DNS 条目、如何处理版本管理等等。这些问题可能有许多，有些问题会早些出现，有些则会晚些出现。你的部署策略显然取决于当前的应用程序及其现有机制。然而，随着你的应用程序和部署策略，你也会发现未曾考虑到的问题和空白。一个主要的问题是需要交付的工件种类以及如何对其进行标准化。例如，如果你交付容器，并且有一个内部的标准来描述部署（例如使用清单和 Helm 图），那么一切都会变得简单得多。

图4：一个平台的技术例子：

在完成这一切的过程中，你的平台会不断发展和演进，并且你会定义其结构。图4展示了一个在生产系统中可能考虑的示例，比如一个开发者门户，用于利用模板并获取关于服务的洞察，用于存储信息的仓库或数据库，还有供开发者使用的接口和服务。

尽管这样的平台可以为开发者带来巨大的价值，但它们也应该帮助人们，而不是强迫他们进行他们不喜欢的流程。

在提供平台时，我们的主要利益相关者是使用这些平台的开发者。因此，记得他们，征求他们的意见，并教他们如何使用平台。此外，人们选择他们的工具并以某种方式构建事物，这背后是有原因的。因此，构建平台不是一种一刀切的解决方案，但确实存在一些模式可以帮助你在这一过程中。

• 让人们成为平台的一部分：可能有些人愿意尽力解答问题并解决问题，他们喜欢讨论技术，通过彼此交流，更好的解决方案将被找到。
• 开放/内源开发：构建可共享的工件（例如基础设施模板和配置）时，在公司内部进行广泛共享，让其他团队可以重复使用。这样可以建立最佳实践和模式，帮助人们发展。此外，人们还可以发起拉取/合并请求，为平台贡献自己的力量。
• 社区建设：举办内部聚会，展示基于平台的成功系统，并分享成功的经验。这将有助于平台的发展，并吸引更多的关注。

另外，每家公司都有自己的历史、内部价值和流程。在开始搭建平台时，记住这些，并尝试找出如何让人们加入我们的行列。

与此同时，你可能想知道这与人工智能有什么关系，或者它如何帮助你在旅程中。本文开头我提到过 Kubernetes 的复杂性以及为什么对某些人来说操作起来有难度。人们正在努力帮助那些使用 Kubernetes 的人，但即使是有经验的工程师也可能会遇到配置上的麻烦，或者至少是简单的故障排除。

早期的 Kubernetes 和 AI 领域项目之一是 K8sGPT，它帮助人们解决 Kubernetes 环境中的问题。因此，可以在 Kubernetes 集群上运行一个简单的命令（如 k8sgpt analyze — explain），以发现配置错误及其解决方案（基于不同 AI 提供商提供的方法），也可作为开发者门户（如 Backstage）的一部分使用。

图5：后台中的K8sGPT插件

这些工具可以与各种其他工具结合使用。例如，您可以使用一些GitOps工具交付应用程序，并在之后运行分析，以检查应用程序是否按预期运行。已经有人努力将工具结合起来以检测并自动解决此类问题。在我最近的一次演示中，我使用了一个GitOps控制器来部署应用程序，使用Keptn验证应用程序的功能，并使用K8sGPT来查找部署中的问题。

这篇文章应该让你了解平台如何在你的云原生之旅中提供帮助，并解决哪些问题。首先，我们简单介绍了Kubernetes的复杂性。接着，我谈了谈庞大的云原生生态系统。最后，我们把所有内容整合在一起，转向了平台。我们发现，制定交付策略不仅有助于解决现有问题，还能帮助你发现新的问题。你还会发现，无论是平台的构建还是标准化，关键都在于人。最后，我还提到了平台中的AI如何简化Kubernetes的复杂性。

• Hohpe, G. (2020). 云策略：基于决策的云迁移成功方法.
• CNCF 平台工作组团队. (2023). CNCF 平台白皮书报告. https://tag-app-delivery.cncf.io/whitepapers/platforms/
• K8sGPT, https://k8sgpt.ai
• Backstage K8sGPT 插件 (https://github.com/suxess-it/backstage-plugin-k8sgpt/blob/main/README.md)