Cilium 与 Calico CNI 链式Chaining部署实战指南eBPF 数据面叠加方案【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本指南讲解如何在已由 Calico 作为基础 CNI 的 Kubernetes 集群上通过CNI Chaining链式配置叠加部署 Cilium让 Calico 继续负责底层网络连通性与 IPAM而由 Cilium 的 eBPF 程序附着在 Calico 创建的 veth 设备上提供 L3/L4 网络可见性、安全策略执行与负载均衡等高级能力。读完本文你将掌握如何编写链式 CNI 配置、以正确的 Helm 参数部署 Cilium并通过cilium status与连通性测试验证整套链路是否工作正常同时理解链式模式下各 CNI 插件在 ADD/DEL/CHECK 调用链中的协作机制。什么是 CNI Chaining为什么需要它CNI chaining 允许 Cilium 与其他 CNI 插件在同一集群内协同工作。其核心分工模式是基础 CNI 插件本场景为 Calico负责底层网络连通性与 IP 地址管理IPAM即它先创建容器网络命名空间、veth 设备并分配 IPCilium作为链中的后续插件不重新分配 IP 或重建网络设备而是将 eBPF 程序附着到基础插件创建的网络设备上以此提供 L3/L4 网络可见性、策略执行Policy Enforcement与其他高级特性。在链式架构下Cilium 的代理Agent依赖 Calico 已经完成的网络规划自身则聚焦于数据路径上的 eBPF 逻辑。这种模式特别适合已经在生产环境使用 Calico、希望渐进式引入 Cilium 的 eBPF 能力如策略与可观测性而不必一次性迁移整个数据面的场景。链式部署的已知限制在与其他 CNI 插件链式使用时Cilium 的部分高级特性会受到限制官方文档明确列出Layer 7 策略L7 PolicyHTTP/gRPC 等七层策略在链式模式下不可用IPSec 加密encryption_ipsec链式模式下无法启用基于 IPSec 的透明加密。这些限制源于链式模式下 Cilium 不接管端点Endpoint的网络命名空间生命周期且数据路径的编排方是基础插件。规划架构时需评估这两项能力是否属于硬性需求。第一步创建 CNI 链式配置ConfigMap创建一个chaining.yaml文件内容基于以下模板。该 ConfigMap 会被 Cilium 代理读取用于生成/etc/cni/net.d/下的 CNI 链式配置apiVersion: v1 kind: ConfigMap metadata: name: cni-configuration namespace: kube-system data: cni-config: |- { name: generic-veth, cniVersion: 0.3.1, plugins: [ { type: calico, log_level: info, datastore_type: kubernetes, mtu: 1440, ipam: { type: calico-ipam }, policy: { type: k8s }, kubernetes: { kubeconfig: /etc/cni/net.d/calico-kubeconfig } }, { type: portmap, snat: true, capabilities: {portMappings: true} }, { type: cilium-cni } ] }对这份配置的逐段解读配置段作用关键字段name: generic-veth链式配置名。该名字与 Helm 的cni.chainingModegeneric-veth对应是 Cilium 识别链式模式的依据namecniVersion: 0.3.1CNI 规范版本决定插件间传递PrevResult的格式cniVersion第一个插件calico基础 CNI负责建网与 IPAMtype、ipam.typecalico-ipam、policy.typek8s、kubernetes.kubeconfig第二个插件portmap端口映射HostPort 支持snat: true启用 SNAT通过capabilities声明对portMappings的支持type、snat、capabilities第三个插件cilium-cniCilium 链式接入点作为链的最后一环读取上游PrevResult并挂载 eBPFtype说明mtu: 1440是模板中的默认取值实际部署时应根据底层网络如 VXLAN、云厂商 overlay 网络的 MTU 情况调整避免因分片影响吞吐。应用该配置kubectl apply -f chaining.yaml从源码实现看cilium-cni在链式模式下会解析这份 JSON。在 plugins/cilium-cni/types/types.go 中NetConfList结构体持有整个plugins数组ReadNetConf会读取配置文件并调用LoadNetConf反序列化为 Cilium 可识别的网络配置结构为后续判断是否进入链式模式做准备。第二步通过 Helm 部署 Cilium首先配置 Helm 仓库。Cilium 官方 chart 可以通过 Helm 仓库或 OCI Registry 获取helm repo add cilium https://helm.cilium.io/也可以使用 OCI 方式直接安装helm install cilium cilium/cilium --version VERSION --namespace kube-systemOCI RegistryQuay.io 与 Docker Hub无需额外配置。接着使用以下参数部署 Cilium 到kube-system命名空间helm install cilium cilium/cilium --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set enableIdentityMarkfalse各参数的语义与配置要点Helm 参数含义为什么这样设置cni.chainingModegeneric-veth启用 CNI 链式模式模式名为generic-veth告诉 Cilium 它是链中的一环且基础设备类型为通用 veth与 ConfigMap 的name一致cni.customConftrue使用用户自定义的 CNI 配置让 Cilium 代理不去覆盖你手动提供的cni-configurationConfigMapcni.configMapcni-configuration指定承载链式 CNI 配置的 ConfigMap 名称指向第一步创建的chaining.yamlroutingModenative路由模式设为原生非隧道模式与 Calico 的 underlay/直连路由架构匹配避免再次封装enableIPv4Masqueradefalse关闭 Cilium 的 IPv4 地址伪装Masquerade伪装职责已由 Calico 数据面承担避免双重 SNATenableIdentityMarkfalse关闭 Cilium 在数据包上打安全身份标记Identity Mark链式模式下由 Calico 处理转发路径Cilium 不参与 mark 的消费关于已有 Pod 的重要注意事项链式配置不会自动应用到集群中已存在的 Pod。具体表现为已存在的 Pod 依然可达Cilium 可以对其做负载均衡即新流量能被正确转发到这些 Pod但策略执行Policy Enforcement不会作用于这些存量 Pod从存量 Pod 发起的流量也不会经过 Cilium 的负载均衡。因此必须重启这些存量 Pod让 kubelet 在重建容器时重新执行 CNI ADD 调用链新的链式配置才会生效。常见的做法是对相关 Deployment/DaemonSet 做滚动重启如kubectl rollout restart。第三步验证安装方式一使用 Cilium CLI先安装最新版 Cilium CLILinux 示例CILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) aarch64 ]; then CLI_ARCHarm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum} sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}检查 Cilium 各组件状态$ cilium status --wait /¯¯\ /¯¯\__/¯¯\ Cilium: OK \__/¯¯\__/ Operator: OK /¯¯\__/¯¯\ Hubble: disabled \__/¯¯\__/ ClusterMesh: disabled \__/ DaemonSet cilium Desired: 2, Ready: 2/2, Available: 2/2 Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2 Containers: cilium-operator Running: 2 cilium Running: 2 Image versions cilium quay.io/cilium/cilium:v1.9.5: 2 cilium-operator quay.io/cilium/operator-generic:v1.9.5: 2运行完整的网络连通性测试$ cilium connectivity test ℹ️ Monitor aggregation detected, will skip some flow validation steps ✨ [k8s-cluster] Creating namespace for connectivity check... (...) --------------------------------------------------------------------------------------------------------------------- Test Report --------------------------------------------------------------------------------------------------------------------- ✅ 69/69 tests successful (0 warnings)若连通性测试 Pod 因 too many open files 部署失败可尝试提高宿主机的 inotify 资源限制后重试。方式二手动使用 kubectl观察 Cilium 相关组件的启动过程$ kubectl -n kube-system get pods --watch NAME READY STATUS RESTARTS AGE cilium-operator-cb4578bc5-q52qk 0/1 Pending 0 8s cilium-s8w5m 0/1 PodInitializing 0 7s coredns-86c58d9df4-4g7dd 0/1 ContainerCreating 0 8m57s coredns-86c58d9df4-4l6b2 0/1 ContainerCreating 0 8m57s等待数分钟后全部组件应进入Running状态。接着部署官方的 connectivity-check 测试套件建议使用独立命名空间kubectl create ns cilium-test kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml该套件会部署一系列 Deployment覆盖多种连通性路径有无 Service 负载均衡、多种网络策略组合等。Pod 名称标明其测试的连通性变体其就绪readiness与存活liveness探针即代表测试成败$ kubectl get pods -n cilium-test NAME READY STATUS RESTARTS AGE echo-a-76c5d9bd76-q8d99 1/1 Running 0 66s echo-b-795c4b4f76-9wrrx 1/1 Running 0 66s echo-b-host-6b7fc94b7c-xtsff 1/1 Running 0 66s host-to-b-multi-node-clusterip-85476cd779-bpg4b 1/1 Running 0 66s pod-to-a-allowed-cnp-58b7f7fb8f-lkq7p 1/1 Running 0 66s pod-to-a-denied-cnp-6967cb6f7f-7h9fn 1/1 Running 0 66s ...单节点集群上检查多节点功能的 Pod 会一直处于Pending状态这是预期行为它们需要至少 2 个节点才能被调度。测试完成后清理命名空间kubectl delete ns cilium-test源码视角cilium-cni 如何识别并执行链式模式理解链式配置的生效机制需要回到cilium-cni插件的实现。在 plugins/cilium-cni/cmd/cmd.go 中插件对 CNI ADD/DEL/CHECK 请求的处理逻辑清晰体现了链式设计的三个关键判断1. 通过PrevResult判断是否为链式调用。CNI 规范规定链中的后续插件会收到前序插件此处为 calico、portmap产出的PrevResult。源码在 ADD 路径上会检查n.NetConf.RawPrevResult是否非空若非空则说明本插件处于链式上下文中进而构建chainingapi.PluginContext并委派给对应的链式实现若没有配置链式模式却收到了PrevResult会直接报错提示 CNI PrevResult supplied, but not in chaining mode -- this is invalid, please set chaining-mode in CNI configuration。2. 依据ChainingMode查找链式插件。函数getChainedActionplugins/cilium-cni/cmd/cmd.go#L1332会通过chainingapi.Lookup(n.ChainingMode)按模式名查找已注册的链式实现未知模式会返回 invalid chaining-mode 错误DEL 与 CHECK 路径的处理逻辑与此对称且注释特别说明 DEL always has PrevResult set删除操作总是携带PrevResult因此不能仅凭PrevResult判断是否链式。3.generic-veth链式实现的实际动作。注册名为generic-veth的链式插件位于 plugins/cilium-cni/chaining/generic-veth/generic-veth.go其Add方法先解析PrevResult获取前序插件Calico创建的网络结果再打开容器网络命名空间netns.OpenPinned在命名空间内遍历网络链路找到类型为veth的接口——这正是 Calico 已创建好的容器侧 veth——Cilium 随即基于该 veth 建立 Endpoint 模型并挂载 eBPF 程序而不会重新配置 IP 或新建虚拟设备。这也从实现层面印证了基础 CNI 负责连通性与 IPAM、Cilium 叠加 eBPF 能力的分工。与之对应Agent 侧通过--cni-chaining-modeCNIChainingMode见 pkg/option/config.go#L465-L466接收链式模式配置数据路径相关代码如 iptables 处理也会针对特定链式模式如aws-cni走不同的逻辑分支说明链式模式是一个贯穿 CNI 插件与 Agent 数据面的全局配置。常见问题排查存量 Pod 无策略保护这是链式模式的预期行为需重启 Pod 使新配置生效。双重 SNAT 导致连通性异常检查是否设置了enableIPv4Masqueradefalse若同时开启 Cilium 与 Calico 的伪装功能可能出现源地址被改写两次的问题。invalid chaining-mode报错确认 Helm 参数cni.chainingMode与 ConfigMap 中name字段一致且 Agent 能读取到自定义 ConfigMapcni.customConftrue与cni.configMap必须同时正确设置。L7 策略 / IPSec 无法生效链式模式的固有限制需回归本指南开头列出的能力边界重新评估方案选型。后续可以做什么验证通过后可以基于这套链式部署进一步探索部署 Hubble 以启用可观测性与 Service Map参考仓库 Documentation/installation 下的 Hubble 相关指南配置 ClusterMesh 实现多集群网络与策略互联通过示例策略文件examples/policies验证链式模式下 L3/L4 策略的执行效果确认策略 Enforcement 在新创建的 Pod 上按预期工作。需要注意的是链式模式中的 L7 策略与 IPSec 加密受限若后续需要这些能力应评估切换到 Cilium 独立接管数据面的部署形态。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cilium 与 Calico CNI 链式（Chaining）部署实战指南：eBPF 数据面叠加方案
Cilium 与 Calico CNI 链式Chaining部署实战指南eBPF 数据面叠加方案【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本指南讲解如何在已由 Calico 作为基础 CNI 的 Kubernetes 集群上通过CNI Chaining链式配置叠加部署 Cilium让 Calico 继续负责底层网络连通性与 IPAM而由 Cilium 的 eBPF 程序附着在 Calico 创建的 veth 设备上提供 L3/L4 网络可见性、安全策略执行与负载均衡等高级能力。读完本文你将掌握如何编写链式 CNI 配置、以正确的 Helm 参数部署 Cilium并通过cilium status与连通性测试验证整套链路是否工作正常同时理解链式模式下各 CNI 插件在 ADD/DEL/CHECK 调用链中的协作机制。什么是 CNI Chaining为什么需要它CNI chaining 允许 Cilium 与其他 CNI 插件在同一集群内协同工作。其核心分工模式是基础 CNI 插件本场景为 Calico负责底层网络连通性与 IP 地址管理IPAM即它先创建容器网络命名空间、veth 设备并分配 IPCilium作为链中的后续插件不重新分配 IP 或重建网络设备而是将 eBPF 程序附着到基础插件创建的网络设备上以此提供 L3/L4 网络可见性、策略执行Policy Enforcement与其他高级特性。在链式架构下Cilium 的代理Agent依赖 Calico 已经完成的网络规划自身则聚焦于数据路径上的 eBPF 逻辑。这种模式特别适合已经在生产环境使用 Calico、希望渐进式引入 Cilium 的 eBPF 能力如策略与可观测性而不必一次性迁移整个数据面的场景。链式部署的已知限制在与其他 CNI 插件链式使用时Cilium 的部分高级特性会受到限制官方文档明确列出Layer 7 策略L7 PolicyHTTP/gRPC 等七层策略在链式模式下不可用IPSec 加密encryption_ipsec链式模式下无法启用基于 IPSec 的透明加密。这些限制源于链式模式下 Cilium 不接管端点Endpoint的网络命名空间生命周期且数据路径的编排方是基础插件。规划架构时需评估这两项能力是否属于硬性需求。第一步创建 CNI 链式配置ConfigMap创建一个chaining.yaml文件内容基于以下模板。该 ConfigMap 会被 Cilium 代理读取用于生成/etc/cni/net.d/下的 CNI 链式配置apiVersion: v1 kind: ConfigMap metadata: name: cni-configuration namespace: kube-system data: cni-config: |- { name: generic-veth, cniVersion: 0.3.1, plugins: [ { type: calico, log_level: info, datastore_type: kubernetes, mtu: 1440, ipam: { type: calico-ipam }, policy: { type: k8s }, kubernetes: { kubeconfig: /etc/cni/net.d/calico-kubeconfig } }, { type: portmap, snat: true, capabilities: {portMappings: true} }, { type: cilium-cni } ] }对这份配置的逐段解读配置段作用关键字段name: generic-veth链式配置名。该名字与 Helm 的cni.chainingModegeneric-veth对应是 Cilium 识别链式模式的依据namecniVersion: 0.3.1CNI 规范版本决定插件间传递PrevResult的格式cniVersion第一个插件calico基础 CNI负责建网与 IPAMtype、ipam.typecalico-ipam、policy.typek8s、kubernetes.kubeconfig第二个插件portmap端口映射HostPort 支持snat: true启用 SNAT通过capabilities声明对portMappings的支持type、snat、capabilities第三个插件cilium-cniCilium 链式接入点作为链的最后一环读取上游PrevResult并挂载 eBPFtype说明mtu: 1440是模板中的默认取值实际部署时应根据底层网络如 VXLAN、云厂商 overlay 网络的 MTU 情况调整避免因分片影响吞吐。应用该配置kubectl apply -f chaining.yaml从源码实现看cilium-cni在链式模式下会解析这份 JSON。在 plugins/cilium-cni/types/types.go 中NetConfList结构体持有整个plugins数组ReadNetConf会读取配置文件并调用LoadNetConf反序列化为 Cilium 可识别的网络配置结构为后续判断是否进入链式模式做准备。第二步通过 Helm 部署 Cilium首先配置 Helm 仓库。Cilium 官方 chart 可以通过 Helm 仓库或 OCI Registry 获取helm repo add cilium https://helm.cilium.io/也可以使用 OCI 方式直接安装helm install cilium cilium/cilium --version VERSION --namespace kube-systemOCI RegistryQuay.io 与 Docker Hub无需额外配置。接着使用以下参数部署 Cilium 到kube-system命名空间helm install cilium cilium/cilium --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set enableIdentityMarkfalse各参数的语义与配置要点Helm 参数含义为什么这样设置cni.chainingModegeneric-veth启用 CNI 链式模式模式名为generic-veth告诉 Cilium 它是链中的一环且基础设备类型为通用 veth与 ConfigMap 的name一致cni.customConftrue使用用户自定义的 CNI 配置让 Cilium 代理不去覆盖你手动提供的cni-configurationConfigMapcni.configMapcni-configuration指定承载链式 CNI 配置的 ConfigMap 名称指向第一步创建的chaining.yamlroutingModenative路由模式设为原生非隧道模式与 Calico 的 underlay/直连路由架构匹配避免再次封装enableIPv4Masqueradefalse关闭 Cilium 的 IPv4 地址伪装Masquerade伪装职责已由 Calico 数据面承担避免双重 SNATenableIdentityMarkfalse关闭 Cilium 在数据包上打安全身份标记Identity Mark链式模式下由 Calico 处理转发路径Cilium 不参与 mark 的消费关于已有 Pod 的重要注意事项链式配置不会自动应用到集群中已存在的 Pod。具体表现为已存在的 Pod 依然可达Cilium 可以对其做负载均衡即新流量能被正确转发到这些 Pod但策略执行Policy Enforcement不会作用于这些存量 Pod从存量 Pod 发起的流量也不会经过 Cilium 的负载均衡。因此必须重启这些存量 Pod让 kubelet 在重建容器时重新执行 CNI ADD 调用链新的链式配置才会生效。常见的做法是对相关 Deployment/DaemonSet 做滚动重启如kubectl rollout restart。第三步验证安装方式一使用 Cilium CLI先安装最新版 Cilium CLILinux 示例CILIUM_CLI_VERSION$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) CLI_ARCHamd64 if [ $(uname -m) aarch64 ]; then CLI_ARCHarm64; fi curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum} sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}检查 Cilium 各组件状态$ cilium status --wait /¯¯\ /¯¯\__/¯¯\ Cilium: OK \__/¯¯\__/ Operator: OK /¯¯\__/¯¯\ Hubble: disabled \__/¯¯\__/ ClusterMesh: disabled \__/ DaemonSet cilium Desired: 2, Ready: 2/2, Available: 2/2 Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2 Containers: cilium-operator Running: 2 cilium Running: 2 Image versions cilium quay.io/cilium/cilium:v1.9.5: 2 cilium-operator quay.io/cilium/operator-generic:v1.9.5: 2运行完整的网络连通性测试$ cilium connectivity test ℹ️ Monitor aggregation detected, will skip some flow validation steps ✨ [k8s-cluster] Creating namespace for connectivity check... (...) --------------------------------------------------------------------------------------------------------------------- Test Report --------------------------------------------------------------------------------------------------------------------- ✅ 69/69 tests successful (0 warnings)若连通性测试 Pod 因 too many open files 部署失败可尝试提高宿主机的 inotify 资源限制后重试。方式二手动使用 kubectl观察 Cilium 相关组件的启动过程$ kubectl -n kube-system get pods --watch NAME READY STATUS RESTARTS AGE cilium-operator-cb4578bc5-q52qk 0/1 Pending 0 8s cilium-s8w5m 0/1 PodInitializing 0 7s coredns-86c58d9df4-4g7dd 0/1 ContainerCreating 0 8m57s coredns-86c58d9df4-4l6b2 0/1 ContainerCreating 0 8m57s等待数分钟后全部组件应进入Running状态。接着部署官方的 connectivity-check 测试套件建议使用独立命名空间kubectl create ns cilium-test kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml该套件会部署一系列 Deployment覆盖多种连通性路径有无 Service 负载均衡、多种网络策略组合等。Pod 名称标明其测试的连通性变体其就绪readiness与存活liveness探针即代表测试成败$ kubectl get pods -n cilium-test NAME READY STATUS RESTARTS AGE echo-a-76c5d9bd76-q8d99 1/1 Running 0 66s echo-b-795c4b4f76-9wrrx 1/1 Running 0 66s echo-b-host-6b7fc94b7c-xtsff 1/1 Running 0 66s host-to-b-multi-node-clusterip-85476cd779-bpg4b 1/1 Running 0 66s pod-to-a-allowed-cnp-58b7f7fb8f-lkq7p 1/1 Running 0 66s pod-to-a-denied-cnp-6967cb6f7f-7h9fn 1/1 Running 0 66s ...单节点集群上检查多节点功能的 Pod 会一直处于Pending状态这是预期行为它们需要至少 2 个节点才能被调度。测试完成后清理命名空间kubectl delete ns cilium-test源码视角cilium-cni 如何识别并执行链式模式理解链式配置的生效机制需要回到cilium-cni插件的实现。在 plugins/cilium-cni/cmd/cmd.go 中插件对 CNI ADD/DEL/CHECK 请求的处理逻辑清晰体现了链式设计的三个关键判断1. 通过PrevResult判断是否为链式调用。CNI 规范规定链中的后续插件会收到前序插件此处为 calico、portmap产出的PrevResult。源码在 ADD 路径上会检查n.NetConf.RawPrevResult是否非空若非空则说明本插件处于链式上下文中进而构建chainingapi.PluginContext并委派给对应的链式实现若没有配置链式模式却收到了PrevResult会直接报错提示 CNI PrevResult supplied, but not in chaining mode -- this is invalid, please set chaining-mode in CNI configuration。2. 依据ChainingMode查找链式插件。函数getChainedActionplugins/cilium-cni/cmd/cmd.go#L1332会通过chainingapi.Lookup(n.ChainingMode)按模式名查找已注册的链式实现未知模式会返回 invalid chaining-mode 错误DEL 与 CHECK 路径的处理逻辑与此对称且注释特别说明 DEL always has PrevResult set删除操作总是携带PrevResult因此不能仅凭PrevResult判断是否链式。3.generic-veth链式实现的实际动作。注册名为generic-veth的链式插件位于 plugins/cilium-cni/chaining/generic-veth/generic-veth.go其Add方法先解析PrevResult获取前序插件Calico创建的网络结果再打开容器网络命名空间netns.OpenPinned在命名空间内遍历网络链路找到类型为veth的接口——这正是 Calico 已创建好的容器侧 veth——Cilium 随即基于该 veth 建立 Endpoint 模型并挂载 eBPF 程序而不会重新配置 IP 或新建虚拟设备。这也从实现层面印证了基础 CNI 负责连通性与 IPAM、Cilium 叠加 eBPF 能力的分工。与之对应Agent 侧通过--cni-chaining-modeCNIChainingMode见 pkg/option/config.go#L465-L466接收链式模式配置数据路径相关代码如 iptables 处理也会针对特定链式模式如aws-cni走不同的逻辑分支说明链式模式是一个贯穿 CNI 插件与 Agent 数据面的全局配置。常见问题排查存量 Pod 无策略保护这是链式模式的预期行为需重启 Pod 使新配置生效。双重 SNAT 导致连通性异常检查是否设置了enableIPv4Masqueradefalse若同时开启 Cilium 与 Calico 的伪装功能可能出现源地址被改写两次的问题。invalid chaining-mode报错确认 Helm 参数cni.chainingMode与 ConfigMap 中name字段一致且 Agent 能读取到自定义 ConfigMapcni.customConftrue与cni.configMap必须同时正确设置。L7 策略 / IPSec 无法生效链式模式的固有限制需回归本指南开头列出的能力边界重新评估方案选型。后续可以做什么验证通过后可以基于这套链式部署进一步探索部署 Hubble 以启用可观测性与 Service Map参考仓库 Documentation/installation 下的 Hubble 相关指南配置 ClusterMesh 实现多集群网络与策略互联通过示例策略文件examples/policies验证链式模式下 L3/L4 策略的执行效果确认策略 Enforcement 在新创建的 Pod 上按预期工作。需要注意的是链式模式中的 L7 策略与 IPSec 加密受限若后续需要这些能力应评估切换到 Cilium 独立接管数据面的部署形态。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考