GKE Autopilot修改readinessProbe/livenessProbe后仍检测旧URL问题咨询

控制台看到Deployment YAML为最新版本不代表运行中Pod已经加载了新配置，按以下步骤操作即可让新规则生效：

• 第一步先校验运行中Pod的实际配置，不要只看Deployment资源：
  执行以下命令查看Pod维度的探针配置：

  # 替换<pod名>、<命名空间>为实际值
  kubectl get pod <pod名> -n <命名空间> -o yaml | grep -A15 livenessProbe
  kubectl get pod <pod名> -n <命名空间> -o yaml | grep -A15 readinessProbe
  

  • 如果输出中探针检测URL仍为旧地址，说明Deployment滚动更新卡住，没有完成Pod替换：
    1. 先检查Deployment更新策略，确认spec.strategy.type为RollingUpdate，且maxUnavailable没有设置为0导致新副本无法调度
    2. 手动触发滚动重建即可加载新配置：kubectl rollout restart deployment/<你的deployment名> -n <命名空间>
    3. 执行kubectl rollout status deployment/<你的deployment名> -n <命名空间>等更新完成后，再次校验新Pod的探针配置即可
  • 如果输出中探针URL已经是新地址，但仍有请求发往旧URL：
    1. 排查应用本身是否存在3xx重定向规则，将新探针路径跳转到旧地址，可通过临时debug Pod在集群内直接curl新探针路径验证响应
    2. 若集群开启了服务网格（如Istio、ASM），检查sidecar配置是否存在路径改写规则拦截了探针请求，可临时关闭对应工作负载的sidecar注入后重建Pod验证
    3. Autopilot模式下节点kubelet存在短时间配置缓存，等待2分钟缓存自动失效即可，若仍不生效可通过给Pod添加临时nodeSelector触发重调度到新节点加载新配置

集群中负责执行探针检测的组件是每个节点上运行的kubelet：

• 控制面组件不会参与探针请求发起，当Pod被调度到某台节点后，节点上的kubelet会读取Pod spec中定义的探针规则，周期性在节点本地向对应Pod的IP、端口、路径发起检测请求
• livenessProbe检测失败时，kubelet会直接触发对应容器的重启；readinessProbe检测失败时，kubelet会将对应PodIP从所有关联Service的端点列表中移除，不会把流量转发给未就绪的Pod
• GKE Autopilot的节点为Google托管，用户无法直接登录节点操作kubelet，但探针执行逻辑和开源K8s完全一致。

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