Cilium 与 AWS VPC CNI 混合部署CNI Chaining 模式下 eBPF 数据面接管实战指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium在 AWS EKS 环境中Cilium 通常以独占 CNI 的身份接管全部网络数据面但并非所有场景都适合一步到位地完成迁移。本文基于 Cilium 官方安装指南Documentation/installation/cni-chaining-aws-cni.rst完整讲解混合模式由 AWS VPC CNI 插件继续负责 Pod 虚拟网卡创建与基于 ENI 的 IP 地址分配IPAMCilium 仅作为 CNI 链chaining的下游插件被调用将 eBPF 程序挂载到 AWS VPC CNI 已建好的网络设备上从而在不改变现有 Pod 网络模型的前提下启用网络策略、负载均衡与加密能力。读完本文你将掌握该模式的 Helm 部署参数、存量 Pod 的识别与重启方法以及 EKS security groups for pods 特性的配套启用步骤。混合模式的工作原理在 Cilium 与 AWS VPC CNI 的混合部署中两个 CNI 插件各司其职职责边界非常清晰AWS VPC CNI 插件负责创建 Pod 的虚拟网络设备veth 对并通过 ENIElastic Network Interface完成 IPAM即 Pod 直接使用 VPC 内的 ENI IP 地址Cilium CNI 插件在网络设备就绪后被链式调用chained call将 eBPF 程序挂载到上述设备上执行网络策略policy enforcement、服务负载均衡load-balancing以及可选的流量加密。从源码可以确认这一链式接管的具体实现。Cilium CNI 插件在启动时通过init()函数把aws-cni这一 chaining mode 注册到全局的 chaining API 中其处理逻辑直接复用通用 veth chainer// plugins/cilium-cni/chaining/awscni/aws-cni.go func init() { chainingapi.Register(aws-cni, genericveth.GenericVethChainer{}) }而在 generic-veth chainer 的实现中针对 AWS CNI 场景构造 endpoint 时明确设置了四项数据面配置精确对应了只接管 eBPF、不接管网络的职责划分// plugins/cilium-cni/chaining/generic-veth/generic-veth.go DatapathConfiguration: models.EndpointDatapathConfiguration{ // aws-cni requires ARP passthrough between Linux and // the pod RequireArpPassthrough: true, // The route is pointing directly into the veth of the // pod, install a host-facing egress program to // implement ingress policy and to provide reverse NAT RequireEgressProg: true, // The IP is managed by the aws-cni plugin, no need for // Cilium to manage any aspect of addressing ExternalIpam: true, // All routing is performed by the Linux stack RequireRouting: disabled, },逐项解读配置项取值含义RequireArpPassthroughtrueLinux 宿主机与 Pod 之间需要 ARP 直通因为 Pod 的 IP 是 VPC 内真实可路由的地址RequireEgressProgtrue路由直接指向 Pod veth需在宿主机侧安装 host-facing egress 程序来实现 ingress 策略与反向 NATExternalIpamtrueIP 由 AWS VPC CNI 管理Cilium 完全不介入地址分配RequireRouting禁用所有路由均由 Linux 协议栈完成Cilium 不安装自己的路由表此外由于 AWS VPC CNI 会在 iptables 中创建自己的规则例如 conntrack 跟踪 Pod IPCilium 在 iptables 数据面实现中专门识别了aws-cnichaining mode对形如eni621c0fc8425的容器接口名称做特殊处理避免与 AWS CNI 的规则冲突。Helm chart 也提供了配套开关cni.iptablesRemoveAWSRules默认true用于在部署时移除 AWS CNI 插件创建的 iptables 规则。功能限制混合模式能做什么、不能做什么在动手之前必须先明确边界。根据文档中引用的cni-chaining-limitations.rst与其他 CNI 插件链式部署时部分 Cilium 高级功能会受到限制明确列出受限能力的有L7 网络策略Layer 7 PolicyIPSec 加密encryption。因此如果你需要这些高级能力文档给出的建议是彻底迁移到 Cilium 独占模式即完全替换 AWS VPC CNI而不是长期停留在 chaining 模式。前置条件准备 EKS 集群并升级 AWS VPC CNI1. 创建集群可以参照 Cilium 文档中的 EKS 快速安装指南Documentation/installation/k8s-install-eks.rst对应章节k8s_install_quick来创建集群也可以使用任意你熟悉的方式Terraform、eksctl 等在 AWS 上部署 Kubernetes 集群。需要确认两点aws-vpc-cni-k8s插件已安装——如果集群是通过 EKS 控制台/API 创建的这通常是默认状态插件版本足够新。2. 检查并升级 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如果输出版本低于 1.11.2通过 apply AWS 官方发布清单进行升级$ kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/release-1.11/config/master/aws-k8s-cni.yaml提示aws-node是 AWS VPC CNI 以 DaemonSet 形式在kube-system命名空间运行的工作负载每个节点一个副本Cilium 的 chaining 逻辑将直接作用于它创建的网络设备。3. 下载 Cilium 发行版按 Cilium 标准的 Kubernetes 安装流程下载所需版本的 Cilium 发布包对应文档中的k8s-install-download-release.rst章节后续 Helm 安装将从本地 chart 目录部署。通过 Helm 部署 Cilium四个关键参数下载完成后以本地 chart 目录为源执行 Helm 安装helm install cilium cilium/cilium \ --namespace kube-system \ --set cni.chainingModeaws-cni \ --set cni.exclusivefalse \ --set enableIPv4Masqueradefalse \ --set routingModenative这组参数就是混合模式的核心配置逐一说明其作用参数取值作用与原理cni.chainingModeaws-cni声明 Cilium 以 chaining 方式运行在 AWS VPC CNI 之上。在 Helm chart 的 values.yaml中cni.chainingMode的合法取值为none、aws-cni、flannel、generic-veth、portmap同时 chart 注释指出一个特殊约定chaining mode of aws-cni implies a chainingTarget of aws-cni即设置了该模式后无需再显式指定cni.chainingTargetcni.exclusivefalse关闭 Cilium 对/etc/cni/net.d的独占接管。默认exclusive: true时 Cilium 会把非 Cilium 的 CNI 配置重命名为*.cilium_bak混合模式下必须保留 AWS VPC CNI 的配置10-aws.conflist生效因此要设为falseenableIPv4Masqueradefalse关闭 masqueradeSNAT。原因是 ENI IP 地址在 VPC 内本来就可以直接路由Pod 流量无需再改写源地址routingModenative使用原生路由模式同样因为隧道tunnel在此场景下没有必要——ENI IP 可在 VPC 中直接寻址部署完成后Cilium 的 Helm 校验逻辑见 validate.yaml 模板会对 chaining 配置做一致性检查确保chainingMode与集群中实际存在的 CNI 配置相匹配。重启存量 Podchaining 配置为何不会追溯生效这是部署流程中最容易被忽略、却直接影响功能正确性的一步。文档明确警告新的 CNI chaining 配置不会作用于集群中已经在运行的任何 Pod。对于存量 Pod其网络状态是Pod 仍然可达Cilium 能对其做负载均衡tothem但从 Pod 发出的流量不走Cilium 数据面notfromthem策略强制执行同样不生效。原因是 eBPF 程序只在 CNI ADD 事件时挂载到接口上存量 Pod 的接口早已由 AWS VPC CNI 单独创建Cilium 从未被调用过。因此必须重启这些 Pod让 kubelet 重新触发 CNI 调用链Cilium 才有机会将 eBPF 程序挂上去。官方提供的检测脚本用于找出有 Pod 但尚无对应 Cilium endpointCEP的对象——Cilium endpoint 的 CustomResourceciliumendpoint缩写cep只有在本插件成功处理过该 Pod 后才会生成for 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脚本逻辑解读遍历所有命名空间分别取出该命名空间下的 Cilium endpoint 名称集合ceps与非 hostNetwork Pod 名称集合pods用sort | uniq -u做差集运算剩下的就是有 Pod 却没有 endpoint的存量 Pod逐条输出namespace/pod-name供你执行kubectl -n ns delete pod pod触发重建由 Deployment/StatefulSet 等控制器自动拉起新实例新实例将完整走一遍 CNI 链。重启完成后每个新建 Pod 都应有对应的 CEP 资源且cilium status中 endpoint 状态应为 ready。验证安装部署并重启存量 Pod 后按 Cilium 标准流程验证对应k8s-install-validate.rst方式一Cilium CLI# 查看整体状态节点、agent、BPF 后端、策略引擎均应正常 cilium status --verbose # 运行端到端连通性测试套件覆盖 L3/L4及策略转发路径 cilium connectivity test方式二kubectl 手动验证# 确认每个节点上 cilium-agent 处于 Running 状态 kubectl -n kube-system get pods -l k8s-appcilium -o wide # 手动构造两个测试 Pod 验证策略与转发 kubectl run client --imagequay.io/cilium/cilium:v1.17.0 --rm -it -- sh在混合模式下重点观察新创建的 Pod 是否生成了 CEP、跨节点 Pod 间流量是否经由 ENI IP 直连而非隧道封装、Service 负载均衡是否由 Cilium 完成节点上不应再依赖 kube-proxy 处理 Cilium 管理的 endpoint。进阶为 Pod 启用 EKS Security GroupsSGP在支持 security groups for podsSGP特性的 EKS 集群上Cilium 的 chaining 模式可以与该特性共存。SGP 允许直接给 Pod 关联 AWS 安全组从而把网络准入控制的一部分下沉到 AWS VPC 层。启用步骤如下前置要求本机已安装并配置好jq与 AWS CLI。步骤 1为 EKS 集群角色附加 IAM 托管策略将AmazonEKSVPCResourceController策略附加到集群的 IAM 角色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}步骤 2确认 AWS VPC CNI 版本足够新SGP 特性要求较新的aws-node版本1.7.10 及以上而本文前述的 Cilium 兼容性要求是 1.11.2满足其一即可同时满足两者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步骤 3Patchaws-nodeDaemonSet 开启 Pod ENIkubectl -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两个环境变量分别的作用ENABLE_POD_ENItrue注入aws-node容器开启 trunk ENI 上的 member ENI 分配即每个 Pod 获得独立的 member ENI从而可以单独关联安全组DISABLE_TCP_EARLY_DEMUXtrue注入aws-vpc-cni-init容器禁用 TCP early demux sysctl保证 trunk ENI 的流转发行为正确。步骤 4验证 trunk 挂载rollout 完成后所有节点应带有vpc.amazonaws.com/has-trunk-attached: true标签kubectl 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至此Cilium chaining 与 SGP 两条能力同时就绪Pod 层面由 AWS 安全组做第一道边界Cilium 在其上叠加 L3/L4 策略与服务级负载均衡。具体如何把安全组关联到 Pod通过 Pod 注解vpc.amazonaws.com/pod-assign-eni-class与vpc.amazonaws.com/pod-security-group-ids按 AWS EKS 官方 SGP 文档操作即可——这部分是 AWS 平台侧配置与 Cilium 配置相互独立。小结混合模式的能力边界与迁移决策把整个部署流程串起来准备 EKS 集群确认aws-vpc-cni-k8s≥ 1.11.2不足则 apply 官方清单升级Helm 安装 Cilium设置cni.chainingModeaws-cni、cni.exclusivefalse、enableIPv4Masqueradefalse、routingModenative用Pod 与 CEP 差集脚本找出存量 Pod 并逐个重启以cilium status/cilium connectivity test验证数据面接管效果可选按 SGP 四步流程叠加 Pod 级 AWS 安全组。源码层面这一模式的本质是GenericVethChainer配合ExternalIpam RequireArpPassthrough RequireEgressProg的数据面配置让 Cilium 只挂程序、不碰 IPAM 和路由。需要牢记的限制是L7 策略与 IPSec 加密在 chaining 模式下受限。如果你的业务依赖这两项能力混合模式只应作为过渡方案最终目标是迁移到 Cilium 独占模式——届时cni.chainingMode回退为noneroutingMode可选native或vxlanCilium 将完整接管从 IPAM 到策略执行的全部职责。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考