kubectl exec执行成功但存活探针exec失败，求环境差异原因

问题场景 #

使用命令kubectl exec pod/my-pod -- wget -q -O- 127.0.0.1:3000通过kubectl exec手动执行时，能成功访问容器内的服务；但将相同命令配置为LivenessProbe的Exec探针：

livenessProbe:
  exec:
    command:
      - /usr/bin/wget
      - -q
      - -O-
      - 127.0.0.1:3000

却报错wget: can't connect to remote host (127.0.0.1): Connection refused，两者执行结果不一致的核心环境差异如下：

关键环境差异 #

• 执行时机不匹配
  kubectl exec是在Pod完全就绪后手动触发的，此时容器内的服务已经完成启动并监听了目标端口；而LivenessProbe默认在容器启动后立刻开始探测（无等待时间），如果服务启动需要加载配置、初始化依赖等耗时操作，探针执行时端口还处于未开放状态，就会出现连接拒绝。

• 探针执行的资源上下文不同
  容器启动初期，初始化进程可能占用了大部分CPU、内存资源，导致服务启动速度变慢；手动执行kubectl exec时，初始化进程已经完成，资源已释放给服务进程，服务完全就绪。探针在资源紧张的初始化阶段执行，大概率会遇到服务未就绪的情况。

• （次要）探针执行链路差异
  kubectl exec是通过Kube-APIServer转发请求到Kubelet，再由Kubelet执行容器内命令；而LivenessProbe的Exec探针是由Kubelet直接调用容器内命令。不过这个链路差异一般不会影响网络连接，核心还是前面两个因素。

验证与解决建议 #

1. 查看容器启动日志，确认服务从启动到监听端口的耗时，给LivenessProbe添加initialDelaySeconds参数，设置为大于服务启动时间的值：

livenessProbe:
  exec:
    command:
      - /usr/bin/wget
      - -q
      - -O-
      - 127.0.0.1:3000
  initialDelaySeconds: 10  # 根据实际启动时间调整

2. 改用httpGet探针替代Exec探针，更直观地检测服务状态：

livenessProbe:
  httpGet:
    path: /
    port: 3000
  initialDelaySeconds: 10

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