【云原生 | 从零开始学Kubernetes】十三、k8s的容器探测以及启动探测

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 许多应用程序经过长时间运行,最终过渡到无法运行的状态,除了重启,无法恢复。通常情况下,K8S 会发现应用程序已经终止,然后重启应用程序 pod。有时应用程序可能因为某些原因(后端服务故障等)导致暂时无法对外提供服务,但应用软件没有终止,导致 K8S 无法隔离有故障的 pod,调用者可能会访问到有故障的 pod,导致业务不稳定。K8S 提供 livenessProbe 来检测容器是否正常运行,并且对相应状况进行相应的补救措施。

存活性探测 livenessProbe 和就绪性探测 readinessProbe


livenessProbe:存活性探测


许多应用程序经过长时间运行,最终过渡到无法运行的状态,除了重启,无法恢复。通常情况下,K8S 会发现应用程序已经终止,然后重启应用程序 pod。有时应用程序可能因为某些原因(后端服务故障等)导致暂时无法对外提供服务,但应用软件没有终止,导致 K8S 无法隔离有故障的 pod,调用者可能会访问到有故障的 pod,导致业务不稳定。K8S 提供 livenessProbe 来检测容器是否正常运行,并且对相应状况进行相应的补救措施。


readinessProbe:就绪性探测


在没有配置 readinessProbe 的资源对象中,pod 中的容器启动完成后,就认为 pod 中的应用程序可以对外提供服务,该 pod 就会加入相对应的 service,对外提供服务。但有时一些应用程序启动后,需要较长时间的加载才能对外服务,如果这时对外提供服务,执行结果必然无法达到预期效果,影响用户体验。比如使用 tomcat 的应用程序来说,并不是简单地说 tomcat 启动成功就可以 对外提供服务的,还需要等待 spring 容器初始化,数据库连接上等等。


目前 LivenessProbe 和 ReadinessProbe 两种探针都支持下面三种探测方法:


1、ExecAction:在容器中执行指定的命令,如果执行成功,退出码为 0 则探测成功。


2、TCPSocketAction:通过容器的 IP 地址和端口号执行 TCP 检查,如果能够建立 TCP 连接, 则表明容器健康。


3、HTTPGetAction:通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法,如果响应的状态码大于等于 200 且小于 400,则认为容器健康


探针探测结果有以下值:


1、Success:表示通过检测。


2、Failure:表示未通过检测。


3、Unknown:表示检测没有正常进行。


Pod 探针相关的属性


探针(Probe)有许多可选字段,可以用来更加精确的控制 Liveness 和 Readiness 两种探针的行为


initialDelaySeconds: Pod 启动后首次进行检查的等待时间,单位“秒”。


periodSeconds: 检查的间隔时间,默认为 10s,单位“秒”。


timeoutSeconds: 探针执行检测请求后,等待响应的超时时间,默认为 1s,单位“秒”。


successThreshold:连续探测几次成功,才认为探测成功,默认为 1,在 Liveness 探针中必须为 1,最小值为 1。


failureThreshold: 探测失败的重试次数,重试一定次数后将认为失败,在 readiness 探针中,Pod 会被标记为未就绪,默认为 3,最小值为 1


两种探针区别:


ReadinessProbe 和 livenessProbe 可以使用相同探测方式,只是对 Pod 的处置方式不同:


readinessProbe 当检测失败后,将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。


livenessProbe 当检测失败后,将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。


Pod 探针使用示例


1、LivenessProbe 探针使用示例


通过 exec 方式做健康探测


[root@k8smaster node]# vim liveness-exec.yaml 
apiVersion: v1
kind: Pod 
metadata: 
  name: liveness-exec
  labels:
    app: liveness
spec: 
  containers:
  - name: liveness
    image: busybox
    args: #创建测试探针探测的文件 
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe: 
      initialDelaySeconds: 10 #延迟检测时间 
      periodSeconds: 5 #检测时间间隔 
      exec:
        command:
        - cat
        - /tmp/healthy
容器启动设置执行的命令
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" 容器在初始化后,首先创建一个 /tmp/healthy 文件,然后执行睡眠命令,睡眠 30 秒,到时间后执行删除 /tmp/healthy 文件命令。而设置的存活探针检检测方式为执行 shell 命令,用 cat 命令输出 healthy 文件的内容,如果能成功执行这条命令,存活探针就认为探测成功,否则探测失败。在前 30 秒内,由于文件存在,所以存活探针探测时执行 cat /tmp/healthy 命令成功执行。30 秒后 healthy 文件被删除,所以执行命令失败,Kubernetes 会根据 Pod 设置的重启策略来判断,是否重启 Pod。
[root@k8smaster node]# kubectl apply -f liveness-exec.yaml 
pod/liveness-exec created
[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
liveness-exec           1/1     Running   0          30s
[root@k8smaster node]# kubectl exec -it liveness-exec -- /bin/sh
/ # cd /tmp/
/tmp # ls
/tmp # 
#进入容器之后发现文件被删除了
[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
liveness-exec           1/1     Running   1          2m54s
#然后过一会他就重启了 rest那里是1
[root@k8smaster node]# kubectl describe pods liveness-exec
 Warning  Unhealthy  5s (x7 over 2m50s)   kubelet, k8snode2  Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
#可以在详细信息看到找不到文件


通过 HTTP 方式做健康探测


[root@k8smaster node]# vim liveness-http.yaml 
apiVersion: v1
kind: Pod 
metadata: 
  name: liveness-http 
  labels:
    app: liveness
spec: 
  containers:
  - name: liveness
    image: mydlqclub/springboot-helloworld:0.0.1
    livenessProbe: 
      initialDelaySeconds: 20 #延迟检测时间 
      periodSeconds: 5 #检测时间间隔 
      timeoutSeconds: 10  #超时时间设置 
      httpGet:
        scheme: HTTP
        port: 8081 
    path: /actuator/health
      readinessProbe:   #就绪型探测
      initialDelaySeconds: 20
      periodSeconds: 5 
      timeoutSeconds: 10 
      httpGet:
        scheme: HTTP
        port: 8081 
        path: /actuator/health
上面 Pod 中启动的容器是一个 SpringBoot 应用,其中引用了 Actuator 组件,提供了 /actuator/health 健康检查地址,存活探针可以使用 HTTPGet 方式向服务发起请求,请求 8081 端口的 /actuator/health 路径来进行存活判断。
任何大于或等于 200 且小于 400 的代码表示探测成功,任何其他代码表示失败。如果探测失败,则会杀死 Pod 进行重启操作。 
httpGet 探测方式有如下可选的控制字段: 
scheme: 用于连接 host 的协议,默认为 HTTP。 
host:要连接的主机名,默认为 Pod IP,可以在 http request head 中设置 host 头部。 
port:容器上要访问端口号或名称。 
path:http 服务器上的访问 URI。 
httpHeaders:自定义 HTTP 请求 headers,HTTP 允许重复 headers。 
[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS             RESTARTS   AGE
liveness-http           1/1     Running            0          35s
[root@k8smaster node]# kubectl logs liveness-http | grep 8081
2022-07-10 19:04:19.392  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8081 (http)
2022-07-10 19:04:19.510  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8081 (http) with context path ''
2022-07-10 19:04:37.453  INFO 1 --- [nio-8081-exec-1] o.a.c.c.C.[Tomcat-1].[localhost].[/]     : Initializing Spring DispatcherServlet 'dispatcherServlet'
2022-07-10 19:04:37.453  INFO 1 --- [nio-8081-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2022-07-10 19:04:37.458  INFO 1 --- [nio-8081-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 5 ms
[root@k8smaster node]# curl http://10.244.1.7:8081/actuator/health
{"status":"UP"}
[root@k8smaster node]# curl -I http://10.244.1.7:8081/actuator/health
HTTP/1.1 200 
Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 10 Jul 2022 11:08:55 GMT
#返回200状态码,启动成功!


通过 TCP 方式做健康探测


[root@k8smaster node]# vim liveness-tcp.yaml 
apiVersion: v1
kind: Pod 
metadata: 
  name: liveness-tcp 
  labels:
    app: liveness
spec: 
  containers:
  - name: liveness
    image: nginx
    livenessProbe: 
      initialDelaySeconds: 15 
      periodSeconds: 20   
    tcpSocket: 
        port: 80
TCP 检查方式和 HTTP 检查方式非常相似,在容器启动 initialDelaySeconds 参数设定的时间后,kubelet 将发送第一个 livenessProbe 探针,尝试连接容器的 80 端口,如果连接失败则将杀死 Pod 重启容器。 
[root@k8smaster node]# kubectl apply -f liveness-tcp.yaml 
pod/liveness-tcp created
[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
liveness-tcp            1/1     Running   0          19s


2、ReadinessProbe 探针使用示例


Pod 的 ReadinessProbe 探针使用方式和 LivenessProbe 探针探测方法一样,也是支持三种,只是一个是用于探测应用的存活,一个是判断是否对外提供流量的条件。比如Springboot 项目,设置 ReadinessProbe 探测 SpringBoot 项目的 8081 端口下的 /actuator/health 接口,如果探测成功则代表内部程序以及启动,就开放对外提供接口访问,否则内部应用没有成功启动,暂不对外提供访问,直到就绪探针探测成功。


两个也可以一起用。


[root@k8smaster node]# vim readiness-exec.yaml 
apiVersion: v1
kind: Service
metadata:
  name: springboot 
  labels:
    app: springboot
spec:
  type: NodePort
  ports:
  - name: server 
    port: 8080
    targetPort: 8080
    nodePort: 31180
  - name: management  
    port: 8081
    targetPort: 8081
    nodePort: 31181
  selector:
    app: springboot
--- 
apiVersion: v1 
kind: Pod 
metadata: 
  name: springboot
  labels:
    app: springboot
spec: 
  containers:
  - name: springboot
    image: mydlqclub/springboot-helloworld:0.0.1
    ports: 
    - name: server
      containerPort: 8080
    - name: management
      containerPort: 8081
    readinessProbe:
      initialDelaySeconds: 20
      periodSeconds: 5
      timeoutSeconds: 10
      httpGet:
        scheme: HTTP
        port: 8081
        path: /actuator/health
[root@k8smaster node]# kubectl apply -f readiness-exec.yaml 
service/springboot created
pod/springboot created
[root@k8smaster node]# kubectl get pods -o wide | grep springboot
springboot              1/1     Running   0          42s     10.244.1.9    k8snode2


pod的启动探测


Kubernetes 的三种探针


livenessProbe:用于探测容器是否运行。如果存活探测失败,则 kubelet 会杀死容器,并且容器将受到其重启策略的影响决定是否重启。如果容器不提供存活探针,则默认状态为 Success。


readinessProbe:一般用于探测容器内的程序是否健康,容器是否准备好服务请求。如果就绪探测失败,endpoint 将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪 状态默认为 Failure。如果容器不提供就绪探针,则默认状态为 Success。


startupProbe: 探测容器中的应用是否已经启动。如果提供了启动探测(startup probe),则禁用所有其他探测,直到它成功为止。如果启动探测失败,kubelet 将杀死容器,容器服从其重启策略进行重启。 如果容器没有提供启动探测,则默认状态为成功 Success。


可以自定义在 pod 启动时是否执行这些检测,如果不设置,则检测结果均默认为通过,如果设置, 则顺序为 startupProbe>readinessProbe>livenessProbe。


为什么要用 startupProbe?


在 k8s 中,通过控制器管理 pod,如果更新 pod 的时候,会创建新的 pod,删除老的 pod,但是如果新的 pod 创建了,pod 里的容器还没完成初始化,老的 pod 就被删除了,会导致访问 service 或者 ingress 时候,访问到的 pod 是有问题的,所以 k8s 就加入了一些存活性探针:livenessProbe、就绪性探针 readinessProbe 以及启动探针 startupProbe。


startupProbe 是在 k8s v1.16 加入了 alpha 版,官方对其作用的解释是: 
Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state is Success
翻译:判断容器内的应用程序是否已启动。如果提供了启动探测,则禁用所有其他探测,直到它成功为止。如果启动探测失败,kubelet 将杀死容器,容器将服从其重启策略。如果容器没有提供启动探测,则默认状态为成功。


注意:不要将 startupProbe 和 readinessProbe 混淆。


什么时候会用 startupProbe 呢?


正常情况下,我们会在 pod template 中配置 livenessProbe 来探测容器是否正常运行,如果异常则会触发 restartPolicy 重启容器(因为默认情况下 restartPolicy 设置的是 always)


livenessProbe: 
  httpGet: 
    path: /test 
    prot: 80 
  failureThreshold: 1 
  initialDelay:10 
  periodSeconds: 10


上面配置的意思是容器启动 10s 后每 10s 检查一次,允许失败的次数是 1 次。如果失败次数超过 1 则会触发 restartPolicy。


但是有时候会存在特殊情况,比如服务 A 启动时间很慢,需要 60s。这个时候如果还是用上面的探针就会进入死循环,因为上面的探针 10s 后就开始探测,这时候我们服务并没有起来,发现探测失败就会触发 restartPolicy。这时候有的朋友可能会想到把 initialDelay 调成 60s 不就可以了?但是我们并不能保证这个服务每次起来都是 60s,假如新的版本起来要 70s,甚至更多的时间,我们就不好控制了。有的朋友可能还会想到把失败次数增加,比如下面配置:


livenessProbe: 
  httpGet: 
    path: /test 
    prot: 80 
  failureThreshold: 5 
  initialDelay:60 
  periodSeconds: 10


这在启动的时候是可以解决我们目前的问题,但是如果这个服务挂了呢?如果 failureThreshold=1 则 10s 后就会报警通知服务挂了,如果设置了 failureThreshold=5,那么就需要 5*10s=50s 的时间,在现在大家追求快速发现、快速定位、快速响应的时代是不被允许的。


在这时候我们把 startupProbe 和 livenessProbe 结合起来使用就可以很大程度上解决我们的问题。


livenessProbe: 
  httpGet: 
    path: /test 
    prot: 80 
  failureThreshold: 1 
  initialDelay:10 
  periodSeconds: 10 
startupProbe: 
  httpGet: 
    path: /test 
    prot: 80 
  failureThreshold: 10 
  initialDelay:10 
  periodSeconds: 10


上面的配置是只有 startupProbe 探测成功后再交给 livenessProbe。我们 startupProbe 配置的是 10*10s,也就是说只要应用在 100s 内启动都是 OK 的,而且应用挂掉了 10s 就会发现问题。


其实这种还是不能确定具体时间,只能给出一个大概的范围。我个人认为对服务启动时间的影响因素太多了,有可能是应用本身,有可能是外部因素,比如主机性能等等。我们只有在最大程度上追求高效、 稳定,但是我们不能保证 100%稳定,所以我们自己要做好监控有效性,告警的及时性,响应的快速性,处理的高效性。


K8s 的 LivenessProbe 和 ReadinessProbe 的启动顺序问题


LivenessProbe 会导致 pod 重启,ReadinessProbe 只是不提供服务。我们最初的理解是 LivenessProbe 会在 ReadinessProbe 成功后开始检查,但事实并非如此。


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


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


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


真正的启动顺序


官方文档:Caution: Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.


也就是 Liveness probes 并不会等到 Readiness probes 成功之后才运行,根据上面的官方文档,Liveness 和 readiness 应该是某种并发的关系。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1天前
|
Kubernetes Cloud Native 持续交付
云原生之旅:Docker容器化与Kubernetes集群管理
【9月更文挑战第33天】在数字化转型的浪潮中,云原生技术如同一艘航船,带领企业乘风破浪。本篇文章将作为你的航海指南,从Docker容器化的基础讲起,直至Kubernetes集群的高级管理,我们将一起探索云原生的奥秘。你将学习到如何封装应用、实现环境隔离,以及如何在Kubernetes集群中部署、监控和扩展你的服务。让我们启航,驶向灵活、可伸缩的云原生未来。
|
4天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker与Kubernetes入门
【9月更文挑战第30天】在云计算的浪潮中,云原生技术正以前所未有的速度重塑着软件开发和运维领域。本文将通过深入浅出的方式,带你了解云原生的核心组件——Docker容器和Kubernetes集群,并探索它们如何助力现代应用的构建、部署和管理。从Docker的基本命令到Kubernetes的资源调度,我们将一起开启云原生技术的奇妙之旅。
|
1天前
|
Kubernetes Cloud Native Ubuntu
云原生之旅:Kubernetes集群搭建与应用部署
【8月更文挑战第65天】本文将带你进入云原生的世界,通过一步步指导如何在本地环境中搭建Kubernetes集群,并部署一个简单的应用。我们将使用Minikube和Docker作为工具,探索云原生技术的魅力所在。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的信息和实践技巧。
|
5天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
|
5天前
|
Kubernetes Cloud Native Docker
云原生之旅:深入理解容器化与Kubernetes
【9月更文挑战第29天】在云计算的海洋中,云原生技术如同一艘航船带领着企业乘风破浪。本文将作为你的航海图,带你探索云原生的核心——容器化和Kubernetes。我们将从容器的基本概念出发,逐步深入到如何在Kubernetes集群中部署应用,最后探讨这些技术如何助力现代软件开发。文章旨在为读者提供清晰的云原生入门知识,并展示实际操作的步骤,让你能够自信地启航。
|
21天前
|
弹性计算 运维 持续交付
探索Docker容器化技术及其在生产环境中的应用
探索Docker容器化技术及其在生产环境中的应用
70 5
|
14天前
|
Linux iOS开发 Docker
Docker:容器化技术的领航者 —— 从基础到实践的全面解析
在云计算与微服务架构日益盛行的今天,Docker作为容器化技术的佼佼者,正引领着一场软件开发与部署的革命。它不仅极大地提升了应用部署的灵活性与效率,还为持续集成/持续部署(CI/CD)提供了强有力的支撑。
192 69
|
14天前
|
运维 Cloud Native Docker
云原生技术入门:Docker容器化实战
【9月更文挑战第20天】本文将引导你走进云原生技术的世界,通过Docker容器化技术的实战演练,深入理解其背后的原理和应用。我们将一起探索如何在云平台上利用Docker简化部署、扩展和管理应用程序的过程,并揭示这一技术如何改变现代软件的开发和运维模式。
|
9天前
|
Cloud Native 持续交付 Docker
云原生技术入门与实践:Docker容器化部署示例
【9月更文挑战第25天】在数字化转型的浪潮下,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,为初学者揭示云原生技术的核心概念及其应用价值。我们将以Docker容器为例,逐步引导读者了解如何将应用程序容器化,并在云端高效运行。这不仅是对技术趋势的跟随,更是对资源利用和开发效率提升的探索。
29 4
|
1月前
|
NoSQL 关系型数据库 Redis
mall在linux环境下的部署(基于Docker容器),Docker安装mysql、redis、nginx、rabbitmq、elasticsearch、logstash、kibana、mongo
mall在linux环境下的部署(基于Docker容器),docker安装mysql、redis、nginx、rabbitmq、elasticsearch、logstash、kibana、mongodb、minio详细教程,拉取镜像、运行容器
mall在linux环境下的部署(基于Docker容器),Docker安装mysql、redis、nginx、rabbitmq、elasticsearch、logstash、kibana、mongo

相关产品

  • 容器服务Kubernetes版
  • 下一篇
    无影云桌面