为什么每家企业都在构建内部Kubernetes平台？

本文最初发布于 loft.sh，经原作者授权由 InfoQ 中文站翻译并分享。

近来，你可能从许多不同的信息源听说过“内部 Kubernetes 平台”：KubeCon 演讲、博客文章，或者同事和朋友。有时候，这样的平台并不叫内部 Kubernetes 平台。现在，让工程师可以通过标准方式在云环境中轻松获得 Kubernetes 访问的解决方案似乎越来越普遍。

在本文中，我将介绍下是什么促使公司构建和采用这样的平台。为此，我会使用三家科技公司Eventbrite、Spotify和Datadog的公开案例，并分享我使用开箱即用的 Kubernetes 内部平台解决方案 Loft 的一些工作经验。

内部 Kubernetes 平台

我在另一篇文章中定义了什么是内部Kubernetes平台。

简言之，内部 Kubernetes 平台为工程师提供了直接访问Kubernetes开发环境的机会，他们可以在预生产阶段使用这个环境。通常，这样的平台允许工程师创建自助式命名空间，但是也可以使用整个集群或虚拟集群（vcluster）。

尽管术语“平台”可能让人想到它只是一个基础设施组件，但通常，内部 Kubernetes 平台也包含一些工具，帮助开发人员简化平台的使用和管理以及一般的Kubernetes开发工作流，特别是部署工作流，即使他们以前没有使用 Kubernetes 的经验。

因此，如果你听说过内部 Kubernetes 平台，那么你也会经常听到开发经验和相关工具，而不仅仅是技术基础设施决策。

什么促使公司构建这样的平台？

由于这项工作涵盖许许多多的方面，所以为工程师构建一个内部Kubernetes平台可能相当具有挑战性。例如，Spotify 花了 2 年时间才使其内部平台普遍可用。

考虑到为大型团队构建平台需要做大量的工程工作并付出可观的云计算成本，因此，公司在进行这样的投资之前就应该问为什么。显然，这样做肯定有很大的价值，当然也有很大的压力。

1.对于本地环境来说，应用程序变得太大

因此，让我们通过 Eventbrite 的案例来探究构建 Kubernetes 内部平台的潜在原因：在一次采访中，Eventbrite DevTools 团队首席工程师 Remy DeWolf 解释了为什么他们从本地开发转向使用Kubernetes的基于云的开发。和许多公司一样，Eventbrite 一开始也是构建了一个单体应用。随着时间的推移，这个单体应用变得越来越大，这就是为什么它被部分地转换成微服务，而新服务也是以微服务的形式添加。

因为所有这些都运行在容器中（至少对于开发而言是如此），所以最初这不是问题。然而，随着软件的进一步发展，你最终会遇到一个问题，即它太大了，无法利用本地 Kubernetes 解决方案（如Minikube或Docker Desktop）在本地计算机上运行。

此时，你可以采用变通方法，例如只运行应用程序的一些必要部分，或者本地运行一部分，远程运行其他部分，以保持现有的本地开发工作流。这可能是一种合适的方法，但由于大多数公司和系统都在不断增长，随着时间的推移，继续进行本地开发会变得越来越困难。这将导致开发人员生产力降低，因为开发人员越来越难以忍受其本地设置和运行缓慢的笔记本电脑。

为此，你需要在投资内部平台（以及云资源的持续成本）和浪费的工程时间之间进行权衡。这就很明确了，为什么很多公司开始时使用本地 Kubernetes 解决方案，但越来越多的公司现在已经到了有必要转向基于云的 Kubernetes 环境的“临界点”。

Eventbrite 也是因此决定采用云环境，并构建了一个名为“yak”的内部工具，使工程师可以部署和管理远程容器。这样，现在每个工程师都在共享 Kubernetes 集群中有自己的命名空间，可以轻松地在其中运行大约 50 个容器。

这样的演进不仅发生在 Eventbrite，大约有 800 名开发人员的Datadog似乎也做出了类似的决定。我还可以用我们 Loft 客户的经验来支持这一观点：在某些情况下，他们的应用程序会变得特别复杂，无法在本地运行，因此，迁移到基于云的 Kubernetes 环境成了一个必要的步骤。

有趣的是，这不仅适用于大型组织，在工程师较少的情况下也可能会发生，如果他们通常开发的是资源密集型或复杂的应用程序，比如 AI/ML 软件。

在许多情况下，应用程序有时会变得太大而无法在本地运行。那时，从本地开发环境转移到基于云的 Kubernetes 开发环境通常是有意义的。

2.自主与专注相结合

在KubeCon演讲中，Spotify 高级 SRE James Wen 并没有直接分享他们建立内部 Kubernetes 平台的原因。不过，我们仍然可以从中获得有价值的见解，这些见解可能会促使我们做出这个决定。

虽然他没有提到 Spotify 工程师无法继续进行本地开发，但如果他们有大量的团队（280+）、工程师（1500+）和微服务（1200+），而且他们之前已经有了一个非 kubernetes 云解决方案，我们就可以做出这样的假设。

不过，我认为，在 James Wen 提到的内容中，更有趣的一些方面是：Spotify 使用“团队 Ops”模式，这是一个很有吸引力的组合，团队完全自治加完全集中化的运维。团队独立构建和运维他们自己的服务，但是他们可以依赖集中式 Ops 团队提供的工具和平台。

我认为，这是一个聪明的解决方案，因为它让团队可以自主工作并根据需要配置 Kubernetes（他们甚至可以根据自己的节奏采用它），但他们自己不需要考虑和管理这一切，而是使用一个通用的平台解决所有“标准”问题，避免多余的工作。

从管理员（DevTool 团队）的角度来看，这样的解决方案也很有吸引力，因为管理员不必单独与所有的开发环境交互，那可能是一个大问题，例如手动提供所有的环境。相反，管理员可以专注于提供集群和良好的平台体验，并为使用它的开发人员提供支持，例如解决问题，这也更容易，因为它可以在云中共享一个开发环境。

有了内部 Kubernetes 平台，开发人员就能自由、自主地工作，而不必关心运维任务，因为它们可以通过集中化的方式得到更好的解决。管理员团队也可以受益，因为他们能专注于平台以及为其他工程师提供支持，但不必操心每个单独的环境。

3. 简化 Kubernetes 工作流

当开发人员开始使用 Kubernetes 时，可能会遇到相当大的挑战。使用内部平台使得向 Kubernetes 过渡的过程更容易，因为一些任务可以简化，而且开发人员不必自己设置 Kubernetes。

例如，Spotify 开发了一个全面的教程和文档，让新开发人员从第一天就能轻松地使用内部平台和 Kubernetes。在 Loft，我们为开发人员（我们客户的内部 Kubernetes 平台的用户）提供了一份入门指南，向开发人员解释了基本概念和所有标准任务。

这是可能的，因为工作环境总是以相同的标准化的方式创建，这在本地计算机上是不可能的，因为硬件、操作系统、系统配置等存在差异。这也是 Eventbrite 认识到的一个优势：他们能够减少“平均恢复时间”，即恢复到干净状态的时间，如果开发人员陷入困境或犯了错误，这就有必要了。因此，内部 Kubernetes 平台也降低了使用 Kubernetes 进行试验的风险，这让它对开发人员更具吸引力。

一般来说，许多开发人员对 Kubernetes 感兴趣，并希望学习和使用它，正如最近的Stack Overflow开发人员调查的结论那样。通过内部平台，他们可以很容易地接触到 Kubernetes，然后逐步提升他们的技能。

在这里，还有其他 Kubernetes 工具发挥了重要作用。显然，Spotify、Eventbrite 和 Datadog 都开发了一些工具，使工程师更容易使用Kubernetes工作流。至少，Spotify 的“tugboat”和 Eventbrite 的“yak”不仅可以作为平台管理工具，还能支持部署过程，从而提供更好的 Kubernetes 开发体验。在 Loft，我们还看到，这对于我们的客户也很重要，这就是为什么我们为DevSpace开发了直接的Loft集成。这样，工程师只需要一个工具就可以启动他们的工作环境，在其中开发，并部署到其中。

包含一些开发工具的内部 Kubernetes 平台有助于标准化 Kubernetes 工作流，使没有 Kubernetes 经验的工程师也能使用它。这促进了平台的采用，并为开发人员更多地了解 Kubernetes 提供了支持。

4.节省成本

采用内部 Kubernetes 平台的另一个驱动力是节省成本。通常，共享集群更便宜，而且，自助命名空间平台允许这样的集群共享。节省的成本来自于计算资源更高效的自动伸缩、资源共享和一些核心 Kubernetes 组件（如 API 服务器）。因此，与其他基于云的环境（例如为开发人员/团队提供单独的集群）相比，内部平台可以节省成本。

除了这些直接节省的成本，当开发人员能使用优化的工作流，而不必再关心自己的 Kubernetes 环境时，他们的生产效率就会提高，这间接地节省了成本。因此，前面提到的使用内部平台的原因最终都有助于降低Kubernetes的成本。

另一方面，来自客户的经验也能证明这一点，他们实现了显著的成本节约（这也得益于节省成本的特性，比如可以在公共平台上实现的睡眠模式）。然而，正如 James Wen 在演讲中指出的那样，成本也是工程团队转向 Spotify 内部服务的一个重要因素。

为工程师提供 Kubernetes 环境，内部 Kubernetes 平台是一个非常具有成本效益的的解决方案，因为计算资源可以被充分利用，工程师能更高效地工作。

提供内部 Kubernetes 平台的要素

现在，你可能想要开始创建自己的内部 Kubernetes 平台了。我写过一份关于如何构建内部Kubernetes平台的指南。当然，你也应该看看 James Wen 的演讲来了解 Spotify 的经验。

不过，在这之前，我想强调一下，平台的成功取决于一些重要的决定性因素。

提供良好的开发体验

即使你的平台是供内部使用的，你也有“客户”，这些客户就是你所在的组织的开发人员。为了确保他们采纳并喜欢你的解决方案，你需要为他们提供良好的开发体验。在最好的情况下，这意味着他们可以使用一种工具完成所有工作，包括创建环境、使用该工具进行开发，以及最终部署到该工具上。你还需要为开发人员准备大量的文档，并且在编写这些文档时应该考虑到开发人员的经验（这对编写文档的管理员来说是一个挑战）。总之，正如 James Wen 所描述的那样，你的平台必须是开发者的“最佳选择”。

度量用户参与度并与用户沟通

了解用户非常重要。因此，你必须不断地与开发人员沟通，这通常很自然，因为平台提供者需要为开发人员使用它提供支持。此外，你还应该度量用户参与度，以查看你的平台实际是否被使用，并找出平台可能缺少的东西。

度量平台的成本和性能

你还应该度量平台是否可靠地工作，并确保你能快速修复问题。在适当的地方进行备份并进行广泛的测试是非常有帮助的。这里，你应该记住，即使平台“只”在内部使用，但一旦每个人都使用，它对整个工程部门的生产力就变得至关重要。为了支持和理解平台的业务案例，度量引入平台之前和之后的成本也很重要。

改善平台和开发体验

正如你从前面的要素中所看到的，构建一个内部平台是一项持续不断的工作。因此，你必须不断更新和改进平台的稳定性和性能，以及提高开发人员的使用体验（也包括文档）。

开发经验比技术细节更重要

对开发人员来说，最重要的是他们能有效地使用平台。通常，他们并不真正关心底层的技术到底是如何运作的，也不关心它在哪里运行。（Eventbrite 使用 EKS，开始时只有一个集群，现在运行几个集群，Spotify 依赖于 GKE 上的多个集群，而 Datadog 只使用一个自管理集群。我相信这种选择对开发者来说并不是决定性的。）提供平台的工程师团队应该以用户为中心。这意味着，即使是在看起来很小的改进上投资也是值得的，这将大大简化开发人员的工作。

购买可能比构建更便宜

与大多数软件一样，自己构建并不总是最好的解决方案。相反，你可以简单地购买[一个内部 Kubernetes 平台解决方案，它是由一个专门的团队持续开发的，对于许多用例（特别是在没有极特殊需求的情况下），这可能都是更好、更便宜的选择。

即使你决定自己构建，你也应该考虑集成已经存在的开源解决方案，例如，kiosk可以帮助你实现多租户，而像Skaffold或DevSpace这样的开发工具能用作开发和部署工具。

结论

内部 Kubernetes 平台已经变得越来越常见，尽管它们并不一定叫这个名。有了这样一个平台，开发人员就可以直接访问云中的 Kubernetes 环境。

可以预见，使用 Kubernetes 并希望扩展其技术的软件团队都会到达这样一个点：本地开发变得不可行或者非常低效。那时，迁移到云环境是有意义的，如果你的生产系统运行在 Kubernetes 上，那么它也应该是一个 Kubernetes 环境。

考虑到构建这样一个平台所花费的时间和精力，他们应该提前预见，他们可能需要一个内部开发平台，并开始不断地评估引入这样一项技术，这样他们就能找到恰当的投资回报点。

一旦决定构建内部 Kubernetes 平台，就应该将重点放在开发体验上，以确保开发人员会真得采用和参与，因为只有这样才有可能获得这样一个平台的全部好处。

原文链接：

https://itnext.io/why-everyone-builds-internal-kubernetes-platforms-284c2cf76226