2026/9/14 8:50:10
FEATURED · 精选文章 
Cilium Service Mesh 排障实战Ingress 与连接性问题的系统化定位方法【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇指南聚焦 Cilium 官方运维文档 troubleshooting_servicemesh.rst 中描述的 Service MeshCilium Envoy proxy排障流程覆盖从部署基线检查、Ingress 资源配置核查到基于 Hubble 与cilium-dbg的逐层连接性故障定位。读完后你将掌握一套可复制的排障操作序列能够验证CiliumEnvoyConfigCEC资源是否正确下发、Envoy 代理是否真正在节点上运行并借助world(identity 2)、ingress(identity 8) 与后端 Pod identity 的流量视图精确定位 503、no healthy upstream等典型故障的根因。一、准备工作验证 Cilium 组件基本健康排障的第一步是确认控制面组件本身处于健康状态。按文档要求先安装 Cilium CLI然后执行$ cilium status需要确认ds/ciliumCilium agent DaemonSet以及deployment/cilium-operator的 Pod 均处于 healthy 且 ready 状态。Cilium 的 Envoy 服务网格能力由 agent节点侧 xDS 服务端与 Envoy 进程管理和 operatorIngress 控制器、CEC 翻译共同提供任何一侧不健康都会直接导致网格不可用。二、手动验证 Service Mesh 前置配置在深入具体故障前文档要求手动核对三个关键配置这是最常见的“部署级”故障来源。2.1 验证 kubeProxyReplacement 已启用Cilium 的 Envoy 代理流量路径依赖 Cilium 自身实现的服务负载均衡替代 kube-proxy。在任意节点上执行$ kubectl exec -n kube-system ds/cilium -- cilium-dbg status ... KubeProxyReplacement: True ...KubeProxyReplacement: True出现即表示节点已按网格所需的模式工作。2.2 验证 enable-envoy-config 与 enable-ingress-controller$ kubectl -n kube-system get cm cilium-config -o json | egrep enable-ingress-controller|enable-ingress-controller|enable-envoy-config enable-envoy-config: true, enable-ingress-controller: true,enable-envoy-config开启 agent 对CiliumEnvoyConfig/CiliumClusterwideEnvoyConfigCRD 的监听与 Envoy 配置下发能力。该开关对应的配置常量定义在 pkg/option/config.goEnableEnvoyConfig enable-envoy-config。enable-ingress-controller开启 Cilium Ingress 控制器。如果用户只手动使用CiliumEnvoyConfig或CiliumClusterwideEnvoyConfigCRD 而不依赖 Ingress 自动翻译该开关是可选的。从源码结构看agent 侧的 CEC 处理逻辑位于 pkg/ciliumenvoyconfig/包含 CEC 资源解析cec_resource_parser.go、K8s 监听器k8s_reflector.go、状态表tables.go与reconciler.go而 operator 侧的 Ingress 控制器位于 operator/pkg/ingress/ 与 operator/pkg/model/translation/ingress/两者分别对应上述两个开关所控制的功能。三、Ingress 排障理解内部生成的资源模型3.1 每个 Ingress 对应哪些资源Cilium Ingress 控制器内部会为每一个 Ingress 资源创建一个LoadBalancer Service一个CiliumEnvoyConfigCEC一个占位用的 dummy Endpoint 资源。这一命名/翻译逻辑可以在 operator 源码中得到印证operator/pkg/model/translation/ingress/dedicated_ingress.go 中定义了ciliumIngressPrefix cilium-ingress即 Service、CEC 等衍生资源均以该前缀命名。3.2 检查 LoadBalancer Service 与 CEC 是否存在先确认 Ingress 已被分配地址$ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE basic-ingress cilium * 10.97.60.117 80 16m然后按 Load Balancer 模式分别检查Dedicated Load Balancer 模式每个 Ingress 独立 Service 与 CEC# 专属 LoadBalancer 模式下的 Service $ kubectl get service cilium-ingress-basic-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-basic-ingress LoadBalancer 10.97.60.117 10.97.60.117 80:31911/TCP 17m # 专属 LoadBalancer 模式下的 CEC命名规则cilium-ingress-namespace-ingress-name $ kubectl get cec cilium-ingress-default-basic-ingress NAME AGE cilium-ingress-default-basic-ingress 18mShared Load Balancer 模式所有 Ingress 共享kube-system下的一个 Service 与 CEC# 共享 LoadBalancer 模式的 Service $ kubectl get services -n kube-system cilium-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress LoadBalancer 10.111.109.99 10.111.109.99 80:32690/TCP,443:31566/TCP 38m # 共享 LoadBalancer 模式的 CEC $ kubectl get cec -n kube-system cilium-ingress NAME AGE cilium-ingress 15m3.3 三个关键核查点LoadBalancer Service 是否拿到外部 IP 或 FQDN如果长时间没有分配问题在云厂商侧的 LB 供给能力应查阅对应云提供商的 LoadBalancer 相关文档该段链路在 Cilium 范围之外。CEC 资源下发过程有无告警/错误对于 Ingress 控制器自动生成的 CEC这一步出问题概率较低但手动创建的 CEC 需要重点关注。务必了解 CEC 的校验盲区按官方警告warning.rst这些 Envoy 资源完全不受 K8s 校验——kubectl apply会报告成功但节点本地 Envoy 实例解析/安装资源可能已经失败。当前唯一的验证手段是观察 Cilium Agent 日志中的错误与告警此外 Agent 会对集群内相互冲突的 Envoy 资源打印 warning 日志。因此凡是从kubectl get cec到“实际代理行为”之间对不上的情况第一手证据永远是 agent 日志。四、连接性排障沿请求路径逐层验证本节以 Ingress 资源为主同样适用于手动配置的CiliumEnvoyConfig资源。一条入站请求的正常路径是云 LoadBalancer Service → 节点 NodePort → Cilium Envoy proxy重定向端口→ 真实后端 Service/Pod4.0 开启调试日志前提建议先开启debug与debug-verbose$ kubectl get -n kube-system cm cilium-config -o json | grep debug debug: true, debug-verbose: flow,注意任何 Cilium flag 的变更都需要重启 Cilium agent 和 operator 才会生效。另外有一个关键事实要牢记ingress 流量的策略执行依据的是原始源 IPworld而不是代理的 IP。4.1 第一层云 LB → 节点 NodePortCilium 范围之外这一段链路属于云提供商侧需按其文档确认集群的 LB 配置正确。确认方式见下一节——直接在本机打 NodePort即可把该层隔离出去。4.2 第二层在节点本机打 NodePort验证“流量已到达 Envoy”先拿到 NodePort$ kubectl get service cilium-ingress-basic-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-basic-ingress LoadBalancer 10.97.60.117 10.97.60.117 80:31911/TCP 17mSSH 登录任意 k8s 节点后对 localhost 的该端口发送同类请求# ssh 到任一 k8s 节点后 $ curl -v http://localhost:31911/ * Trying 127.0.0.1:31911... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 31911 (#0) GET / HTTP/1.1 Host: localhost:31911 User-Agent: curl/7.68.0 Accept: */* * Mark bundle as not supporting multiuse HTTP/1.1 503 Service Unavailable content-length: 19 content-type: text/plain date: Thu, 07 Jul 2022 12:25:56 GMT server: envoy * Connection #0 to host localhost left intact返回体带有server: envoy响应头、HTTP 503说明请求已经成功被重定向到 Envoy 代理503 是后端尚未就绪时 Envoy 的正常应答。同时可用 Hubble 观察worldidentity 2的流$ kubectl -n kube-system exec ds/cilium -- hubble observe -f --identity 2 Jul 7 12:28:27.970: 127.0.0.1:54704 - 127.0.0.1:13681 http-response FORWARDED (HTTP/1.1 503 0ms (GET http://localhost:31911/))替代路径直接打 Envoy proxy 端口。Ingress 场景下proxy 端口由 Cilium Ingress 控制器随机分配手动 CEC 场景下端口直接取自资源 spec。随机端口的取值方法——观察 agent 日志$ kubectl logs -f -n kube-system ds/cilium --timestamps | egrep envoy|proxy ... 2022-07-08T08:05:13.986649816Z levelinfo msgAdding new proxy port rules for cilium-ingress-default-basic-ingress:19672 proxy port namecilium-ingress-default-basic-ingress subsysproxy # ssh 到任一 k8s 节点后直接向 Envoy proxy 端口发请求 $ curl -v http://localhost:19672 * Trying 127.0.0.1:19672... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 19672 (#0) GET / HTTP/1.1 Host: localhost:19672 User-Agent: curl/7.68.0 Accept: */* * Mark bundle as not supporting multiuse HTTP/1.1 503 Service Unavailable content-length: 19 content-type: text/plain date: Fri, 08 Jul 2022 08:12:35 GMT server: envoy从源码结构看这条日志出自 agent 的代理端口管理逻辑 pkg/proxy/proxyports/proxyports.go当某条 CEC 配置的 proxy 端口被确认后AckProxyPort会打印Adding new proxy port rules并调用InstallProxyRules在节点上安装流量重定向规则——即这条日志既是“端口在哪”的查询手段也是“重定向规则已安装”的证据。如果上述请求能返回带server: envoy的 503说明重定向链完整最常见的根因是该节点上的 Cilium Envoy proxy 没有运行或 CEC 资源的 provisioning 出了问题。此时应检查$ kubectl exec -n kube-system ds/cilium -- cilium-dbg status ... Controller Status: 49/49 healthy Proxy Status: OK, ip 10.0.0.25, 6 redirects active on ports 10000-20000 Global Identity Range: min 256, max 65535Proxy Status: OK且redirects active表明 Envoy 已运行、重定向规则已生效。4.3 第三层通过外部 IP/FQDN 打真实后端定位 “no healthy upstream”前两层通过后使用外部 IP或 FQDN发请求$ LB_IP$(kubectl get ingress basic-ingress -o json | jq .status.loadBalancer.ingress[0].ip | jq -r .) $ curl -s http://$LB_IP/details/1 no healthy upstreamno healthy upstream表示 Envoy 已收到请求但找不到健康上游。此时先确认后端 Service 是否 up 且 healthy再检查 CEC 中 EDS 资源的后端命名。Envoy Discovery ServiceEDS资源名遵循约定namespace/service-name:port$ kubectl get cec cilium-ingress-default-basic-ingress -o json | jq .spec.resources[] | select(.typeEDS) { type: type.googleapis.com/envoy.config.cluster.v3.Cluster, connectTimeout: 5s, name: default/details:9080, outlierDetection: { consecutiveLocalOriginFailure: 2, splitExternalLocalOriginErrors: true }, type: EDS, typedExtensionProtocolOptions: { envoy.extensions.upstreams.http.v3.HttpProtocolOptions: { type: type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions, useDownstreamProtocolConfig: { http2ProtocolOptions: {} } } } } { type: type.googleapis.com/envoy.config.cluster.v3.Cluster, connectTimeout: 5s, name: default/productpage:9080, ... }若配置全部正确用 Hubble 按 identity 过滤应能看到三类流量world(2)、ingress(8即 Envoy 代理) 以及后端 Pod 的 identity可通过cilium-dbg identity list查询# world identity 的流 $ kubectl exec -n kube-system ds/cilium -- hubble observe --identity 2 -f Jul 7 13:07:46.726: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-request FORWARDED (HTTP/1.1 GET http://10.97.60.117/details/1) Jul 7 13:07:46.727: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-response FORWARDED (HTTP/1.1 200 1ms (GET http://10.97.60.117/details/1)) # ingress identityEnvoy 代理的流 $ kubectl exec -n kube-system ds/cilium -- hubble observe --identity 8 -f Jul 7 13:07:46.726: 10.0.0.95:42509 - default/details-v1-5498c86cf5-cnt9q:9080 to-endpoint FORWARDED (TCP Flags: SYN) Jul 7 13:07:46.726: 10.0.0.95:42509 - default/details-v1-5498c86cf5-cnt9q:9080 to-stack FORWARDED (TCP Flags: SYN, ACK) ... # 后端 Pod 的流identity 通过 cilium-dbg identity list 获取示例为 48847 $ kubectl exec -n kube-system ds/cilium -- hubble observe --identity 48847 -f Jul 7 13:07:46.726: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-request FORWARDED (HTTP/1.1 GET http://10.97.60.117/details/1) Jul 7 13:07:46.727: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-response FORWARDED (HTTP/1.1 200 1ms (GET http://10.97.60.117/details/1)) ...也可以用cilium-dbg monitor观察更细的转发视图正常转发时能看到identity ingress-backend与Request ... verdict Forwarded的记录$ kubectl exec -n kube-system ds/cilium -- cilium-dbg monitor levelinfo msgInitializing dissection cache... subsysmonitor - endpoint 212 flow 0x3000e251 , identity ingress-61131 state new ifindex lxcfc90a8580fd6 orig-ip 10.0.0.192: 10.0.0.192:34219 - 10.0.0.164:9080 tcp SYN - Request http from 0 ([reserved:world]) to 212 ([...k8s:appdetails]), identity 2-61131, verdict Forwarded GET http://10.99.74.157/details/1 0 - Response http to 0 ([reserved:world]) from 212 ([...k8s:appdetails]), identity 61131-2, verdict Forwarded GET http://10.99.74.157/details/1 200五、排障路径速查现象首先检查依据所有网格功能不可用cilium status、agent/operator 是否 readykubeProxyReplacement、enable-envoy-config是否开启第二、三节pkg/option/config.goIngress 无 ADDRESS云 LB 供给Service/CEC 是否存在dedicated 与 shared 两种命名operator/pkg/model/translation/ingress/dedicated_ingress.go节点打 NodePort 无响应/无 503Envoy 是否运行cilium-dbg status的Proxy Statusagent 日志中Adding new proxy port rulespkg/proxy/proxyports/proxyports.go收到 503 带server: envoy链路已到 Envoy继续查后端 Service 健康度与 CEC 的 EDS 命名namespace/service-name:port4.2 / 4.3 节no healthy upstream后端 Pod/Service 健康状态hubble observe --identity 8看代理到后端的 TCP 流是否 DROPPED4.3 节kubectl apply的 CEC “成功”但行为异常CEC 不受 K8s 校验检查 agent 日志的 error/warningwarning.rst六、小结Cilium Service Mesh 的排障核心思路是沿数据路径分层隔离云 LB → 节点 NodePortcurl本机 server: envoy503 验证重定向生效→ Envoy proxyProxy Status与随机 proxy 端口验证代理运行→ 后端 EDSno healthy upstream时核对namespace/service-name:port命名与后端健康度。全程以hubble observe --identity 2|8|backend与cilium-dbg monitor提供的流量视图作为判定依据并把“CEC 资源不被 K8s 校验、只能看 agent 日志”这一盲区纳入每次排查的默认动作。更完整的 Hubble 流量诊断方法可参考官方 Hubble 排障章节文档内hubble_troubleshooting引用Envoy 资源的生成逻辑则可进一步阅读 operator/pkg/ingress/ 与 pkg/ciliumenvoyconfig/ 下的源码与测试数据如 pkg/ciliumenvoyconfig/testdata/ingress.txtar加深理解。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cilium Service Mesh 排障实战：Ingress 与连接性问题的系统化定位方法
Cilium Service Mesh 排障实战Ingress 与连接性问题的系统化定位方法【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium本篇指南聚焦 Cilium 官方运维文档 troubleshooting_servicemesh.rst 中描述的 Service MeshCilium Envoy proxy排障流程覆盖从部署基线检查、Ingress 资源配置核查到基于 Hubble 与cilium-dbg的逐层连接性故障定位。读完后你将掌握一套可复制的排障操作序列能够验证CiliumEnvoyConfigCEC资源是否正确下发、Envoy 代理是否真正在节点上运行并借助world(identity 2)、ingress(identity 8) 与后端 Pod identity 的流量视图精确定位 503、no healthy upstream等典型故障的根因。一、准备工作验证 Cilium 组件基本健康排障的第一步是确认控制面组件本身处于健康状态。按文档要求先安装 Cilium CLI然后执行$ cilium status需要确认ds/ciliumCilium agent DaemonSet以及deployment/cilium-operator的 Pod 均处于 healthy 且 ready 状态。Cilium 的 Envoy 服务网格能力由 agent节点侧 xDS 服务端与 Envoy 进程管理和 operatorIngress 控制器、CEC 翻译共同提供任何一侧不健康都会直接导致网格不可用。二、手动验证 Service Mesh 前置配置在深入具体故障前文档要求手动核对三个关键配置这是最常见的“部署级”故障来源。2.1 验证 kubeProxyReplacement 已启用Cilium 的 Envoy 代理流量路径依赖 Cilium 自身实现的服务负载均衡替代 kube-proxy。在任意节点上执行$ kubectl exec -n kube-system ds/cilium -- cilium-dbg status ... KubeProxyReplacement: True ...KubeProxyReplacement: True出现即表示节点已按网格所需的模式工作。2.2 验证 enable-envoy-config 与 enable-ingress-controller$ kubectl -n kube-system get cm cilium-config -o json | egrep enable-ingress-controller|enable-ingress-controller|enable-envoy-config enable-envoy-config: true, enable-ingress-controller: true,enable-envoy-config开启 agent 对CiliumEnvoyConfig/CiliumClusterwideEnvoyConfigCRD 的监听与 Envoy 配置下发能力。该开关对应的配置常量定义在 pkg/option/config.goEnableEnvoyConfig enable-envoy-config。enable-ingress-controller开启 Cilium Ingress 控制器。如果用户只手动使用CiliumEnvoyConfig或CiliumClusterwideEnvoyConfigCRD 而不依赖 Ingress 自动翻译该开关是可选的。从源码结构看agent 侧的 CEC 处理逻辑位于 pkg/ciliumenvoyconfig/包含 CEC 资源解析cec_resource_parser.go、K8s 监听器k8s_reflector.go、状态表tables.go与reconciler.go而 operator 侧的 Ingress 控制器位于 operator/pkg/ingress/ 与 operator/pkg/model/translation/ingress/两者分别对应上述两个开关所控制的功能。三、Ingress 排障理解内部生成的资源模型3.1 每个 Ingress 对应哪些资源Cilium Ingress 控制器内部会为每一个 Ingress 资源创建一个LoadBalancer Service一个CiliumEnvoyConfigCEC一个占位用的 dummy Endpoint 资源。这一命名/翻译逻辑可以在 operator 源码中得到印证operator/pkg/model/translation/ingress/dedicated_ingress.go 中定义了ciliumIngressPrefix cilium-ingress即 Service、CEC 等衍生资源均以该前缀命名。3.2 检查 LoadBalancer Service 与 CEC 是否存在先确认 Ingress 已被分配地址$ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE basic-ingress cilium * 10.97.60.117 80 16m然后按 Load Balancer 模式分别检查Dedicated Load Balancer 模式每个 Ingress 独立 Service 与 CEC# 专属 LoadBalancer 模式下的 Service $ kubectl get service cilium-ingress-basic-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-basic-ingress LoadBalancer 10.97.60.117 10.97.60.117 80:31911/TCP 17m # 专属 LoadBalancer 模式下的 CEC命名规则cilium-ingress-namespace-ingress-name $ kubectl get cec cilium-ingress-default-basic-ingress NAME AGE cilium-ingress-default-basic-ingress 18mShared Load Balancer 模式所有 Ingress 共享kube-system下的一个 Service 与 CEC# 共享 LoadBalancer 模式的 Service $ kubectl get services -n kube-system cilium-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress LoadBalancer 10.111.109.99 10.111.109.99 80:32690/TCP,443:31566/TCP 38m # 共享 LoadBalancer 模式的 CEC $ kubectl get cec -n kube-system cilium-ingress NAME AGE cilium-ingress 15m3.3 三个关键核查点LoadBalancer Service 是否拿到外部 IP 或 FQDN如果长时间没有分配问题在云厂商侧的 LB 供给能力应查阅对应云提供商的 LoadBalancer 相关文档该段链路在 Cilium 范围之外。CEC 资源下发过程有无告警/错误对于 Ingress 控制器自动生成的 CEC这一步出问题概率较低但手动创建的 CEC 需要重点关注。务必了解 CEC 的校验盲区按官方警告warning.rst这些 Envoy 资源完全不受 K8s 校验——kubectl apply会报告成功但节点本地 Envoy 实例解析/安装资源可能已经失败。当前唯一的验证手段是观察 Cilium Agent 日志中的错误与告警此外 Agent 会对集群内相互冲突的 Envoy 资源打印 warning 日志。因此凡是从kubectl get cec到“实际代理行为”之间对不上的情况第一手证据永远是 agent 日志。四、连接性排障沿请求路径逐层验证本节以 Ingress 资源为主同样适用于手动配置的CiliumEnvoyConfig资源。一条入站请求的正常路径是云 LoadBalancer Service → 节点 NodePort → Cilium Envoy proxy重定向端口→ 真实后端 Service/Pod4.0 开启调试日志前提建议先开启debug与debug-verbose$ kubectl get -n kube-system cm cilium-config -o json | grep debug debug: true, debug-verbose: flow,注意任何 Cilium flag 的变更都需要重启 Cilium agent 和 operator 才会生效。另外有一个关键事实要牢记ingress 流量的策略执行依据的是原始源 IPworld而不是代理的 IP。4.1 第一层云 LB → 节点 NodePortCilium 范围之外这一段链路属于云提供商侧需按其文档确认集群的 LB 配置正确。确认方式见下一节——直接在本机打 NodePort即可把该层隔离出去。4.2 第二层在节点本机打 NodePort验证“流量已到达 Envoy”先拿到 NodePort$ kubectl get service cilium-ingress-basic-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-basic-ingress LoadBalancer 10.97.60.117 10.97.60.117 80:31911/TCP 17mSSH 登录任意 k8s 节点后对 localhost 的该端口发送同类请求# ssh 到任一 k8s 节点后 $ curl -v http://localhost:31911/ * Trying 127.0.0.1:31911... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 31911 (#0) GET / HTTP/1.1 Host: localhost:31911 User-Agent: curl/7.68.0 Accept: */* * Mark bundle as not supporting multiuse HTTP/1.1 503 Service Unavailable content-length: 19 content-type: text/plain date: Thu, 07 Jul 2022 12:25:56 GMT server: envoy * Connection #0 to host localhost left intact返回体带有server: envoy响应头、HTTP 503说明请求已经成功被重定向到 Envoy 代理503 是后端尚未就绪时 Envoy 的正常应答。同时可用 Hubble 观察worldidentity 2的流$ kubectl -n kube-system exec ds/cilium -- hubble observe -f --identity 2 Jul 7 12:28:27.970: 127.0.0.1:54704 - 127.0.0.1:13681 http-response FORWARDED (HTTP/1.1 503 0ms (GET http://localhost:31911/))替代路径直接打 Envoy proxy 端口。Ingress 场景下proxy 端口由 Cilium Ingress 控制器随机分配手动 CEC 场景下端口直接取自资源 spec。随机端口的取值方法——观察 agent 日志$ kubectl logs -f -n kube-system ds/cilium --timestamps | egrep envoy|proxy ... 2022-07-08T08:05:13.986649816Z levelinfo msgAdding new proxy port rules for cilium-ingress-default-basic-ingress:19672 proxy port namecilium-ingress-default-basic-ingress subsysproxy # ssh 到任一 k8s 节点后直接向 Envoy proxy 端口发请求 $ curl -v http://localhost:19672 * Trying 127.0.0.1:19672... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 19672 (#0) GET / HTTP/1.1 Host: localhost:19672 User-Agent: curl/7.68.0 Accept: */* * Mark bundle as not supporting multiuse HTTP/1.1 503 Service Unavailable content-length: 19 content-type: text/plain date: Fri, 08 Jul 2022 08:12:35 GMT server: envoy从源码结构看这条日志出自 agent 的代理端口管理逻辑 pkg/proxy/proxyports/proxyports.go当某条 CEC 配置的 proxy 端口被确认后AckProxyPort会打印Adding new proxy port rules并调用InstallProxyRules在节点上安装流量重定向规则——即这条日志既是“端口在哪”的查询手段也是“重定向规则已安装”的证据。如果上述请求能返回带server: envoy的 503说明重定向链完整最常见的根因是该节点上的 Cilium Envoy proxy 没有运行或 CEC 资源的 provisioning 出了问题。此时应检查$ kubectl exec -n kube-system ds/cilium -- cilium-dbg status ... Controller Status: 49/49 healthy Proxy Status: OK, ip 10.0.0.25, 6 redirects active on ports 10000-20000 Global Identity Range: min 256, max 65535Proxy Status: OK且redirects active表明 Envoy 已运行、重定向规则已生效。4.3 第三层通过外部 IP/FQDN 打真实后端定位 “no healthy upstream”前两层通过后使用外部 IP或 FQDN发请求$ LB_IP$(kubectl get ingress basic-ingress -o json | jq .status.loadBalancer.ingress[0].ip | jq -r .) $ curl -s http://$LB_IP/details/1 no healthy upstreamno healthy upstream表示 Envoy 已收到请求但找不到健康上游。此时先确认后端 Service 是否 up 且 healthy再检查 CEC 中 EDS 资源的后端命名。Envoy Discovery ServiceEDS资源名遵循约定namespace/service-name:port$ kubectl get cec cilium-ingress-default-basic-ingress -o json | jq .spec.resources[] | select(.typeEDS) { type: type.googleapis.com/envoy.config.cluster.v3.Cluster, connectTimeout: 5s, name: default/details:9080, outlierDetection: { consecutiveLocalOriginFailure: 2, splitExternalLocalOriginErrors: true }, type: EDS, typedExtensionProtocolOptions: { envoy.extensions.upstreams.http.v3.HttpProtocolOptions: { type: type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions, useDownstreamProtocolConfig: { http2ProtocolOptions: {} } } } } { type: type.googleapis.com/envoy.config.cluster.v3.Cluster, connectTimeout: 5s, name: default/productpage:9080, ... }若配置全部正确用 Hubble 按 identity 过滤应能看到三类流量world(2)、ingress(8即 Envoy 代理) 以及后端 Pod 的 identity可通过cilium-dbg identity list查询# world identity 的流 $ kubectl exec -n kube-system ds/cilium -- hubble observe --identity 2 -f Jul 7 13:07:46.726: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-request FORWARDED (HTTP/1.1 GET http://10.97.60.117/details/1) Jul 7 13:07:46.727: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-response FORWARDED (HTTP/1.1 200 1ms (GET http://10.97.60.117/details/1)) # ingress identityEnvoy 代理的流 $ kubectl exec -n kube-system ds/cilium -- hubble observe --identity 8 -f Jul 7 13:07:46.726: 10.0.0.95:42509 - default/details-v1-5498c86cf5-cnt9q:9080 to-endpoint FORWARDED (TCP Flags: SYN) Jul 7 13:07:46.726: 10.0.0.95:42509 - default/details-v1-5498c86cf5-cnt9q:9080 to-stack FORWARDED (TCP Flags: SYN, ACK) ... # 后端 Pod 的流identity 通过 cilium-dbg identity list 获取示例为 48847 $ kubectl exec -n kube-system ds/cilium -- hubble observe --identity 48847 -f Jul 7 13:07:46.726: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-request FORWARDED (HTTP/1.1 GET http://10.97.60.117/details/1) Jul 7 13:07:46.727: 192.168.49.1:59608 - default/details-v1-5498c86cf5-cnt9q:9080 http-response FORWARDED (HTTP/1.1 200 1ms (GET http://10.97.60.117/details/1)) ...也可以用cilium-dbg monitor观察更细的转发视图正常转发时能看到identity ingress-backend与Request ... verdict Forwarded的记录$ kubectl exec -n kube-system ds/cilium -- cilium-dbg monitor levelinfo msgInitializing dissection cache... subsysmonitor - endpoint 212 flow 0x3000e251 , identity ingress-61131 state new ifindex lxcfc90a8580fd6 orig-ip 10.0.0.192: 10.0.0.192:34219 - 10.0.0.164:9080 tcp SYN - Request http from 0 ([reserved:world]) to 212 ([...k8s:appdetails]), identity 2-61131, verdict Forwarded GET http://10.99.74.157/details/1 0 - Response http to 0 ([reserved:world]) from 212 ([...k8s:appdetails]), identity 61131-2, verdict Forwarded GET http://10.99.74.157/details/1 200五、排障路径速查现象首先检查依据所有网格功能不可用cilium status、agent/operator 是否 readykubeProxyReplacement、enable-envoy-config是否开启第二、三节pkg/option/config.goIngress 无 ADDRESS云 LB 供给Service/CEC 是否存在dedicated 与 shared 两种命名operator/pkg/model/translation/ingress/dedicated_ingress.go节点打 NodePort 无响应/无 503Envoy 是否运行cilium-dbg status的Proxy Statusagent 日志中Adding new proxy port rulespkg/proxy/proxyports/proxyports.go收到 503 带server: envoy链路已到 Envoy继续查后端 Service 健康度与 CEC 的 EDS 命名namespace/service-name:port4.2 / 4.3 节no healthy upstream后端 Pod/Service 健康状态hubble observe --identity 8看代理到后端的 TCP 流是否 DROPPED4.3 节kubectl apply的 CEC “成功”但行为异常CEC 不受 K8s 校验检查 agent 日志的 error/warningwarning.rst六、小结Cilium Service Mesh 的排障核心思路是沿数据路径分层隔离云 LB → 节点 NodePortcurl本机 server: envoy503 验证重定向生效→ Envoy proxyProxy Status与随机 proxy 端口验证代理运行→ 后端 EDSno healthy upstream时核对namespace/service-name:port命名与后端健康度。全程以hubble observe --identity 2|8|backend与cilium-dbg monitor提供的流量视图作为判定依据并把“CEC 资源不被 K8s 校验、只能看 agent 日志”这一盲区纳入每次排查的默认动作。更完整的 Hubble 流量诊断方法可参考官方 Hubble 排障章节文档内hubble_troubleshooting引用Envoy 资源的生成逻辑则可进一步阅读 operator/pkg/ingress/ 与 pkg/ciliumenvoyconfig/ 下的源码与测试数据如 pkg/ciliumenvoyconfig/testdata/ingress.txtar加深理解。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
