1. 课程导论：多租户隔离的挑战、Cilium在云原生网络中的角色、蓝图与灰度发布的概念
1.1 多租户隔离的核心挑战
在Kubernetes集群中实现多租户隔离，远不止于创建几个Namespace。传统基于网络策略（NetworkPolicy）的隔离模型在以下场景中暴露出严重不足：
| 挑战维度 | 传统方案痛点 | 多租户场景下的影响 |
|---|---|---|
| 网络边界模糊 | NetworkPolicy仅支持L3/L4，无法感知应用层协议 | 租户间HTTP/gRPC流量无法按路径或方法精细管控 |
| 身份与策略耦合 | 策略依赖Pod IP或CIDR，Pod重建后IP变化导致策略失效 | 租户工作负载频繁滚动更新时，隔离策略出现漂移 |
| 审计与合规缺失 | 缺少租户级流量日志和策略命中记录 | 无法满足金融、医疗等行业对租户间通信的审计要求 |
| 资源竞争不可控 | 缺乏租户粒度的带宽、连接数、QoS保障 | 一个租户的突发流量可能抢占其他租户的网络资源 |
| 策略规模爆炸 | 每个租户独立维护NetworkPolicy，总数随租户数线性增长 | 集群达到数百租户时，etcd和kube-proxy性能急剧下降 |
关键洞察： 传统隔离方案在“身份感知”、“应用层过滤”、“可观测性”和“资源隔离”四个维度上均存在结构性缺陷，无法满足企业级多租户场景下的安全与运维要求。
1.2 Cilium在云原生网络中的角色
Cilium基于eBPF技术，将网络、安全、可观测性能力下沉到Linux内核，为多租户隔离提供了全新的技术栈。其核心角色体现在三个层面：
- 身份驱动的网络策略： 基于Kubernetes ServiceAccount、Pod标签等身份标识定义策略，而非IP地址。Pod重建后身份不变，策略自动生效。
- L3-L7全栈隔离： 支持HTTP、gRPC、Kafka等应用层协议过滤，可在API路径、方法、Header级别实施租户间访问控制。
- 集群网格与加密： 通过CiliumClusterwideNetworkPolicy实现跨节点、跨集群的租户隔离，并支持WireGuard/IPsec透明加密。
为什么选择Cilium？ eBPF允许在不修改内核代码、不重启服务的前提下，动态注入安全策略。这意味着多租户隔离策略可以在毫秒级生效，且对业务Pod完全透明。
1.3 蓝图与灰度发布的概念
在多租户集群中，隔离策略的变更风险极高——一个错误的策略可能导致整个租户的服务中断。为此，我们引入“蓝图”与“灰度发布”机制：
1.3.1 集群模板蓝图
蓝图是一份声明式、可版本化、可复用的集群网络与安全配置模板。它定义了租户的“黄金配置”：
- 基础网络策略： 默认拒绝入站/出站、允许DNS、允许监控探针等。
- 身份与标签规范： 租户标识、环境标签、合规分类。
- 可观测性配置： Hubble流量采集范围、审计日志目标。
- 资源配额： 带宽上限、连接数限制、QoS等级。
1.3.2 灰度发布准入检查
当运维人员提交一份新的CiliumNetworkPolicy或集群蓝图变更时，系统不会立即全量生效，而是经过以下准入检查流水线：
- 静态校验： YAML语法、CRD版本、字段合法性。
- 语义分析： 策略是否与现有蓝图冲突？是否覆盖了必要的白名单规则？
- 模拟执行： 在eBPF Map中模拟策略效果，检查是否会导致合法流量被阻断。
- 灰度生效： 先应用到小规模金丝雀租户，观察Hubble指标和告警。
- 自动回滚： 如果错误率上升或关键指标异常，自动回退到上一版本蓝图。
注意： 灰度发布不是可选项，而是多租户集群的强制性安全机制。没有灰度验证的蓝图变更，可能在几分钟内导致数百个租户的网络中断。本课程后续章节将详细实现每个准入检查步骤的Cilium策略与代码。
1.4 课程核心目标
通过本课程，你将掌握以下能力：
| 模块 | 核心产出 | 技术栈 |
|---|---|---|
| 蓝图设计 | 可复用的CiliumNetworkPolicy模板 | Cilium CRD · YAML · Helm |
| 准入检查 | ValidatingAdmissionWebhook + eBPF模拟器 | Go · Kubernetes Webhook · BPF |
| 灰度发布 | 金丝雀租户 + 自动回滚流水线 | ArgoCD · Hubble · Prometheus |
| 持续验证 | 租户隔离合规扫描与告警 | Kyverno · OPA · Grafana |
接下来的章节，我们将从零搭建一个支持多租户隔离的Cilium集群，并逐步实现蓝图驱动的灰度发布准入检查系统。