如何让K8s服务无视Pod的IP变化

如何让Kubernetes服务无视Pod的IP变化？生产环境实战指南

在Kubernetes集群中，Pod的IP地址就像租房族的搬家频率——可能因扩缩容、节点故障或滚动更新频繁变化。但作为开发者，我们绝不希望用户因这种“搬家”感知到服务中断。本文将分享生产环境中确保服务高可用的核心技术方案。

---

一、核心思路：服务发现代替直接IP访问

直接访问Pod IP的致命问题：
假设前端服务直接调用后端Pod的IP，一旦Pod重启或迁移，前端代码中的IP地址立刻失效。这相当于每次搬家都要手动通知所有朋友新地址，显然不现实。

正确做法：
让Kubernetes自动管理服务发现，客户端只需通过固定入口（如Service名称）访问，底层IP变化由集群自动处理。

---

二、四大核心方案及生产实践

1. Service：服务的抽象门牌号

• 功能：为一组Pod提供统一入口，自动维护IP与端口映射。

• 生产配置要点：

  apiVersion: v1
  kind: Service
  metadata:
    name: order-service  # 服务名称即固定访问地址
  spec:
    type: ClusterIP       # 内部访问选ClusterIP，外部选LoadBalancer
    selector:
      app: order         # 必须匹配Pod的标签
    ports:
    - name: http
      port: 80           # 服务暴露端口
      targetPort: 8080    # 实际容器端口
  

• 关键动作：

  • 客户端通过order-service名称访问，而非具体Pod IP。
  • Service通过Endpoints对象动态更新后端Pod列表（kubectl get ep可查看）。

• 进阶技巧：

  • 会话保持：添加sessionAffinity: ClientIP实现基于源IP的会话粘滞。
  • 多端口协议：在ports中定义多个端口，支持混合协议（如TCP+UDP）。

2. DNS：服务名称解析的基石

• 自动实现：
  在Pod内直接通过<Service名称>.<命名空间>.svc.cluster.local访问服务，例如：

  curl http://order-service.default.svc.cluster.local
  

• 生产注意：
  • 避免在应用内硬编码IP，优先使用环境变量或DNS解析。
  • 跨命名空间访问需使用完整域名。

3. StatefulSet：有状态服务的VIP身份证

• 适用场景：
  MySQL、Redis等需要稳定网络标识的有状态服务。

• 核心优势：

  • 每个Pod拥有固定名称：<StatefulSet名称>-<序号>
  • 专属DNS：pod-name.service-name.ns.svc.cluster.local

• 示例配置：

  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: mysql-cluster
  spec:
    serviceName: "mysql-service"  # 必须关联一个无头Service
    replicas: 3
    template:
      metadata:
        labels:
          app: mysql
      spec:
        containers:
        - name: mysql
          image: mysql:8.0
  

4. Ingress：七层流量调度器

• 核心价值：
  对外暴露HTTP/HTTPS服务，实现基于域名、路径的复杂路由。
• 典型架构：

  用户 -> Ingress Controller (如Nginx) -> Service -> Pod
  

• 生产配置示例：

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: shop-ingress
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /  # 特定控制器的功能
  spec:
    rules:
    - host: shop.example.com
      http:
        paths:
        - path: /api
          pathType: Prefix
          backend:
            service:
              name: api-service
              port: 
                number: 80
        - path: /
          backend:
            service:
              name: web-service
              port: 
                number: 80
  

---

三、生产环境增强策略

1. 健康检查机制

• 就绪探针（Readiness Probe）：
  确保流量只转发到完全就绪的Pod，避免启动过程中的服务中断。

  readinessProbe:
    httpGet:
      path: /health
      port: 8080
    initialDelaySeconds: 10  # 容器启动10秒后开始检查
    periodSeconds: 5         # 每5秒检查一次
  

2. 优雅终止（Graceful Shutdown）

• 处理流程：

  1. 收到终止信号后，Service立即从Endpoints移除该Pod
  2. 等待预配置时间（默认30秒），允许完成存量请求
  3. 发送SIGTERM终止容器

• 最佳实践：

  spec:
    terminationGracePeriodSeconds: 60  # 适当延长等待时间
  

3. 客户端重试机制

• 应对场景：
  虽然Kubernetes会自动更新Endpoints，但客户端可能缓存了旧的DNS记录。
• 解决方案：
  • 配置HTTP客户端超时时间（建议2-5秒）
  • 实现自动重试逻辑（如指数退避算法）

---

四、避坑指南：常见问题排查

1. Service无法访问检查清单：

   • 确认Selector标签与Pod匹配
   • 检查Endpoints是否包含预期Pod（kubectl get endpoints）
   • 验证网络策略（NetworkPolicy）是否放行流量

2. DNS解析问题：

   # 在Pod内执行诊断
   nslookup order-service
   cat /etc/resolv.conf  # 确认search域名配置
   

3. 跨命名空间访问：
   使用全限定域名：service-name.namespace.svc.cluster.local

---

五、总结

通过Service抽象服务访问入口，配合DNS自动解析、StatefulSet稳定网络标识、Ingress实现高级流量管理，Kubernetes构建了完整的服务发现体系。生产环境中需结合健康检查、优雅终止等机制，确保服务IP变化时用户完全无感知。记住：永远不要相信Pod的IP，让Kubernetes做该做的事。