AKS 1.24.6更新K8s Deployment时出现连接拒绝错误求助

针对你遇到的Deployment更新时test-service短暂出现Connection refused (os error 111)、30-45秒后恢复的问题，下面是几个常见的排查和解决方向：

• 检查Pod就绪探针配置
  这是最常见的触发原因：新启动的Pod还未完全就绪就被Service纳入端点列表，导致流量打到未启动完成的实例上。

  • 确认readinessProbe的initialDelaySeconds是否足够覆盖应用实际启动时间，如果你的服务需要30秒以上完成初始化，这个值不能设置过小。
  • 验证探针的检测路径（比如/healthz）是否真正代表服务已准备好处理请求——有些应用仅启动了Web容器，但业务逻辑还未初始化完成，探针却提前返回成功。
  • 示例调整后的就绪探针配置：

    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 40
      periodSeconds: 5
      failureThreshold: 3
    

• 调整Deployment滚动更新策略
  默认滚动更新策略可能允许部分旧Pod被销毁后，新Pod仍未就绪，导致出现流量间隙。可以设置maxUnavailable: 0，确保旧Pod仅在新Pod就绪后才会被终止：

  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  

  maxSurge控制更新时最多额外启动的Pod数量，可根据集群资源情况灵活调整。

• 排查kube-proxy缓存刷新延迟
  AKS 1.24使用EndpointSlice管理服务端点，kube-proxy需要同步这些信息到节点的网络规则中。如果同步延迟，会导致节点上的iptables/IPVS规则未及时更新，流量仍被导向已销毁的Pod或未就绪的Pod。

  • 查看kube-proxy日志（kubectl logs -n kube-system <kube-proxy-pod-name>），确认是否存在EndpointSlice同步的报错或延迟信息。
  • 如果使用IPVS模式，可调整IPVS超时参数，但需通过Azure门户或az cli确认当前集群网络模式后操作。

• 优化应用启动速度
  如果应用本身启动耗时过长（超过30秒），即使调整探针和滚动策略，仍可能出现短暂不可用窗口。可从以下方向优化：

  • 减少应用启动时的初始化操作，比如延迟加载非必要组件。
  • 使用更轻量化的基础镜像，缩短镜像拉取时间。
  • 启用AKS与ACR的集成缓存，加快镜像拉取速度。

内容的提问来源于stack exchange，提问作者RahulKumar Surati