Cilium CNI Chaining 完全指南与 AWS VPC CNI、Azure CNI、Calico、Weave Net 等插件共存的混合部署实战【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文基于 Cilium 官方安装文档Documentation/installation/cni-chaining.rst及其关联子文档编写系统讲解CNI ChainingCNI 链式编排这一核心部署模式让 Cilium 与其他 CNI 插件在同一集群中协同工作由非 Cilium 插件负责基础网络连通性与 IP 地址管理IPAM而 Cilium 则通过 eBPF 程序挂载到对方插件创建的网络设备上提供 L3/L4 网络可见性、策略执行、负载均衡与加密等高级能力。读完本文你将掌握 CNI Chaining 的工作原理、通用限制、基于 ConfigMap 的链式配置编写方法以及分别在 AWS VPC CNI、Azure CNI、Calico、Weave Net、Oracle OKE 等主流插件之上部署 Cilium 的完整实战步骤与关键 Helm 参数并学会处理“重启既有 Pod”与卸载清理等常见运维场景。适用前提本文面向 Kubernetes 集群中已部署其他 CNI 插件、希望在其之上叠加 Cilium 安全/可观测性能力的场景。所有命令与参数以当前仓库Documentation/installation/目录下的安装文档为准使用 Helm v3 部署。CNI Chaining 是什么核心模型谁负责什么CNI ChainingCNI 链式编排允许 Cilium 与其他 CNI 插件组合使用。在链式模式下非 Cilium CNI 插件负责基础网络连通性的建立以及 IP 地址管理IPAM。例如 AWS VPC CNI 通过 ENI 管理 Pod IPAzure CNI 负责虚拟网络设备与地址分配Calico 通过其 IPAM 分配地址。Cilium CNI 插件在非 Cilium 插件完成初始网络设置之后被调用将 eBPF 程序挂载到对方插件创建的网络设备上从而提供L3/L4 网络可见性Documentation/installation/cni-chaining-aws-cni.rst原文表述为 L3/L4 network visibility网络策略执行Network Policy Enforcement负载均衡Load-Balancing加密Encryption。从源码结构看Cilium 的 CNI 插件支持链式模式的核心逻辑位于plugins/cilium-cni目录CNI 配置中的chaining-mode字段在 types.go 中定义插件在cmd.go中通过chainingapi.Lookup(n.ChainingMode)查找对应的链式实现若配置了不支持的 chaining-mode 会报invalid chaining-mode错误见 cmd.go。同时cmd.go 中还有一项关键校验如果 CNI 提供了PrevResult即前面已有插件执行结果但 Cilium 并未处于 chaining 模式会报错 CNI PrevResult supplied, but not in chaining mode。链式执行顺序插件数组的先后次序CNI Chaining 的本质是把多个 CNI 插件按顺序放入同一个 conflistCNI 配置列表的plugins数组中kubelet 会按数组顺序依次调用。从各官方指南的配置模板中可以总结出典型顺序主 CNI 插件如azure-vnet、calico、weave-net、oci-ptp等创建网络设备并完成 IPAMportmap插件可选提供 HostPort 能力配置capabilities: {portMappings: true}cilium-cni插件作为链中最后一个插件挂载 eBPF 程序、执行策略与负载均衡。例如 Azure CNI 的链式配置将azure-vnet、portmap、cilium-cni三者串联见下文 Azure 一节。通用限制链式模式下哪些高级功能受限在与其他 CNI 插件链式组合时Cilium 的部分高级功能可能受限。Documentation/installation/cni-chaining-limitations.rst明确列出了两类Layer 7 PolicyL7 策略即 HTTP/gRPC 等七层协议策略对应仓库中的l7_policy文档章节IPsec 加密encryption_ipsec即基于 IPsec 的传输加密功能。这是所有 CNI Chaining 场景的通用约束下文各具体插件指南中均通过.. include:: cni-chaining-limitations.rst引入此段内容。因此如果你需要上述高级功能应优先考虑完全迁移到 Cilium 作为唯一 CNI。通用部署流程ConfigMap 与 Helm 参数虽然各插件指南略有差异但整体流程一致可归纳为三步第一步编写链式 CNI 配置ConfigMap大多数场景Azure、Calico、Weave Net、generic-veth要求手工创建一个名为chaining.yaml的 ConfigMap其data.cni-config字段内嵌一个符合 CNI 规范的 JSON conflistapiVersion: 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 } ] }部署该 ConfigMapkubectl apply -f chaining.yaml该 ConfigMap 会被安装为所有节点上的 CNI 配置文件Azure 指南原文“This ConfigMap will be installed as the CNI configuration file on all nodes and defines the chaining configuration”并定义了链式配置内容。第二步通过 Helm 部署 Cilium 并指定链式模式官方指南均使用如下 Helm 参数组合以 generic-veth 链式为例helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse各参数的作用与适用场景Helm 参数作用典型取值cni.chainingMode指定链式模式aws-cni、azure-cni、generic-veth、portmap等cni.customConftrue告知 Cilium 使用自定义手工管理的 CNI 配置而非自行生成truecni.configMapcni-configuration指向存放链式 conflist 的 ConfigMap 名称cni-configurationcni.exclusivefalse让 Cilium 不独占 CNI 配置目录保留对方插件的 DaemonSet 控制权falseroutingModenative关闭隧道overlay模式因为 Pod IP 在底层网络VPC/VCN中可直接路由nativeenableIPv4Masqueradefalse关闭 IPv4 伪装masquerade理由同上false从源码层面看这些参数与 Cilium agent 的pkg/option/config.go中的命令行选项一一对应cni-chaining-modeCNIChainingModeconfig.go与cni-chaining-targetCNIChainingTargetconfig.go。前者配置 Cilium 与哪个 CNI 插件链式组合后者则指定 Cilium 应该合并进入的既有 CNI 网络名称用于 OKE 这类自动注入场景。第三步重启既有 Pod新 CNI 链式配置不会作用于集群中已经运行的任何 Pod。官方文档反复强调既有 Pod 依然可达Cilium 会负载均衡到它们但不会对来自它们的流量执行策略与负载均衡。因此必须重启这些 Pod使链式配置得以生效。可以使用以下脚本检查哪些 Pod 需要重启基于 CEP 与 Pod 列表的差集计算来自cni-chaining-aws-cni.rst与cni-chaining-oracle-oke.rstfor ns in $(kubectl get ns -o jsonpath{.items[*].metadata.name}); do ceps$(kubectl -n ${ns} get cep \ -o jsonpath{.items[*].metadata.name}) pods$(kubectl -n ${ns} get pod \ -o custom-columnsNAME:.metadata.name,NETWORK:.spec.hostNetwork \ | grep -E \s(none|false) | awk {print $1} | tr \n ) ncep$(echo ${pods} ${ceps} | tr \n | sort | uniq -u | paste -s -d -) for pod in $(echo $ncep); do echo ${ns}/${pod}; done done该脚本遍历所有命名空间对比kubectl get cepCiliumEndpoint与运行中非 hostNetwork的 Pod 列表找出没有对应 CEP 的 Pod——这些就是尚未被 Cilium 纳管的存量 Pod需要重启。场景一与 AWS VPC CNI 插件链式组合EKS架构与职责划分在 AWS 混合模式下AWS VPC CNI 插件负责创建虚拟网络设备以及通过 ENI 进行 IP 地址管理IPAM初始网络设置完成后Cilium CNI 插件被调用将 eBPF 程序挂载到 AWS VPC CNI 创建的网络设备上以实现网络策略执行、负载均衡与加密Documentation/installation/cni-chaining-aws-cni.rst。由于 ENI 分配的 Pod IP 可以直接在 VPC 内路由因此无需隧道tunneling也无需开启 masquerade。前置条件AWS VPC CNI 插件版本请确保 AWS VPC CNI 插件版本为1.11.2 或更新以保证与 Cilium 的兼容性。可通过以下命令检查当前版本$ kubectl -n kube-system get ds/aws-node -o json | jq -r .spec.template.spec.containers[0].image 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.11.2如果运行的是更旧版本可以升级$ kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.11/config/master/aws-k8s-cni.yaml部署步骤1. 准备 EKS 集群按照 Kubernetes 安装快速指南在 AWS 上创建 EKS 集群或使用任何你喜欢的方式在 AWS 上搭建 Kubernetes 集群。若使用 EKSaws-vpc-cni-k8s插件通常已预装但仍需按上文确保版本足够新。2. 下载 Cilium release参考Documentation/installation/k8s-install-download-release.rst。3. 通过 Helm 部署 Ciliumhelm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModeaws-cni \ --set cni.exclusivefalse \ --set enableIPv4Masqueradefalse \ --set routingModenative参数说明cni.chainingModeaws-cni启用与 AWS VPC CNI 插件的链式组合cni.exclusivefalseCilium 不独占 CNI 配置目录enableIPv4MasqueradefalseENI 的 Pod IP 可在 VPC 内直接路由因此无需伪装routingModenative无需隧道因为 ENI IP 可在 VPC 内直接路由。4. 重启既有 Pod使用上文通用脚本然后参考Documentation/installation/k8s-install-validate.rst验证安装。高级启用 EKS Security Groups for PodsCilium 可以在链式模式下与 EKS 的security groups for pods特性协同工作适用于受支持的集群。启用步骤如下前提需要已安装并配置好jq与 AWS CLI。步骤一为 EKS 集群关联的 IAM 角色附加AmazonEKSVPCResourceController托管策略export EKS_CLUSTER_NAMEmy-eks-cluster # Change accordingly export EKS_CLUSTER_ROLE_NAME$(aws eks describe-cluster \ --name ${EKS_CLUSTER_NAME} \ | jq -r .cluster.roleArn | awk -F/ {print $NF}) aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController \ --role-name ${EKS_CLUSTER_ROLE_NAME}步骤二确保集群中运行的 AWS VPC CNI 插件版本足够新kubectl -n kube-system get ds/aws-node \ -o jsonpath{.spec.template.spec.containers[0].image} 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.7.10步骤三patchkube-system/aws-nodeDaemonSet 以启用 security groups for podskubectl -n kube-system patch ds aws-node \ -p {spec:{template:{spec:{initContainers:[{env:[{name:DISABLE_TCP_EARLY_DEMUX,value:true}],name:aws-vpc-cni-init}],containers:[{env:[{name:ENABLE_POD_ENI,value:true}],name:aws-node}]}}}} kubectl -n kube-system rollout status ds aws-node步骤四验证节点 trunk 标签。rollout 完成后集群中所有节点应带有vpc.amazonaws.com/has-trunk-attached标签且值为truekubectl get nodes -L vpc.amazonaws.com/has-trunk-attached NAME STATUS ROLES AGE VERSION HAS-TRUNK-ATTACHED ip-192-168-111-169.eu-west-2.compute.internal Ready none 22m v1.19.6-eks-49a6c0 true ip-192-168-129-175.eu-west-2.compute.internal Ready none 22m v1.19.6-eks-49a6c0 true此后即可将安全组关联到 Pod具体关联方法参考 AWS EKS 官方文档此处不再展开。场景二与 Azure CNILegacy链式组合AKS背景与适用性说明官方文档指出对大多数用户而言在 AKS 上运行 Cilium 的最佳方式是AKS BYO CNI或使用Azure CNI Powered by CiliumAzure 官方基于 Cilium 数据面的托管方案。本文的链式配置是运行 Azure CNI Cilium 的传统legacy方式因为 Azure IPAM 属于遗留方案。职责划分混合模式下Azure CNI 插件负责创建虚拟网络设备与地址分配IPAM初始网络设置完成后Cilium CNI 插件被调用将 eBPF 程序挂载到 Azure CNI 创建的网络设备上以实现网络策略执行、负载均衡与加密。创建 AKS Cilium CNI 链式配置创建chaining.yaml内容基于以下模板。示例中 Azure CNI、portmap 与 Cilium 三者链式组合apiVersion: v1 kind: ConfigMap metadata: name: cni-configuration namespace: kube-system data: cni-config: |- { cniVersion: 0.3.0, name: azure, plugins: [ { type: azure-vnet, mode: transparent, ipam: { type: azure-vnet-ipam } }, { type: portmap, capabilities: {portMappings: true}, snat: true }, { name: cilium, type: cilium-cni } ] }部署 ConfigMapkubectl apply -f chaining.yaml部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.exclusivefalse \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set endpointRoutes.enabledtrue注意点这里虽然使用 Azure CNI但cni.chainingMode取值为generic-veth因为 Azure CNI 的设备模型同样是 vethgeneric-veth 链式插件足以适配。同时通过cni.configMapcni-configuration让 Cilium 读取上面创建的 ConfigMap。随后参考Documentation/installation/k8s-install-restart-pods.rst重启既有 Pod并按k8s-install-validate.rst验证。场景三与 Calico 链式组合创建 CNI 配置创建chaining.yaml文件基于以下模板指定链式配置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 } ] }部署 ConfigMapkubectl apply -f chaining.yaml部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set enableIdentityMarkfalse其中enableIdentityMarkfalse用于关闭 Cilium 的 identity mark在与其他 CNI 链式组合时避免标记冲突。随后验证安装并重启既有 PodCalico 指南同样强调既有 Pod 不受策略管控、必须重启。场景四Generic Veth Chaining通用 veth 链式插件适用范围与前置验证generic-veth 链式插件允许在任意使用veth 设备模型的 CNI 插件之上启用 CNI 链式组合——而大多数 CNI 插件都采用这种模型。在部署前请先验证当前 CNI 插件确实使用 vethSSH 登录到某个工作节点运行ip -d link列出节点上的所有网络设备应能发现代表该节点上 Pod 的网络设备网络设备看起来可能类似这样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。若当前链式的 CNI 插件未使用 veth则 generic-veth 插件不适用。此时需要一个能理解底层插件设备模型的完整 CNI 链式插件编写此类插件并不复杂。创建链式 CNI 配置创建chaining.yaml将XXX替换为你的主 CNI 插件类型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 } ] }部署 ConfigMap 后通过 Helm 部署 Cilium参数与 Calico 场景一致cni.chainingModegeneric-veth、cni.customConftrue、cni.configMapcni-configuration、routingModenative、enableIPv4Masqueradefalse随后验证并重启既有 Pod。从源码看generic-veth 链式实现注册在 plugins/cilium-cni/chaining/generic-veth 包中作为独立实现被 CNI 插件默认导入对应cmd.go中的chainingapi.Lookup分发逻辑。场景五与 Weave Net 链式组合创建 CNI 配置创建chaining.yaml文件基于以下模板指定链式配置apiVersion: v1 kind: ConfigMap metadata: name: cni-configuration namespace: kube-system data: cni-config: |- { cniVersion: 0.3.1, name: weave, plugins: [ { name: weave, type: weave-net, hairpinMode: true }, { type: portmap, capabilities: {portMappings: true}, snat: true }, { type: cilium-cni } ] }部署 ConfigMapkubectl apply -f chaining.yaml部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse随后按k8s-install-validate.rst验证安装并重启既有 Pod。场景六Oracle OKE VCN-Native Pod Networking 自动注入工作原理chainingTarget 自动合并Oracle Kubernetes EngineOKE的VCN-Native Pod Networking是 Oracle 推荐的 OKE 生产级 CNI 模式Pod IP 直接取自 VCN 子网Pod 无需 overlay 即可原生路由相当于 AWS VPC CNI 或 Azure CNI 的 Oracle 版本。其 CNI 栈依次运行两个插件oci-ipvlan通过 OCI IPAM 从 VCN 子网分配 Pod IP并管理底层计算实例上的 VNIC 挂载oci-ptp在 Pod 网络命名空间与宿主机之间创建 veth 对。注意尽管插件名为oci-ipvlan实际面向 Pod 的接口是标准 veth 对。Pod 获得 VCN 原生 IP宿主机持有每 Pod 的 veth 对端路由使用位于169.254.1.1的 proxy-ARP 网关——该模型与 AWS VPC CNI 功能上等价。Cilium 通过generic-veth链式模式作为链中的第三个插件运行。与前述场景不同OKE 场景无需手工创建 CNI ConfigMap当设置cni.chainingTargetoci时Cilium agent 会发现在每个节点上已存在的名为oci的 conflist将自身合并进插件数组并把结果写入/etc/cni/net.d/05-cilium.conflist。原始的10-oci.conflist不会被修改检查该文件看不到cilium-cni条目。由于05-cilium.conflist在字典序上先于10-oci.conflistkubelet 会自动为所有新 Pod 使用它。前置条件启用 VCN-Native Pod Networking 的 OKE 集群非 Flannel配置好并指向集群的kubectlHelm v3。部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingTargetoci \ --set cni.exclusivefalse \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set kubeProxyReplacementfalse \ --set ipam.modecluster-pool \ --set ipam.operator.clusterPoolIPv4PodCIDRList100.64.0.0/16参数说明cni.chainingTargetoci告知 Cilium agent 找到现有 OCI CNI conflist 并自动注入自身routingModenativePod IP 可在 VCN 内直接路由因此关闭隧道enableIPv4MasqueradefalseOCI 在 VCN 层面处理路由因此关闭伪装cni.exclusivefalseCilium 不接管 CNI 配置目录将控制权保留给 OKE 的vcn-native-ip-cniDaemonSetkubeProxyReplacementfalseOKE 默认运行kube-proxy此参数保留它若希望 Cilium 替代 kube-proxy可在链式设置稳定后参考 kubeproxy-free 指南ipam.operator.clusterPoolIPv4PodCIDRList100.64.0.0/16使用 RFC 6598 CGNAT 网段不与 VCN 子网冲突仅供 Cilium 内部使用实际 Pod IP 始终由 OCI IPAM 从 VCN 子网分配。重启既有 Pod与前述场景相同链式配置不会作用于已运行的 Pod。使用上文通用的 CEP/Pod 差集脚本找出需要重启的 Pod。卸载注意事项重要$ helm uninstall cilium -n kube-system警告helm uninstall只移除 Kubernetes 资源不会清理写入节点主机路径的文件。/etc/cni/net.d/05-cilium.conflist在卸载后仍会留在每个节点上。由于它在字典序上先于10-oci.conflistkubelet 会继续为新 Pod 使用它。此时 Cilium agent 已不存在cilium-cni无法连接其 socket新 Pod 将卡在 ContainerCreating报错为dial unix /var/run/cilium/cilium.sock: connect: no such file or directory已运行的 Pod 不受影响因为 CNI 只在 Pod 创建时被调用。卸载后需要 SSH 到每个节点删除该文件$ sudo rm -f /etc/cni/net.d/05-cilium.conflist之后 OKE 的vcn-native-ip-cniDaemonSet 将重新通过10-oci.conflist处理所有新 Pod 的网络。场景七用 portmap 链式启用 HostPortkubeProxyReplacementfalse 时背景从 Cilium 1.8 开始Kubernetes HostPort 特性已通过 Cilium 基于 eBPF 的 kube-proxy replacement 原生支持不再需要 CNI chaining。但存在一种例外当 Cilium 以kubeProxyReplacementfalse部署时可以通过与实现 HostPort 的portmap 插件进行 CNI 链式组合来启用 HostPort。本场景即针对这种链式情况。部署步骤1. 安装 portmap 二进制部分 Kubernetes 发行版会自带 portmap。若工作节点上没有需将其安装到/opt/cni/bin/可从 CNI 项目 release 页面获取二进制。2. 下载 Cilium release。3. 通过 Helm 部署 Ciliumhelm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModeportmap提示cni.chainingModeportmap可以与任何其他安装指南组合使用官方原文You can combine the cni.chainingModeportmap option with any of the other installation guides。由于 Cilium 以 DaemonSet 形式部署它会写入一份新的 CNI 配置该配置现在启用了 HostPort。此后新调度的任何 Pod 都能使用 HostPort 功能。4. 重启既有 Pod新配置不会作用于已运行的 Pod需要重启以应用链式配置。配置参数速查下表汇总了本文涉及的所有核心 Helm 参数及其在源码中的对应关系Helm 参数对应 agent 选项源码作用使用场景cni.chainingModecni-chaining-modepkg/option/config.go中CNIChainingMode指定链式模式aws-cni/generic-veth/portmap等所有链式场景cni.chainingTargetcni-chaining-targetCNIChainingTarget指定要合并进自身的既有 CNI 网络名称自动注入 conflistOKEoci等自动注入场景cni.customConf—使用自定义 CNI 配置cni.configMap指向的 ConfigMapAzure / Calico / Weave / generic-vethcni.configMap—存放链式 conflist 的 ConfigMap 名称同上cni.exclusive—是否独占 CNI 配置目录false表示保留对方插件控制权AWS-CNI / OKEroutingMode—路由模式native表示关闭隧道、直接路由所有链式场景enableIPv4Masquerade—是否开启 IPv4 伪装底层可直连路由时关闭所有链式场景endpointRoutes.enabled—启用 endpoint 路由加速逐 Pod 路由Azure CNI 链式enableIdentityMark—关闭 identity mark 避免与其他 CNI 标记冲突Calico 链式kubeProxyReplacement—是否以 eBPF 替代 kube-proxy链式阶段通常保持falseOKEipam.mode/ipam.operator.clusterPoolIPv4PodCIDRList—Cilium 内部 IPAM 的池与网段不参与实际 Pod IP 分配OKE总结与选型建议CNI Chaining 让 Cilium 能在保留既有 CNI 插件及其云厂商 IPAM/网络模型的同时以 eBPF 叠加策略、负载均衡与可观测性能力。选择何种链式模式可参考以下逻辑底层插件是veth 设备模型绝大多数插件→ 使用generic-veth并自行准备 ConfigMapAzure、Calico、Weave 等均属此类云厂商提供自动注入能力如 OKE 的chainingTargetoci→ 使用自动注入无需手工 ConfigMap仅需HostPort 且 kubeProxyReplacementfalse→ 使用portmap链式模式需要 L7 策略或 IPsec 加密等高级特性 → 注意链式模式下这些能力受限见Documentation/installation/cni-chaining-limitations.rst官方建议考虑完全迁移到 Cilium 作为唯一 CNI。无论选择哪种场景都请记住两个通用要点新链式配置只对新 Pod 生效必须重启既有 Pod卸载时注意清理节点上的 CNI 配置文件尤其 OKE 的05-cilium.conflist避免新 Pod 陷入 ContainerCreating。延伸阅读仓库内CNI Chaining 总览CNI Chaining 通用限制AWS VPC CNI 链式部署Azure CNI 链式部署Calico 链式部署Generic Veth 链式部署Oracle OKE 链式部署Portmap/HostPort 链式部署Weave Net 链式部署安装验证指南重启既有 Pod 指南链式模式实现的源码入口plugins/cilium-cni/types/types.go、plugins/cilium-cni/cmd/cmd.go、pkg/option/config.go【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cilium CNI Chaining 完全指南：与 AWS VPC CNI、Azure CNI、Calico、Weave Net 等插件共存的混合部署实战
Cilium CNI Chaining 完全指南与 AWS VPC CNI、Azure CNI、Calico、Weave Net 等插件共存的混合部署实战【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读本文基于 Cilium 官方安装文档Documentation/installation/cni-chaining.rst及其关联子文档编写系统讲解CNI ChainingCNI 链式编排这一核心部署模式让 Cilium 与其他 CNI 插件在同一集群中协同工作由非 Cilium 插件负责基础网络连通性与 IP 地址管理IPAM而 Cilium 则通过 eBPF 程序挂载到对方插件创建的网络设备上提供 L3/L4 网络可见性、策略执行、负载均衡与加密等高级能力。读完本文你将掌握 CNI Chaining 的工作原理、通用限制、基于 ConfigMap 的链式配置编写方法以及分别在 AWS VPC CNI、Azure CNI、Calico、Weave Net、Oracle OKE 等主流插件之上部署 Cilium 的完整实战步骤与关键 Helm 参数并学会处理“重启既有 Pod”与卸载清理等常见运维场景。适用前提本文面向 Kubernetes 集群中已部署其他 CNI 插件、希望在其之上叠加 Cilium 安全/可观测性能力的场景。所有命令与参数以当前仓库Documentation/installation/目录下的安装文档为准使用 Helm v3 部署。CNI Chaining 是什么核心模型谁负责什么CNI ChainingCNI 链式编排允许 Cilium 与其他 CNI 插件组合使用。在链式模式下非 Cilium CNI 插件负责基础网络连通性的建立以及 IP 地址管理IPAM。例如 AWS VPC CNI 通过 ENI 管理 Pod IPAzure CNI 负责虚拟网络设备与地址分配Calico 通过其 IPAM 分配地址。Cilium CNI 插件在非 Cilium 插件完成初始网络设置之后被调用将 eBPF 程序挂载到对方插件创建的网络设备上从而提供L3/L4 网络可见性Documentation/installation/cni-chaining-aws-cni.rst原文表述为 L3/L4 network visibility网络策略执行Network Policy Enforcement负载均衡Load-Balancing加密Encryption。从源码结构看Cilium 的 CNI 插件支持链式模式的核心逻辑位于plugins/cilium-cni目录CNI 配置中的chaining-mode字段在 types.go 中定义插件在cmd.go中通过chainingapi.Lookup(n.ChainingMode)查找对应的链式实现若配置了不支持的 chaining-mode 会报invalid chaining-mode错误见 cmd.go。同时cmd.go 中还有一项关键校验如果 CNI 提供了PrevResult即前面已有插件执行结果但 Cilium 并未处于 chaining 模式会报错 CNI PrevResult supplied, but not in chaining mode。链式执行顺序插件数组的先后次序CNI Chaining 的本质是把多个 CNI 插件按顺序放入同一个 conflistCNI 配置列表的plugins数组中kubelet 会按数组顺序依次调用。从各官方指南的配置模板中可以总结出典型顺序主 CNI 插件如azure-vnet、calico、weave-net、oci-ptp等创建网络设备并完成 IPAMportmap插件可选提供 HostPort 能力配置capabilities: {portMappings: true}cilium-cni插件作为链中最后一个插件挂载 eBPF 程序、执行策略与负载均衡。例如 Azure CNI 的链式配置将azure-vnet、portmap、cilium-cni三者串联见下文 Azure 一节。通用限制链式模式下哪些高级功能受限在与其他 CNI 插件链式组合时Cilium 的部分高级功能可能受限。Documentation/installation/cni-chaining-limitations.rst明确列出了两类Layer 7 PolicyL7 策略即 HTTP/gRPC 等七层协议策略对应仓库中的l7_policy文档章节IPsec 加密encryption_ipsec即基于 IPsec 的传输加密功能。这是所有 CNI Chaining 场景的通用约束下文各具体插件指南中均通过.. include:: cni-chaining-limitations.rst引入此段内容。因此如果你需要上述高级功能应优先考虑完全迁移到 Cilium 作为唯一 CNI。通用部署流程ConfigMap 与 Helm 参数虽然各插件指南略有差异但整体流程一致可归纳为三步第一步编写链式 CNI 配置ConfigMap大多数场景Azure、Calico、Weave Net、generic-veth要求手工创建一个名为chaining.yaml的 ConfigMap其data.cni-config字段内嵌一个符合 CNI 规范的 JSON conflistapiVersion: 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 } ] }部署该 ConfigMapkubectl apply -f chaining.yaml该 ConfigMap 会被安装为所有节点上的 CNI 配置文件Azure 指南原文“This ConfigMap will be installed as the CNI configuration file on all nodes and defines the chaining configuration”并定义了链式配置内容。第二步通过 Helm 部署 Cilium 并指定链式模式官方指南均使用如下 Helm 参数组合以 generic-veth 链式为例helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse各参数的作用与适用场景Helm 参数作用典型取值cni.chainingMode指定链式模式aws-cni、azure-cni、generic-veth、portmap等cni.customConftrue告知 Cilium 使用自定义手工管理的 CNI 配置而非自行生成truecni.configMapcni-configuration指向存放链式 conflist 的 ConfigMap 名称cni-configurationcni.exclusivefalse让 Cilium 不独占 CNI 配置目录保留对方插件的 DaemonSet 控制权falseroutingModenative关闭隧道overlay模式因为 Pod IP 在底层网络VPC/VCN中可直接路由nativeenableIPv4Masqueradefalse关闭 IPv4 伪装masquerade理由同上false从源码层面看这些参数与 Cilium agent 的pkg/option/config.go中的命令行选项一一对应cni-chaining-modeCNIChainingModeconfig.go与cni-chaining-targetCNIChainingTargetconfig.go。前者配置 Cilium 与哪个 CNI 插件链式组合后者则指定 Cilium 应该合并进入的既有 CNI 网络名称用于 OKE 这类自动注入场景。第三步重启既有 Pod新 CNI 链式配置不会作用于集群中已经运行的任何 Pod。官方文档反复强调既有 Pod 依然可达Cilium 会负载均衡到它们但不会对来自它们的流量执行策略与负载均衡。因此必须重启这些 Pod使链式配置得以生效。可以使用以下脚本检查哪些 Pod 需要重启基于 CEP 与 Pod 列表的差集计算来自cni-chaining-aws-cni.rst与cni-chaining-oracle-oke.rstfor ns in $(kubectl get ns -o jsonpath{.items[*].metadata.name}); do ceps$(kubectl -n ${ns} get cep \ -o jsonpath{.items[*].metadata.name}) pods$(kubectl -n ${ns} get pod \ -o custom-columnsNAME:.metadata.name,NETWORK:.spec.hostNetwork \ | grep -E \s(none|false) | awk {print $1} | tr \n ) ncep$(echo ${pods} ${ceps} | tr \n | sort | uniq -u | paste -s -d -) for pod in $(echo $ncep); do echo ${ns}/${pod}; done done该脚本遍历所有命名空间对比kubectl get cepCiliumEndpoint与运行中非 hostNetwork的 Pod 列表找出没有对应 CEP 的 Pod——这些就是尚未被 Cilium 纳管的存量 Pod需要重启。场景一与 AWS VPC CNI 插件链式组合EKS架构与职责划分在 AWS 混合模式下AWS VPC CNI 插件负责创建虚拟网络设备以及通过 ENI 进行 IP 地址管理IPAM初始网络设置完成后Cilium CNI 插件被调用将 eBPF 程序挂载到 AWS VPC CNI 创建的网络设备上以实现网络策略执行、负载均衡与加密Documentation/installation/cni-chaining-aws-cni.rst。由于 ENI 分配的 Pod IP 可以直接在 VPC 内路由因此无需隧道tunneling也无需开启 masquerade。前置条件AWS VPC CNI 插件版本请确保 AWS VPC CNI 插件版本为1.11.2 或更新以保证与 Cilium 的兼容性。可通过以下命令检查当前版本$ kubectl -n kube-system get ds/aws-node -o json | jq -r .spec.template.spec.containers[0].image 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.11.2如果运行的是更旧版本可以升级$ kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.11/config/master/aws-k8s-cni.yaml部署步骤1. 准备 EKS 集群按照 Kubernetes 安装快速指南在 AWS 上创建 EKS 集群或使用任何你喜欢的方式在 AWS 上搭建 Kubernetes 集群。若使用 EKSaws-vpc-cni-k8s插件通常已预装但仍需按上文确保版本足够新。2. 下载 Cilium release参考Documentation/installation/k8s-install-download-release.rst。3. 通过 Helm 部署 Ciliumhelm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModeaws-cni \ --set cni.exclusivefalse \ --set enableIPv4Masqueradefalse \ --set routingModenative参数说明cni.chainingModeaws-cni启用与 AWS VPC CNI 插件的链式组合cni.exclusivefalseCilium 不独占 CNI 配置目录enableIPv4MasqueradefalseENI 的 Pod IP 可在 VPC 内直接路由因此无需伪装routingModenative无需隧道因为 ENI IP 可在 VPC 内直接路由。4. 重启既有 Pod使用上文通用脚本然后参考Documentation/installation/k8s-install-validate.rst验证安装。高级启用 EKS Security Groups for PodsCilium 可以在链式模式下与 EKS 的security groups for pods特性协同工作适用于受支持的集群。启用步骤如下前提需要已安装并配置好jq与 AWS CLI。步骤一为 EKS 集群关联的 IAM 角色附加AmazonEKSVPCResourceController托管策略export EKS_CLUSTER_NAMEmy-eks-cluster # Change accordingly export EKS_CLUSTER_ROLE_NAME$(aws eks describe-cluster \ --name ${EKS_CLUSTER_NAME} \ | jq -r .cluster.roleArn | awk -F/ {print $NF}) aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController \ --role-name ${EKS_CLUSTER_ROLE_NAME}步骤二确保集群中运行的 AWS VPC CNI 插件版本足够新kubectl -n kube-system get ds/aws-node \ -o jsonpath{.spec.template.spec.containers[0].image} 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.7.10步骤三patchkube-system/aws-nodeDaemonSet 以启用 security groups for podskubectl -n kube-system patch ds aws-node \ -p {spec:{template:{spec:{initContainers:[{env:[{name:DISABLE_TCP_EARLY_DEMUX,value:true}],name:aws-vpc-cni-init}],containers:[{env:[{name:ENABLE_POD_ENI,value:true}],name:aws-node}]}}}} kubectl -n kube-system rollout status ds aws-node步骤四验证节点 trunk 标签。rollout 完成后集群中所有节点应带有vpc.amazonaws.com/has-trunk-attached标签且值为truekubectl get nodes -L vpc.amazonaws.com/has-trunk-attached NAME STATUS ROLES AGE VERSION HAS-TRUNK-ATTACHED ip-192-168-111-169.eu-west-2.compute.internal Ready none 22m v1.19.6-eks-49a6c0 true ip-192-168-129-175.eu-west-2.compute.internal Ready none 22m v1.19.6-eks-49a6c0 true此后即可将安全组关联到 Pod具体关联方法参考 AWS EKS 官方文档此处不再展开。场景二与 Azure CNILegacy链式组合AKS背景与适用性说明官方文档指出对大多数用户而言在 AKS 上运行 Cilium 的最佳方式是AKS BYO CNI或使用Azure CNI Powered by CiliumAzure 官方基于 Cilium 数据面的托管方案。本文的链式配置是运行 Azure CNI Cilium 的传统legacy方式因为 Azure IPAM 属于遗留方案。职责划分混合模式下Azure CNI 插件负责创建虚拟网络设备与地址分配IPAM初始网络设置完成后Cilium CNI 插件被调用将 eBPF 程序挂载到 Azure CNI 创建的网络设备上以实现网络策略执行、负载均衡与加密。创建 AKS Cilium CNI 链式配置创建chaining.yaml内容基于以下模板。示例中 Azure CNI、portmap 与 Cilium 三者链式组合apiVersion: v1 kind: ConfigMap metadata: name: cni-configuration namespace: kube-system data: cni-config: |- { cniVersion: 0.3.0, name: azure, plugins: [ { type: azure-vnet, mode: transparent, ipam: { type: azure-vnet-ipam } }, { type: portmap, capabilities: {portMappings: true}, snat: true }, { name: cilium, type: cilium-cni } ] }部署 ConfigMapkubectl apply -f chaining.yaml部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.exclusivefalse \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set endpointRoutes.enabledtrue注意点这里虽然使用 Azure CNI但cni.chainingMode取值为generic-veth因为 Azure CNI 的设备模型同样是 vethgeneric-veth 链式插件足以适配。同时通过cni.configMapcni-configuration让 Cilium 读取上面创建的 ConfigMap。随后参考Documentation/installation/k8s-install-restart-pods.rst重启既有 Pod并按k8s-install-validate.rst验证。场景三与 Calico 链式组合创建 CNI 配置创建chaining.yaml文件基于以下模板指定链式配置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 } ] }部署 ConfigMapkubectl apply -f chaining.yaml部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set enableIdentityMarkfalse其中enableIdentityMarkfalse用于关闭 Cilium 的 identity mark在与其他 CNI 链式组合时避免标记冲突。随后验证安装并重启既有 PodCalico 指南同样强调既有 Pod 不受策略管控、必须重启。场景四Generic Veth Chaining通用 veth 链式插件适用范围与前置验证generic-veth 链式插件允许在任意使用veth 设备模型的 CNI 插件之上启用 CNI 链式组合——而大多数 CNI 插件都采用这种模型。在部署前请先验证当前 CNI 插件确实使用 vethSSH 登录到某个工作节点运行ip -d link列出节点上的所有网络设备应能发现代表该节点上 Pod 的网络设备网络设备看起来可能类似这样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。若当前链式的 CNI 插件未使用 veth则 generic-veth 插件不适用。此时需要一个能理解底层插件设备模型的完整 CNI 链式插件编写此类插件并不复杂。创建链式 CNI 配置创建chaining.yaml将XXX替换为你的主 CNI 插件类型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 } ] }部署 ConfigMap 后通过 Helm 部署 Cilium参数与 Calico 场景一致cni.chainingModegeneric-veth、cni.customConftrue、cni.configMapcni-configuration、routingModenative、enableIPv4Masqueradefalse随后验证并重启既有 Pod。从源码看generic-veth 链式实现注册在 plugins/cilium-cni/chaining/generic-veth 包中作为独立实现被 CNI 插件默认导入对应cmd.go中的chainingapi.Lookup分发逻辑。场景五与 Weave Net 链式组合创建 CNI 配置创建chaining.yaml文件基于以下模板指定链式配置apiVersion: v1 kind: ConfigMap metadata: name: cni-configuration namespace: kube-system data: cni-config: |- { cniVersion: 0.3.1, name: weave, plugins: [ { name: weave, type: weave-net, hairpinMode: true }, { type: portmap, capabilities: {portMappings: true}, snat: true }, { type: cilium-cni } ] }部署 ConfigMapkubectl apply -f chaining.yaml部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModegeneric-veth \ --set cni.customConftrue \ --set cni.configMapcni-configuration \ --set routingModenative \ --set enableIPv4Masqueradefalse随后按k8s-install-validate.rst验证安装并重启既有 Pod。场景六Oracle OKE VCN-Native Pod Networking 自动注入工作原理chainingTarget 自动合并Oracle Kubernetes EngineOKE的VCN-Native Pod Networking是 Oracle 推荐的 OKE 生产级 CNI 模式Pod IP 直接取自 VCN 子网Pod 无需 overlay 即可原生路由相当于 AWS VPC CNI 或 Azure CNI 的 Oracle 版本。其 CNI 栈依次运行两个插件oci-ipvlan通过 OCI IPAM 从 VCN 子网分配 Pod IP并管理底层计算实例上的 VNIC 挂载oci-ptp在 Pod 网络命名空间与宿主机之间创建 veth 对。注意尽管插件名为oci-ipvlan实际面向 Pod 的接口是标准 veth 对。Pod 获得 VCN 原生 IP宿主机持有每 Pod 的 veth 对端路由使用位于169.254.1.1的 proxy-ARP 网关——该模型与 AWS VPC CNI 功能上等价。Cilium 通过generic-veth链式模式作为链中的第三个插件运行。与前述场景不同OKE 场景无需手工创建 CNI ConfigMap当设置cni.chainingTargetoci时Cilium agent 会发现在每个节点上已存在的名为oci的 conflist将自身合并进插件数组并把结果写入/etc/cni/net.d/05-cilium.conflist。原始的10-oci.conflist不会被修改检查该文件看不到cilium-cni条目。由于05-cilium.conflist在字典序上先于10-oci.conflistkubelet 会自动为所有新 Pod 使用它。前置条件启用 VCN-Native Pod Networking 的 OKE 集群非 Flannel配置好并指向集群的kubectlHelm v3。部署 Cilium下载 Cilium release 后通过 Helm 部署helm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingTargetoci \ --set cni.exclusivefalse \ --set routingModenative \ --set enableIPv4Masqueradefalse \ --set kubeProxyReplacementfalse \ --set ipam.modecluster-pool \ --set ipam.operator.clusterPoolIPv4PodCIDRList100.64.0.0/16参数说明cni.chainingTargetoci告知 Cilium agent 找到现有 OCI CNI conflist 并自动注入自身routingModenativePod IP 可在 VCN 内直接路由因此关闭隧道enableIPv4MasqueradefalseOCI 在 VCN 层面处理路由因此关闭伪装cni.exclusivefalseCilium 不接管 CNI 配置目录将控制权保留给 OKE 的vcn-native-ip-cniDaemonSetkubeProxyReplacementfalseOKE 默认运行kube-proxy此参数保留它若希望 Cilium 替代 kube-proxy可在链式设置稳定后参考 kubeproxy-free 指南ipam.operator.clusterPoolIPv4PodCIDRList100.64.0.0/16使用 RFC 6598 CGNAT 网段不与 VCN 子网冲突仅供 Cilium 内部使用实际 Pod IP 始终由 OCI IPAM 从 VCN 子网分配。重启既有 Pod与前述场景相同链式配置不会作用于已运行的 Pod。使用上文通用的 CEP/Pod 差集脚本找出需要重启的 Pod。卸载注意事项重要$ helm uninstall cilium -n kube-system警告helm uninstall只移除 Kubernetes 资源不会清理写入节点主机路径的文件。/etc/cni/net.d/05-cilium.conflist在卸载后仍会留在每个节点上。由于它在字典序上先于10-oci.conflistkubelet 会继续为新 Pod 使用它。此时 Cilium agent 已不存在cilium-cni无法连接其 socket新 Pod 将卡在 ContainerCreating报错为dial unix /var/run/cilium/cilium.sock: connect: no such file or directory已运行的 Pod 不受影响因为 CNI 只在 Pod 创建时被调用。卸载后需要 SSH 到每个节点删除该文件$ sudo rm -f /etc/cni/net.d/05-cilium.conflist之后 OKE 的vcn-native-ip-cniDaemonSet 将重新通过10-oci.conflist处理所有新 Pod 的网络。场景七用 portmap 链式启用 HostPortkubeProxyReplacementfalse 时背景从 Cilium 1.8 开始Kubernetes HostPort 特性已通过 Cilium 基于 eBPF 的 kube-proxy replacement 原生支持不再需要 CNI chaining。但存在一种例外当 Cilium 以kubeProxyReplacementfalse部署时可以通过与实现 HostPort 的portmap 插件进行 CNI 链式组合来启用 HostPort。本场景即针对这种链式情况。部署步骤1. 安装 portmap 二进制部分 Kubernetes 发行版会自带 portmap。若工作节点上没有需将其安装到/opt/cni/bin/可从 CNI 项目 release 页面获取二进制。2. 下载 Cilium release。3. 通过 Helm 部署 Ciliumhelm install cilium cilium/cilium --version VERSION \ --namespace kube-system \ --set cni.chainingModeportmap提示cni.chainingModeportmap可以与任何其他安装指南组合使用官方原文You can combine the cni.chainingModeportmap option with any of the other installation guides。由于 Cilium 以 DaemonSet 形式部署它会写入一份新的 CNI 配置该配置现在启用了 HostPort。此后新调度的任何 Pod 都能使用 HostPort 功能。4. 重启既有 Pod新配置不会作用于已运行的 Pod需要重启以应用链式配置。配置参数速查下表汇总了本文涉及的所有核心 Helm 参数及其在源码中的对应关系Helm 参数对应 agent 选项源码作用使用场景cni.chainingModecni-chaining-modepkg/option/config.go中CNIChainingMode指定链式模式aws-cni/generic-veth/portmap等所有链式场景cni.chainingTargetcni-chaining-targetCNIChainingTarget指定要合并进自身的既有 CNI 网络名称自动注入 conflistOKEoci等自动注入场景cni.customConf—使用自定义 CNI 配置cni.configMap指向的 ConfigMapAzure / Calico / Weave / generic-vethcni.configMap—存放链式 conflist 的 ConfigMap 名称同上cni.exclusive—是否独占 CNI 配置目录false表示保留对方插件控制权AWS-CNI / OKEroutingMode—路由模式native表示关闭隧道、直接路由所有链式场景enableIPv4Masquerade—是否开启 IPv4 伪装底层可直连路由时关闭所有链式场景endpointRoutes.enabled—启用 endpoint 路由加速逐 Pod 路由Azure CNI 链式enableIdentityMark—关闭 identity mark 避免与其他 CNI 标记冲突Calico 链式kubeProxyReplacement—是否以 eBPF 替代 kube-proxy链式阶段通常保持falseOKEipam.mode/ipam.operator.clusterPoolIPv4PodCIDRList—Cilium 内部 IPAM 的池与网段不参与实际 Pod IP 分配OKE总结与选型建议CNI Chaining 让 Cilium 能在保留既有 CNI 插件及其云厂商 IPAM/网络模型的同时以 eBPF 叠加策略、负载均衡与可观测性能力。选择何种链式模式可参考以下逻辑底层插件是veth 设备模型绝大多数插件→ 使用generic-veth并自行准备 ConfigMapAzure、Calico、Weave 等均属此类云厂商提供自动注入能力如 OKE 的chainingTargetoci→ 使用自动注入无需手工 ConfigMap仅需HostPort 且 kubeProxyReplacementfalse→ 使用portmap链式模式需要 L7 策略或 IPsec 加密等高级特性 → 注意链式模式下这些能力受限见Documentation/installation/cni-chaining-limitations.rst官方建议考虑完全迁移到 Cilium 作为唯一 CNI。无论选择哪种场景都请记住两个通用要点新链式配置只对新 Pod 生效必须重启既有 Pod卸载时注意清理节点上的 CNI 配置文件尤其 OKE 的05-cilium.conflist避免新 Pod 陷入 ContainerCreating。延伸阅读仓库内CNI Chaining 总览CNI Chaining 通用限制AWS VPC CNI 链式部署Azure CNI 链式部署Calico 链式部署Generic Veth 链式部署Oracle OKE 链式部署Portmap/HostPort 链式部署Weave Net 链式部署安装验证指南重启既有 Pod 指南链式模式实现的源码入口plugins/cilium-cni/types/types.go、plugins/cilium-cni/cmd/cmd.go、pkg/option/config.go【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
