3

我对 k8s 很陌生，如果问题没有意义或不正确/愚蠢，我深表歉意。

我为我的 pod 定义配置了一个活跃度探针，它只是命中一个健康 API 并检查它的响应状态以测试 pod 的活跃度。

我的问题是，虽然我理解 liveness/readiness 探测的目的......它们到底是什么？它们是否只是另一种类型的 pod，它们被旋转起来尝试通过配置的 API 与我们的 pod 通信？或者它们是某种在 pod 内部运行并尝试 API 调用的轻量级进程？

另外，探针如何与 pod 通信？我们是否需要为 pod 配置服务，以便探针能够访问 API，或者它是不需要额外配置的内部进程？

4

2 回答 2

3

简短回答： kubelet处理此检查以确保您的服务正在运行，如果没有，它将被另一个容器替换。Kubelet 在集群的每个节点上运行，您不需要进行任何额外的配置。

您无需配置服务帐户即可使探测工作，它是由 kubernetes 处理的内部进程。

来自 Kubernetes文档：

Probe 是由 kubelet 在容器上定期执行的 诊断。为了执行诊断，kubelet 调用 由 Container 实现的Handler 。共有三种类型的处理程序：

  • ExecAction：在 Container 内执行指定的命令。如果命令以状态码 0 退出，则认为诊断成功。

  • TCPSocketAction：在指定端口上针对容器的 IP 地址执行 TCP 检查。如果端口打开，则认为诊断成功。

  • HTTPGetAction：在指定端口和路径上针对容器的 IP 地址执行 HTTP Get 请求。如果响应的状态代码大于或等于 200 且小于 400，则认为诊断成功。

每个探针都有以下三个结果之一：

  • 成功：容器通过了诊断。
  • 失败：容器未能通过诊断。
  • 未知：诊断失败，因此不应采取任何措施。

kubelet 可以选择对运行中的容器执行三种探测并做出反应：

  • livenessProbe: 表示 Container 是否正在运行。如果 liveness 探测失败，kubelet 会杀死 Container，并且 Container 会受到其 重启策略的约束。如果 Container 不提供 liveness 探测，则默认状态为 Success。

  • readinessProbe：指示容器是否准备好为请求提供服务。如果就绪探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认就绪状态是 Failure。如果 Container 不提供就绪探测，则默认状态为 Success。

  • startupProbe：表示Container内的应用程序是否启动。如果提供了启动探测，则所有其他探测都将被禁用，直到它成功为止。如果启动探测失败，kubelet 会杀死 Container，并且 Container 会受到其 重启策略的约束。如果 Container 不提供启动探测，则默认状态为 Success。

于 2020-03-25T09:22:03.820 回答
1

对于网络探测，它们从运行 pod 的节点上的 kubelet 运行。Exec 探针通过与 kubectl exec 相同的机制运行。

于 2020-03-24T21:37:19.033 回答