kubernetes之探针

文章目录

kubernetes之探针
- 三种探针类型
- 存活探针
- 就绪探针
- 存活与就绪探针的区别

三种探针类型

HTTP GET 探针对容器的IP地址执行HTTP GET请求。如果探测器收到响应，并且响应状态码不代表错误（换句话说，如果HTTP响应状态码是 2xx 或 3xx），则认为探测成功。如果服务器返回错误响应状态码或者根本没有响应，那么探测就被认为是失败的，容器将重新启动。
TCP 套接字探针尝试与窗口指定端口建立TCP连接。如果连接成功建立，则探测成功。否则，容器重新启动。
Exec 探针在容器内执行任意命令，并检查命令的退出状态码。如果状态码是0，则探测成功。所有其他状态码都被认为失败。

存活探针

Kubernetes 可以通过存活探针（liveness probe）检查容器是否还在运行。可以为 pod 中的每个容器单独指定存活探针。
如果探测失败，Kubernetes 将定期执行探针并重新启动容器。

存活探针的附加信息：
Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3

信息释义：

delay：延迟，delay=0s 部分显示在容器启动后立即开始探测。
timeout：timeout=1s，容器必须在1秒内进行响应，不然这次探测记作失败。
period：period=10s，每10秒探测一次容器。
failure：failure=3，探测连续三次失败后重启容器。

定义探针时可以自定义这些附加参数。例如，要设置初始延迟，即initialDelaySeconds。如果没有设置初始延迟，探针将在启动时立即开始探测容器，这通常会导致探测失败，因为应用程序还没准备好开始接收请求。如果失败次数超过阈值，在应用程序能正确响应请求之前，容器就会重启。这里面有个场景会经常遇到：容器正在重启，但使用kubectl describe会看到容器以退出码137或143结束，并看到pod是被迫终止的，还将在pod事件的列表将显示容器因liveness探测失败而终止。这种情况下大部分是因为未能设置初始延迟。

务必记得设置一个初始延迟来说明应用程序的启动时间。

就绪探针

就绪探针（readiness probe）会定期调用，并确定特定的 pod 是否接收客户端请求。当容器的准备就绪探测返回成功时，表示容器已准备好接收请求。显然这个是每个容器特有的东西，Kubernetes 只能检查在容器中运行的应用程序是否响应一个简单的 GET/ 请求，或者它可以响应特定的 URL 路径，该 URL 导致应用程序执行一系列检查以确定它是否准备就绪。因此，这种确切的准备就绪的判定是应用程序开发人员的责任。

为什么会需要就绪探针？
如果没有将就绪探针添加到pod中，它们几乎会立即成为服务端点。如果在服务启动但尚未准备好接收传入连接时，客户端请求将被转发到该pod。那么客户端会看到“连接被拒绝”类型的错误。

就绪探针的附加信息：
Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3

命令解释：就绪探针将定期在容器内执行ls /var/ready命令。如果文件存在，则ls命令返回退出码0，否则返回非0的退出码。如果文件存在，则就绪探针将成功，否则它会失败。

这里面的信息释义也存活探针一样。

就绪探针确保客户端只与正常的 pod 交互，并且永远不会知道系统存在问题。

存活与就绪探针的区别

与存活探针不同，如果容器未通过准备检查，则不会被终止或重新启动。这是两种探针之间的重要区别。

存活探针通过杀死异常的容器并用新的正常容器替代它们来保持 pod 正常工作，而就绪探针确保只有准备好处理求的 pod 才可以接收请求。这在容器启动时最为必要。

参考书籍：《Kubernetes in action》