尧图网站建设 
Cilium 安装验证指南使用 kubectl 部署 connectivity-check 测试集群 Pod 连通性【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇指南讲解如何在不借助 Cilium CLI 的情况下仅用kubectl部署官方的connectivity-check探针套件对 Cilium 数据平面进行端到端连通性验证。它适用于已完成 Cilium 安装、希望确认 Pod 间路由、Service 负载均衡、NodePort、网络策略CiliumNetworkPolicy与外部流量访问是否全部正常工作的场景。读完本文你将掌握完整的部署、判读与清理流程并能依据 Pod 名称与探针状态快速定位是哪一层数据通路出了问题。为什么需要 connectivity-checkCilium 的安装过程k8s-install-validate.rst提供了两种验证入口使用ciliumCLI 的自动化测试以及本文所介绍的手动kubectl验证方式。当集群环境受限、不便安装 Cilium CLI或希望用最原始的方式观察数据平面行为时connectivity-check是最轻量的选择。该套件以一批 Deployment、Service 和 CiliumNetworkPolicyCNP的形式部署到集群中测试 Pod 之间通过多种不同的数据通路互相访问。每一条通路都对应一类底层功能测试类别覆盖的功能点Pod-to-pod节点内eBPF 路由是否可用Pod-to-pod跨节点数据面、路由、网络overlay是否可用Pod-to-service节点内eBPF service map 查找是否正确Pod-to-service跨节点overlay 端口如 VXLAN与跨节点转发是否正常Pod-to-external 资源出向流量、CiliumNetworkPolicy、masqueradeSNAT是否正常该对照表同样出现在 troubleshooting.rst 的「Cilium connectivity tests」一节用于在排障时快速判断「某项测试通过」意味着「哪个子系统工作正常」。第一步创建独立的测试命名空间官方强烈建议为连通性测试创建独立命名空间避免与业务 Pod、既有网络策略相互干扰。推荐命名空间名为cilium-testkubectl create ns cilium-test注意connectivity-check 只应在没有其他 Pod 或网络策略的命名空间中运行。如果集群中启用了 Cilium Clusterwide Network PolicyCCNP同样可能破坏该连通性检查的结果。第二步部署 connectivity-check 清单仓库中提供了完整的清单文件 connectivity-check.yaml一条命令即可完成全部资源创建kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml提示若使用的是仓库克隆目录可直接以仓库根目录下的相对路径引用该文件若从文档页面操作请将路径替换为实际克隆到本地后的文件位置。该 YAML 由 Makefile 自动生成文件头部有# Automatically generated by Makefile. DO NOT EDIT注释不建议手工编辑如有定制需求应修改其上游模板或选择仓库中提供的其他变体清单。第三步观察测试结果部署后所有测试 Pod 会立即开始运行探针。Pod 名称表示连通性变体connectivity variantreadiness 与 liveness 探针状态则表示该测试的成功或失败——READY列为1/1且STATUS为Running即代表通过$ 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 host-to-b-multi-node-headless-dc6c44cb5-8jdz8 1/1 Running 0 65s pod-to-a-79546bc469-rl2qq 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-to-b-intra-node-nodeport-9b487cf89-6ptrt 1/1 Running 0 65s pod-to-b-multi-node-clusterip-7db5dfdcf7-jkjpw 1/1 Running 0 66s pod-to-b-multi-node-headless-7d44b85d69-mtscc 1/1 Running 0 66s pod-to-b-multi-node-nodeport-7ffc76db7c-rrw82 1/1 Running 0 65s pod-to-external-1111-d56f47579-d79dz 1/1 Running 0 66s pod-to-external-fqdn-allow-google-cnp-78986f4bcf-btjn7 1/1 Running 0 66s从源码结构看每个 Deployment 都在清单中被打上了语义化标签component: network-check、services-check、policy-check、nodeport-check以及topology: any / multi-node / intra-node这既用于探针 Pod 的亲和性调度也方便人工按类别过滤排查。单节点集群的预期行为如果当前集群只有一个节点凡是负责跨节点multi-node功能验证的 Pod 会一直停留在Pending状态。这是预期行为这些 Pod 通过podAntiAffinity反亲和被强制调度到与echo-b不同的节点上单节点集群中没有第二个节点可供调度因此无法被调度成功。同理探针 Pod 若看到Pending不代表数据平面故障。第四步测试完成后清理验证完毕删除整个命名空间即可无需逐条删除资源kubectl delete ns cilium-test探针套件组成解析为了让你在遇到失败时能快速定位问题这里结合 connectivity-check.yaml 的完整内容拆解每个资源的角色。服务端echo 系列 Deployment 与 Service清单首先创建了四个「被访问方」echo-a普通 Pod 内监听8080由 ClusterIP 类型 Serviceecho-a暴露用于基础 Pod-to-Pod 与 Pod-to-Service 测试。echo-b监听8080并同时声明hostPort: 40000由 NodePort 类型 Serviceecho-bnodePort: 31414暴露用于 Service 负载均衡与 NodePort 测试。echo-b-host以hostNetwork: true方式运行、监听21000并通过podAffinity强制与echo-b同节点调度配合无头 Serviceecho-b-host-headless模拟「宿主机网络」访问路径。无头headlessServiceecho-b-headlessclusterIP: None则用于验证绕过 kube-proxy 语义、直接由 DNS 返回 Pod IP 的访问路径。所有 echo Pod 均使用quay.io/cilium/json-mock镜像通过readinessProbe/livenessProbe对自身localhost:8080或21000做curl --fail探测保证服务端自身健康才标记就绪。客户端各类探针 Deployment客户端探针统一使用quay.io/cilium/alpine-curl镜像容器主进程仅执行sleep真正的验证动作全部由 Kubernetes 探针readiness/liveness完成。其命名即测试意图探针 Pod验证的数据通路pod-to-aPod 到 PodClusterIP Serviceecho-a的基础连通性pod-to-b-multi-node-clusterip跨节点访问 ClusterIP Service经 Service 负载均衡pod-to-b-multi-node-headless跨节点访问无头 Service直接解析到后端 Pod IPpod-to-b-multi-node-nodeport跨节点访问 NodePort31414pod-to-b-intra-node-nodeport节点内访问 NodePorthost-to-b-multi-node-clusterip/host-to-b-multi-node-headless以hostNetwork: truednsPolicy: ClusterFirstWithHostNet从宿主机网络命名空间访问 Service验证宿主机侧数据通路pod-to-external-1111Pod 出向访问外部https://1.1.1.1验证 egress、masqueradepod-to-a-allowed-cnp在 CNP 放行策略下访问echo-a:8080/public预期成功pod-to-a-denied-cnp在 CNP 默认拒绝策略下访问echo-a:8080/private探针命令为! curl ...预期失败取反后成功pod-to-external-fqdn-allow-google-cnp基于 FQDN 规则的出向访问www.google.com验证 DNS 感知的 egress 策略跨节点类探针通过podAntiAffinitytopologyKey: kubernetes.io/hostname强制与echo-b分离调度从而保证流量确实穿越了节点间网络节点内类探针则通过podAffinity强制同节点调度。网络策略三个 CiliumNetworkPolicypod-to-a-denied-cnp对自身endpointSelector生效egress 仅放行 DNS53/5353与默认拒绝其余流量使访问echo-a的/private路径被拒。pod-to-a-allowed-cnpegress 显式放行到echo-a的 8080/TCP 与 DNS验证「显式放行」路径。pod-to-external-fqdn-allow-google-cnpegress 通过toFQDNs: matchPattern: *.google.com放行 Google 域名并配套rules.dns允许 DNS 查询——这正是 Cilium 基于 FQDN 的动态策略能力的最小演示。失败时的排查方法若某个探针 Pod 处于CrashLoopBackOff或NotReady可用kubectl describe查看探针失败详情例如 troubleshooting.rst 中给出的示例$ kubectl describe pod 失败的探针 Pod -n cilium-test Warning Unhealthy 6s (x6 over 56s) kubelet, agent1 Readiness probe failed: curl: (7) Failed to connect to echo-b-host-headless port 40000: Connection refused Warning Unhealthy 2s (x3 over 52s) kubelet, agent1 Liveness probe failed: curl: (7) Failed to connect to echo-b-host-headless port 40000: Connection refusedcurl: (7) Connection refused表明目标端口无监听或数据通路未建立可据此结合上表定位是路由、Service 还是策略层面的问题再配合kubectl logs与 Cilium 的cilium-dbg命令进一步深入。其他场景变体清单仓库的 examples/kubernetes/connectivity-check/ 目录下还提供了针对特定场景的变体清单可按需替换第二步中的文件名connectivity-check-single-node.yaml去掉跨节点测试专供单节点集群使用避免无谓的Pending干扰判断。connectivity-check-internal.yaml仅保留集群内部流量测试不含访问外部资源如 1.1.1.1的探针适合无外网或出口受限的环境。connectivity-check-netpol-only.yaml聚焦网络策略CNP相关探针的变体。connectivity-check-proxy.yaml额外包含基于 Envoy 代理的 L7 策略探针从源码结构看包含echo-c/echo-c-host及*-proxy-ingress-policy、*-proxy-egress-policy等 Deployment 与对应 CNP用于验证代理重定向与 L7 策略执行。connectivity-check-hostport.yaml在标准套件基础上叠加 hostPort 相关探针含pod-to-b-intra-node-hostport、pod-to-b-multi-node-hostport。connectivity-check-quarantine.yaml面向隔离quarantine场景的探针变体。选择建议生产或离线集群优先使用-internal变体单节点集群使用-single-node需要验证 L7 代理能力时使用-proxy。小结通过kubectl部署 connectivity-check 是验证 Cilium 安装是否成功的最直接手段创建cilium-test命名空间 → 应用 connectivity-check.yaml → 观察探针 Pod 的 READY 状态 → 清理命名空间。整个过程不依赖任何额外 CLI 工具且 Pod 命名自带语义配合本指南中的功能对照表即使面对复杂的数据通路故障也能快速锁定问题子系统。若需要更自动化的逐项连通性报告可进一步使用 Cilium CLI 的cilium connectivity test作为补充。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cilium 安装验证指南：使用 kubectl 部署 connectivity-check 测试集群 Pod 连通性
Cilium 安装验证指南使用 kubectl 部署 connectivity-check 测试集群 Pod 连通性【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇指南讲解如何在不借助 Cilium CLI 的情况下仅用kubectl部署官方的connectivity-check探针套件对 Cilium 数据平面进行端到端连通性验证。它适用于已完成 Cilium 安装、希望确认 Pod 间路由、Service 负载均衡、NodePort、网络策略CiliumNetworkPolicy与外部流量访问是否全部正常工作的场景。读完本文你将掌握完整的部署、判读与清理流程并能依据 Pod 名称与探针状态快速定位是哪一层数据通路出了问题。为什么需要 connectivity-checkCilium 的安装过程k8s-install-validate.rst提供了两种验证入口使用ciliumCLI 的自动化测试以及本文所介绍的手动kubectl验证方式。当集群环境受限、不便安装 Cilium CLI或希望用最原始的方式观察数据平面行为时connectivity-check是最轻量的选择。该套件以一批 Deployment、Service 和 CiliumNetworkPolicyCNP的形式部署到集群中测试 Pod 之间通过多种不同的数据通路互相访问。每一条通路都对应一类底层功能测试类别覆盖的功能点Pod-to-pod节点内eBPF 路由是否可用Pod-to-pod跨节点数据面、路由、网络overlay是否可用Pod-to-service节点内eBPF service map 查找是否正确Pod-to-service跨节点overlay 端口如 VXLAN与跨节点转发是否正常Pod-to-external 资源出向流量、CiliumNetworkPolicy、masqueradeSNAT是否正常该对照表同样出现在 troubleshooting.rst 的「Cilium connectivity tests」一节用于在排障时快速判断「某项测试通过」意味着「哪个子系统工作正常」。第一步创建独立的测试命名空间官方强烈建议为连通性测试创建独立命名空间避免与业务 Pod、既有网络策略相互干扰。推荐命名空间名为cilium-testkubectl create ns cilium-test注意connectivity-check 只应在没有其他 Pod 或网络策略的命名空间中运行。如果集群中启用了 Cilium Clusterwide Network PolicyCCNP同样可能破坏该连通性检查的结果。第二步部署 connectivity-check 清单仓库中提供了完整的清单文件 connectivity-check.yaml一条命令即可完成全部资源创建kubectl apply -n cilium-test -f examples/kubernetes/connectivity-check/connectivity-check.yaml提示若使用的是仓库克隆目录可直接以仓库根目录下的相对路径引用该文件若从文档页面操作请将路径替换为实际克隆到本地后的文件位置。该 YAML 由 Makefile 自动生成文件头部有# Automatically generated by Makefile. DO NOT EDIT注释不建议手工编辑如有定制需求应修改其上游模板或选择仓库中提供的其他变体清单。第三步观察测试结果部署后所有测试 Pod 会立即开始运行探针。Pod 名称表示连通性变体connectivity variantreadiness 与 liveness 探针状态则表示该测试的成功或失败——READY列为1/1且STATUS为Running即代表通过$ 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 host-to-b-multi-node-headless-dc6c44cb5-8jdz8 1/1 Running 0 65s pod-to-a-79546bc469-rl2qq 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-to-b-intra-node-nodeport-9b487cf89-6ptrt 1/1 Running 0 65s pod-to-b-multi-node-clusterip-7db5dfdcf7-jkjpw 1/1 Running 0 66s pod-to-b-multi-node-headless-7d44b85d69-mtscc 1/1 Running 0 66s pod-to-b-multi-node-nodeport-7ffc76db7c-rrw82 1/1 Running 0 65s pod-to-external-1111-d56f47579-d79dz 1/1 Running 0 66s pod-to-external-fqdn-allow-google-cnp-78986f4bcf-btjn7 1/1 Running 0 66s从源码结构看每个 Deployment 都在清单中被打上了语义化标签component: network-check、services-check、policy-check、nodeport-check以及topology: any / multi-node / intra-node这既用于探针 Pod 的亲和性调度也方便人工按类别过滤排查。单节点集群的预期行为如果当前集群只有一个节点凡是负责跨节点multi-node功能验证的 Pod 会一直停留在Pending状态。这是预期行为这些 Pod 通过podAntiAffinity反亲和被强制调度到与echo-b不同的节点上单节点集群中没有第二个节点可供调度因此无法被调度成功。同理探针 Pod 若看到Pending不代表数据平面故障。第四步测试完成后清理验证完毕删除整个命名空间即可无需逐条删除资源kubectl delete ns cilium-test探针套件组成解析为了让你在遇到失败时能快速定位问题这里结合 connectivity-check.yaml 的完整内容拆解每个资源的角色。服务端echo 系列 Deployment 与 Service清单首先创建了四个「被访问方」echo-a普通 Pod 内监听8080由 ClusterIP 类型 Serviceecho-a暴露用于基础 Pod-to-Pod 与 Pod-to-Service 测试。echo-b监听8080并同时声明hostPort: 40000由 NodePort 类型 Serviceecho-bnodePort: 31414暴露用于 Service 负载均衡与 NodePort 测试。echo-b-host以hostNetwork: true方式运行、监听21000并通过podAffinity强制与echo-b同节点调度配合无头 Serviceecho-b-host-headless模拟「宿主机网络」访问路径。无头headlessServiceecho-b-headlessclusterIP: None则用于验证绕过 kube-proxy 语义、直接由 DNS 返回 Pod IP 的访问路径。所有 echo Pod 均使用quay.io/cilium/json-mock镜像通过readinessProbe/livenessProbe对自身localhost:8080或21000做curl --fail探测保证服务端自身健康才标记就绪。客户端各类探针 Deployment客户端探针统一使用quay.io/cilium/alpine-curl镜像容器主进程仅执行sleep真正的验证动作全部由 Kubernetes 探针readiness/liveness完成。其命名即测试意图探针 Pod验证的数据通路pod-to-aPod 到 PodClusterIP Serviceecho-a的基础连通性pod-to-b-multi-node-clusterip跨节点访问 ClusterIP Service经 Service 负载均衡pod-to-b-multi-node-headless跨节点访问无头 Service直接解析到后端 Pod IPpod-to-b-multi-node-nodeport跨节点访问 NodePort31414pod-to-b-intra-node-nodeport节点内访问 NodePorthost-to-b-multi-node-clusterip/host-to-b-multi-node-headless以hostNetwork: truednsPolicy: ClusterFirstWithHostNet从宿主机网络命名空间访问 Service验证宿主机侧数据通路pod-to-external-1111Pod 出向访问外部https://1.1.1.1验证 egress、masqueradepod-to-a-allowed-cnp在 CNP 放行策略下访问echo-a:8080/public预期成功pod-to-a-denied-cnp在 CNP 默认拒绝策略下访问echo-a:8080/private探针命令为! curl ...预期失败取反后成功pod-to-external-fqdn-allow-google-cnp基于 FQDN 规则的出向访问www.google.com验证 DNS 感知的 egress 策略跨节点类探针通过podAntiAffinitytopologyKey: kubernetes.io/hostname强制与echo-b分离调度从而保证流量确实穿越了节点间网络节点内类探针则通过podAffinity强制同节点调度。网络策略三个 CiliumNetworkPolicypod-to-a-denied-cnp对自身endpointSelector生效egress 仅放行 DNS53/5353与默认拒绝其余流量使访问echo-a的/private路径被拒。pod-to-a-allowed-cnpegress 显式放行到echo-a的 8080/TCP 与 DNS验证「显式放行」路径。pod-to-external-fqdn-allow-google-cnpegress 通过toFQDNs: matchPattern: *.google.com放行 Google 域名并配套rules.dns允许 DNS 查询——这正是 Cilium 基于 FQDN 的动态策略能力的最小演示。失败时的排查方法若某个探针 Pod 处于CrashLoopBackOff或NotReady可用kubectl describe查看探针失败详情例如 troubleshooting.rst 中给出的示例$ kubectl describe pod 失败的探针 Pod -n cilium-test Warning Unhealthy 6s (x6 over 56s) kubelet, agent1 Readiness probe failed: curl: (7) Failed to connect to echo-b-host-headless port 40000: Connection refused Warning Unhealthy 2s (x3 over 52s) kubelet, agent1 Liveness probe failed: curl: (7) Failed to connect to echo-b-host-headless port 40000: Connection refusedcurl: (7) Connection refused表明目标端口无监听或数据通路未建立可据此结合上表定位是路由、Service 还是策略层面的问题再配合kubectl logs与 Cilium 的cilium-dbg命令进一步深入。其他场景变体清单仓库的 examples/kubernetes/connectivity-check/ 目录下还提供了针对特定场景的变体清单可按需替换第二步中的文件名connectivity-check-single-node.yaml去掉跨节点测试专供单节点集群使用避免无谓的Pending干扰判断。connectivity-check-internal.yaml仅保留集群内部流量测试不含访问外部资源如 1.1.1.1的探针适合无外网或出口受限的环境。connectivity-check-netpol-only.yaml聚焦网络策略CNP相关探针的变体。connectivity-check-proxy.yaml额外包含基于 Envoy 代理的 L7 策略探针从源码结构看包含echo-c/echo-c-host及*-proxy-ingress-policy、*-proxy-egress-policy等 Deployment 与对应 CNP用于验证代理重定向与 L7 策略执行。connectivity-check-hostport.yaml在标准套件基础上叠加 hostPort 相关探针含pod-to-b-intra-node-hostport、pod-to-b-multi-node-hostport。connectivity-check-quarantine.yaml面向隔离quarantine场景的探针变体。选择建议生产或离线集群优先使用-internal变体单节点集群使用-single-node需要验证 L7 代理能力时使用-proxy。小结通过kubectl部署 connectivity-check 是验证 Cilium 安装是否成功的最直接手段创建cilium-test命名空间 → 应用 connectivity-check.yaml → 观察探针 Pod 的 READY 状态 → 清理命名空间。整个过程不依赖任何额外 CLI 工具且 Pod 命名自带语义配合本指南中的功能对照表即使面对复杂的数据通路故障也能快速锁定问题子系统。若需要更自动化的逐项连通性报告可进一步使用 Cilium CLI 的cilium connectivity test作为补充。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考