K8s Liveness/Readiness/Startup 探针机制
官方参考文档
目录
- 前言
- 一、默认健康检测
- 1.1 restartPolicy
- 1.2 测试案例
- 二、Liveness
- 三、Readiness
- 四、Startup
前言
玩过 Docker Swarm
的应该都知道,有一种功能叫自愈功能
,当集群检测到节点或服务故障时回进行自动故障转移,从而保障业务的可用性。而 K8s 集群相对于其他集群体系,其自愈能力更加强大,这也是 K8s 容器编排引擎的一重要特性。自愈从某种角度上来讲,其实现了以下几几种功能特性:
- 零停机部署;
- 避免无效镜像;
- 实现滚动升级与回退。
K8s 有三种探针,分别是:存活(Liveness)
、就绪(Readiness)
和启动(Startup)
存活(Liveness):kubelet 使用存活探针来确定什么时候要重启容器。 例如,存活探针可以探测到应用死锁(应用程序在运行,但是无法继续执行后面的步骤)情况。 重启这种状态下的容器有助于提高应用的可用性,即使其中存在缺陷。
就绪(Readiness):kubelet 使用就绪探针可以知道容器何时准备好接受请求流量。当一个 Pod 内的所有容器都就绪时,才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪,会被从 Service 的负载均衡器中剔除。
启动(Startup):kubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针,你就可以控制容器在启动成功后再进行存活性和就绪态检查, 确保这些存活、就绪探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测,避免它们在启动运行之前就被杀掉。
K8s 探针有三种探测方式,分别是:ExecAction
、HTTPGetAction
和 TCPSocketAction
。
注意,这三种探测方式只能同时使用一种,不能两种或三种同时使用。
- ExecAction:在容器中执行指定的命令,如果执行成功,退出码为0则探测成功。
- HTTPGetAction:通过容器的IP地址、端口号及路径调用HTTP Get方法,如果响应的状态码大于等于200且小于400,则认为容器健康。
- TCPSocketAction:通过容器的IP地址和端口号执行TCP检查,如果能够建立TCP连接,则表明容器健康。
探针探测的结果有以下值:
- Success:表示通过检测。
- Failure:表示未通过检测。
- Unknown:表示检测没有正常进行。
一、默认健康检测
1.1 restartPolicy
了解 Docker 的都知道,每个容器启动时都会执行一个进程,该进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果进程退出或返回状态码为非零时,则认为容器发生故障,这个时候 K8s 就会根据 restartPolicy
重启容器。restartPolicy
有三种重启策略:
Always
Pod 中容器不论如何停止都将自动重启;
OnFailure
Pod 中容器非正常停止会自动重启,正常停止不会重启;Never
Pod 中容器不论以任何方式停止,都不会自动重启。
K8s 的 restartPolicy
默认为 Always
。如果探针超过失败重试的次数,则 Pod 就会根据 restartPolicy 策略进行选择是否重启。
1.2 测试案例
1、创建一个 Pod
apiVersion: v1
kind: Pod
metadata:labels:test: healthcheckname: healthcheck
spec:restartPolicy: OnFailurecontainers:- name: healthcheckimage: busyboxargs:- /bin/sh- -c- sleep 10;exit 1
2、观察 Pod 状态
这个容器启动 10s 后会发生故障,接下来执行 kubectl apply
创建 Pod,Pod Name 为 healthcheck。过几分钟后看看 Pod 的状态:
可看到已经重启了三次,该案例中容器进程返回值为非零,k8s 则认为容器发生故障,需要重启。但可能有些情况下发生了故障进程不退出的现象,如访问 Web 服务器时返回 500 错误代码,这可能是系统负荷较大或资源锁死,此时 httpd 进程并没有异常退出,这种情况下可直接重启容器。而 K8s 的 Liveness 机制刚好能解决此类问题(即出现此类问题会直接 Kill 掉容器并重新启动)。
二、Liveness
Liveness 探针让用户可以自定义判断容器是否健康的条件,如果探测失败,K8s 就会重启容器,如下案例:
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5
在这个配置文件中,可以看到 Pod 中只有一个 Container
。 periodSeconds
字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds
字段告诉 kubelet 在执行第一次探测前应该等待 5 秒(即 5 秒后才开始启动探针)。 kubelet 在容器内执行命令 cat /tmp/healthy
来进行探测。 如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值,kubelet 会杀死这个容器并重新启动它。当容器启动时,会执行如下的命令:
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"
这个容器生命的前 30 秒,/tmp/healthy
文件是存在的。 所以在这最开始的 30 秒内,执行命令 cat /tmp/healthy
会返回成功代码。 30 秒之后,执行命令 cat /tmp/healthy
就会返回失败代码。
执行 kubectl apply
创建 Pod 。
kubectl apply -f liveness.yml
查看 Pod 启动日志:
kubectl describe pod liveness-exec
前 30s /tmp/healthy
文件是存在的:
35s 后检测到/tmp/healthy
文件已经不存在:
再过十几秒后容器被重启:
三、Readiness
除了可以自定义判断容器是否健康的条件外,用户也可以通过 Readiness
探针告诉 K8s 什么时候可以重启容器实现自愈,Readiness
探针则告诉 K8s 什么时候可以将容器加入到 Service 负载均衡池中,对外提供服务。就绪探针的配置和存活探针的配置相似。 唯一区别就是要使用 readinessProbe
字段,而不是 livenessProbe
字段。
apiVersion: v1
kind: Pod
metadata:labels:test: readinessname: readiness-exec
spec:containers:- name: livenessimage: busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600readinessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5
看看启动日志,与 Liveness
探针类似
kubectl describe pod readiness-exec
Probe 有很多配置字段,可以使用这些字段精确地控制启动、存活和就绪检测的行为:
initialDelaySeconds
:容器启动后要等待多少秒后才启动启动、存活和就绪探针, 默认是 0 秒,最小值是 0。periodSeconds
:执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1。timeoutSeconds
:探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。successThreshold
:探针在失败后,被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。failureThreshold
:当探测失败时,Kubernetes 的重试次数。 对存活探测而言,放弃就意味着重新启动容器。 对就绪探测而言,放弃意味着 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
注意:存活探针 不等待 就绪性探针成功。如果要在执行存活探针之前等待就绪性探针,应该使用 initialDelaySeconds
或 startupProbe
。
四、Startup
Startup 是 k8s 1.16+
版本后新加的探测方式,用于判断容器内应用程序是否已经启动,如果同时配置了 startuprobe
、Livenessprobe
、Readinessprobe
,K8s 就会先禁用其他的探针,而首先使用 startuprobe
探测直到它成功为止,成功后将不再进行探测。
startupProbe 探针与另两种区别?
如果三个探针同时存在,先执行startupProbe探针,其他两个探针将会被暂时禁用,直到pod满足startupProbe探针配置的条件,其他2个探针启动,如果不满足按照规则重启容器。
另外两种探针在容器启动后,会按照配置,直到容器消亡才停止探测,而startupProbe探针只是在容器启动后按照配置满足一次后,不在进行后续的探测。
那 Startup 存在的意义又是什么呢?
试想一个问题,如果启动一个服务需要 1 分钟,如果没有 Startup
的情况下,且假设我们配置了 livenessProbe
探针,具体如下:
livenessProbe:httpGet:path: /testprot: 80
failureThreshold: 6
initialDelay:40
periodSeconds: 5
我们设置了失败重试次数为 6,每 5 秒探测一次,加上我们探测前等待的 40 秒,总时间就是:40 + 6 x 5 = 70s,这样 Pod 确实能够启动起来。那问题又来了,如果这个配置用于生产配置上,将会导致我们比较晚的收到服务不可用的情况,也就是说我的服务可能在 5s 时已经不可用,但是由于我们探测机制(有 6 次失败重试的机会),我们在至少 6 x 5 = 30s 才会发现服务不可用的情况,这在生产上一般是不被允许的。那该如何解决类似这样的问题呢?答案是 startupProbe
。
注意上面这个案例,如果
failureThreshold
设置为 1 或 2,那这个服务是永远起不起来的,因为你把initialDelay
的时间算上也不足 1 分钟,因为我们说启动至少需要 1 分钟,那超过失败重试次数后,就会根据 Pod 的restartPolicy
来重启容器。
接着我们引入 startupProbe
,继续优化:
livenessProbe:httpGet:path: /testprot: 80
failureThreshold: 1
initialDelay:5
periodSeconds: 5startupProbe:httpGet:path: /testprot: 80
failureThreshold: 60
initialDelay:5
periodSeconds: 5
前面说了,startupProbe
会在探测成功后停止探测,而其他两种探针则是随着 Pod 的生命周期一直在探测的。因此上面的配置功能就是:K8s 部署服务后会在 5s 后启动 startupProbe
,在 5 x 60 = 300s 的时间内只要成功探测到服务则停止探测(否则需接受 Pod 的重启策略进行重启),并启用 livenessProbe
探针,此时livenessProbe
探针就会伴随着 Pod 的生命周期每 5s 检测一次,且我们只设置了 1 次失败重试的机会,这就意味着我们只需要在 1 x 5 = 5s 时间就可以发现服务不可用。因此,你配置了 startupProbe
,那其他2种探针如果配置了initialDelaySeconds
,建议时间就不要给太长。这就是 Startup 探针存在的意义。
K8s Liveness/Readiness/Startup 探针机制相关推荐
- kuberbetes 容器探测(liveness/readiness probes)
1.容器探测(liveness/readiness probes) 容器探测用于检测容器中的应用实例是否正常工作,是保障业务可用性的一种传统机制.如果经过探测,实例的状态不符合预期,那么kuberne ...
- Skywalking使用与探针机制
对于 大型 几十个.几百个微服务构成的微服务架构系统 出现问题无法快速定位.各个微服务之间的依赖关系理不清.各个微服务的接口性能很难分析.业务调用流程处理顺序理不清 skywalking是一个国产开源 ...
- k8s集群RBAC安全机制:role rolebing user
k8s集群RBAC安全机制:role rolebing user
- JAVA探针机制—Agent(一)
JAVA探针机制-Agent(一) agent机制首次出现在JDK5版本,在JDK6版本得到升级并且正式被官方定义为agent原理. 首先要明确JavaAgent是一个JVM层面的插件,他可以利用JD ...
- linux探针,存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)、容器钩子
一.探针 1.1.探针类型 LivenessProbe 用于判断容器是否存活(running状态),如果LivenessProbe探针探测到容器不健康,则kubelet杀掉该容器,并根据容器的重启策略 ...
- k8s核心技术-集群安全机制(概述)---K8S_Google工作笔记0038
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 接下来我们说k8s的安全机制: 可以看到对于k8s来说,有上面三步需要做,在访问k8s集群的时候 ...
- DCOS之k8s的容器监测探针
大部分的应用程序我们在部署的时候都会适当的添加监控,对于运行载体容器则更应该如此.kubernetes提供了 liveness probes来检查我们的应用程序.它是由节点上的kubelet定期执行的 ...
- @kubernetes(k8s)pod服务探针(健康检查)及回调钩子HOOK详解
文章目录 服务探针与回调hook(健康检查) 一.存活性探针(LivenessProbe) 1.存活型检查基本用法 2.存活性探针三种使用方式 [ExecAction] [TCPSocketActio ...
- k8s核心技术-集群安全机制(RBAC介绍)---K8S_Google工作笔记0039
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 然后咱们来说k8s中鉴权所用的rbac 来看看他的工作过程,其实他就是基于角色的鉴权. 可以看到首 ...
最新文章
- IT阅读——关于“业务”
- JAVA-初步认识-第十一章-object类-equals方法覆盖
- Spring Cloud(五)断路器监控(Hystrix Dashboard)
- poj1503(高精度模拟加法)
- 基于PaddlePaddle的机器翻译教程 | 深度学习基础任务系列
- Java反编译Jar包和Android APK(类似.NET Reflector)
- MATLAB实战系列(四十)-小波变换MATLAB图像融合
- Python命令行解析:sys.argv[]函数的简介、案例应用之详细攻略
- 程序员的十层楼(第11层)
- C# 之不安全代码(2)
- 正则表达式与神经网络的深度融合
- JavaScript实现breadth First Search广度优先搜索算法(附完整源码))
- 2020牛客国庆集训派对day2 F题 Java大数处理
- 布同:web版比赛实时算分系统的设计
- 简单设置让Win7不等更新直接关机
- 构建Docker镜像仓库的另一选择:Nexus3 - DockOne.io
- 衍射受限透镜成像_成像专题 | 基于孔径阵列的数字全息重建 (AIP APL)
- 启动优化之Android-Startup
- 分数阶微积分基本理论(课堂笔记1)
- 爬虫实战 爬取谷歌图片 Google images