Cilium 1.20 介绍与选型指南

Cilium 1.20 介绍与选型指南：eBPF 数据面的 Kubernetes 网络/可观测/安全方案，讲解 eBPF 架构与核心组件，附版本基准（v1.20.4，三条维护线）、K8s 兼容矩阵（1.33–1.36）及与 Calico、Flannel 的社区活跃度量化对比（2026-10-24 实查）与 k3s 场景选型建议。

CiliumKubernetesK3s云原生网络配置k8s2026/10/24

Cilium 1.20 介绍与选型指南

目标：讲清楚 Cilium 是什么、eBPF 架构为什么能同时解决网络与安全两个问题，并给出与 Calico、Flannel 的量化选型对比。本文为选型认知篇：版本号、发布日期、Kubernetes 兼容矩阵、社区活跃度数据全部来自官方文档站与 GitHub 实查，查询日期 2026-10-24；k3s 场景适配建议含本系列部署实测结论（实测过程见本系列部署篇）。

一、Cilium 是什么

Cilium 是一个基于 eBPF 技术的开源网络、可观测性与安全解决方案，用于为 Kubernetes 集群提供 Pod 网络（CNI）、网络策略（NetworkPolicy）与流量可视化能力。它是 CNCF 毕业项目（Graduated），由 eBPF 数据面驱动，是当前云原生网络领域活跃度最高的项目之一。

Cilium 的核心思路与 iptables 时代的 CNI 有本质区别：它不依赖逐条匹配的 iptables 规则链，而是把网络转发、策略过滤、负载均衡的逻辑编译为 eBPF 字节码，动态加载到 Linux 内核中执行，使每个数据包的转发与策略判定都在内核态一次完成。这带来两个直接收益：

  • 性能：绕过 iptables 规则链的线性遍历，转发路径更短，大规模集群（数千节点、数万 Pod）下延迟与 CPU 开销更可控；
  • 规模：服务与策略查找基于内核中的高效 eBPF 哈希表实现，几乎不受规则数量线性增长的拖累，支持高密度服务场景。

💡 技术拓展：Kubernetes CNI 的数据面实现主要有三类路线——

路线代表方案原理取舍
eBPFCilium字节码注入内核，转发/策略/负载均衡在内核态完成性能与可编程性最强，对内核版本有要求（建议 ≥ 4.19）
iptables + 路由CalicoL3 路由 + iptables 策略，可配 BGP 组网纯 L3/L4 高效成熟，L7 需挂 Envoy
简单 overlayFlannelVXLAN/host-gw 打通 Pod 网络最简单稳定，不自带 NetworkPolicy

本文主角 Cilium 采用 eBPF 路线，理由是它把网络、安全、可观测三件事统一在同一内核数据面上，这也是它与另外两条路线拉开差距的根本原因。

Hubble 是 Cilium 的可观测组件，基于 eBPF 数据面天然产出的流量级事件（谁能访问谁、协议是什么、被哪条策略放行/拒绝），提供网络流日志、指标与服务依赖拓扑，不需要在业务 Pod 里插桩。

二、eBPF 架构与核心组件

2.1 eBPF 数据面如何工作

eBPF（extended Berkeley Packet Filter）允许把经过验证器安全检查的字节码动态插入 Linux 内核的多个挂载点（如 XDP、流量控制 TC、socket 层）执行。Cilium 在每个节点上运行一个 Agent，负责把用户期望的网络连通性与策略规则编译成 eBPF 程序与 bpf_map（哈希表），加载到内核：

  • 包处理：入站/出站流量在 XDP/TC 挂载点由 eBPF 程序直接完成路由、封装（VXLAN/Geneve 隧道或原生路由）与策略判定；
  • 身份（Identity）：Cilium 用标签体系为每个工作负载计算安全身份，网络策略按身份而非 IP 生效，Pod 重建换 IP 策略依然命中；
  • 服务负载均衡：eBPF 程序在内核态完成 Service 转发，可完整替代 kube-proxy；
  • 协议感知：借助 Envoy 代理层，策略可下沉到 HTTP/gRPC/Kafka 等 L7 语义（如"允许 GET /api/health，拒绝 POST"）。

对内核版本有要求：生产建议 Linux 内核 4.19 及以上；5.10+ 内核可开启更多特性（带宽管理、BPF 主机路由等）。

2.2 核心组件

Cilium 部署到集群后由以下组件构成（这也是本系列部署实测中 cilium status 展示的组件清单）：

组件部署形态职责
ciliumDaemonSet（每节点）核心 Agent：管理 eBPF 程序/映射、IPAM、NetworkPolicy 执行
cilium-envoyDaemonSet（每节点）Envoy 代理层，承载 L7 策略与协议可见性
cilium-operatorDeployment集群级控制循环：IPAM 运维、节点 CIDR 管理、垃圾回收
hubble-relayDeployment汇聚各节点 Hubble 流量事件，提供集群级观测 API
clustermesh-apiserverDeployment（可选）跨集群互联（ClusterMesh）时启用

2.3 功能全景

依据 Cilium 1.20 官方文档站导航目录，功能面覆盖：

  • 网络连通：VXLAN/Geneve 隧道或原生路由、IPAM 模式（Kubernetes/集群池/ENI 等）、BGP 组网；
  • 网络策略：标准 NetworkPolicy（networking.k8s.io/v1）+ 扩展的 CiliumNetworkPolicy（cilium.io/v2，支持 L7）、CiliumClusterwideNetworkPolicy、Egress Gateway、CiliumCIDRGroup；
  • kube-proxy 替代：Service/NodePort 的 eBPF 转发、本地重定向策略（Local Redirect Policy）、L2 公告与 Node IPAM LB；
  • 可观测：Hubble 流日志与指标、Layer 7 协议可见性、Prometheus/Grafana 集成；
  • 跨集群与接入：ClusterMesh 多集群组网、Service Mesh / Gateway API 支持；
  • 性能：eBPF 数据面（XDP/主机路由）、带宽管理（Bandwidth Manager）、多播（Beta）。

三、版本基准与兼容矩阵（2026-10-24 实查）

3.1 版本现状

以下数据于 2026-10-24 从 Cilium 官方文档站与 GitHub 仓库实查：

项目数据
最新稳定版v1.20.4
在维护版本线1.20.x（当前 1.20.4）、1.19.x（当前 1.19.10）、1.18.x（当前 1.18.16）
v1.20.0 发布日期2026-07-29
v1.19.0 发布日期2026-02-04

从 1.19.0（2026-02-04）到 1.20.0（2026-07-29），主版本节奏约为 每 6 个月一个 minor 版本；稳定后小版本（patch）按缺陷修复持续滚动，1.20 自发布以来已推进到 1.20.4。选型建议跟随最新稳定 minor 的最新 patch（即 1.20.4），旧 minor 只用于尚未完成升级的存量集群。

3.2 Kubernetes 兼容矩阵

Cilium 1.20 官方文档（Kubernetes Compatibility 页）声明：下列 Kubernetes 版本均经过 e2e 测试保证兼容——

Kubernetes 版本k8s NetworkPolicy APICilium CRD
1.33 / 1.34 / 1.35 / 1.36networking.k8s.io/v1cilium.io/v2（CustomResourceDefinition）

官方同时说明：矩阵之外的更旧/更新 Kubernetes 版本，依赖 Kubernetes 自身的前向/后向兼容承诺，不在此保证范围；开发分支会在 Kubernetes 官方当前支持的版本上持续跑 e2e。选型时第一件事就是核对集群 Kubernetes 版本是否落在 1.33–1.36 区间（旧版本集群需要降级选 Cilium 1.18/1.19 维护线，官方文档按 Cilium 版本分别提供兼容页）。

3.3 本系列实测环境对兼容矩阵的验证

本系列部署篇在 k3s v1.36.5+k3s1（对应上游 Kubernetes 1.36，落在 1.20 矩阵内）上完成了 Cilium 1.20.4 的安装与连通性验证，cilium status 全组件 OK、全部 Pod 由 Cilium 托管，实测细节见《Cilium 1.20 部署指南：在 k3s 上安装与验证》。

四、与 Calico、Flannel 的量化对比

对比数据口径：GitHub 仓库徽章与 Releases 页，2026-10-24 实查（stars 数为 GitHub API 当日值，contributors/commit activity 为 shields.io 徽章当日口径）。

4.1 社区活跃度与版本节奏

维度CiliumCalicoFlannel
GitHub Stars25,7117.4k9.6k
贡献者数（contributors）396282246
提交活跃度（commits/月）49339320
最新发布版本v1.20.4v3.33.0v0.28.10
所属基金会CNCF 毕业项目CNCF 孵化项目CNCF 孵化项目

活跃度差距显著：Cilium 的月提交量约为 Calico 的 1.25 倍、Flannel 的 24 倍，贡献者规模三者中最大。Flannel 提交量极低并非"死了"，而是其定位就是最小化 CNI，功能面早已稳定，维护以低频修复为主——选它的人买的是"极简"，而非活跃度。

4.2 能力对比

能力Cilium 1.20CalicoFlannel
数据面eBPF（XDP/TC/socket 层）iptables/Linux 路由（可选 eBPF 数据面）iptables/VXLAN、host-gw
组网模式原生路由或 VXLAN/Geneve 隧道BGP/路由、IPIP/VXLANVXLAN、host-gw
NetworkPolicyL3–L4 全量，L7 经 Envoy 扩展（HTTP/gRPC/Kafka 等）L3–L4 全量，L7 需启用 Envoy 策略层不内置（需搭配其他组件）
kube-proxy 替代支持（eBPF 内核态转发）支持（eBPF 模式）不支持
可观测性Hubble：流日志、指标、L7 可见性、服务拓扑指标与流日志（Calico Cloud 更强）基本无
多集群ClusterMesh 原生支持联邦/隧道多方案无
内核要求建议 ≥ 4.19，5.10+ 特性更全宽松（iptables 路线）宽松
运维复杂度较高（eBPF/内核相关性）中低

4.3 版本节奏对比

  • Cilium：约 6 个月一个 minor（1.19.0 → 1.20.0 间隔约 5.8 个月），patch 滚动快，同时维护三条 minor 线；
  • Calico：版本节奏同样稳定（当前 v3.33.0），采用 yymm 式 minor 编号，维护线较多；
  • Flannel：v0.x 阶段多年，节奏以低频修复为主。

五、k3s 场景选型建议

k3s 内置的默认网络方案是 Flannel（含内置的 NetworkPolicy 控制器）。想在 k3s 上使用 Cilium，需要在 k3s 启动参数中关闭内置组件：

  • --flannel-backend=none：停用内置 Flannel，腾出 CNI 位置；
  • --disable-network-policy：停用内置策略控制器，避免与 Cilium 的策略执行冲突。

本系列部署篇按此方式在 k3s v1.36.5+k3s1 上完成了 Cilium 1.20.4 的完整安装与验证（k3s 的 Kubernetes 版本 1.36 恰好落在 Cilium 1.20 兼容矩阵的边界版本上，实测无兼容问题）。完整的启动参数、安装命令与逐行验证输出见《Cilium 1.20 部署指南：在 k3s 上安装与验证》。

5.1 选型结论

  • 选 Cilium：需要 L7 策略、深度流量可观测（Hubble）、kube-proxy 替代、多集群组网，或集群规模大、对网络性能敏感；前提是内核版本 ≥ 4.19 且团队愿意承担 eBPF 数据面的运维复杂度。边缘与轻量场景（k3s 单节点/少量节点）同样适用，但建议先用部署篇的流程验证内核与网络环境。
  • 选 Calico：需要成熟稳定的 L3/L4 策略与 BGP 组网，内核版本老旧或希望运维负担更小；L7 需求不强时可优先考虑。
  • 选 Flannel：只求 Pod 能互通、环境最简、资源最省，能接受没有内置 NetworkPolicy；常见于纯测试或叠加第三方策略方案的场景。

一句话总结：Flannel 解决"通"，Calico 解决"通 + 隔离"，Cilium 解决"通 + 隔离 + 看得见 + 看得懂"。如果内核条件允许且需要在 k3s 上落地，直接参考本系列部署篇开装。

六、参考链接

本系列导航

  1. Cilium 1.20 介绍与选型指南（本篇）
  2. 《Cilium 1.20 部署指南：在 k3s 上安装与验证》——从零安装与完整验证回显
  3. 《Cilium 1.20 配置参数详解》——三层配置体系与改参数闭环
  4. 《Cilium 1.20 CLI 命令详解：cilium 与 hubble》——两套 CLI 的完整命令实战