1. 课程导入与全景认知

在传统数据中心里，网络通常由交换机、路由器和专用防火墙承担转发与安全职责，主机上的 iptables 只是做一层补充。进入 Kubernetes 时代后，Pod 数量动辄成百上千，IP 地址频繁变化，Service、Ingress、NetworkPolicy 等抽象层不断叠加，传统基于 iptables 的 kube-proxy 模式在规则规模膨胀后会出现明显的性能衰减和排障困难。Cilium 正是为解决这一类问题而生的云原生网络、安全与可观测性方案，它的技术底座是 Linux 内核中的 eBPF。

理解 Cilium，首先要理解 eBPF 的定位。eBPF 允许把经过验证的字节码程序动态挂载到内核的钩子点上，例如网卡收包（XDP）、流量控制（tc）、套接字（socket）、cgroup 以及内核跟踪点（kprobe/tracepoint）。这些程序运行在内核态，无需修改内核源码、无需加载内核模块，就能对数据包、系统调用和网络事件进行拦截、改写、统计和转发。Cilium 把网络转发、负载均衡、策略执行、可观测性等能力都实现在 eBPF 程序里，因此它不再依赖庞大的 iptables 规则链，而是用哈希表、LPM trie 等数据结构做 O(1) 或 O(log n) 级别的查找。

从整体架构看，Cilium 由几个关键部分组成。每个节点上运行一个 Cilium Agent（以 DaemonSet 形式部署），它负责监听 Kubernetes API、分配 Pod IP、生成并加载 eBPF 程序、维护 eBPF map。数据面由挂载在内核各钩子点的 eBPF 程序组成，负责实际的转发、NAT、策略判断和监控。Cilium Operator 负责集群级别的地址管理、CRD 协调等任务。Hubble 则从 eBPF 数据面直接采集流日志、服务依赖和策略判定结果，提供网络可观测性。下图展示了这一分层关系与数据流方向。

这张图说明了 Cilium 的关键分工：Agent 是控制面的“翻译官”，把 Kubernetes 的声明式对象翻译成 eBPF 程序和 map 条目；eBPF 数据面是真正的执行者，负责每个数据包的命运；Hubble 从数据面旁路采集信息，形成可观测性。理解这条链路，后续学习 NetworkPolicy、ClusterMesh、BGP、服务网格等能力时就不会迷失方向。

Cilium 的核心价值可以归纳为四点。第一，性能与规模：用 eBPF map 替代线性匹配的 iptables 规则，在数万 Service 规模下仍能保持稳定转发延迟。第二，身份化安全：Cilium 为每组 Pod 分配安全身份（Identity），策略基于身份而非 IP，Pod 重建后 IP 变化不影响策略语义。第三，深度可观测性：Hubble 能直接给出“哪个 Pod 访问哪个服务、被哪条策略允许或拒绝”的流级视图，排障效率远高于抓包加猜。第四，可扩展性：通过 eBPF 钩子可以叠加 L7 策略、加密（WireGuard/IPsec）、带宽管理、BGP 通告等能力，而无需更换数据面。

学习路径建议按“先跑通、再理解、后深入”推进。第一阶段完成环境搭建，让一个最小集群跑起来并观察 Pod 互通；第二阶段理解 eBPF 数据面与 Cilium 的映射关系，掌握 Identity、Endpoint、Policy 等核心对象；第三阶段进入 NetworkPolicy、L7 策略、Hubble 可观测性；第四阶段扩展到 ClusterMesh、BGP、服务网格、性能调优与故障排查。每一阶段都应以“能观察到的现象”为验收标准，而不是只记住概念。

实验环境搭建是本章最需要动手的部分。推荐两种方式：一是本地用 kind 或 minikube 快速起一个单节点集群，适合验证基础功能；二是用多节点虚拟机或云主机搭建三节点集群，便于观察跨节点转发和 ClusterMesh。下面给出一个基于 kind 的最小可用示例，注意这些参数属于教学示例，实际环境需按机器配置调整。

# 1. 安装 kind 与 kubectl（示例版本，按官方文档选择最新稳定版）
# 2. 创建集群，禁用默认 CNI，交给 Cilium 接管
cat <<'EOF' > kind-cilium.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true
  podSubnet: "10.244.0.0/16"
nodes:
  - role: control-plane
  - role: worker
  - role: worker
EOF

kind create cluster --config kind-cilium.yaml --name cilium-lab

# 3. 安装 Cilium CLI 并部署
cilium install --version 1.16.0
cilium status --wait

# 4. 验证连通性与 Hubble
cilium connectivity test
cilium hubble enable --ui

部署完成后，判断环境是否健康的依据有几条：cilium status 应显示 Cilium、Operator、Hubble 均为 OK；kubectl get pods -n kube-system 中 cilium-agent 在每个节点都处于 Running；cilium connectivity test 全部用例通过；cilium hubble ui 能打开并看到流记录。如果 agent 反复重启，优先检查内核版本（建议 5.10 以上）、是否禁用了默认 CNI、以及节点是否可拉取镜像。

最后需要建立一种正确的学习心态：Cilium 的能力大多发生在内核态，很多现象无法只靠 kubectl describe 看清。因此本课程会反复使用 cilium monitor、cilium endpoint list、hubble observe 等工具，把“看不见的内核行为”变成可读的事件流。只要坚持“部署—观察—验证—排障”的循环，就能逐步把 Cilium 从黑盒变成可控、可解释的网络平台。