由于GCP服务帐户，Pod在Kubernetes遭到了猛烈的回退

在使用掌舵车部署之后，我遇到了CrashLoopBackOff错误。 名称就绪状态重新启动 myproject-myproject-54ff57477d-h5fng 0/1紧急回退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”级别=致命消息=应用程序\u主错误=“Post”https://www.googleapis.com/{….blabla….}:oauth2:无法获取令牌：400错误请求\n响应：{\n\“错误\:\”无效的\u授权\“，\n\“错误描述\:\”不是有效的电子邮件或用户ID。\“\n}”

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

---

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

您可以禁用liveness probe来停止CrashLoopBackoff，执行到容器中并从容器中进行测试。

---

理想情况下，您不应该为liveness and readiness probe保留保存配置。liveness probe不建议依赖任何外部内容，它应该只检查pod是否处于活动状态。

有关授予GCP访问权限的问题，请使用电子邮件地址解决此问题（以

..@developer.gserviceaccount.com

结尾的字符串）而不是Client_ID参数值的Client ID。Google设置的命名令人困惑

更多信息和疑难解答可在此处找到：

指探头问题：

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

就绪探测和活动探测可以并行用于同一个容器。使用这两种探测可以确保通信不会到达未准备就绪的容器，并且在容器失败时重新启动容器

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

准备就绪探测器将实际检查pod是否准备好接收流量。因此，如果没有/path端点，它将永远不会显示为正在运行

鸡蛋：

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

确保您正确设置了活跃度和准备度探测器。

对于HTTP探测，kubelet向指定的 执行检查的路径和端口。kubelet将探头发送到 pod的IP地址，除非该地址被可选的 httpGet中的主机字段。如果scheme字段设置为HTTPS，则kubelet 发送HTTPS请求，跳过证书验证。在大多数情况下 场景，您不想设置主机字段。以下是一个场景 假设容器监听

127.0.0.1

Pod的hostNetwork字段为真。然后主机，在httpGet下， 应设置为

127.0.0.1。

确保已执行。如果您的pod依赖 在虚拟主机上，这可能是更常见的情况，您应该 不使用主机，而是在httpHeaders中设置主机头

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

使用liveness探测器时需要配置的最重要的东西是initialDelaySeconds设置

确保容器上的端口

80

打开

Liveness probe失败会导致pod重新启动。您需要确保在应用程序准备就绪之前探测器不会启动。否则，应用程序将不断重新启动，并且永远不会准备就绪

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

看看这里：

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