Cilium Generic Veth CNI Chaining在任意 veth 模型 CNI 插件之上叠加 eBPF 网络能力【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本文介绍 Cilium 的 Generic Veth Chaining通用 veth 链路模式如何在任意基于 veth 设备模型的第三方 CNI 插件如 Flannel、Weave、AWS CNI、Azure CNI 等之上通过 CNI Chaining 让 Cilium 以cilium-cni链式插件的形式叠加 eBPF 数据路径从而获得 L3/L4 网络可见性与策略执行能力。读完本文你将掌握 veth 设备模型的验证方法、chaining ConfigMap 的编写、Helm 参数的正确组合以及该模式下 Layer 7 策略与 IPsec 加密等高级功能的限制边界。什么是 Generic Veth ChainingCNI Chaining 允许 Cilium 与其他 CNI 插件在同一网络命名空间中共存。在 Cilium 的 CNI Chaining 模式下基础网络连通性与 IP 地址管理由非 Cilium 的 CNI 插件负责Cilium 则将 eBPF 程序附加到该插件创建的网络设备上提供网络可见性、策略执行及其他高级功能参见 Documentation/installation/cni-chaining.rst。Generic Veth Chaining 是其中适用面最广的一种形态它使 CNI Chaining 能够叠加在任何采用 veth 设备模型的 CNI 插件之上而绝大多数 CNI 插件使用的正是这种模型。与针对特定插件编写的专用 chaining 插件如 aws-cni、azure-cni、calico、weave不同generic-veth 不关心上层插件是谁只要它最终通过 veth 对把 Pod 接入主机网络即可。从源码看 generic-veth 的注册与定位在 plugins/cilium-cni/chaining/generic-veth/generic-veth.go 中插件通过init()函数向 chaining 框架注册自己func init() { chainingapi.Register(generic-veth, GenericVethChainer{}) }注册表定义在 plugins/cilium-cni/chaining/api/api.go每个 chaining 插件必须实现ChainingPlugin接口的四个方法AddCNI ADD 时创建端点、DeleteCNI DELETE 时删除端点、CheckCNI CHECK 时校验端点健康、StatusCNI STATUS 时检查 daemon 可用性。当 CNI 配置中携带chaining-mode时plugins/cilium-cni/cmd/cmd.go 中的getChainedAction会通过chainingapi.Lookup(n.ChainingMode)查找对应实现同时它支持隐式推断——当 CNI 网络名称既不是默认的cilium也不是portmap时会直接按网络名查找 chaining 插件。这解释了为什么文档中的配置把网络名直接命名为generic-veth。第一步验证现有 CNI 插件确实使用 veth 设备模型在开始 chaining 之前必须确认底层 CNI 插件使用的是 veth 设备模型否则 generic-veth 插件无法工作。验证步骤使用 SSH 登录任意一个工作节点执行ip -d link列出节点上的全部网络设备找出代表该节点上 Pod 的网络设备一个典型的 veth 设备输出形如103: lxcb3901b7f9c02if102: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 3a:39:92:17:75:6f brd ff:ff:ff:ff:ff:ff link-netnsid 18 promiscuity 0 veth addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535第 3 行中的veth关键字表明该网络设备类型为虚拟以太网virtual ethernet。只有当设备类型是 veth 时generic-veth 插件才适用。如果底层插件当前并未使用 veth则 generic-veth 不适用此时需要能理解底层插件设备模型的完整 CNI Chaining 插件。从源码结构看plugins/cilium-cni/chaining/ 目录下已为 aws-cni、azure、flannel 等提供了专用实现可作为编写自有 chaining 插件的参考模板。第二步创建 CNI Chaining 配置ConfigMap基于以下模板创建chaining.yaml用于声明期望的 CNI Chaining 配置apiVersion: v1 kind: ConfigMap metadata: name: cni-configuration namespace: kube-system data: cni-config: |- { name: generic-veth, cniVersion: 0.3.1, plugins: [ { type: XXX, [...] }, { type: cilium-cni, chaining-mode: generic-veth } ] }要点说明name设为generic-veth如上文源码分析当网络名不是cilium或portmap时getChainedAction会按网络名隐式查找 chaining 插件因此网络名generic-veth与显式chaining-mode: generic-veth是等效且互相印证的type为XXX的第一段插件替换为实际底层 CNI 插件如flannel、weave、aws-cni等及其完整参数它负责分配 IP 与建立基础连通性type为cilium-cni的第二段插件即 Cilium 自身chaining-mode: generic-veth显式声明链式模式配置以cni-config键写入 ConfigMap 的data中键名与 Helm 参数cni.configMapKey的默认值一致。应用该 ConfigMapkubectl apply -f chaining.yaml第三步通过 Helm 部署 Cilium 并启用 chaining首先添加 Helm 仓库Cilium 官方 Chart 仓库参见 Documentation/installation/k8s-install-download-release.rsthelm repo add cilium https://helm.cilium.io/随后在kube-system命名空间部署 Cilium并设置以下关键参数helm install cilium cilium/cilium --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse各参数的作用与含义Helm 参数值说明cni.chainingModegeneric-veth将 Cilium 配置为 generic-veth 链式插件可选值包括aws-cni、azure、flannel、portmap等参见 install/kubernetes/cilium/values.yamlcni.customConftrue跳过 Cilium 对 CNI 配置文件的默认写入允许使用外部自动化管理的 CNI 配置默认值为falseinstall/kubernetes/cilium/values.yamlcni.configMapcni-configuration指定存放 CNI 配置的 ConfigMap 名称agent 启动时会将其中的cni-config键内容写为节点上的 CNI 配置文件install/kubernetes/cilium/values.yamlroutingModenative使用原生路由模式依赖 Linux 内核自身的路由栈转发流量enableIPv4Masqueradefalse关闭 IPv4 源地址伪装因为底层 CNI 插件已负责 IP 分配与出站路径避免二次 NAT 破坏连通性补充说明如果仅设置cni.chainingTarget网络名Helm 会隐式假定 chaining 模式为generic-veth作为特例aws-cni的 chainingTarget 隐式对应aws-cni模式详见 install/kubernetes/cilium/values.yaml。Generic Veth Chaining 的底层工作原理从 plugins/cilium-cni/chaining/generic-veth/generic-veth.go 的Add实现可以还原完整的执行流程解析前一插件结果通过cniVersion.ParsePrevResult与cniTypesVer.NewResultFromResult读取底层 CNI 插件第一段type: XXX返回的PrevResult从中获得接口、IP 等拓扑信息打开 Pod 网络命名空间netns.OpenPinned进入 Pod 所在 netns遍历其中的链路找到类型为veth的设备采集其 MAC、IPv4/IPv6 地址IPv6 优先取全局单播地址并通过netlink.VethPeerIndex找到主机侧的 veth peer可选调整路由 MTU当EnableRouteMTU或EnableRouteMTUForCNIChaining开启时遍历命名空间内的 IPv4/IPv6 路由并把 MTU 统一替换为RouteMTU配置值构建 EndpointChangeRequest将主机侧 MAC、接口索引、容器侧接口名与 MAC、Pod 元数据名称/命名空间/UID一并提交给 Cilium agent其中DatapathConfiguration明确声明了四个关键特性RequireArpPassthrough: true——ARP 在 Linux 与 Pod 之间直通RequireEgressProg: true——路由直接指向 Pod 的 veth需要安装面向主机的出口程序以实施入口策略并提供反向 NATExternalIpam: true——IP 由外部插件管理Cilium 不参与地址管理RequireRouting: disabled值为false——所有路由交由 Linux 协议栈完成同步 MAC 地址若 agent 返回的新端点 MAC 与 veth 当前 MAC 不一致则在 Pod 命名空间内更新接口 MAC 并同步到PrevResult最终把PrevResult作为本插件的返回值向上传递。Delete与Check则保持轻量删除时通过EndpointDelete清理端点客户端故障视为致命错误其余告警后继续检查时向 agent 请求端点健康状态并据此判定 CNI CHECK 是否通过。已知限制与其他 CNI 插件链式共存时Cilium 的部分高级特性会受到限制详见 Documentation/installation/cni-chaining-limitations.rstLayer 7 策略L7 Policy在 chaining 场景下不可用IPsec 加密encryption_ipsec同样在 chaining 场景下受限。在规划网络架构时需提前确认如果工作负载依赖 L7 策略或 IPsec应评估是否适合采用 generic-veth chaining或考虑让 Cilium 独立作为主 CNI 的部署方式。小结与部署检查完成以上三步验证 veth 模型 → 应用chaining.yamlConfigMap → Helm 部署后Cilium 即以链式插件身份运行在底层 CNI 之上底层插件负责 IPAM 与基础连通性Cilium 负责附加 eBPF 程序提供 L3/L4 可见性与策略执行。部署后可参考 Documentation/installation/k8s-install-validate.rst 运行连通性验证并留意日志中Using chained plugin的提示该日志来自 plugins/cilium-cni/cmd/cmd.go确认 chaining 模式已正确生效。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考