📚 课程目录第1章多租户控制面架构概述

1. 多租户控制面架构概述

1.1 多租户概念与核心诉求

多租户（Multi-Tenancy）是一种软件架构模式，允许一个共享的集群或基础设施同时服务于多个相互隔离的“租户”。每个租户可以是团队、项目、业务线或外部客户，拥有独立的资源视图、权限边界和策略空间。

在 Kubernetes 与 Cilium 的语境下，多租户的核心诉求可归纳为以下四个维度：

维度	描述	典型需求
网络隔离	租户之间的流量必须被严格阻断，防止横向移动或数据泄露	禁止跨命名空间通信、禁止 Pod IP 直连
策略自治	租户管理员能自行定义本租户内的网络策略，而不影响其他租户	租户级 CiliumNetworkPolicy、租户级 Identity
资源配额	每个租户消耗的节点、IP、带宽等资源有上限，防止“吵闹邻居”	IP 池划分、带宽限制、节点亲和性
审计与可见性	租户只能看到自己的流量和策略日志，集群管理员能看到全局	Hubble 租户过滤、RBAC 隔离

关键区分：多租户 ≠ 多命名空间。命名空间只是逻辑分组，缺乏跨节点的网络隔离和策略自治能力。Cilium 通过 eBPF 实现的 Identity 机制，才是真正实现租户级网络隔离的技术基石。

1.2 控制面架构定义

“控制面架构”在本课程中特指：Kubernetes 控制面组件（API Server、etcd、Controller Manager）与 Cilium 控制面组件（Cilium Operator、KVStore、Agent）之间的协作拓扑。在多租户场景下，控制面架构需要解决以下关键问题：

策略分发路径：租户策略如何从 API Server 下发到正确的 Cilium Agent？
Identity 管理：不同租户的 Pod 如何获得唯一且隔离的安全 Identity？
KVStore 隔离：是否需要在租户间共享 etcd，还是为每个租户部署独立 KVStore？
Operator 职责：Cilium Operator 如何感知租户边界，避免跨租户的资源协调？

下图展示了多租户控制面架构的核心组件与交互关系：

  架构要点：控制面采用“集中式 API Server + 分布式 Agent”模式。Cilium Operator 负责全局协调（如 IPAM、Identity 分配），而每个节点的 Cilium Agent 独立执行策略。KVStore（etcd）作为状态同步中枢，承载 Identity 和策略的实时分发。

1.3 Cilium 在多租户场景中的角色

Cilium 基于 eBPF 技术，在 Kubernetes 多租户场景中扮演了网络策略引擎、安全 Identity 提供者、可观测性数据源三重角色。其核心能力与租户需求的对应关系如下：

Cilium 能力	对应租户需求	实现机制
Identity 机制	租户间网络隔离	基于 Label 生成 24-bit 安全 ID，绑定到 Pod 网络栈
CiliumNetworkPolicy	租户策略自治	支持 Namespace 级、Cluster 级策略，可限制 Identity 范围
ClusterMesh	跨集群租户通信	多集群共享 Identity 空间，策略可跨集群生效
Hubble	租户级可观测性	基于 Identity 和 Namespace 过滤流量，支持 RBAC 隔离
Bandwidth Manager	租户资源配额	基于 eBPF 的 EDT 算法，精确限制 Pod 出站带宽

下图展示了 Cilium 如何通过 Identity 和策略引擎实现租户间的安全隔离：

重要提醒：Cilium 的 Identity 机制是全局唯一的，默认情况下不同租户的 Pod 即使 Label 不同，也可能被分配到不同的 Identity。但如果没有显式配置 CiliumNetworkPolicy，Kubernetes 默认的“允许所有”策略会导致租户间流量畅通。因此，多租户场景的第一步必须是创建全局默认拒绝策略，后续再按需放行。

1.4 多租户控制面架构的典型部署模式

根据租户隔离的粒度和管理复杂度，多租户控制面架构通常分为以下三种模式：

模式	隔离粒度	控制面共享	适用场景
软隔离模式	命名空间 + 策略	完全共享	内部团队、Dev/Test 环境
硬隔离模式	独立集群或虚拟集群	独立 API Server	金融、医疗等强合规场景
混合模式	共享控制面 + 租户级策略	共享 API Server + 租户 RBAC	SaaS 平台、多产品线