Merge pull request #351 from willseeyou/patch-18
Update configure-liveness-readiness-probes.mdpull/353/head
commit
bff0eb074c
|
@ -1,8 +1,8 @@
|
||||||
# 配置Pod的liveness和readiness探针
|
# 配置Pod的liveness和readiness探针
|
||||||
|
|
||||||
当你使用kuberentes的时候,有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环?你有没有想过kubernetes是如何检测pod是否还存活?虽然容器已经启动,但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢?让我们通过kuberentes官网的这篇文章[Configure Liveness and Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/),来一探究竟。
|
当你使用kubernetes的时候,有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环?你有没有想过kubernetes是如何检测pod是否还存活?虽然容器已经启动,但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢?让我们通过kubernetes官网的这篇文章[Configure Liveness and Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/),来一探究竟。
|
||||||
|
|
||||||
本文将向展示如何配置容器的存活和可读性探针。
|
本文将展示如何配置容器的存活和可读性探针。
|
||||||
|
|
||||||
Kubelet使用liveness probe(存活探针)来确定何时重启容器。例如,当应用程序处于运行状态但无法做进一步操作,liveness探针将捕获到deadlock,重启处于该状态下的容器,使应用程序在存在bug的情况下依然能够继续运行下去(谁的程序还没几个bug呢)。
|
Kubelet使用liveness probe(存活探针)来确定何时重启容器。例如,当应用程序处于运行状态但无法做进一步操作,liveness探针将捕获到deadlock,重启处于该状态下的容器,使应用程序在存在bug的情况下依然能够继续运行下去(谁的程序还没几个bug呢)。
|
||||||
|
|
||||||
|
@ -132,7 +132,7 @@ spec:
|
||||||
periodSeconds: 3
|
periodSeconds: 3
|
||||||
```
|
```
|
||||||
|
|
||||||
该配置文件只定义了一个容器,`livenessProbe` 指定kubelete需要每隔3秒执行一次liveness probe。`initialDelaySeconds` 指定kubelet在该执行第一次探测之前需要等待3秒钟。该探针将向容器中的server的8080端口发送一个HTTP GET请求。如果server的`/healthz`路径的handler返回一个成功的返回码,kubelet就会认定该容器是活着的并且很健康。如果返回失败的返回码,kubelet将杀掉该容器并重启它。
|
该配置文件只定义了一个容器,`livenessProbe` 指定kubelet需要每隔3秒执行一次liveness probe。`initialDelaySeconds` 指定kubelet在该执行第一次探测之前需要等待3秒钟。该探针将向容器中的server的8080端口发送一个HTTP GET请求。如果server的`/healthz`路径的handler返回一个成功的返回码,kubelet就会认定该容器是活着的并且很健康。如果返回失败的返回码,kubelet将杀掉该容器并重启它。
|
||||||
|
|
||||||
任何大于200小于400的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。
|
任何大于200小于400的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue