分布式系统和微服务体系结构的挑战之一是自动检测不失常的应用程序，并将申请（request）从新路由到其余可用零碎，复原损坏的组件。健康检查是应答该挑战的一种牢靠办法。应用 Kubernetes，能够通过探针配置运行状况查看，以确定每个 Pod 的状态。
默认状况下，Kubernetes 会察看 Pod 生命周期，并在容器从挂起（pending）状态转移到胜利（succeeded）状态时，将流量路由到 Pod。Kubelet 会监控解体的应用程序，并重新启动 Pod 进行复原。许多开发人员认为这样的根本设置就足够了，尤其是当 Pod 内的应用程序还配置了守护过程管理器（例如 Node.js 的 PM2）时。但有一种意外状况，当 Kubernetes 在所有容器启动后，认为 Pod 是衰弱且能够承受申请时，但应用程序在理论准备就绪之前就已收到流量，比方应用程序在解决利用程序逻辑之前，初始化了一些状态，建设了数据库连贯或加载了数据。当 Deployment 开始扩大时，未就绪的应用程序会接管流量并返回 500 谬误，站长交易这造成了应用程序理论的准备就绪与 Kubernetes 认为的准备就绪之间的工夫距离问题。
同样的，这也是 Kubernetes 探针用来定义容器何时筹备承受流量，以及何时重新启动容器的形式。从 Kubernetes v1.16 开始，曾经反对三种类型的探针。在本文中将介绍这三种类型的探针、最佳实际和无关工具，以检测可能存在的配置问题。
K8sMeetup
Kubernetes 探针
Kubernetes 版本小于 v1.15 时反对 readiness 和 liveness 探针，在 v1.16 中增加了 startup 探针作为 Alpha 性能，并在 v1.18 中降级为 Beta。
这三种探针均具备以下参数：
initialDelaySeconds：启动 liveness、readiness 探针前要期待的秒数。
periodSeconds：查看探针的频率。
timeoutSeconds：将探针标记为超时（未通过运行状况查看）之前的秒数。
successThreshold：探针须要通过的最小间断胜利查看数量。
failureThreshold：将探针标记为失败之前的重试次数。对于 liveness 探针，这将导致 Pod 重新启动。对于 readiness 探针，将标记 Pod 为未就绪（unready）。
Readiness 探针 readiness 探针能够让 kubelet 晓得应用程序何时筹备承受新流量。如果应用程序在过程启动后须要一些工夫来初始化状态，要配置 readiness 探针让 Kubernetes 在发送新流量之前进行期待。readiness 探针的次要作用是将流量疏导至 service 后的 deployment。
对于 readiness 探针有一点很重要，它会在容器的整个生命周期中运行。这意味着 readiness 探针不仅会在启动时运行，而且还会在 Pod 运行期间重复运行。这是为了解决应用程序临时不可用的状况（比方加载大量数据、期待内部连贯时）。在这种状况下，咱们不肯定要杀死应用程序，能够期待它复原。readiness 探针可用于检测这种状况，并在 Pod 再次通过 readiness 查看后，将流量发送到这些 Pod。Liveness 探针 liveness 探针用于重新启动不衰弱的容器。Kubelet 会定期地 ping liveness 探针，以确定健康状况，并在 liveness 查看不通过的状况下杀死 Pod。liveness 查看能够帮忙应用程序从死锁中复原。如果不进行 liveness 查看，Kubernetes 会认为死锁中的 Pod 处于衰弱状态，因为从 Kubernetes 的角度来看，Pod 的子过程仍在运行，是衰弱的。通过配置 liveness 探针，kubelet 能够检测到应用程序处于不衰弱状态，并重新启动 Pod 以复原可用性。Startup 探针 startup 探针与 readiness 探针相似，但它仅在启动时执行，能针对启动迟缓的容器或在初始化过程中有不可预测行为的应用程序进行优化。借助 readiness 探针，咱们能够配置 initialDelaySeconds 来确定 readiness 探测在准备就绪前要期待多长时间。
假如有一个偶然须要下载大量数据的应用程序，因为 initialDelaySeconds 是一个动态数字，因而该应用程序即便不须要那么长的初始化等待时间，咱们也必须设置最激进的等待时间。通过 startup 探针，咱们能够配置 failureThreshold 和 periodSeconds 来解决该问题，例如设置 failureThreshold 为 15，periodSeconds 为 5，这意味着应用程序在失败之前会有 10×5=75s 的启动工夫。
K8sMeetup
配置探针
当初咱们理解了不同类型的探针，上面是配置每种探针的三种不同形式。
HTTPkubelet 将 HTTP GET 申请发送到 endpoint，并查看 2xx 或 3xx 响应。咱们能够重复使用现有的 HTTP endpoint 或设置轻量级 HTTP 服务器以进行探测（例如，具备 /healthz endpoint 的 Express server）。HTTP 探针蕴含其余额定参数：
host：要连贯的主机名（默认值：pod 的 IP）。
scheme：HTTP（默认）或 HTTPS。
path：HTTP/S 服务器上的门路。
httpHeaders：自定义标头（如果须要标头用于身份验证、CORS 设置等）。
port：拜访服务器的端口名称或端口号。