K8s集群多租户管理

01

背景

为了能够在集团层面对GPU资源进行统一管理，需要在平台对容器公共集群、搜索集群、Hbox 集群进行统一呈现和管理。如何在各部门的集群中进行GPU算力互调共享，是当前需要解决的问题。

现状：

• HBox拥有公司大部分GPU算力，未来规划为公司GPU算力的集中管理部门；

• 搜索已经拥有HBox的管理员权限config文件，可以向HBox集群调度GPU pod，但仅限于授权的 node 节点上（通过主机组划分）；

• 商业化部门目前将GPU机器托管在公共集群自行使用，使用率较高；商业化期待使用K8s容器平台进行GPU实例管理；

现状分析：

• 需要一种能力，能够将各部门、集群之间的资源打通，能够互相调用使用，并在一定程度上进行权限控制；

• 这种能力应不破坏当前的GPU使用方式，并符合业界当前技术主流发展方向；

解决方案：

根据当前的分析，目前业界在多租户方向有以下几种常用的解决方案

1. 使用集群内部Namespace & RBAC进行隔离，每个用户有一个独立的命名空间和权限进行隔离

2. 使用虚拟控制平面进行隔离，每个用户使用独立的虚拟apiserver进行资源的控制

3. 多集群解决方案，在多个物理集群中使用虚拟控制平面进行管理

02

 K8S Namespace & RBAC隔离

2.1 原理

通过使用集群内部的RBAC进行控制（K8s原生）；支持以下类型的角色和绑定，通过角色定义资源的访问权限时，仅支持允许访问资源，不支持拒绝访问资源。

• Role：角色，定义对单个命名空间内资源的访问权限。

• RoleBinding：角色绑定，定义用户和角色的关系。

• ClusterRole：集群角色，定义对整个集群内资源的访问权限。

• ClusterRoleBinding：集群角色绑定，定义用户和集群角色的关系。

节点管理示例：

1. 通过集群角色和集群角色绑定实现对节点的部分访问控制（例如实现读写权限控制）

   创建一个集群角色，在其中定义对节点资源的部分权限。例如，只允许查看（get、list）节点的信息，而不允许修改（update、delete）节点。以下是一个简单的集群角色定义示例（YAML 格式），用于允许获取和列出节点信息：

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: view - nodes - rolerules:- apiGroups:  - ""  resources:  - nodes  verbs:  - get  - list

2. 通过节点label进行选择，实现对部分节点授予权限，例如：

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  name: view - gpu - nodes - rolerules:- apiGroups:  - ""  resources:  - nodes  verbs:  - get  - list  resourceNames: []

通过对ClusterRole的设定，并通过ClusterRoleBinding与用户进行绑定，则可对用户进行有限资源的指定访问权限

实现用户想对某一个集群中的某一类节点进行操作，实现当前公司内部的HBox想要对公共集群商业化节点、搜索集群节点的管理

2.2 适用场景

• 多用户和多团队环境下的资源访问控制

  在企业级的 Kubernetes 集群中，往往有多个团队（如开发团队、运维团队、测试团队等）共享集群资源。

  RBAC 可以清晰地划分每个团队对不同资源的访问权限。

• 第三方工具和服务集成时的安全访问

  当企业将一些第三方工具（如 CI/CD 工具，像 Jenkins）集成到 Kubernetes 集群中时，RBAC 可以确保这些工具以安全的方式访问集群资源。

• 隔离不同业务部门或项目的资源访问

  对于大型企业中不同业务部门或者不同项目使用同一 Kubernetes 集群的情况，RBAC 可以很好地隔离它们的资源访问。

• 合规性和审计要求的满足

  在许多行业（如金融、医疗等），有严格的合规性要求，需要对用户的操作和资源访问进行审计。RBAC 提供了明确的权限分配机制，使得审计过程更加容易。

2.3 优缺点

优点

1. 精准权限分配

   RBAC 能够实现非常精细的权限划分，可针对不同用户、用户组或者服务账户，依据具体的资源类型（像 Pod、Service 等）以及各类操作（如创建、读取、更新、删除等）来精准赋予权限。

2. 良好适应性与扩展性

   随着业务发展、组织架构变动或者项目阶段更迭，RBAC 可以灵活地进行调整。无论是新增用户、用户组，还是更改权限需求，都能方便地创建、修改或者删除对应的角色、角色绑定等配置。

3. 无缝生态集成

   作为 Kubernetes 原生的访问控制机制，RBAC 和其他诸多 Kubernetes 组件、工具能完美融合。像在使用 Helm 部署应用时，可依据 RBAC 配置的权限让 Helm 能在相应命名空间按规定操作；还有在通过 kubectl 命令行工具管理集群资源时，RBAC 所设定的权限会规范操作范围，保障整个操作流程的顺畅与安全。

4. 强化安全保障

   通过严格限制访问权限，只有获得授权的主体才能执行相应操作，极大地降低了恶意攻击、误操作等安全隐患。

缺点

1. 管理难度提升

   在规模较大的组织或者复杂项目场景下，要管理众多的角色、角色绑定、集群角色、集群角色绑定等配置，操作极为繁琐。特别是权限需求频繁变动时，需要耗费大量精力去更新和维护这些配置，容易出现错误。

2. 学习成本较高

   对于刚接触 Kubernetes 以及 RBAC 机制的人员来说，需要深入理解诸如角色、资源类型、操作动词等诸多概念，还要掌握如何合理搭配来实现预期权限控制，这需要花费一定时间去学习和实践。就像新入职的运维人员，刚开始面对 RBAC 配置时，可能会因概念不清而多次配置错误，影响正常的资源访问。

3. 跨命名空间管理复杂

   当涉及跨命名空间的权限管理需求时，RBAC 就显得有些吃力了。如果一个用户需要在多个命名空间中执行相同操作，往往需要为每个命名空间单独创建角色绑定，或者构建较为复杂的跨命名空间权限角色及绑定结构，操作起来较为麻烦。例如在一个集团公司，运维人员要管理多个子公司对应的命名空间资源，若想通过 RBAC 合理分配权限且保障安全性，就需要精心设计和不断调整相关配置。

03

虚拟控制平面

虚拟控制平面的标志性产品为vcluster，vcluster是virtualcluster的一种技术实现

原理

vcluster 是一种在 Kubernetes 中创建虚拟集群的技术方案。它允许用户在一个已有的 Kubernetes 集群内部创建多个虚拟的、独立的集群环境，这些虚拟集群就像是物理集群一样，拥有自己独立的 API 服务器、资源管理等功能。

从架构角度看，vcluster 在物理 Kubernetes 集群之上构建了一层抽象，使得每个虚拟集群可以独立地运行应用程序，而不会相互干扰。每个虚拟集群都可以有自己的命名空间、资源配额、RBAC（基于角色的访问控制）策略等，为多租户环境或者开发 / 测试场景提供了很好的隔离性。

• 资源隔离

  vcluster 通过将物理集群的资源进行隔离来创建虚拟集群。它会为每个虚拟集群分配一定的资源，如 CPU、内存、存储等，这些资源在虚拟集群内部进行管理。例如，在一个物理集群中有多个虚拟集群，每个虚拟集群可以根据自身需求申请和使用物理集群中的资源，就像拥有自己独立的资源池一样

• API服务器代理

  vcluster 会为每个虚拟集群创建一个代理的 API 服务器。这个代理 API 服务器使得用户可以像访问真实的 Kubernetes 集群一样访问虚拟集群。当用户向虚拟集群的 API 服务器发送请求时，代理服务器会将请求转发到物理集群的 API 服务器，并对返回的结果进行处理，然后返回给用户

• 命名空间和RBAC管理

  在 vcluster 中，每个虚拟集群都可以有自己独立的命名空间。这些命名空间在虚拟集群内部是全局可见的，但在不同的虚拟集群之间是隔离的。同时，vcluster 支持在虚拟集群内部独立地配置 RBAC 策略

• 核心组件vcluster syncer

• 资源镜像

• 同步对象类型

syncer识别并同步K8s资源，包括但不限于pods、services、deployment、configmap、secrets等，会在虚拟集群和物理集群之间建立镜像关系

• 双向同步

一方面将虚拟集群中的变化同步到物理集群，另一方面将物理集群中的变化同步到虚拟集群，感知物理集群中的实际变化

• 资源映射和转换

由于资源的命名和配置有可能会有差异，syncer会将资源和配置进行一定的转换后同步到物理集群

• 事件处理

• • 事件监听和触发

    vcluster syncer 会在虚拟集群和物理集群中监听各种 Kubernetes 事件，如资源的创建、更新、删除等事件。当在虚拟集群中发生一个事件时，例如创建一个新的 Pod，syncer 会捕获这个事件，并根据事件类型进行相应的处理。

    它会将这个事件转换为物理集群能够理解的操作，然后触发物理集群中的相应资源创建。同样，当在物理集群中发生事件时，syncer 也会监听并将其传递给虚拟集群，确保两个集群中的事件流保持一致。

  • 事件顺序和一致性保障

    为了确保虚拟集群和物理集群之间资源的一致性，vcluster syncer 会关注事件的顺序。它会按照一定的顺序处理同步事件，以避免出现资源状态不一致的情况。

• 安全和权限同步

• • RBAC同步

  • 安全策略同步

适用场景

vcluster的主要使用场景是在一个物理机群上进行多租户的使用

多个集群之间的调度目前没有在官方文档中实现，仅注释了众多需要解决的事情

• 开发和测试环境隔离

  在软件开发过程中，不同的开发团队或者不同的项目可能需要独立的开发和测试环境。vcluster 可以为每个团队或项目创建一个虚拟集群，这些虚拟集群在逻辑上相互独立，就好像每个团队都有自己专属的完整 Kubernetes 集群一样。

• 多租户环境下的资源管理

  在多租户的云服务或者企业内部的共享 Kubernetes 集群场景中，不同的租户（如不同的部门或者不同的客户）需要使用集群资源，但又要保证租户之间的资源划分和安全隔离。

• CI/CD流水线集成

  在持续集成 / 持续交付（CI/CD）的流程中，需要频繁地创建和销毁测试环境，并且要确保测试环境的一致性和独立性。vcluster 可以很好地融入 CI/CD 流水线。

优缺点

优点

• 隔离性好，用户感觉自己拥有一个独立的k8s集群

• 访问控制灵活

• 高度可定制，例如使用的k8s API版本都可以不同

• 单一命名空间封装，一个虚拟集群的所有负载都在一个命名空间内

缺点

• 功能有限，部分功能不支持，底层复杂的，不如网络、存储等复杂场景，有可能不支持

• 存储、网络具有挑战，需要每个虚拟集群有独立的存储管理，网络配置通信可能会有较大的挑战

• 兼容性问题，底层和vcluster之间的版本如果发生变化，有可能会出现不兼容的情况出现

04

多集群管理方案

多集群管理是让用户通过对一个虚拟集群的操作，能将负载发布到不同的物理集群中

目前典型的实现有Kamada、通过VK实现负载下发等

Karmada

架构图

适用场景

• 跨云、跨数据中心管理

  提供资源统一视图、高效应用调度、应用一致性管理

• 边缘计算与中心云协同

  边缘资源整合、中心-边缘应用分发、边缘自治与集中管控平衡

• 多集群高可用和容灾备份

  故障转移、数据备份和恢复协调、健康检测和自愈

缺点

• 偏重的是应用管理，资源管理能力较弱

• 精细化管理能力较弱，主要是调度器、各集群的资源细节无法呈现

Virtual Kubelet

Virtual Kubelet 通过模拟 Kubernetes 节点，实现了 Kubernetes 集群与其他资源管理平台的无缝对接。它不仅支持云平台的弹性伸缩和按需使用，还简化了多集群管理的复杂性。通过灵活的 Provider 机制，Virtual Kubelet 可以轻松扩展到各种场景，包括边缘计算、混合云和多云环境。

优势

• 对 Kubernetes 集群无侵入：Virtual Kubelet 不需要修改 Kubernetes 集群的任何代码

• 灵活的扩展性：通过 Provider 接口，可以轻松对接各种资源管理平台

• 按需使用和按需计费：支持 Serverless 模式，用户只需为实际使用的资源付费

• 简化多集群管理：将多个集群的资源整合成一个大的资源池，便于统一管理

缺点

• 调度限制：虽然 Virtual Kubelet 可以用于多集群管理，但它本质上只是一个转换器，依赖于现有的平台能力

• 服务发现和负载均衡：在某些情况下，Virtual Kubelet 可能无法很好地支持服务发现和负载均衡

架构图

05

总结

综上所述，可根据公司实际需求和技术栈，选择合适的方案。如果希望在现有集群内实现精细权限控制，可选择K8s Namespace & RBAC隔离；若需要更好的隔离性和灵活性，可考虑虚拟控制平面；而多集群管理方案则适合需要跨集群调度和管理的场景。

更多技术干货，

请关注“360智汇云开发者”👇

360智汇云官网：https://zyun.360.cn（复制在浏览器中打开）

更多好用又便宜的云产品，欢迎试用体验~

添加工作人员企业微信👇，get更快审核通道+试用包哦~