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》