如果你与在生产环境中运行 Kubernetes 的人员交谈，你经常听到的抱怨之一是多租户有多么困难。组织使用两种主要模型与多个租户共享 Kubernetes 集群，但这两种模型都存在问题。这些模型是
- 基于命名空间的多租户
- 基于集群的多租户
第一种常见的多租户模型基于命名空间隔离，其中各个租户（例如，开发微服务的团队）被限制为在集群中使用一个或多个命名空间。 虽然此模型适用于某些团队，但它存在缺陷。 首先，将团队成员限制为仅访问命名空间中的资源意味着他们无法管理集群中的全局对象，例如自定义资源定义 (CRD)。 对于将 CRD 作为其应用程序一部分或作为依赖项（例如，基于 Kubeflow 或 Argo Pipelines 构建）的团队来说，这是一个大问题。
其次，一个更大的长期维护问题是需要不断地向命名空间隔离规则添加例外。 例如，当使用网络策略锁定各个命名空间时，管理员可能会发现某些团队最终需要运行多个相互通信的微服务。 集群管理员需要以某种方式为这些情况添加例外，跟踪它们并管理所有这些特殊情况。 当然，随着时间的推移以及越来越多的团队开始加入 Kubernetes，复杂性也会增加。
另一种标准的多租户模型，即在集群级别使用隔离，问题更多。 在这种情况下，每个团队都获得自己的集群，甚至可能是多个集群（开发、测试、UAT、暂存等）。 使用集群隔离的直接问题是最终需要管理许多集群，这可能会非常头疼。 即使在晚上或周末等没有人积极使用它们时，所有这些集群也需要昂贵的云计算资源。 正如 Holly Cummins 在她的 KubeCon 2021 主题演讲中指出的那样，集群的这种爆炸式增长对环境产生了危险的影响。
直到最近，集群管理员还必须在这两种令人不满意的模型之间做出选择，选择更适合其用例和预算的模型。 然而，Kubernetes 中有一个相对较新的概念，称为虚拟集群，它更适合许多用例。
什么是虚拟集群？
虚拟集群是一个共享的 Kubernetes 集群，对租户而言，它看起来像是一个专用集群。 2020 年，我们 Loft Labs 团队发布了 vcluster，这是一个虚拟 Kubernetes 集群的开源实现。
借助 vcluster，工程师可以在共享的 Kubernetes 集群之上配置虚拟集群。 这些虚拟集群在底层集群的常规命名空间内运行。 因此，管理员可以启动虚拟集群并将它们分发给租户，或者——如果组织已经使用基于命名空间的多租户，但用户被限制在单个命名空间中——租户用户可以在他们自己的命名空间内启动这些虚拟集群。
这结合了上述两种多租户方法的优点：租户被限制在单个命名空间中，无需例外，因为他们在虚拟集群内部拥有完全控制权，但在虚拟集群外部的访问权限非常有限。
与集群管理员一样，用户在虚拟集群内部拥有完全控制权。 这允许他们在虚拟集群内执行任何操作，而不会影响底层共享主机集群上的其他租户。 在幕后，vcluster 通过在主机集群上命名空间内的 pod 中运行 Kubernetes API 服务器和其他一些组件来实现这一点。 用户将其命名空间内的请求发送到该虚拟集群 API 服务器，而不是底层集群的 API 服务器。 虚拟集群的集群状态也与底层集群完全分离。 在虚拟集群内部创建的 Deployment 或 Ingress 等资源仅存在于虚拟集群的数据存储中，并且不会持久保存在底层集群的 etcd 中。
这种架构比命名空间隔离和集群隔离模型具有显着优势
- 由于用户是其虚拟集群中的管理员，因此他们可以管理集群范围的对象，例如 CRD，这克服了命名空间隔离的重大限制。
- 由于用户与他们自己的 API 服务器通信，因此他们的流量比在正常的共享集群中更隔离。 这也提供了联邦，这有助于在高流量集群中扩展 API 请求。
- 虚拟集群的配置和拆除速度非常快，因此用户可以受益于使用真正的临时环境，并且可以在需要时启动许多虚拟集群。
[ 了解使用现代工具开发云原生应用程序所需的知识。 下载电子书 Kubernetes-native microservices with Quarkus and MicroProfile。 ]
如何使用虚拟集群
虚拟集群有很多用例，但这里列出了一些我们看到大多数 vcluster 用户采用的用例。
开发环境
配置和管理开发环境是目前 vcluster 最流行的用例。 在 Kubernetes 集群中运行服务的开发人员需要在开发过程中运行其应用程序的地方。 虽然可以使用 Docker Compose 等工具来编排开发环境的容器，但针对 Kubernetes 集群进行编码的开发人员将获得更接近其服务在生产环境中运行的体验。
本地开发的另一个选择是使用 Minikube 或 Docker Desktop 等工具来配置 Kubernetes 集群，但这有一些缺点。 开发人员必须拥有和维护该本地集群堆栈，这是一个负担，并且非常耗时。 此外，这些本地集群可能需要大量的计算能力，这在本地开发机器上很困难。 我们都知道笔记本电脑在开发过程中会变得多热，将 Kubernetes 添加到其中可能不是一个好主意。
在共享开发集群中将虚拟集群作为开发环境运行可以解决这些问题。 此外，如上所述，vcluster 可以快速配置和删除。 管理员只需使用单个 kubetctl 命令删除底层主机命名空间，或运行命令行界面工具提供的 vcluster delete 命令即可删除 vcluster。 开发工作流程中基础设施和工具的速度至关重要，因为缩短开发人员的周期时间可以提高他们的生产力和幸福感。
CI/CD 管道
持续集成/持续开发 (CI/CD) 是虚拟集群的另一个强大用例。 通常，管道配置被测系统 (SUT) 以针对其运行测试套件。 通常，团队希望这些是全新的系统，没有累积的垃圾，这些垃圾可能会干扰测试。 运行包含许多测试的长管道的团队可能会在一次测试运行中多次配置和销毁 SUT。 如果您花费大量时间配置集群，您可能已经注意到启动 Kubernetes 集群通常是一个耗时的操作。 即使在最复杂的公共云中，也可能需要 20 多分钟。
使用 vcluster 可以快速轻松地配置虚拟集群。 运行 vcluster create 命令来配置新的虚拟集群时，幕后涉及的所有操作都是运行 Helm chart 并安装一些 pod。 这通常只需要几秒钟的操作。 任何运行长测试套件的人都知道，从流程中节省的任何时间都可以对 QA 团队和工程师接收反馈的速度产生巨大影响。
此外，组织可以使用 vcluster 的速度来改进任何其他需要配置大量集群的流程，例如为研讨会或客户培训创建环境。
测试不同的 Kubernetes 版本
如前所述，vcluster 在底层主机命名空间中运行 Kubernetes API 服务器。 它默认使用 K3s（轻量级 Kubernetes）API 服务器，但您也可以使用 k0s、Amazon Elastic Kubernetes Service 或常规上游 Kubernetes API 服务器。 当您配置 vcluster 时，您可以指定要运行它的 Kubernetes 版本，这开辟了许多可能性。 您可以
- 在虚拟集群中运行较新版本的 Kubernetes，以了解应用程序在较新的 API 服务器上的行为方式。
- 运行具有不同 Kubernetes 版本的多个虚拟集群，以便在开发或端到端测试期间在一组不同的 Kubernetes 发行版和版本中测试运算符。
了解更多
Kubernetes 多租户可能没有完美的解决方案，但虚拟集群解决了当前租户模型的许多问题。 Vcluster 的速度和易用性使其成为许多场景的绝佳选择，在这些场景中，您希望使用共享集群，但也希望让用户灵活地管理他们的集群。 除了本文中描述的用例之外，vcluster 还有许多用例。
要了解更多信息，请访问 vcluster.com，或者如果您想直接深入代码，请从 GitHub 存储库下载它。 Loft Labs 团队维护 vcluster，我们很乐意收到关于它的想法。 我们根据用户反馈添加了许多功能。 请随时提出问题或 PR。 如果您想先与我们讨论您的想法或在探索 vcluster 时有任何疑问，我们还在 Slack 上开设了 vcluster 频道。
评论已关闭。