在K8S中，K8S集群外部，突然之间无法访问到Pod，排查思路是什么？

在K8s集群外部突然无法访问Pod时，排查需遵循“从底层到上层、从目标到入口”的逻辑，结合具体访问路径（如Service、Ingress）逐步定位问题，核心思路如下：

1. 先明确访问路径（关键前提）

外部访问Pod的方式决定了排查方向，需先确认是通过哪种方式访问：

• 直接通过 Service：如 NodePort（节点IP:端口）、LoadBalancer（负载均衡器IP:端口）；
• 通过 Ingress：通过域名访问（由Ingress控制器转发到后端Service/Pod）。
  不同路径的排查重点不同，需针对性分析。

2. 检查Pod本身是否正常（底层根基）

Pod是访问的最终目标，若Pod自身异常，必然导致访问失败：

• 状态检查：执行 kubectl get pods <pod-name>，确认Pod处于 Running 状态，且 READY 数正常（如 1/1）。若为 Pending 或 CrashLoopBackOff，需看事件（kubectl describe pod）排查原因（如资源不足、镜像拉取失败）。
• 就绪探针：若Pod未就绪（如 0/1），通过 kubectl describe pod 查看 Readiness Probe 失败原因（如端口未监听、健康检查接口返回错误）—— 未就绪的Pod会被Service从Endpoints中剔除，导致无法访问。
• 应用日志：执行 kubectl logs <pod-name> 确认应用是否正常启动（如是否监听了正确端口、是否有崩溃日志）。

3. 检查关联的Service（中间转发层）

外部通常通过Service访问Pod（Pod IP临时，Service提供固定入口），需验证Service是否正确转发流量：

• 基础配置：kubectl get svc <svc-name> 确认Service存在，类型匹配（如 NodePort/LoadBalancer），端口映射正确（port 对应Service端口，targetPort 对应Pod内应用端口）。
• Endpoints验证：Service通过Endpoints关联Pod，执行 kubectl describe svc <svc-name> 查看 Endpoints 字段：
  • 若为空（<none>）：说明Service的 selector 标签与Pod标签不匹配，或Pod未就绪，需修正标签或Pod问题。
  • 若有值（如 10.244.1.5:80）：说明Service已关联Pod，继续排查转发。
• Service类型专项检查：
  • NodePort：确认节点端口（如 30080）是否被监听（节点上执行 ss -tuln | grep 30080），未监听可能是kube-proxy异常。
  • LoadBalancer：查看外部IP（EXTERNAL-IP）是否有效，通过云厂商控制台检查负载均衡器后端节点是否健康（若后端不健康，可能是节点端口未开放或Pod故障）。

4. 若通过Ingress访问，检查Ingress配置与控制器

Ingress依赖控制器（如Nginx）转发域名流量，需验证规则和控制器状态：

• Ingress资源配置：kubectl describe ingress <ingress-name> 确认：
  • Host 与访问域名一致；
  • Path 规则匹配访问路径；
  • Backend 指向正确的Service和端口。
• Ingress控制器状态：
  • 检查控制器Pod是否运行：kubectl get pods -n <ingress-ns>（如 ingress-nginx 命名空间），若未运行，需看日志排查（如 kubectl logs <ingress-pod> -n <ingress-ns>）。
  • 测试控制器入口：用 curl -H "Host: 域名" <控制器IP:端口> 模拟访问，若失败，可能是控制器端口未开放或规则未生效。

5. 逐层测试网络连通性（定位拦截点）

用 curl/nc 从外部到Pod逐层验证，找出哪一层不通：

• 外部到入口：
  • 若为NodePort：nc <节点公网IP> <NodePort>，失败说明外部到节点的流量被拦截（如安全组、节点防火墙）。
  • 若为LoadBalancer：nc <LB公网IP> <端口>，失败检查LB配置或云厂商网络。
  • 若为Ingress：curl 域名 或 curl -H "Host: 域名" <控制器IP>，失败检查DNS解析或控制器转发。
• 节点到Pod：
  • 在节点上访问Pod IP:端口：curl <pod-ip>:<port>，失败说明Pod内应用未监听端口（如应用配置错误）或集群网络插件故障（如Calico/Flannel异常）。
  • 在节点上访问Service ClusterIP:端口：curl <cluster-ip>:<port>，失败说明Service转发异常（如kube-proxy未生成规则）。

6. 排查网络拦截（防火墙/策略）

流量可能被多层防火墙拦截：

• 节点防火墙：检查节点是否开放目标端口（如 iptables -L | grep <NodePort> 或 firewall-cmd --list-ports）。
• NetworkPolicy：执行 kubectl get networkpolicy 查看是否有Pod级防火墙规则，若存在，确认规则是否允许外部/Service的流量进入（如 from 字段是否包含正确源）。
• 外部防火墙：检查云厂商安全组、公司内网防火墙是否允许访问节点IP:端口或LB IP:端口。

7. 检查关键组件状态（转发核心）

• kube-proxy：负责Service转发，检查其Pod状态（kubectl get pods -n kube-system | grep kube-proxy）和日志（kubectl logs <kube-proxy-pod> -n kube-system），排查是否有规则配置失败（如iptables/ipvs错误）。
• 网络插件：若节点到Pod不通，检查网络插件（如Calico）的Pod状态（kubectl get pods -n kube-system）和日志，确认集群内部网络是否正常。

总结排查顺序

1. 确认Pod正常运行 → 2. 验证Service关联Pod（Endpoints非空） → 3. 检查访问入口（NodePort/LB/Ingress）是否可达 → 4. 排除网络拦截（防火墙/策略） → 5. 确认kube-proxy/Ingress控制器等组件正常。

通过以上步骤，可快速定位问题（如Pod崩溃、Service标签错误、防火墙拦截、控制器异常等）。