服务器之家

服务器之家 > 正文

Kubernetes容器健康检查配置

时间:2021-08-12 01:04     来源/作者:掘金

简介

此文讲述如何配置容器的Liveness、Readiness、Startup探针。

kubelet使用Liveness探测器来知道什么时候要重启容器。例如,Liveness探测器可以捕捉到死锁(应用程序在运行,但是无法继续执行后面的步骤)。这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。

Kubernetes容器健康检查配置

kubelet使用Readiness探测器可以知道容器什么时候准备好了并可以开始接受请求流量, 当一个Pod内的所有容器都准备好了,才能把这个Pod看作就绪了。这种信号的一个用途就是控制哪个Pod作为Service的后端。在Pod还没有准备好的时候,会从Service的负载均衡器中被剔除的。

kubelet使用Startup探测器可以知道应用程序容器什么时候启动了。如果配置了这类探测器,就可以控制容器在启动成功后再进行Liveness和Readiness检查,确保这些存活、就绪探测器不会影响应用程序的启动。这可以用于对慢启动容器进行存活性检测,避免它们在启动运行之前就被杀掉。

定义一个Liveness探针

许多长时间运行的应用程序最终会过渡到断开的状态,除非重新启动,否则无法恢复。Kubernetes提供了Liveness探测器来发现并补救这种情况。

创建一个Pod,其中运行一个基于k8s.gcr.io/busybox镜像的容器。配置文件如下。文件名:exec-liveness.yaml

  1. apiVersion: v1 
  2. kind: Pod 
  3. metadata: 
  4. labels: 
  5. test: liveness 
  6. name: liveness-exec 
  7. spec: 
  8. containers: 
  9. name: liveness 
  10. image: k8s.gcr.io/busybox 
  11. args: 
  12. - /bin/sh 
  13. - -c 
  14. - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 
  15. livenessProbe: 
  16.   exec
  17.     command: 
  18.     - cat 
  19.     - /tmp/healthy 
  20.   initialDelaySeconds: 5 
  21.   periodSeconds: 5 

在配置文件中,可以看到Pod中只有一个容器。periodSeconds字段指定了kubelet应该每5秒执行一次存活检测。initialDelaySeconds字段告诉kubelet在执行第一次探针前应该等待5秒。kubelet在容器中执行命令cat /tmp/healthy来进行检测。如果命令执行成功并且返回值为0,kubelet会认为这个容器是健康存活的。如果这个命令返回非0值,kubelet会杀死这个容器并重新启动它。执行命令如下:

  1. /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" 

这个容器生命的前30秒,/tmp/healthy文件是存在的。执行命令cat /tmp/healthy会返回成功码。30秒后,执行命令cat /tmp/healthy就回返回失败码。

创建Pod:

  1. # kubectl apply -f /root/k8s-example/probe/exec-liveness.yaml 

在 30 秒内,查看Pod的事件:

  1. kubectl describe pod liveness-exec 

输出结果显示还没有存活探测器失败:

  1. Events:  
  2. Type Reason Age From Message  
  3. ---- ------ ---- ---- -------  
  4. Normal Scheduled default-scheduler Successfully assigned default/liveness-exec to k8s-node04  
  5. Normal Pulled 22s kubelet, k8s-node04 Container image "k8s.gcr.io/busybox" already present on machine  
  6. Normal Created 22s kubelet, k8s-node04 Created container liveness  
  7. Normal Started 22s kubelet, k8s-node04 Started container liveness 

30秒之后,再来看Pod的事件:

  1. kubectl describe pod liveness-exec 

在输出结果的最下面,有信息显示存活探测器失败了,这个容器被杀死并且被重建了。

  1. Events:  
  2. Type Reason Age From Message  
  3. ---- ------ ---- ---- -------  
  4. Normal Scheduled default-scheduler Successfully assigned default/liveness-exec to k8s-node04  
  5. Normal Pulled 47s kubelet, k8s-node04 Container image "k8s.gcr.io/busybox" already present on machine  
  6. Normal Created 47s kubelet, k8s-node04 Created container liveness  
  7. Normal Started 47s kubelet, k8s-node04 Started container liveness  
  8. Warning Unhealthy 5s (x3 over 15s) kubelet, k8s-node04 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory 
  9.  Normal Killing 5s kubelet, k8s-node04 Container liveness failed liveness probe, will be restarted 

再等另外30秒,检查看这个容器被重启了:

  1. kubectl get pod liveness-exec 
  2. NAME            READY   STATUS    RESTARTS   AGE 
  3. liveness-exec   1/1     Running   2          3m10s 

再查看Pod资源详情:

  1. kubectl describe pod liveness-exec 

输出结果如下,容器重启成功。

  1. Events:  
  2. Type Reason Age From Message  
  3. ---- ------ ---- ---- -------  
  4. Normal Scheduled default-scheduler Successfully assigned default/liveness-exec to k8s-node04  
  5. Warning Unhealthy 35s (x6 over 2m) kubelet, k8s-node04 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory  
  6. Normal Killing 35s (x2 over 110s) kubelet, k8s-node04 Container liveness failed liveness probe, will be restarted  
  7. Normal Pulled 5s (x3 over 2m32s) kubelet, k8s-node04 Container image "k8s.gcr.io/busybox" already present on machine  
  8. Normal Created 5s (x3 over 2m32s) kubelet, k8s-node04 Created container liveness  
  9. Normal Started 5s (x3 over 2m32s) kubelet, k8s-node04 Started container liveness 

定义一个存活态HTTP请求接口

另外一种类型的Liveness探测方式是使用HTTP GET请求。下面是一个Pod的配置文件,其中运行一个基于k8s.gcr.io/liveness镜像的容器。

创建Pod:

  1. apiVersion: v1 
  2. kind: Pod 
  3. metadata: 
  4. labels: 
  5. test: liveness 
  6. name: liveness-http 
  7. spec: 
  8. containers: 
  9. name: liveness 
  10. image: k8s.gcr.io/liveness 
  11. args: 
  12. - /server 
  13. livenessProbe: 
  14.   httpGet: 
  15.     path: /healthz 
  16.     port: 8080 
  17.     httpHeaders: 
  18.     - name: X-Custom-Header 
  19.       value: Awesome 
  20.   initialDelaySeconds: 3 
  21.   periodSeconds: 3 

配置文件中,Pod中只有一个容器。periodSeconds字段指定了kubelet每隔3秒执行一次检测。initialDelaySeconds字段告诉kubelet在执行第一次探测前应该等待3秒。kubelet 会向容器内运行的服务(服务会监听 8080 端口)发送一个 HTTP GET 请求来执行探测。如果服务上/healthz路径下的处理程序返回成功码。则kubelet认为容器是健康存活的。如果处理程序返回失败码,则kubelet会杀死这个容器并且重新启动它。

任何大于或等于200并且小于400的返回码标示成功,其它返回码都标示失败。

可以在这里看到服务的源码:https://github.com/kubernetes/ ... er.go

容器存活的最开始10秒中,/healthz处理程序返回一个200的状态码。之后处理程序返回500的状态码。

  1. http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { 
  2. duration := time.Now().Sub(started) 
  3. if duration.Seconds() > 10 { 
  4.     w.WriteHeader(500) 
  5.     w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds()))) 
  6. else { 
  7.     w.WriteHeader(200) 
  8.     w.Write([]byte("ok")) 
  9. }) 

kubelet在容器启动之后3秒开始执行健康检测。所以前几次健康检查都是成功的。但是10秒之后,健康检查会失败,并且kubelet会杀死容器再重新启动容器。

  1. # kubectl apply -f /root/k8s-example/probe/http-liveness.yaml 

10秒之后,通过看Pod事件来检测存活探测器已经失败了并且容器被重新启动了。

  1. Events:  
  2. Type Reason Age From Message  
  3. ---- ------ ---- ---- -------  
  4. Normal Scheduled default-scheduler Successfully assigned default/liveness-http to k8s-node01  
  5. Normal Pulled 17s kubelet, k8s-node01 Container image "k8s.gcr.io/liveness" already present on machine  
  6. Normal Created 17s kubelet, k8s-node01 Created container liveness  
  7. Normal Started 16s kubelet, k8s-node01 Started container liveness  
  8. Warning Unhealthy 1s (x2 over 4s) kubelet, k8s-node01 Liveness probe failed: HTTP probe failed with statuscode: 500 

定义TCP的存活探测

第三种类型的liveness探测是使用TCP套接字。通过配置,kubelet会尝试在指定端口和容器建立套接字链接。如果能建立链接,这个容器就被看作是健康的,如果不能则这个容器就被看作是有问题的。

创建一个Pod。文件名:tcp-liveness-readiness.yaml

  1. apiVersion: v1 
  2. kind: Pod 
  3. metadata: 
  4. name: goproxy 
  5. labels: 
  6. app: goproxy 
  7. spec: 
  8. containers: 
  9. name: goproxy 
  10. image: k8s.gcr.io/goproxy:0.1 
  11. ports: 
  12. - containerPort: 8080 
  13. readinessProbe: 
  14.   tcpSocket: 
  15.     port: 8080 
  16.   initialDelaySeconds: 5 
  17.   periodSeconds: 10 
  18. livenessProbe: 
  19.   tcpSocket: 
  20.     port: 8080 
  21.   initialDelaySeconds: 15 
  22.   periodSeconds: 20 

TCP检测的配置和HTTP检测非常相似。下面这个例子同时使用就绪和存活探测器。kubelet会在容器启动5秒后发送第一个就绪探测。这会尝试连接goproxy容器的8080端口。如果探测成功,这个Pod会被标记为就绪状态,kubelet将继续每隔10秒运行一次检测。

除了readiness探测,这个配置包括了一个Liveness探测。kubelet会在容器启动15秒后进行第一次Liveness探测。就像Readiness探测一样,会尝试连接goproxy容器的8080端口。如果存活探测失败,这个容器会被重新启动。

  1. # kubectl apply -f /root/k8s-example/probe/tcp-liveness-readiness.yaml 

15秒之后,通过看Pod事件来检测存活探测器:

  1. # kubectl describe pod goproxy 

使用命名端口:

对于HTTP或者TCP存活检测可以使用命名的容器端口。

  1. ports: 
  2. name: liveness-port 
  3. containerPort: 8080 
  4. hostPort: 8080 
  5. ​ 
  6. livenessProbe: 
  7. httpGet: 
  8. path: /healthz 
  9. port: liveness-port 

使用Startup探测器保护慢启动容器

有时候,会有一些现有的应用程序在启动时需要较多的初始化时间。要不影响对引起探测死锁的快速响应,这种情况下,设置Liveness探测参数是要技巧的。技巧就是使用一个命令来设置Startup探测,针对HTTP或者TCP检测,可以通过设置failureThreshold * periodSeconds参数来保证有足够长的时间应对糟糕情况下的启动时间。

所以,前面的例子就变成了:

  1. ports: 
  2. name: liveness-port 
  3. containerPort: 8080 
  4. hostPort: 8080 
  5. ​ 
  6. livenessProbe: 
  7. httpGet: 
  8. path: /healthz 
  9. port: liveness-port 
  10. failureThreshold: 1 
  11. periodSeconds: 10 
  12. ​ 
  13. startupProbe: 
  14. httpGet: 
  15. path: /healthz 
  16. port: liveness-port 
  17. failureThreshold: 30 
  18. periodSeconds: 10 

幸亏有Startup探测,应用程序将会有最多5分钟(30*10=300s)的时间来完成它的启动。 一旦Startup探测成功一次,存活探测任务就会接管对容器的探测,对容器死锁可以快速响应。 如果Startup探测一直没有成功,容器会在300秒后被杀死,并且根据restartPolicy来设置Pod状态。

定义Readliness探测器

有时候,应用程序会暂时性的不能提供通信服务。例如,应用程序在启动时可能需要加载很大的数据或配置文件,或是启动后要依赖等待外部服务。在这种情况下,既不想杀死应用程序,也不想给它发送请求。Kubernetes提供了就绪探测器来发现并缓解这些情况。容器所在Pod上报还未就绪的信息,并且不接受通过Kubernetes Service的流量。

注意:就绪探测器在容器的整个生命周期中保持运行状态。

就绪探测器的配置和存活探测器的配置相似。唯一区别就是要使用readinessProbe字段,而不是LivenessProbe字段。

  1. readinessProbe: 
  2. exec
  3. command: 
  4. - cat 
  5. - /tmp/healthy 
  6. initialDelaySeconds: 5 
  7. periodSeconds: 5 

HTTP和TCP的Readliness探测器配置也和Liveness探测器的配置一样的。

Readliness和Liveness探测可以在同一个容器上并行使用。两者都用可以确保流量不会发给还没有准备好的容器,并且容器会在它们失败的时候被重新启动。

配置探测器

探测器有很多配置字段,可以使用这些字段精确的控制存活和就绪检测的行为:

  • initialDelaySeconds:容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认是0秒,最小值是0。
  • periodSeconds:执行探测的时间间隔(单位是秒)。默认是10秒。最小值是1。
  • timeoutSeconds:探测的超时后等待多少秒。默认值是1秒。最小值是1。
  • successThreshold:探测器在失败后,被视为成功的最小连续成功数。默认值是1。存活探测的这个值必须是1。最小值是1。
  • failureThreshold:当Pod启动了并且探测到失败,Kubernetes的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃Pod会被打上未就绪的标签。默认值是3。最小值是1。

HTTP探测器可以在httpGet上配置额外的字段:

  • host:连接使用的主机名,默认是Pod的IP。也可以在HTTP头中设置“Host”来代替。
  • scheme:用于设置连接主机的方式(HTTP还是HTTPS)。默认是HTTP。
  • path:访问HTTP服务的路径。
  • httpHeaders:请求中自定义的HTTP头。HTTP头字段允许重复。
  • port:访问容器的端口号或者端口名。如果数字必须在1 ~ 65535之间。

对于HTTP探测,kubelet发送一个HTTP请求到指定的路径和端口来执行检测。除非httpGet中的host字段设置了,否则kubelet默认是给Pod的IP地址发送探测。如果scheme字段设置为了HTTPS,kubelet会跳过证书验证发送HTTPS请求。大多数情况下,不需要设置host字段。这里有个需要设置host字段的场景,假设容器监听127.0.0.1,并且Pod的hostNetwork字段设置为了true。那么httpGet中的host字段应该设置为127.0.0.1。可能更常见的情况是如果Pod依赖虚拟主机,你不应该设置host字段,而是应该在httpHeaders中设置Host。

对于一次探测,kubelet在节点上(不是在Pod里面)建立探测连接,这意味着你不能在host参数上配置service name,因为kubelet不能解析service name。

原文地址:https://juejin.cn/post/6993457394827132964

相关文章

热门资讯

yue是什么意思 网络流行语yue了是什么梗
yue是什么意思 网络流行语yue了是什么梗 2020-10-11
2020微信伤感网名听哭了 让对方看到心疼的伤感网名大全
2020微信伤感网名听哭了 让对方看到心疼的伤感网名大全 2019-12-26
背刺什么意思 网络词语背刺是什么梗
背刺什么意思 网络词语背刺是什么梗 2020-05-22
苹果12mini价格表官网报价 iPhone12mini全版本价格汇总
苹果12mini价格表官网报价 iPhone12mini全版本价格汇总 2020-11-13
2021德云社封箱演出完整版 2021年德云社封箱演出在线看
2021德云社封箱演出完整版 2021年德云社封箱演出在线看 2021-03-15
返回顶部