📌 项目地址：cilium/cilium | ⭐ 25,327 颗星 | 🔧 Go | 📜 未标注
📌 项目地址：cilium/cilium | ⭐ 25,327 颗星 | 🔧 Go | CNCF 毕业项目
先说结论
如果你维护的 Kubernetes 集群规模上来了，或者你需要“只允许 A 服务访问 B 服务的某个 HTTP 路径”这种粒度的网络策略，Cilium 值得认真评估。如果只是几十个节点的小集群、追求开箱即用，Flannel 这类轻量方案更省心。
它到底做了什么
一句话：Cilium 把 Kubernetes 的网络和安全逻辑从 iptables 搬进了 Linux 内核，靠的是 eBPF。
传统方案（早期 Calico、Flannel）工作在 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/cilium-cilium……不对，是 cilium/cilium-observability，里面有 Cilium 和 Hubble 的 Grafana 看板以及更多演示，可以直接拿来上手。
和其他 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 clustermesh等 CLI 工具的输出怎么看
我的看法
Cilium 是那种“技术选型时绕不开”的项目。Kubernetes 网络、安全、可观测三件事它都做，而且底层思路（eBPF 进内核）代表了这几年的方向。门槛确实存在，但对中大规模集群来说，一次性的学习成本换来的是长期的可控性和观测能力，这笔账算得过来。