如何正确设置 Kubernetes 的 readinessProbe 的基本身份验证？

Question

如何正确设置 Kubernetes 的 readinessProbe 的基本身份验证？

如果在部署类型中为 Kubernetes 的 readinessProbe 设置此配置。

readinessProbe:
  httpGet:
    path: /healthcheck
    port: 8080
    httpHeaders:
    - name: Authorization
      value: Basic <real base64 encoded data>

将其部署到 GKE，GCP 的健康检查无法通过使用基本身份验证访问内部应用程序。

但从here 看来，它应该使用这种语法。为什么不能通过？

服务器端在 /healthcheck 点使用 JSON 响应。 httpHeaders是否也需要设置Accept或Content-Type？

而且，将此运行状况检查设置为 livenessProbe 或 readinessProbe 是否合适？

Answer 1

根据 kubernetes 文档：

如果容器中的进程在遇到问题或变得不健康时能够自行崩溃，则不一定需要活性探测； kubelet 会根据 Pod 的 restartPolicy 自动执行正确的动作。如果您希望您的容器在探测失败时被杀死并重新启动，那么请指定一个活跃度探测，并指定一个 Always 或 OnFailure 的 restartPolicy。

参考：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-liveness-probe

如果您希望仅在探测成功后才开始向 Pod 发送流量，请指定就绪探测。在这种情况下，readiness probe 可能和 liveness probe 一样，但是 spec 中 readiness probe 的存在意味着 Pod 会在不接收任何流量的情况下启动，只有在探测成功后才开始接收流量。如果您的容器需要在启动过程中加载大数据、配置文件或迁移，请指定就绪探针。

参考：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-readiness-probe

因此，您可以根据需要使用健康检查。但是在 kubernetes doc 中，他们给出了一个健康检查的例子，作为一个活力探测。

参考：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request

当您发送请求而不是浏览器或其他典型客户端时，最好使用 Content-Type。我相信使用 Content-Type: application/json 将解决问题，如果其他事情在服务器端正常进行。