这是最佳实践的第三部。

你好，我是杰克。

好了，第三篇了。这次我们来谈谈Kubernetes的健康检查。
代码并不多，可能会比上一篇有点冗长，但我们还是来试试看吧。

每次的事情，官方博客在这里。
Kubernetes 最佳实践：使用就绪和存活性探针设置健康检查。

太长不看

• 分散システムにhealth checkは欠かせないものである、Kubernetesもまた例外ではない

• Kubernetesのhealth checkの種類は2つ

Readiness
Liveness

Health checkプローブの種類は3つ

HTTP Probes
Command Probes
TCP Probes

LivenessのinitialDelaySecondsに要注意

再多提供一些细节

健康检查是必不可少的

由于分散系统涉及多台计算机（虚拟机）各自承担角色，因此管理工作非常复杂。我们需要构建一种系统，它能感知异常并自动恢复，例如在某一台计算机发生故障时，不会导致全部系统崩溃，而是能转移流量等操作来实现自动恢复。

为了做出这种恰当的回应，进行健康检查可以说是确认系统是否正常运行的最简单方式。

在Kubernetes中，Pod在成功启动后开始发送流量，并且在崩溃时重新启动，这是默认设置。虽然这是令人高兴的，但并不完美。因此，本次我们将介绍构建更强大系统所需的Kubernetes健康检查配置知识。

体检的种类

在Kubernetes中，有两种类型的健康检查，需要了解它们的区别。

1. 准备就绪

Readiness探针用于向Kubernetes通知应用程序已成功启动并准备好接收流量。如果成功，Kubernetes将开始将流量发送到该Pod；如果失败，Kubernetes可以暂时停止将流量发送到该Pod，直到成功为止。

在什么情况下使用？

通常情况下，Kubernetes会在确认Pod容器已成功启动后立即开始发送流量。但如果是启动时间较长的应用程序呢？在Kubernetes的正常行为中，应用程序在准备好之前就开始接收流量了。这时，就轮到Readiness Probe登场了。通过使用Readiness Probe，我们可以告诉Kubernetes在Pod准备就绪之前不要发送流量，而是等待一下。

活力

一方面，活动探针用于向Kubernetes通知应用程序的正常或异常情况。如果失败，将删除Pod并启动新的Pod来进行替换。

需要在什么情况下使用

假设应用程序存在死锁问题。在这种情况下，应用程序将无法继续下一步处理并变得僵死。然而，Kubernetes不知道应用程序的行为，而认为Pod正常运行。因此，即使应用程序已经僵死，它仍然会不断向该Pod发送请求。
在这种情况下，我们应该使用Liveness探针。通过向Kubernetes传达应用程序已经死亡的消息，我们可以重新启动它。

探针的种类 de

好的，我們已經查看了健康檢查的種類，現在來看一下實際上有哪些種類的探針。總共有三種種類。

超文本传输协议

首先，我们有HTTP。这是一种最常用的探针类型。
即使应用程序不是基于HTTP服务器，它也是最方便易用的探针类型，因为它非常容易启动。

• HTTPレスポンスで判断

2XX、3XXのレスポンス healthy

それ以外が unhealthy

命令

命令探针(Command probe)在Kubernetes中执行命令并在容器内部运行。

• exit codeで判断

0 の時は healthy

それ以外は unhealthy

传输控制协议 (TCP)

最终，通过进行TCP连接探测来确定。

• TCPコネクションで判断

繋がれば healthy

繋げられなければ unhealthy

总结

我已经看过了健康检查的类型和探针的类型，有很多种呢。利用这些知识，我们可以创建一个更为坚固的基础和稳定的系统，不是吗？

另外，关于Probe更详细的设置已经在官方文档中以简明易懂的方式写明，请随意参考。

那么，下次再见。