📌 项目地址：cilium/cilium | ⭐ 25,327 颗星 | 🔧 Go | 📜 未标注
📌 项目地址：cilium/cilium | ⭐ 25,327 颗星 | Go | CNCF 毕业项目
先给结论
集群规模上来了，或者你需要“只允许 A 服务访问 B 服务的某个 HTTP 路径”这种粒度的策略，Cilium 值得认真评估。几十个节点的小集群、追求开箱即用，Flannel 这类轻量方案更省心。
它解决什么问题
一句话：Cilium 把 Kubernetes 的网络和安全逻辑从 iptables 搬进了 Linux 内核，靠的是 eBPF。
传统方案工作在 IP 和端口层面，策略一变就要批量改 iptables 规则。集群一大，规则数量跟着 Service 数量膨胀，kube-proxy 的 iptables 模式在这点上特别吃亏。Cilium 把数据面逻辑直接挂到内核钩子上执行，绕开了 iptables 这一层。
能力分三块：
- 网络连通：Pod 间路由、负载均衡（可以完全替代 kube-proxy）、多集群互联、网关 API 支持
- 安全策略：基于身份而非 IP 的 Network Policy，规则可以按 Kubernetes Label、DNS 名字、甚至 HTTP 路径来写
- 可观测：Hubble 组件提供流量全景图，不改应用代码、不注入 sidecar，就能看到服务之间的调用关系
身份模型值得多说两句。Cilium 给每个 Pod 分配集群级身份，策略匹配基于身份。好处很直接：Pod 重建后 IP 变了，策略照样生效，不用做 IP 归属推断。
怎么装
README 给的通用命令：
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --version 1.17.4
--namespace kube-system
但 README 自己就承认：这条命令在大多数情况下不够。实际部署要按环境调参数。官方有交互式安装向导（docs.cilium.io 搜 installation），它会根据你的云厂商和内核版本生成对应的 Helm 命令。生产集群务必走向导，别裸装。
装完之后验证：
cilium status --wait
cilium connectivity test
第一条检查组件是否就绪，第二条跑一套完整的连通性测试，覆盖集群内外的各种访问路径。
想深入体验 Hubble 的观测能力，GitHub 上有配套仓库 cilium/hubble，包含 UI、CLI 和文档，可以拿来看服务依赖图和流量日志。
跟其他 CNI 比有什么不一样
- eBPF 原生数据面：Service 多的集群收益最明显，规则数不再随 Service 线性膨胀
- L7 粒度策略：能写到“允许访问 /api 路径”这个级别，Hubble 还能直接看到这些流量
- 功能边界比传统 CNI 宽：无 sidecar 的 Service Mesh、多集群组网、eBPF/XDP 高性能负载均衡，都在这个项目里
代价是复杂度。Cilium 对内核版本有要求，越高越好；排障时你得懂一点 eBPF 的基本原理。学习曲线比 Flannel 陡，这是事实。
上生产前核对几件事
- 内核版本：eBPF 特性依赖内核，CentOS 7 这种老内核可能开不了全部功能，部署前对照官方版本要求查一遍
- 高级功能默认不开：kube-proxy 替换、Bandwidth Manager 这些要显式传参，具体看文档
- 排障准备：出问题时只看 Pod 日志往往不够，提前熟悉
cilium status、cilium-dbg这类 CLI 的输出怎么看
我的看法
Cilium 是技术选型时绕不开的项目。Kubernetes 的网络、安全、可观测三件事它都做，底层思路（eBPF 进内核）也代表了这几年的方向。门槛确实存在，但对中大规模集群来说，一次性的学习成本换来长期的可控性和观测能力，这笔账算得过来。