无法从集群内通过 pod IP 访问 pod,导致 liveness/readiness 探测失败

Cannot access pod via pod IP from within the cluster, causing liveness / readiness probe failure

一些快速背景知识: 在 golang 中创建应用程序,运行在 MacOS 10.14.2 上的 minikube 上运行

karlewr [0] $ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-18T11:37:06Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4", GitCommit:"f49fa022dbe63faafd0da106ef7e05a29721d3f1", GitTreeState:"clean", BuildDate:"2018-12-14T06:59:37Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

问题: 我无法从集群内部通过它的 pod IP 访问我的 pod。这个问题只发生在这个 pod 上,这让我相信我在某处配置错误。

我的pods规格如下:

containers:
  - name: {{ .Chart.Name }}
    image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
    ports:
      - name: http
        containerPort: 8080
        protocol: TCP
    livenessProbe:
      httpGet:
        path: /ping
        port: 8080
      initialDelaySeconds: 60
    readinessProbe:
      httpGet:
        path: /ping
        port: 8080
      initialDelaySeconds: 60

奇怪的是,我可以通过在端口 8080 和 运行ning curl localhost:8080/ping 上转发那个 pod 来访问它,然后再进行活性和就绪探测 运行 和在 pod 初始化之后。这个returns 200行。

同样在 CrashLoopBackoff 之前的这段时间里,如果我 ssh 进入我的 minikube 节点并且 运行 curl http://172.17.0.21:8080/ping 我得到 curl: (7) Failed to connect to 172.17.0.21 port 8080: Connection refused。使用的IP是我的pod的IP。

但是当我在 initialDelaySeconds 期之后描述 pod 时,我看到了这个:

  Warning  Unhealthy  44s (x3 over 1m)  kubelet, minikube  Readiness probe failed: Get http://172.17.0.21:8080/ping: dial tcp 172.17.0.21:8080: connect: connection refused
  Warning  Unhealthy  44s (x3 over 1m)  kubelet, minikube  Liveness probe failed: Get http://172.17.0.21:8080/ping: dial tcp 172.17.0.21:8080: connect: connection refused

为什么我的连接只会被 pod 的 IP 拒绝?

编辑 我没有运行任何自定义网络的东西,只是开箱即用的 minikube

Why would my connection be getting refused only from the pod's IP?

因为您的程序显然只在本地主机上侦听(又名 127.0.0.1 又名 lo0

在不了解您的容器的更多信息的情况下,我们无法为您提供进一步的建议,但根据您的描述,这几乎肯定是问题所在。