必看：Kubernetes 开发环境对比
曾几何时，Kubernetes 还被主流视为一种运维技术，但今天的情况已经不同了，现在 Kubernetes 对很多开发人员来说都是很重要的。正如我在有关 Kubernetes 工作流的 博客文章 中所写的那样，对于开始直接接触 Kubernetes 的开发人员来说，第一步工作就是设置 / 接入一个 Kubernetes 开发环境。
接入 Kubernetes 环境不仅是我们要做的第一步，而且是在工作中启用 Kubernetes 的基本要求。尽管如此，接入这样的环境时经常也会出问题：VMware 的一项研究甚至发现“访问基础架构是开发人员生产力的最大障碍”。为此，对于所有计划使用这种技术的团队来说，Kubernetes 开发环境都应该具有较高的优先级。
在本文中，我将描述和对比四种不同的 Kubernetes 开发环境，并说明何时应该使用哪种开发环境。
-
- 本地 Kubernetes 集群
- 基于云的独立集群
- 自服务命名空间
- 自服务虚拟集群
1、开发环境的 6 个评估标准
为了让不同的 Kubernetes 开发环境具有可比性，我们应该首先定义所使用的评估标准。我将使用以下标准对每种环境打分：
- 开发体验：开发人员入门这个环境有多容易？这包括设置速度、易用性以及开发人员所需的知识等因素。
- 管理体验：管理员管理这个环境和系统有多容易？在这里，我将考虑系统的复杂性、管理该系统以及添加其他用户的工作量。
- 灵活性 / 现实性：与生产环境相比，开发环境的现实程度如何？对于不同的用例，它的灵活性如何？一个好的开发环境应该与生产环境非常相似，以避免出现“它在我的机器上本来可以运行”的问题，并且还应该可以自由配置以用于许多不同的用例（例如编码、测试等）。
- 可扩展性：如果有许多用户正在使用这个系统，环境本身的可扩展性如何？方法的可扩展性如何？特别是对于复杂的、需要大量计算资源的应用程序，开发环境应该能够满足需求。另外，向开发人员提供这种环境的通用方法也应该适用于大型团队。
- 隔离度 / 稳定性：用户之间如何隔离，系统有多脆弱？开发人员应该能够并行工作而不会互相干扰，并且他们使用的系统应该稳定且安全，以减少低效的中断事件。
- 成本：这种方法有多昂贵？成本的含义大家都知道，在为团队选择正确的开发环境时，它仍然是重要的因素。
现在评估标准已经明确，我们可以开始对比 Kubernetes 开发环境了：
本地 Kubernetes 集群是在开发人员的单台计算机上运行的集群。有许多工具可以提供这样的环境，例如 Minikube、microk8s、k3s 或 kind。尽管它们并不完全相同，但它们在开发环境中的用法具有相当的可比性。
开发人员必须在计算机上自行设置本地开发环境，因为这些环境就是在本地计算机上运行的。这可能非常具有挑战性，特别是因为本地设置总是有各种区别（不同的硬件、不同的操作系统、不同的配置等），这样想要找到一个非常简单的设置指南就更难了。设置完成后，开发人员还要负责自己护理和管理自己的环境。如果他们以前没有 Kubernetes 经验，他们通常会感到不习惯。
因此，对开发人员来说总体的开发体验相对较差（至少在没有 Kubernetes 知识的情况下）。
管理员不参与本地 Kubernetes 集群的设置和管理。这意味着他们在这里没有任何要做的事情。但是，他们也不知道开发人员是否能够使用自己的集群，并且通常被排除在集群的设置和管理工作之外。尽管如此，如果出现问题，管理员可能仍需要支持开发人员。
总体而言，管理体验得分中等，因为管理员没有面对典型的挑战，而是需要单独地教育和支持开发人员。
一方面，本地集群在云环境中总是与“真实”集群有所不同。它们通常是精简的 Kubernetes 版本，缺少一些无法在本地复制（并且通常在本地不需要）的特性。比如看名字“k3s”就能看出来，这是对原始 Kubernetes 的“k8s”的简化。另一方面，工程师可以对本地集群执行任何所需的操作，因此他们也可以灵活地对其配置。
总而言之，本地集群在灵活性配置方面得分较高，但在现实性方面得分较低，因为它们不具有所有 Kubernetes 特性，因此不能用于所有用例。
由于本地集群只能访问工程师计算机上可用的计算资源，因此它们相对更容易达到复杂应用程序的极限。另外，让工程师自己创建本地集群的方法实际上并没有扩展性，因为必须为几乎每一位没有自动化选项的工程师重复相同的过程。
因此，可扩展性是本地 Kubernetes 集群的明显弱点。
每位开发人员都有一个单独的环境，该环境与其他所有环境完全断开。从理论上讲，它们甚至可以在没有互联网连接的情况下使用。所以本地集群的隔离度是完美的。这种连接断开还确保了只有单个环境会被故障波及，故障绝不会同时导致所有环境失败，这最大程度地降低了这种方法为开发人员提供的 Kubernetes 环境的脆弱性。
隔离和安全性绝对是本地集群的优势。
本地 Kubernetes 集群有时不需要昂贵的云计算资源，而仅使用本地可用的计算资源。各种本地 Kubernetes 解决方案都是开源的，可以免费使用。
使用本地 Kubernetes 集群进行开发没有任何直接成本，因此它是最便宜的解决方案。
在云中运行的独立集群是 Kubernetes 开发环境的第二种类型。它们可以由管理员创建，然后管理员可以单独授予开发人员访问权限，或者如果开发人员拥有自己的云提供商帐户，则可以让他们自己创建开发人员。
开发人员的体验可能会大不相同，并且取决于各个集群的创建方式：如果开发人员可以直接访问云，例如借助精心设计的身份和访问管理（IAM）机制，他们可以按需创建自己的工作环境，并且设置过程非常简单（尤其是在公有云中），因为它总是一样的。但是，他们必须自己执行这一步操作，并且可能需要一些帮助来管理集群。
如果管理员负责创建集群并将访问权限分发给各位开发人员，则开发人员的体验可能会变得很糟糕。现在，集群的管理有人负责了，但管理员却成为了瓶颈。在这里，你将面临前面提到的，开发人员等待中央 IT 提供开发环境的问题。
总体而言，在最佳情况下，如果开发人员具有直接的云访问权限，那么开发体验就足够优秀了。
无论开发人员以哪种方式获取集群，管理员的体验总是很糟糕。如果每个开发人员都有自己的云帐户，则管理员将很难获得整个系统的宏观状况（哪些资源仍在被使用？谁在使用什么资源？）。在这种情况下，他们还必须支持开发人员来管理集群。由于集群的数量与工程师的数量成比例地增加，因此工作量也随团队规模的增长而增加。
在管理员集中创建和分发集群的情况下，管理员也需要付出很多努力。他们将必须回应开发人员对集群和配置更改的所有请求，并且必须始终待命，因为他们对于开发人员的生产力来说至关重要。通常，更多的集群会导致管理员付出更多的管理工作。
从管理员的角度来看，基于云的独立集群方法是一个不好的解决方案，并且必然导致他们手头的工作量大增，甚至到他们无法处理的地步。
由于生产系统通常也在云中的 Kubernetes 中运行，因此这样的开发环境是完全真实的。各个环境也可以自由配置，因此它们完全符合开发人员的需求，或者与生产系统的设置相同。
基于云的独立集群是获得高度真实的开发环境的最佳解决方案。
在可扩展性方面，集群在云环境中运行时优势很大，几乎可以无限扩展。不过可扩展性标准还包括适用于大型团队的通用方法的可扩展性，而在这里，随着管理工作量随团队规模不断增长，各个集群可能会达到极限。
对于云中的独立集群而言，计算资源的可扩展性不是问题，但是在大型组织中推广这样的系统通常是不可行的。
在集群级别隔离开发人员是非常安全的。如果你使用的是公有云，则开发人员的隔离度几乎与不同公司的隔离度是一个级别，这当然是云提供商的高度优先事项。
100％的稳定性和隔离度可能永远不会在云中实现，但是对于独立集群而言，这方面的表现已经够好了。
运行许多集群是非常昂贵的。这是由于以下几个因素：首先，你将具有很多冗余，因为每个集群都有自己的控制平面。其次，采用这种方法几乎不可避免地会产生超大型或未使用的集群，因为要么得由开发人员负责对集群进行大小调整和关闭操作，要么管理员必须集中管理，但后者没法监控和了解集群中仍在使用哪些资源。
此外，开发环境也仅在开发人员正在工作时使用，因此许多集群可能在晚上、节假日和周末处于空闲状态。最后，公有云提供商会为每个集群（在这种情况下是为每个开发人员）计算集群管理费。
在云中为每个工程师提供单独集群是提供 Kubernetes 开发环境的非常昂贵的方法。
除了为每个开发人员提供整个集群之外，还可以为他们提供 Kubernetes 命名空间。同样，这些环境可以由管理员集中创建，或者为开发人员提供一种工具，让后者可以按需创建自服务命名空间。集中提供命名空间的方法也有着前文提到的独立集群所具有的许多缺点，因此在这里我将重点介绍自服务命名空间方法。
由于工程师可以自己创建命名空间，因此它们独立于管理员，无需开发人员等待获取 Kubernetes 开发环境。同时，命名空间在由管理员管理的集群上运行，因此开发人员不必关心环境的管理。命名空间作为集群中的构造通常足以完成更简单的开发工作，因此开发人员将能够执行大多数标准任务，并且仅在某些情况下受到限制，例如当他们需要 CRD 或要安装使用 RBAC 的 Helm 图表时。
因此，对于“标准”开发任务和没有特殊 Kubernetes 配置要求的开发人员来说，自服务命名空间的开发体验是非常不错的。
一开始，管理员需要建立一个内部自服务 Kubernetes 平台，如果他们想从头开始构建它的话可能会花费一些时间，Spotify 这样的公司就选择了这样做。或者，也可以购买将自服务命名空间功能添加到任何集群的解决方案（Loft 就是这样做的）。无论如何，一旦系统正确设置完毕，管理员就可以专注于其他任务，例如基础集群的安全性和稳定性等。此外，由于整个系统都在一个集群中运行，因此获得整个系统的概况相对容易。
自服务命名空间是一种易于管理的解决方案，需要进行一些初始设置。
由于命名空间在共享的 Kubernetes 集群上运行，因此开发人员无法单独配置所有内容。例如，所有工程师都必须使用相同的 Kubernetes 版本，并且不能修改集群范围的资源。尽管如此，命名空间仍在类似于生产环境的云环境中运行，这起码让命名空间成为了相对现实的工作环境。
总体而言，命名空间在某些情况下可能会限制开发人员的灵活性，但它通常不会是不切实际的开发环境。
自服务命名空间系统的可扩展性在两个方面都非常不错：可以扩展命名空间的资源，因为它们在云中运行（当然也可以限制开发人员以防止过度使用）。同时，向系统添加其他用户也没有问题，特别是如果它提供了“单点登录”选项就更方便了。
命名空间是为许多开发人员提供可灵活扩展或缩减的 Kubernetes 环境的有效方法。
命名空间是 Kubernetes 多租户的原生解决方案，但它的隔离并不是完美的，而是一种软多租户的形式。但是，由于承租人（开发人员）是受信任的，所以这对于开发环境而言不一定是问题。此外，多个命名空间共享相同的基础集群，这意味着如果集群关闭，所有命名空间都会失败，因此集群的稳定性至关重要。
命名空间是 Kubernetes 原生的隔离解决方案，但它当然不是完美的。但是，如果基础集群运行良好，那么对于组织内的受信任工程师而言，命名空间仍然是一个不错的解决方案。
为了获得自服务的体验，你可能需要购买自服务的命名空间软件。此外，在云环境中运行的命名空间不是免费的，因为它们还需要云计算资源。但是，许多开发人员可以共享基础集群及其资源，从而提高了利用率并避免了不必要的冗余。从控制中心了解哪些资源空闲也是比较容易的，这样就可以关闭这些资源节省费用。该过程甚至可以通过睡眠模式自动执行。
总体而言，命名空间是一种非常经济高效的方法，是为开发人员提供 Kubernetes 接入的好选项。
虚拟集群（vClusters）是一种解决方案，可让你在 Kubernetes 集群中创建 Kubernetes 集群。像命名空间一样，虚拟集群在单个物理集群上运行，并且如果开发人员可以访问 vCluster 平台，则可以由开发人员按需创建。
虚拟集群的开发体验类似于命名空间。开发人员可以轻松按需创建它们，并且它们独立于中央 IT，但开发人员也不必自己管理基础集群。同时，对于开发人员而言 vClusters 感觉像是“真实的”集群，因此他们通常完全不会遇到什么限制。
因此，vClusters 的开发体验与命名空间相似，但甚至为开发人员提供了更多的自由来执行和配置他们想要的东西。
考虑到管理员的体验，自服务命名空间和 vClusters 也是非常相似的。初始设置后，管理员的管理工作就很少了，因此他们可以专注于其他任务。但与命名空间相比，vClusters 更好地隔离了用户，因此开发人员让基础集群崩溃的可能性更小了。此外，大多数 Kubernetes 的配置和安装都可以在 vCluster 中进行，因此基础集群可以非常简单，只需提供基本特性即可，从而让管理员的工作更加轻松。
一旦正确设置，自服务 vCluster 平台还可以提供非常流畅的管理员体验。
虚拟集群在云中运行，这使它们成为了相当逼真的开发环境，尤其是考虑到开发人员可以单独配置虚拟集群以满足他们的需求。但是，vClusters 与真实集群并不完全相同，因此现实性指标并不像独立集群那样完美。
总体而言，vClusters 可以灵活配置以满足不同用例的要求。由于它们是虚拟构造，因此它们与物理集群之间仍然存在一些细微差异。
vClusters 的可扩展性与命名空间一样好。vClusters 可以在云中拥有不同的且基本上是无尽的计算资源。在独立集群上运行的平台的自服务配置还让 vClusters 可以支持许多工程师同时使用。
自服务 vCluster 解决方案将满足开发环境可扩展性方面的所有需求。
虚拟集群的隔离比命名空间级别的隔离要好，但是 vClusters 仍然是 Kubernetes 多租户的一种形式，因此 vClusters 共享一个公有的物理集群。虚拟集群的一个好处是基础集群可以是非常基础的，这使得集群更容易稳定下来。
总体而言，vClusters 的隔离度很好，并且整个系统的稳定性可以很出色。但是，很多稳定性水平取决于基础集群的稳定性。
虚拟集群平台不是免费的，因为它需要平台的云计算资源和软件。在这方面，vClusters 又非常接近命名空间：集群共享提高了利用率，并让管理员更容易获得系统概况和关闭未使用的虚拟集群，甚至可以通过睡眠模式将这些操作自动化。
虚拟集群平台与命名空间平台一样具有成本优势，但是所有基于云的解决方案都不一定完全免费。
在描述了四种不同类型的 Kubernetes 开发环境之后，问题仍然是哪种环境适合你的情况。
根据我的经验，许多公司和工程师都是从本地开发环境开始的。它们是免费的并且可以在本地计算机上运行，这一事实减少了最初的障碍，因为本地环境不需要复杂的预算审批。对于编程爱好者和小型应用程序来说，本地环境也是一个很好的解决方案；而对于知道如何处理和设置这些环境的 Kubernetes 专家来说，本地环境也是一个不错的选项。
随着组织在云原生的道路上逐渐前行，他们希望将 Kubernetes 推广给更多没有使用 Kubernetes 经验的开发人员。这些组织通常从“显而易见的”解决方案入手：只需为每个开发人员提供一个自己的集群。一段时间后，他们通常会意识到这种方法非常昂贵，并且随着越来越多的开发人员一起使用 K8s，这种方法变得更加复杂。为此，除非开发人员数量相对较低且成本无关紧要，否则基于独立云的集群解决方案通常只是一个临时解决方案。
为了避免大型团队的高昂成本和复杂管理工作，许多组织希望为开发人员提供命名空间或虚拟集群（虚拟集群相对较新，因此命名空间仍然很常见）。但是，由于这些公司已经意识到该方法的可扩展性非常重要，因此他们希望以一种自动化的方式来做到这一点，要么像 Spotify 一样开始开发自己的内部 Kubernetes 平台，要么就购买诸如 Loft 之类的现有解决方案。因此，到底命名空间就够用了，还是说虚拟集群是更好的解决方案，取决于应用程序的复杂性以及开发人员的专业知识和需求。
随着越来越多的公司希望其开发人员启用 Kubernetes，也有越来越多的开发人员需要接入 Kubernetes 环境。已有的几种选项都有其优点和缺点。
尽管本地开发集群是一个好而便宜的起点，但对于经验不足的开发人员或大型组织而言，它们通常不是正确的解决方案。
然后，这些组织会转向各个基于云的集群的“显而易见”的解决方案，这些解决方案在灵活性和现实性方面无与伦比，但对于管理员而言也难以管理，并且可能变得非常昂贵。
最后，共享集群是自服务命名空间或虚拟集群的基础，是一种将成本效益与良好的开发和管理体验相结合的解决方案。尽管这些解决方案不是免费的，并且需要一些初始设置工作，但即使对于较大的公司，它们也是一个长期的解决方案选项。
原文链接： https://loft.sh/blog/kubernetes-development-environments-comparison/
作者 | Daniel Thiry 策划 | 田晓旭 本文最初发布于 Loft 网站，经授权由 InfoQ 中文站翻译并分享。