调试Kubernetes网络问题的关键技术

Kubernetes网络问题通常表现为超时、Connection refused、DNS解析失败、Service端点为空或Ingress响应异常。要快速定位问题，请按以下路径排查：源Pod、目标Pod、Service、DNS、NetworkPolicy，最后检查Ingress或负载均衡器。

本指南提供了一套实用的检查步骤和kubectl命令，帮助您找出流量中断的位置。

理解Kubernetes网络基础

在开始调试之前，掌握Kubernetes的核心网络概念非常重要：

Pod网络： 每个Pod拥有独立的IP地址。同一节点内的Pod可以直接通信，不同节点上的Pod通过虚拟网络（CNI插件）进行通信。
Service： Service为Pod集合提供稳定的IP地址和DNS名称。它作为抽象层，允许其他Pod或外部客户端访问应用后端，而无需知道单个Pod的IP。
DNS： Kubernetes DNS（通常是CoreDNS）将Service名称解析为集群IP，实现服务发现。
网络策略： 当CNI插件强制执行时，这些资源控制Pod流量。不支持NetworkPolicy的集群会接受对象但可能不执行规则。
Ingress： Ingress控制器管理集群内服务的外部访问，通常用于HTTP和HTTPS。它们提供路由、负载均衡和SSL终止功能。

当Pod之间无法通信（即使在同一命名空间内）时，这通常是网络问题的首要迹象。

验证Pod IP： 确保源Pod和目标Pod都有有效的IP地址。使用kubectl exec <pod-name> -- ip addr。
检查网络连通性（在Pod内）： 从源Pod尝试ping目标Pod的IP地址。如果失败，问题可能出在CNI插件或节点网络上。
```
kubectl exec <source-pod-name> -- ping <destination-pod-ip>
```
检查网络策略： 网络策略是常见原因。检查是否有策略意外阻止了Pod间的流量。
```
kubectl get networkpolicies -n <namespace>
```
检查podSelector和ingress/egress规则，了解允许或拒绝的流量。一旦Pod被ingress策略选中，只有明确允许的入站流量才被放行。
CNI插件状态： 确保容器网络接口（CNI）插件（如Calico、Flannel、Cilium）在所有节点上正常运行。检查CNI DaemonSet Pod的日志。
```
kubectl get pods -n kube-system -l k8s-app=<cni-plugin-label>
kubectl logs <cni-plugin-pod-name> -n kube-system
```

当Pod无法通过DNS名称或集群IP访问其他服务时，表明Kubernetes DNS或Service对象配置存在问题。

验证DNS解析： 从Pod测试已知服务的DNS解析。

kubectl exec <pod-name> -- nslookup <service-name>.<namespace>.svc.cluster.local

如果失败，检查CoreDNS Pod的错误。

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs <coredns-pod-name> -n kube-system

检查Service对象： 确保Service对象配置正确，并且有指向健康Pod的端点。
```
kubectl get service <service-name> -n <namespace> -o yaml
kubectl get endpoints <service-name> -n <namespace>
```
endpoints输出应列出支持该服务的Pod IP地址。
Pod就绪探针： 如果Pod未通过就绪探针，它们将不会被添加到Service的端点中。检查就绪探针配置和Pod日志以排查问题。

Ingress资源和Ingress控制器管理服务的外部访问。这里的问题可能导致应用程序从集群外部无法访问。

检查Ingress控制器Pod： 确保Ingress控制器Pod（如Nginx Ingress、Traefik）正在运行且健康。

kubectl get pods -l app.kubernetes.io/component=controller # 根据您的Ingress控制器调整标签
kubectl logs <ingress-controller-pod-name> -n <ingress-namespace>

验证Ingress资源： 检查Ingress资源的配置。
```
kubectl get ingress <ingress-name> -n <namespace> -o yaml
```
确保rules部分正确地将主机名和路径映射到相应的service.name和service.port。
检查Service和端点： 与服务发现类似，确保Ingress指向的后端Service配置正确且有健康的端点。
```
kubectl get service <backend-service-name> -n <namespace>
kubectl get endpoints <backend-service-name> -n <namespace>
```
防火墙和负载均衡器： 如果从集群外部访问，请确保外部防火墙或云提供商负载均衡器正确配置，以将流量转发到Ingress控制器的Service（通常是LoadBalancer类型）。

网络策略功能强大，但如果配置不当，也可能成为连接问题的根源。它们遵循最小权限原则；如果策略未明确允许流量，则默认拒绝。

识别应用的策略： 确定哪些网络策略影响了相关Pod。
```
kubectl get networkpolicy -n <namespace>
```
检查策略选择器： 仔细检查每个相关NetworkPolicy中的podSelector。该选择器决定了策略应用于哪些Pod。如果一个Pod被多个策略选中，允许的流量是所有策略规则的并集，而不是最严格的单个规则。
审查入站/出站规则： 分析网络策略的ingress和egress部分。如果您尝试从Pod A连接到Pod B，需要确保：
- 应用于Pod B的网络策略允许来自Pod A的入站流量（或包含Pod A的更广泛标签选择器）。
- 应用于Pod A的网络策略允许到Pod B的出站流量（或包含Pod B的更广泛标签选择器）。
使用全开放策略测试： 作为临时故障排除步骤，您可以创建一个允许所有流量进出特定Pod或命名空间的网络策略，以查看连接是否恢复。这有助于隔离问题是否确实由网络策略引起。
```
# 示例：允许所有入站和出站流量给带有标签app=my-app的Pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-for-my-app
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
    - {}
  egress:
    - {}
```
警告： 此allow-all策略仅用于临时调试。测试完成后请立即删除。

tcpdump：强大的命令行数据包分析器。您可以在Pod内或节点上运行它以捕获网络流量。

# 示例：在Pod内捕获eth0接口上的80端口流量
kubectl exec <pod-name> -- tcpdump -i eth0 -nn port 80

从内到外调试Kubernetes网络。首先验证Pod IP连通性，然后是Service端点、DNS、NetworkPolicy，最后检查Ingress或外部负载均衡器行为。按此顺序排查，可以避免在Service没有就绪端点时却去追踪Ingress症状的情况。