Update configure-liveness-readiness-probes.md

pull/351/head
Will 2019-03-22 09:58:37 +08:00 committed by GitHub
parent 71b8d4f6c1
commit caf89dcc17
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions

View File

@ -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的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。