Cilium 通过 CNI Chaining 启用 Kubernetes HostPort（portmap 插件）完整指南

Cilium 通过 CNI Chaining 启用 Kubernetes HostPortportmap 插件完整指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本指南讲解如何在kubeProxyReplacementfalse的部署模式下通过 CNI chaining 接入 portmap 插件为 Cilium 启用 Kubernetes HostPort 功能。文章同时对比了 Cilium 1.8 起基于 eBPF kube-proxy replacement 的原生 HostPort 方案并深入仓库源码与 Helm 配置帮助你理解两种方案的适用场景、部署步骤与验证方法从而在混合部署、存量集群迁移等场景下正确选型。HostPort 的两种实现路径原生 eBPF 与 portmap 插件Kubernetes 的 HostPort 特性允许将 Pod 的容器端口直接暴露在节点的指定 IP 与端口上是节点级端口映射的重要能力。在 Cilium 中HostPort 可以通过两条完全不同的路径实现原生 eBPF 支持推荐自 Cilium 1.8 起HostPort 通过 Cilium 的 eBPF kube-proxy replacement 原生支持此时不需要任何 CNI chaining。相关说明见 kubeproxy-free.rst 中的 Container HostPort Support 一节。CNI chaining portmap 插件当 Cilium 以kubeProxyReplacementfalse部署时无法利用原生实现此时可通过 CNI chaining 引入 portmap 插件来提供 HostPort 能力。这正是本文档的核心主题。两种方案的取舍维度原生 eBPF HostPortCNI chaining portmap启用方式kubeProxyReplacementtrue自动启用Helm 设置cni.chainingModeportmap底层机制eBPF datapath服务条目直连本地 backendportmap CNI 插件在主机命名空间打标记并做端口映射适用前提kube-proxy 被 Cilium 替换kube-proxy-free 环境kubeProxyReplacementfalse且主机上安装 portmap 二进制推荐度自 1.8 起为官方首选仅作为无法启用原生方案时的备选原生方案的详细行为可参考 kubeproxy-free.rst未指定hostIP时Pod 会暴露在节点检测到的本地地址上如 Kubernetes InternalIP 或 ExternalIP并且节点上的回环地址127.0.0.1:hostPort也可访问若指定了hostIP则仅在该地址上暴露hostIP为0.0.0.0时等价于未指定。同时hostPort不能落在已配置的 NodePort 端口范围内以避免冲突。前置理解什么是 CNI Chaining在进入 portmap 部署之前先明确 CNI chaining 的总体模型。根据 cni-chaining.rstCNI chaining 允许 Cilium 与其他 CNI 插件协同工作底层网络连通性与 IP 地址管理IPAM由非 Cilium 的 CNI 插件负责Cilium 则将 eBPF 程序附加到该插件创建的网络设备上提供 L3/L4 网络可见性、策略执行等高级能力。Cilium 仓库中内置了多种 chaining 模式从 pkg/metrics/features/metrics.go 可以看到以下受支持的取值none默认不启用 chainingaws-cni、calico、flannel、generic-veth、portmap等其中portmap模式的特殊性在于它并非提供底层连通性而是叠加 HostPort 映射能力因此可与其他安装指南组合使用详见下文。部署 Cilium 并启用 portmap 插件第 1 步安装 portmap 二进制portmap 插件来自 CNI 官方插件集containernetworking/plugins其二进制必须存在于每个工作节点的/opt/cni/bin/目录下# 在所有工作节点上执行将 portmap 放置到 CNI 二进制目录 # 二进制可从 CNI 项目 release 产物中获取 /opt/cni/bin/portmap部分 Kubernetes 发行版会随节点安装一并提供该插件此时无需额外操作。安装前应阅读 Kubernetes 官方关于 HostPort 的 Kubernetes hostPort-CNI 插件文档并参考 Kubernetes 配置最佳实践 理解该特性对调度与端口占用的影响。第 2 步通过 Helm 部署 Cilium使用 Helm 以cni.chainingModeportmap部署 Cilium 到kube-system命名空间helm install cilium cilium/cilium \ --namespace kube-system \ --set cni.chainingModeportmap该选项可以与本仓库 Documentation/installation 目录下的其他任何安装指南组合使用例如在需要时同时设置kubeProxyReplacementfalse与集群 API 地址等参数。第 3 步理解 DaemonSet 对 CNI 配置的写入行为Cilium 以 DaemonSet 方式在每个节点运行 agent启动后会写入一份新的 CNI 配置这份配置将 portmap 插件纳入 chaining 链。配置落盘后任何新调度的 Pod即可使用 HostPort 功能。从源码看chaining 模式通过 agent 的 CLI 标志--cni-chaining-mode传入默认值为none对应实现位于 daemon/cmd/cni/config/config.go。该文件同时展示了 chaining 模式的若干联动逻辑当--cni-chaining-modeaws-cni且未指定 target 时自动将 target 设为aws-cni当设置了--cni-chaining-target而未指定模式时模式自动推导为generic-veth模式为空时兜底为none。在 Helm 侧cni.chainingMode的值会写入 agent 的 ConfigMap最终体现为节点上的cni-chaining-mode键相关模板见 install/kubernetes/cilium/templates/cilium-configmap.yaml。该 ConfigMap 中的注释明确指出在 chaining 模式下底层连通性由被链入的插件负责Cilium 只叠加 L3/L4 网络与策略能力cilium-configmap.yaml。重启存量 Podchaining 配置只对新 Pod 生效必须注意新的 CNI chaining 配置不会应用到集群中已经运行的 Pod。对于存量 Pod它们仍然可达Cilium 会对其做负载均衡但策略执行policy enforcement不会作用于它们同时从这些存量 Pod 发起的流量也不会被负载均衡。因此为了让 chaining 配置在这些 Pod 上生效必须显式重启它们以重新触发 CNI 配置的调用。例如# 以 Deployment 滚动重启为例会触发重新创建 Pod 并执行新 CNI 配置 kubectl rollout restart deployment/name -n namespace重启的本质是让 Pod 重新经历 CNI ADD 流程从而应用包含 portmap 的 chained 配置。对于 DaemonSet 管理的系统组件可采用等效的滚动更新方式。验证 HostPort 是否生效验证分为两个层面1. 验证 Cilium 侧功能状态原生方案在原生 eBPF HostPort 方案下可通过cilium-dbg status查看KubeProxyReplacement信息行kubectl -n kube-system exec ds/cilium -- cilium-dbg status --verbose | grep HostPort - HostPort: Enabled2. 验证 HostPort 映射原生方案以下 Deployment 示例在 nginx 容器上声明hostPort: 8080apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: selector: matchLabels: run: my-nginx replicas: 1 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 80 hostPort: 8080部署后通过cilium-dbg service list观察 HostPort 类型的服务条目kubectl exec -it -n kube-system cilium-fmh8d -- cilium-dbg service list ID Frontend Service Type Backend [...] 5 192.168.178.29:8080 HostPort 1 10.29.207.199:80同时可以确认主机命名空间内没有为 HostPort 生成 iptables 规则原生 eBPF 路径iptables-save | grep HOSTPORT [ empty line ]最后用 curl 验证连通性curl 192.168.178.29:8080 !DOCTYPE html html head titleWelcome to nginx!/title [....]删除 Deployment 后对应的 HostPort 服务条目也会从cilium-dbg service list中移除。上述原生方案的完整说明与验证示例见 kubeproxy-free.rst。对于portmap chaining 方案验证重点是确认 portmap 二进制已存在于各节点/opt/cni/bin/且节点上/etc/cni/net.d/下的配置已由 Cilium agent 更新为包含 portmap 的 chained 配置随后创建带hostPort的 Pod 并验证节点端口可达。运维注意事项与源码线索chaining 模式的可观测性Cilium 将当前 chaining 模式作为 agent feature 暴露在 metrics 中portmap与none、aws-cni、calico、flannel、generic-veth一同出现在默认 chaining 模式列表中见 pkg/metrics/features/metrics.go 与 pkg/metrics/features/cell.go。健康检查行为chaining 模式会影响 agent 的若干默认行为例如在非portmap/none模式下会关闭健康检查相关逻辑见 cilium-configmap.yaml。这意味着选择 portmap chaining 时需要自行确认健康检查与流量路径的匹配关系。iptables 层面的联动agent 的 iptables 管理逻辑会读取 chaining 模式如对aws-cni模式做特判见 pkg/datapath/iptables/iptables.goportmap 模式下流量在主机命名空间与 Pod 之间穿行相关注释见 pkg/datapath/iptables/iptables.go。这提示我们在 portmap chaining 下主机 iptables 规则而非仅 eBPF 路径参与了端口转发。总结针对 HostPort 需求Cilium 给出的最佳实践是优先启用 eBPF kube-proxy replacement 以获得原生 HostPort 支持仅当环境必须保持kubeProxyReplacementfalse时才通过cni.chainingModeportmap的 CNI chaining 方式引入 portmap 插件。无论哪种方案都需要注意存量 Pod 的 CNI 配置刷新问题并在部署后使用cilium-dbg status与cilium-dbg service list等命令完成功能验证。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考