本地Minikube集群中KubeFlow TFJob Pod就绪探针失败问题排查求助

嘿，从你贴的错误日志和TFJob配置来看，这里有个很关键的矛盾点：你在YAML里明明定义的是执行cat /tmp/healthy的exec就绪探针，但实际报错却是在访问15021端口的HTTP探针——这个端口是Istio sidecar代理的默认健康检查端口。下面是几个最可能的故障原因，以及对应的排查方向：

1. Istio自动注入了Sidecar，偷偷改写了你的探针 #

如果你的Kubeflow集群里装了Istio，而且kubeflow命名空间开了sidecar自动注入，Istio会自动修改Pod的探针配置，把你写的exec探针替换成访问它自己sidecar的HTTP探针。要是sidecar没正常启动，或者网络不通，就会出现连接拒绝、超时这类错误。

你可以先验证下命名空间的Istio注入状态：

kubectl get namespace kubeflow -o jsonpath='{.metadata.labels}'

要是返回结果里有istio-injection=enabled，那基本实锤是Istio在搞事情了。

2. 没给Istio加“别碰我探针”的注解 #

就算你需要Istio的sidecar，也可以配置让它不要改写你的自定义探针。你的YAML里只加了默认容器的注解，但缺了Istio专属的跳过探针重写的配置，所以Istio才会自作主张改了你的探针。

3. Istio Sidecar本身启动出问题了 #

要是Istio的istio-proxy容器没正常跑起来——比如Pod资源不够、镜像拉不下来，或者集群的网络策略限制了它的通信——那15021端口自然没法响应健康检查，就会出现连接拒绝或者超时的错误。

你可以看看Pod的详细状态确认下：

kubectl describe pod <你的TFJob Pod名称> -n kubeflow

重点看istio-proxy容器的状态是不是Running，有没有启动失败的日志。

4. 你的镜像没生成/tmp/healthy文件 #

虽然报错显示的是HTTP探针，但如果Istio的探针重写依赖于原始探针的状态，或者你自己的exec探针本身就失败了，也可能间接导致sidecar的健康检查出问题。你可以进容器看看文件有没有生成：

kubectl exec -it <你的TFJob Pod名称> -c tensorflow -n kubeflow -- ls /tmp

• 要是不需要Istio，直接关掉命名空间的自动注入：

  kubectl label namespace kubeflow istio-injection=disabled --overwrite
  

  然后重新创建TFJob就行。
• 要是得保留Istio，就在Pod的metadata注解里加一行，让Istio别碰你的探针：

  annotations:
    kubectl.kubernetes.io/default-container: tensorflow
    sidecar.istio.io/rewriteAppHTTPProbers: "false"
  

• 检查下Pod的资源配置，给tensorflow和istio-proxy容器都分配足够的CPU和内存，避免因为资源不足启动失败。
• 确认你的tf-dist-cifar10:1.0镜像在启动后确实会生成/tmp/healthy文件，这是你原始探针能正常工作的前提。

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