k8s之liveness and readness

作用：

首先是应用的健康状态上面，可以实时地进行观测；
第二个是可以获取应用的资源使用情况；
第三个是可以拿到应用的实时日志，进行问题的诊断与分析。
当出现了问题之后，首先要做的事情是要降低影响的范围，进行问题的调试与诊断。最后当出现问题的时候，理想的状况是：可以通过和 K8s 集成的自愈机制进行完整的恢复。
两种probe
Liveness（存活探针）
Readness（就绪探针）
介绍
用于判断容器是否存活，既 Pod 状态是否为 running，如果 Liveness 探针判断容器不健康，则会触发 kubelet 杀掉容器，并根据配置的策略判断是否重启容器，如果默认不配置 Liveness 探针，则认为返回默认值认为成功
用于判断容器是否启动完成，既 Pod 的 Condition 是否为 Ready，如果探测结果不成功，则会将 Pod 从 Endpoint 中移除，直至下次判断成功，再将 Pod 挂回到 Endpoint 上
检测失败
Pod挂掉
切断上层流量到 Pod
适用场景
支持重新拉起的应用
启动后无法立即对外服务的应用
注意事项
不论是 Liveness 还是 Readness 探针，选择合适的探测方式可以防止被误操作

2.Liveness 存活指针

Liveness probe 来确定你的应用程序是否正在运行，通俗点将就是是否还活着。一般来说，如果你的程序一旦崩溃了， Kubernetes 就会立刻知道这个程序已经终止了，然后就会重启这个程序。而我们的 liveness probe 的目的就是来捕获到当前应用程序还没有终止，还没有崩溃，如果出现了这些情况，那么就重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去。 kubelet 使用活跃度探头知道什么时候重新启动的容器。例如，liveness probe 可以捕获死锁，应用程序正在运行，但无法取得进展。在这种状态下重新启动容器可以继续存活。
3.Readiness 就绪探针

Readiness 也叫就绪指针，用来判断一个 pod 是否处在就绪状态。当一个 pod 处在就绪状态的时候，它才能够对外提供相应的服务，也就是说接入层的流量才能打到相应的 pod。当这个 pod 不处在就绪状态的时候，接入层会把相应的流量从这个 pod 上面进行摘除。
readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了，现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态，因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态，那么我们就会将他从我们的工作队列(实际上就是我们后面需要重点学习的 Service)中移除出来，这样我们的流量就不会被路由到这个 Pod 里面来了。使用 readiness probe 来了解容器何时准备开始接受流量。当所有容器准备就绪时，Pod 被认为已准备就绪。此信号的一个用途是控制哪些 Pod 用作服务的后端。当 Pod 未就绪时，它将从服务负载平衡器中删除。例如当一个应用服务有大文件加载时，这种情况下不允许接受用户访问，readiness probe 就不会对这类型的程序启动服务。
4.探测方式

Liveness 指针和 Readiness 指针支持三种不同的探测方式：
1.第一种是 http.Get。它是通过发送 http Get 请求来进行判断的，当返回码是 200-399 之间的状态码时，标识这个应用是健康的
httpGet 里面有一个字段是路径，第二个字段是 port，第三个是 headers。这个地方有时需要通过类似像 header 头的一个机制做 health 的一个判断时，需要配置这个 header，通常情况下，可能只需要通过 health 和 port 的方式就可以了。
spec:
containers:

name: liveness-http
image: xxxxx/busybox
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
2.第二种探测方式是 Exec，它是通过执行容器中的一个命令来判断当前的服务是否是正常的，当命令的返回结果是 0，则标识容器是健康的。
Liveness probe，它里面配置了一个 exec 的一个诊断。接下来，它又配置了一个 command 的字段，这个 command 字段里面通过 cat 一个具体的文件来判断当前 Liveness probe 的状态，当这个文件里面返回的结果是 0 时，或者说这个命令返回是 0 时，它会认为此时这个 pod 是处在健康的一个状态。
spec:
containers:
name: liveness
image: xxxxx/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy
  lienessProbe:
  exec:
  command:
  - cat
- /tmp/healthy
  3.第三种探测方式是 tcpSocket，它是通过探测容器的 IP 和 Port 进行 TCP 健康检查，如果这个 TCP 的链接能够正常被建立，那么标识当前这个容器是健康的
  tcpSocket 的使用方式其实也比较简单，你只需要设置一个检测的端口，像这个例子里面使用的是 8080 端口，当这个 8080 端口 tcp connect 审核正常被建立的时候，那 tecSocket，Probe 会认为是健康的一个状态。
  spec:
  containers:
name: goproxy
image: xxxxx/busybox
ports:
containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
livenessProbe:
tcpSocket:
port: 8080
5.探测结果

从探测结果来讲主要分为三种：

第一种是 success，当状态是 success 的时候，表示 container 通过了健康检查，也就是 Liveness probe 或 Readiness probe 是正常的一个状态；
第二种是 Failure，Failure 表示的是这个 container 没有通过健康检查，如果没有通过健康检查的话，那么此时就会进行相应的一个处理，那在 Readiness 处理的一个方式就是通过 service。service 层将没有通过 Readiness 的 pod 进行摘除，而 Liveness 就是将这个 pod 进行重新拉起，或者是删除。
第三种状态是 Unknown，Unknown 是表示说当前的执行的机制没有进行完整的一个执行，可能是因为类似像超时或者像一些脚本没有及时返回，那么此时 Readiness-probe 或 Liveness-probe 会不做任何的一个操作，会等待下一次的机制来进行检验。
那在 kubelet 里面有一个叫 ProbeManager 的组件，这个组件里面会包含 Liveness-probe 或 Readiness-probe，这两个 probe 会将相应的 Liveness 诊断和 Readiness 诊断作用在 pod 之上，来实现一个具体的判断。

Global 的参数

Global 的参数。

第一个参数叫 initialDelaySeconds，它表示的是说这个 pod 启动延迟多久进行一次检查，比如说现在有一个 Java 的应用，它启动的时间可能会比较长，因为涉及到 jvm 的启动，包括 Java 自身 jar 的加载。所以前期，可能有一段时间是没有办法被检测的，而这个时间又是可预期的，那这时可能要设置一下 initialDelaySeconds；
第二个是 periodSeconds，它表示的是检测的时间间隔，正常默认的这个值是 10 秒；
第三个字段是 timeoutSeconds，它表示的是检测的超时时间，当超时时间之内没有检测成功，那它会认为是失败的一个状态；
第四个是 successThreshold，它表示的是：当这个 pod 从探测失败到再一次判断探测成功，所需要的阈值次数，默认情况下是 1 次，表示原本是失败的，那接下来探测这一次成功了，就会认为这个 pod 是处在一个探针状态正常的一个状态；
最后一个参数是 failureThreshold，它表示的是探测失败的重试次数，默认值是 3，表示的是当从一个健康的状态连续探测 3 次失败，那此时会判断当前这个 pod 的状态处在一个失败的状态。

两种probe相互作用，只设置其中一种都无法正常监测集群内容器健康状态。
例如：只配置了Liveness，那么在容器启动，应用还没有成功就绪之前，这个时候Pod是ready的（因为容器成功启动了）。那么流量就会被引入到容器的应用中，可能会导致请求失败。虽然在Liveness检查失败后，重启容器，此时Pod的ready的condition会变为false。但是前面会有一些流量因为错误状态导入。

当然只配置了Readiness是无法触发容器重启的

注意事项：
在使用 Liveness 指针和 Readiness 指针的时候有一些注意事项。因为不论是 Liveness 指针还是 Readiness 指针都需要配置合适的探测方式，以免被误操作。

第一个是调大超时的阈值，因为在容器里面执行一个 shell 脚本，它的执行时长是非常长的，平时在一台 ecs 或者在一台 vm 上执行，可能 3 秒钟返回的一个脚本在容器里面需要 30 秒钟。所以这个时间是需要在容器里面事先进行一个判断的，那如果可以调大超时阈值的方式，来防止由于容器压力比较大的时候出现偶发的超时；
第二个是调整判断的一个次数，3 次的默认值其实在比较短周期的判断周期之下，不一定是最佳实践，适当调整一下判断的次数也是一个比较好的方式；
第三个是 exec，如果是使用 shell 脚本的这个判断，调用时间会比较长，比较建议大家可以使用类似像一些编译性的脚本 Golang 或者一些 C 语言、C++ 编译出来的这个二进制的 binary 进行判断，那这种通常会比 shell 脚本的执行效率高 30% 到 50%；
第四个是如果使用 tcpSocket 方式进行判断的时候，如果遇到了 TLS 的服务，那可能会造成后边 TLS 里面有很多这种未健全的 tcp connection，那这个时候需要自己对业务场景上来判断，这种的链接是否会对业务造成影响

应用部署
vi liveness.yaml

apiVersion: v1
kind: Pod
metadata:labels:test: liveness-execname: liveness-exec
spec:restartPolicy: OnFailurecontainers:- name: liveness-execimage: busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command: ["test","-e","/tmp/healthy"]initialDelaySeconds: 5    #探测延时时长，第一次探测前等待5秒，默认为0periodSeconds: 5          #每5秒执行一次liveness探测,默认值10秒，最小1秒timeoutSeconds: 2         #超长时长，默认为1s,最小值也为1sfailureThreshold: 3       #处于成功状态时，探测操作至少连续多少次的失败才被视为检测不通过，默认为3，最小为1

创建

kubectl apply -f live.yaml --validate=false

查看

kubectl describe po liveness-exec

Events:Type     Reason     Age                  From               Message----     ------     ----                 ----               -------Normal   Scheduled  3m24s                default-scheduler  Successfully assigned kuberhealthy/liveness-exec to dce-10-6-116-12Normal   Pulled     67s (x3 over 2m59s)  kubelet            Successfully pulled image "busybox"Normal   Created    66s (x3 over 2m59s)  kubelet            Created container liveness-execNormal   Started    65s (x3 over 2m58s)  kubelet            Started container liveness-execWarning  Unhealthy  42s (x9 over 2m47s)  kubelet            Liveness probe failed:Normal   Killing    42s (x3 over 2m37s)  kubelet            Container liveness-exec failed liveness probe, will be restartedNormal   Pulling    12s (x4 over 3m19s)  kubelet            Pulling image "busybox"

验证成功

http方式

apiVersion : v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: liveness-httpimage: nginxports:- name: httpcontainerPort: 80lifecycle:postStart:exec:command: ["/bin/sh" ,"-c","echo liveness-http test > /usr/share/nginx/html/health"]livenessProbe:httpGet:path: /healthport: httpscheme: HTTP

创建

[root@dce-10-6-116-10 ~]# kubectl apply -f live-http.yaml --validate=false

[root@dce-10-6-116-10 ~]# kubectl get po -o wide
liveness-http           1/1     Running             0          91s   172.29.213.217   dce-10-6-116-12   <none>           <none>

测试

[root@dce-10-6-116-10 ~]# curl 172.29.213.217/health
liveness-http test

删除测试页面health

[root@dce-10-6-116-10 ~]# curl 172.29.213.217/health
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.21.3</center>
</body>
</html>

发现容器重启一次

[root@dce-10-6-116-10 ~]# kubectl get po -o wide
liveness-http           1/1     Running             1          7m13s   172.29.213.217   dce-10-6-116-12   <none>           <none>

k8s之liveness and readness相关推荐

Spring-Boot Liveness 和 Readness 接口使用
Spring Boot Liveness 和 Readness 接口使用在 Spring Boot 2.3+ 中,提供了单独的 liveness 和 readness,用于为 Kubernetes ...
K8s Liveness/Readiness/Startup 探针机制
官方参考文档目录前言一.默认健康检测 1.1 restartPolicy 1.2 测试案例二.Liveness 三.Readiness 四.Startup 前言玩过 Docker Swarm ...
石墨文档基于K8S的Go微服务实践（上篇）
1 架构演进互联网的WEB架构演进可以分为三个阶段:单体应用时期.垂直应用时期.微服务时期. 单体应用时期一般处于一个公司的创业初期,他的好处就是运维简单.开发快速.能够快速适应业务需求变化.但是当 ...
k8s的健康性检查-Health Check
1.k8s健康性检查的默认方式 k8s默认的健康检查机制:基于Dockerfile文件中的CMD或者ENTRYPOINT,如果进程退出时返回码为非零,则认为容器发生故障,k8s就会根据restartP ...
linux网络健康度检测,linux运维、架构之路-K8s健康检查Health Check
一.Health Check介绍强大的自愈能力是k8s容器编排引擎一个重要特性,自愈能力的默认实现方式为自动重启发生故障的容器,另外还可以利用Liveness和Readiness探测机制设置更精细的 ...
aspnetcore.webapi实践k8s健康探测机制 - kubernetes
1.浅析k8s两种健康检查机制 Liveness k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈.比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可 ...
深入玩转K8S之智能化的业务弹性伸缩和滚动更新操作
在上篇我们讲到了较为傻瓜初级的弹性伸缩和滚动更新,那么接下来我们来看看较为高级的智能的滚动更新.本节的知识点呢是K8S的liveness和readiness探测,也就是说利用健康检查来做更为智能化的弹 ...
Kubernetes ~ k8s 从入门到入坑。
Kubernetes ~ k8s 从入门到入坑. 文章目录 Kubernetes ~ k8s 从入门到入坑. 1. Kubernetes 介绍. 1.1 应用部署方式演变. 1.2 kubernete ...
云原生背景下的运维价值思考与实践
作者:刘天斯,腾讯游戏高级工程师前言随着公司自研上云战略如火如荼地进行,IEG-增值服务部作为较早一批响应的团队,截止目前自研上云已完成1/3的流量切换,日PV超百亿.切云的服务大量采用了云原生的 ...
基于Kubernetes的云平台存储容器化实践
本文根据蔡逸煌老师在[Deeplus直播第214期]线上分享演讲内容整理而成. 蔡逸煌 OPPO云平台高级后端工程师主要从事云平台开发工作,擅长K8S.容器网络.存储等领域. 今天分享的主题是OPP ...

k8s之liveness and readness

k8s之liveness and readness相关推荐

最新文章

热门文章