由于 GCP 服务帐户，Pod 在 Kubernetes 中获得了 CrashLoopBackOff答案

【问题标题】：Pod got CrashLoopBackOff in Kubernetes because of GCP service account由于 GCP 服务帐户，Pod 在 Kubernetes 中获得了 CrashLoopBackOff
【发布时间】：2020-01-15 16:04:35
【问题描述】：

使用 helm 推车进行部署后，出现 CrashLoopBackOff 错误。名称就绪状态重新开始年龄 myproject-myproject-54ff57477d-h5fng 0/1 CrashLoopBackOff 10 24m

然后，我描述 pod 以查看事件，我看到了如下所示的 smth

 Liveness probe failed: Get http://10.16.26.26:8080/status: 
 dial tcp 10.16.26.26:8080: connect: connection refused

Readiness probe failed: Get http://10.16.26.26:8080/status: 
dial tcp 10.16.26.26:8080: connect: connection refused

最后，我在日志中看到了对我的 GCP 云代理的无效授予访问权限，如下所示 time="2020-01-15T15:30:46Z" level=fatal msg=application_main error="Post https://www.googleapis.com/{....blabla.....}: oauth2: cannot fetch token: 400 Bad Request\nResponse: {\n \"error\": \"invalid_grant\",\n \"error_description\": \"Not a valid email or user ID.\"\n}"

但是，我在 IAM 中检查了我的服务帐户，它可以访问云代理。此外，我在本地使用相同的凭据进行了测试，并且端点准备就绪探测工作成功。

有人对我的问题有什么建议吗？

【问题讨论】：

标签： kubernetes google-cloud-platform google-cloud-iam

【解决方案1】：

您可以禁用 liveness probe 以停止 CrashLoopBackoff，执行到容器中并从那里进行测试。理想情况下，您不应该为 liveness 和 readiness probe 保存配置。liveness probe 不建议依赖任何外部的东西，它应该只检查 pod 是否处于活动状态。

【讨论】：

【解决方案2】：

提及在 GCP 上授予访问权限的问题 - 通过使用电子邮件地址（以 ...@developer.gserviceaccount.com 结尾的字符串）而不是 client_id 参数值的客户端 ID 来解决此问题。谷歌设置的命名令人困惑。

您可以在此处找到更多信息和疑难解答：google-oautgh-grant。

提及探针问题：

检查 URL 是否健康。您的探测可能过于敏感 - 您的应用程序需要一段时间才能启动或响应。

Readiness 和 liveness 探针可以并行用于同一个容器。使用两者可以确保流量不会到达尚未准备好的容器，并且容器在失败时会重新启动。

Liveness probe 检查您的应用程序在您已经运行的 pod 中是否处于健康状态。

Readiness probe 将实际检查您的 pod 是否已准备好接收流量。因此，如果没有 /path 端点，它将永远不会显示为 Running

鸡蛋：

          livenessProbe:
            httpGet:
              path: /your-path
              port: 5000
            failureThreshold: 1
            periodSeconds: 2
            initialDelaySeconds: 2
            ports:
              - name: http
              containerPort: 5000

如果端点 /index2 不存在，则 pod 将永远不会显示为正在运行。

确保您正确设置了 liveness 和 readiness 探测。

对于 HTTP 探测，kubelet 将 HTTP 请求发送到指定的执行检查的路径和端口。 kubelet 将探测发送到 pod 的 IP 地址，除非该地址被可选的 httpGet 中的主机字段。如果方案字段设置为 HTTPS，则 kubelet 发送跳过证书验证的 HTTPS 请求。多数情况在场景中，您不想设置主机字段。这是一个场景你会在哪里设置它。假设容器监听127.0.0.1 并且 Pod 的 hostNetwork 字段为 true。然后托管，在httpGet下，应该设置为127.0.0.1. 确保你做到了。如果您的 pod 依赖在虚拟主机上，这可能是更常见的情况，你应该不使用host，而是在httpHeaders中设置Host头。

对于 TCP 探测，kubelet 在节点上建立探测连接，不在 pod 中，这意味着您不能在 pod 中使用服务名称 host 参数，因为 kubelet 无法解析它。

使用活性探针时需要配置的最重要的事情。这是 initialDelaySeconds 设置。

确保您在容器上打开了端口 80。

Liveness 探测失败会导致 Pod 重新启动。您需要确保在应用程序准备好之前不会启动探测。否则，应用将不断重启，永远无法准备好！

我建议对 initialDelaySeconds 使用 p99 启动时间。

看看这里：probes-kubernetes，most-common-fails-kubernetes-deployments。

【讨论】：