k8s-liveness和readness详解
最近因为查找问题,看了一些k8s的liveness和readiness配置,这两种都是k8s探针用于健康检测的,是k8s很重要的一个特性,在此记录一下,留作备忘。概述健康检查(health check)是用于检测应用实例是否正常工作,对应用状态的监控,保障业务高可用的一种机制。k8s健康检测主要分为以下三种:存活性探测(Liveness probes) :主要是探测应用是否还活着。如果检测到应用没
最近因为查找问题,看了一些k8s的liveness和readiness配置,这两种都是k8s探针用于健康检测的,是k8s很重要的一个特性,在此记录一下,留作备忘。
概述
健康检查(health check)是用于检测应用实例是否正常工作,对应用状态的监控,保障业务高可用的一种机制。
k8s健康检测主要分为以下三种:
- 存活性探测(Liveness probes) :主要是探测应用是否还活着。如果检测到应用没有存活就杀掉当前pod并重启。
- 就绪性探测(Readiness probes):只要是探测应用是否准备好接受请求访问,如果检测应用准备好了,就把请求流量放进来;反之,则把应用节点从注册中心拿掉。
- 启动探测(Startup Probes):对于旧应用需要更长的启动时间,这时候既不想重启应用也不想让请求访问进来,可以设置启动探测给足够的启动时间保证应用启动成功。
Liveness Probes config和Readiness Probes config
k8s示例配置
readinessProbe:
enabled: true
httpGet:
port: 8080
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 35
periodSeconds: 30
successThreshold: 1
failureThreshold: 3
livenessProbe:
enabled: true
httpGet:
port: 8080
scheme: HTTP
initialDelaySeconds: 60
timeoutSeconds: 35
periodSeconds: 30
successThreshold: 1
failureThreshold: 3
initialDelaySeconds 表示延迟30S开始第一次探测,默认值是0,最小值是0
timeoutSeconds 表示每次探测的超时时间,35S后如果没返回结果就认为超时失败,默认值是1,最小值是1
successThreshold 表示在探测失败后,最小的连续成功被认为是成功的,默认值是1,最小值是1
failureThreshold 表示当探测失败时,Kubernetes将在认为失败前尝试failureThreshold次数。默认值是3,最小值是1;Liveness认为失败的操作是重启pod,而readiness认为失败的操作是把pod标记为 Unready
periodSeconds 表示多久进行一次探测,默认是10S,最小值是1
Startup Probes config
k8s示例配置
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
由于启动探测,应用最多有5分钟(30 * 10 = 300秒)来完成它的启动。一旦启动探测成功一次,活性探测(Livenees probes)将接管以提供对容器死锁的快速响应。如果启动探测从未成功,容器将在300秒后被杀死,并遵循pod的重启策略 restartPolicy
restartPolicy 主要有以下三种策略
- Always: 当容器终止退出后,总是重启容器,默认策略
- Onfailure: 当容器异常退出后(退出码非0)时,才重启容器
- Never: 当容器终止退出时,不重启容器
每次探测都是以下三种结果之一:
- 成功:容器通过了探测
- 失败:容器未通过探测
- 未知:容器探测失败,不采取任何操作
liveness和readiness对比及区别
liveness | readiness | |
---|---|---|
配置和参数 | 相同 | 相同 |
探测失败后的行为 | 重启容器 | 把容器标记为Unready,不接受请求 |
依赖性 | 二者是相互独立,没有依赖,既可以独立使用,也可以同时使用 | 同liveness |
作用 | 判断是否需要重启以实现自愈 | 判断容器是否准备好对外提供服务 |
初始值 | 成功,防止应用在没成功启动前,被误杀 | 失败,防止应用还没准备好,有请求进来 |
默认值 | 二者没配置的话,默认状态都是成功 | |
返回值 | 返回值在[200,400)范围内认为成功,返回值5xx认为失败 | 同liveness |
二者不能相互替代,根据实际情况,配合使用。只配置了readiness是无法触发容器重启的;只配置了liveness,可能应用还没准备好,导致请求失败,status是running,Ready是0/1。
可能的最佳实践
k8s可以和springboot actuator结合使用,运用合理的配置,监控应用的状态,提供报警功能,以保证应用的高可用性,比如/health或/actuator/health。
探讨一下liveness和readiness的更多的可能使用场景
- 扩缩容
- 灰度发布
- …
如果你有更好更多的有关以上健康检测的使用场景,欢迎评论或私信我,探讨交流一下
本文第一时间发布在微信公众号:蜗牛开发笔记,
如果想获取更多的Java开发笔记,请关注微信公众号,您的关注是我最大的动力,谢谢!
更多推荐
所有评论(0)