Pod路由如何配置？常见问题与排查方法是什么？

在Kubernetes集群中，Pod作为最小的可部署单元，其路由机制是确保服务间通信和外部流量访问的核心，Pod的IP地址由集群网络插件动态分配（如Flannel、Calico），具有临时性和不确定性，因此需要通过抽象层实现稳定、高效的流量转发，本文将详细解析Pod路由的核心机制、实现方式及典型应用场景。

Pod路由的核心机制：Service抽象层

直接通过Pod IP进行通信存在风险：Pod可能因故障重启、扩缩容导致IP变化，服务间依赖关系难以维护，Kubernetes通过Service对象解决这一问题，Service为后端Pod提供稳定的虚拟IP（ClusterIP）和DNS名称，并通过标签选择器（Label Selector）关联目标Pod,实现流量转发与负载均衡。

Service类型与路由实现

根据访问场景不同，Service分为四种核心类型，每种类型通过不同方式暴露服务,支持多样化的路由需求：

ClusterIP路由原理：当创建ClusterIP类型Service时，Kubernetes控制器会分配一个虚拟IP（如10.100.0.1），并在集群节点上通过iptables或IPVS规则实现流量转发，客户端访问ClusterIP:80时，kube-proxy会根据后端Pod的标签选择器（如app=nginx），将流量随机/轮询/加权转发到对应Pod的IP和端口（如10.244.1.2:80、10.244.1.3:80），负载均衡模式可通过spec.sessionAffinity和spec.externalTrafficPolicy配置,确保会话保持或保留客户端源IP。

NodePort路由原理：NodePort在每个节点上开放一个固定端口（如30080），客户端可通过任意节点的IP:NodePort访问服务，流量转发流程为：客户端流量→节点IP:NodePort→kube-proxy→ClusterIP→后端Pod，适用于需要集群外部访问但无需公网IP的场景,如测试环境或内网服务暴露。

LoadBalancer路由原理：在NodePort基础上，云厂商控制器（如AWS Load Balancer Controller）会创建云负载均衡器（如ELB、ALB），将外部流量分发到各节点的NodePort，最终转发到后端Pod，适用于生产环境公网服务，支持自动扩缩容和健康检查,但需云厂商支持且可能产生额外费用。

ExternalName原理：通过DNS CNAME记录将集群内部服务映射到外部服务（如external-db.example.com），集群内Pod可通过<service-name>.<namespace>.svc.cluster.local直接访问外部服务，无需修改配置，适用于集群内访问云数据库、第三方API等场景。

Ingress：集群外部流量的智能路由

Service的NodePort和LoadBalancer仅支持四层（TCP/UDP）路由，无法基于域名、HTTP路径、请求头等七层规则进行流量分发，Ingress作为Kubernetes的API对象，通过定义HTTP/HTTPS路由规则，配合Ingress Controller（如Nginx、Traefik）实现七层负载均衡和流量管理。

Ingress核心组件与工作原理

• Ingress资源：用户通过YAML配置路由规则，如基于域名example.com的路径/api转发到后端Service A，路径/admin转发到Service B。
• Ingress Controller：集群中部署的Pod（如Nginx Ingress Controller），监听Ingress资源变化，动态生成Nginx配置（如nginx.conf）,实现HTTP请求的路由转发。
• TLS证书管理：Ingress支持通过spec.tls字段配置TLS证书，实现HTTPS加密访问，也可通过 cert-manager 自动签发和更新证书。

典型Ingress规则示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /admin
        pathType: Prefix
        backend:
          service:
            name: admin-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: example-tls

当客户端访问https://example.com/api时，Ingress Controller（如Nginx）会匹配/api路径，将流量转发到api-service的ClusterIP,再由Service负载均衡到后端Pod。

网络策略与路由控制

默认情况下，集群内所有Pod之间可自由通信，但出于安全考虑，需通过NetworkPolicy限制流量访问规则，NetworkPolicy基于标签选择Pod，定义允许的入站（Ingress）和出站（Egress）流量,实现细粒度路由控制。

NetworkPolicy核心字段

• podSelector：选择目标Pod（如app=backend）。
• policyTypes：指定策略类型（Ingress/Egress）。
• ingress/egress：定义流量规则，如允许特定命名空间的Pod访问,或限制仅允许HTTP流量。

示例：限制仅允许前端Pod访问后端Pod：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

该规则仅允许带有app=frontend标签的Pod访问app=backendPod的80端口，其他Pod的访问将被拒绝，需注意，NetworkPolicy需网络插件支持（如Calico、Cilium）,Flannel默认不支持网络策略。

高级路由场景与实践

（1）灰度发布（金丝雀发布）

通过Service的权重（weight）字段和EndpointSlice，可将流量按比例分配到不同版本的Pod，实现灰度发布，创建v1和v2两个Deployment，对应一个Service，设置EndpointSlice的权重为90:10，使90%流量到v1，10%到v2,逐步调整权重全量发布v2版本。

（2）基于请求头的路由

Ingress支持通过注解（Annotation）实现基于请求头的路由，如Nginx Ingress可通过nginx.ingress.kubernetes.io/canary-by-header配置，当请求头Canary: always时,将流量转发到金丝雀版本Pod。

（3）多集群路由

通过Kubernetes联邦（如Karmada）或Service Mesh（如Istio），可实现跨集群的Pod路由，将流量分发到不同集群的Pod,提升集群可用性和资源利用率。

相关问答FAQs

Q1：Service和Ingress的主要区别是什么？
A：Service工作在OSI模型第四层（传输层），基于TCP/UDP端口和IP进行路由，适用于四层负载均衡（如TCP端口转发）；Ingress工作在第七层（应用层），基于HTTP/HTTPS域名、路径、请求头等规则路由，支持TLS终止、虚拟主机等高级功能，需配合Ingress Controller实现，Service负责“将流量转发到Pod”，Ingress负责“根据HTTP规则将流量转发到不同Service”。

Q2：如何排查Pod路由不通的问题？
A：排查步骤如下：

1. 检查Service状态：执行kubectl get svc <service-name> -n <namespace>，确认Endpoints数量是否与后端Pod数量一致（如kubectl get endpoints）；
2. 检查Pod状态：确认Pod是否Running且Ready（kubectl get pods），检查Pod日志（kubectl logs <pod-name>）是否有异常；
3. 检查网络插件：确认网络插件（如Calico）是否正常运行，Pod间网络是否连通（kubectl exec -it <pod-name> -- ping <pod-ip>）；
4. 检查防火墙/安全组：确认节点防火墙、云厂商安全组是否放通Service端口（如ClusterIP端口、NodePort端口）；
5. 检查kube-proxy：确认kube-proxy Pod正常运行，节点上iptables/IPVS规则是否正确（iptables -t nat -L | grep <service-cluster-ip>）。