Kubernetes 健康检查机制详解三类探针与三种探测方法落地实践Kubernetes Health Check环境准备Health CheckProbe TypeChecking MethodsHTTP Checks-httpGetlivenessProbereadinessProbeExecution Checks-execTCP Socket Checks-tcpSocketHealth Check CaseHealth Check 在 Scale Up 中的应用Health Check 在滚动更新中的应用如果没有配置Health Check 会出现怎样的情况环境清理Kubernetes Health Check摘要本文全面介绍了 Kubernetes 中的健康检查机制包括三种探针类型LivenessProbe、ReadinessProbe、StartupProbe和三种检查方法HTTP Checks、Execution Checks、TCP Socket Checks。通过实际示例演示了如何配置和使用这些探针并探讨了健康检查在 Scale Up 和滚动更新等场景中的应用价值。文章还提供了环境准备和清理的完整操作指南帮助读者深入理解 Kubernetes 如何通过健康检查确保应用的高可用性。学习参考配置存活、就绪和启动探针环境准备rootmaster30:~# kubectl create ns healthrootmaster30:~# kubectl config set-context --current --namespace healthHealth Check应用可能会因为各种问题变的unhealthy例如临时连接断开配置错误应用本身错误。kubelet 使用probes探针周期性地监控容器中应用是否为healthy状态进一步决定什么时候要重启容器。 例如当存活探针可以探测到应用死锁应用在运行但是无法继续执行后面的步骤情况进而重启pod有助于提高应用的可用性即使其中存在缺陷。没有探测的情况看一个例子# 创建一个普通 podrootmaster30:~# kubectl run web --imagehub.laoma.cloud/library/httpd --image-pull-policyIfNotPresent[rootlaoma20 health]# kubectl describe pod web|grep ^IP:IP:10.224.73.16 rootmaster30:~# curl 10.224.73.16htmlbodyh1It works!/h1/body/html# 删除主页文件即使pod中应用数据丢失pod状态依然为Runningrootmaster30:~# kubectl exec web -- rm -f htdocs/index.html# 查看主页内容rootmaster30:~# curl 10.224.73.16!DOCTYPE HTML PUBLIC-//W3C//DTD HTML 3.2 Final//ENhtmlheadtitleIndex of //title/headbodyh1Index of //h1ul/ul/body/htmlrootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web1/1 Running051s# 清理环境rootmaster30:~# kubectl delete pod web --forceProbe Typekubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针存活探针和就绪探针成功之前不会重启确保这些探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测避免它们在启动运行之前就被杀掉。LivenessProbe用于确定pod中应用是否处于healthy状态。如果liveness probe检测的状态为unhealthy则控制器将重新启动pod。ReadinessProbe用于确定pod中应用是否可以提供服务。如果返回失败状态则**服务将从endpoints 中删除容器ip地址。**即使容器处于运行状态也不接受代理发过来的请求。StartupProbe用于确定pod是否成功初始化。 如果指定则在成功完成之前不会执行其他探测。如果此探测失败Pod 将重新启动就像 livenessProbe 失败一样。 这可用于在 Pod 生命周期开始时提供不同的探测参数此时加载数据或预热缓存可能需要比稳态操作期间更长的时间。 这无法更新。我们这里不深入讨论StartupProbe。Checking Methods探针检查容器有四种不同的方法httpGet对容器的 IP 地址上指定端口和路径执行 HTTPGET请求。如果响应的状态码大于等于 200 且小于 400则诊断被认为是成功的。exec在容器内执行指定命令。如果命令退出时返回码为 0则认为诊断成功。tcpSocket对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开则诊断被认为是成功的。 如果远程系统容器在打开连接后立即将其关闭这算作是健康的。grpc使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC 健康检查。 如果响应的状态是 “SERVING”则认为诊断成功。我们这里不讨论grpc方法。HTTP Checks-httpGet当使用HTTP Checks控制器使用webhoook判定容器健康情况。如果HTTP的响应码在200-399之间判定check成功。适应范围可以返回HTTP状态码应用。livenessProberootmaster30:~# vim deploy-httpGet-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.html# port填写时间web端口port:80# scheme指定协议HTTP或者HTTPSscheme:HTTPprobe选项说明initialDelaySeconds必选。容器启动后多长时间probe开始生效。timeoutSeconds必选。probe需要多长时间完成。如果超过该值控制器判定probe失败。默认值1s最小值是1秒。periodSeconds可选。检查频率。默认值10s最小值是1秒。successThreshold可选连续成功最少次数后判定probe成功。默认值1最小值是1。failureThreshold可选。连续失败最少次数后判定probe失败。默认值3最小值是1。rootmaster30:~# kubectl apply -f deploy-httpGet-liveness.yamlrootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-85c6ff748f-qwszz1/1 Running012m rootmaster30:~# kubectl describe pod web-85c6ff748f-j92jn|grep ^IP:IP:10.98.146.216# 删除主页文件rootmaster30:~# kubectl exec web-85c6ff748f-qwszz -- bash -c rm htdocs/index.html# 观察pod状态RESTARTS次数变位1再次访问rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-85c6ff748f-qwszz1/1 Running113m# 容器删除需要一些时间由参数terminationGracePeriodSeconds设定默认值为30s。# 只有等容器删除并创建完成后才会继续检测rootmaster30:~# curl 10.98.146.216htmlbodyh1It works!/h1/body/html# 清理环境rootmaster30:~# kubectl delete deployments.apps webreadinessProberootmaster30:~# vim deploy-httpGet-readiness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:3selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加readinessProbe部分readinessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.htmlport:80scheme:HTTP# 创建应用rootmaster30:~# kubectl apply -f deploy-httpGet-readiness.yamlrootmaster30:~# kubectl expose deployment web --port80 --target-port80rootmaster30:~# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE web ClusterIP10.98.146.216none80/TCP 4m5s rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-9479dc55c-6bpg71/1 Running02m34s web-9479dc55c-d2gbn1/1 Running02m34s web-9479dc55c-hqh8q1/1 Running02m34s# 准备3个pod主页文件rootmaster30:~# for pod in $(kubectl get pods -o name|awk -F / {print $2}); do kubectl exec $pod -- bash -c echo $pod htdocs/index.html; donerootmaster30:~# for i in {1..90};do curl -s 10.96.180.30;done|sort |uniq -c24web-9479dc55c-6bpg733web-9479dc55c-d2gbn33web-9479dc55c-hqh8q rootmaster30:~# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.73.15:80,10.224.73.34:80,10.224.73.35:80 21m# 删除 web-9479dc55c-6bpg7主页文件rootmaster30:~# kubectl exec -it web-9479dc55c-6bpg7 -- rm -f htdocs/index.html# web 服务的后端没有pod的iprootmaster30:~# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.73.15:80,10.224.73.34:80 23m# 访问svc后端无法看到 web-9479dc55c-6bpg7rootmaster30:~# for i in {1..90};do curl -s 10.96.180.30;done|sort |uniq -c50web240web3# 观察web1状态READY为0RESTARTS数量为0rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-9479dc55c-6bpg70/1 Running08m49s web-9479dc55c-d2gbn1/1 Running08m49s web-9479dc55c-hqh8q1/1 Running08m49s# 清理环境rootmaster30:~# kubectl delete deployments.apps webExecution Checks-exec当使用容器执行检测kubelet代理将在容器内执行命令。返回值是0代表check成功。示例1检测容器自带文件rootmaster30:~# vim deploy-exec-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-cat-/usr/local/apache2/htdocs/index.html# 创建应用rootmaster30:~# kubectl apply -f deploy-exec-liveness.yamlrootmaster30:~# kubectl get podsNAME READY STATUS RESTARTS AGE web-8c9ff9b76-nm6s21/1 Running1(2s ago)18s# 删除主页文件rootmaster30:~# kubectl exec web-8c9ff9b76-nm6s2 -- bash -c rm htdocs/index.html# 观察pod状态RESTARTS次数变位1rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web1/1 Running14m5s示例2检测自定义文件rootmaster30:~# kubectl run busybox --imagebusybox --image-pull-policyIfNotPresent -o yaml --dry-runclient busybox.ymlrootmaster30:~# vim deploy-exec-busybox.ymlapiVersion:v1kind:Podmetadata:creationTimestamp:nulllabels:run:busyboxname:busyboxspec:containers:-image:busyboximagePullPolicy:IfNotPresentname:busybox# 添加args参数args:-/bin/sh--c-touch /tmp/healthy; sleep 10; rm-rf /tmp/healthy; sleep 100#添加livenessProbe参数livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-ls-/tmp/healthydnsPolicy:ClusterFirstrestartPolicy:Alwaysrootmaster30~# kubectl apply -f deploy-exec-busybox.ymlrootmaster30~# kubectl get pods busybox -wNAME READY STATUS RESTARTS AGE busybox1/1 Running1(36s ago)91s rootmaster30~# kubectl delete pod/busybox --forceTCP Socket Checks-tcpSocket当使用TCP socket checkskubelet代理尝试打开容器socket。如果check可以建立连接判定check成功。示例liveness probe使用TCP Socket checkrootmaster30:~# vim deploy-tcpSocket-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10tcpSocket:port:80#部署命令kubectl apply-fweb-deploy.yaml#实时监控 Pod 状态kubectl get pods-lappweb-w#正常状态RunningRESTARTS0#制造故障复现探针失败关键实验操作# 进入podkubectlexec-it$(kubectl get pods-lappweb-oname)--sh# 容器内执行停止httpdkill$(pidof httpd)rootmaster30~# kubectl get pods -l appweb -wNAME READY STATUS RESTARTS AGE web-79869c84fd-29kz61/1 Running012s web-79869c84fd-29kz60/1 Completed045s web-79869c84fd-29kz61/1 Running1(2s ago)46s#采用 tcpSocket 方式对 80 端口进行存活探测。容器正常运行时 TCP 握手成功探针持续通过手动关闭 httpd 服务后 80 端口无法访问连续 3 次探测失败控制器重启容器RESTARTS 计数增加。TCP 探针适合验证应用端口监听状态无需应用内置接口常用于 Web、数据库类服务健康检测。web-79869c84fd-29kz61/1 Running012s# 正常运行就绪web-79869c84fd-29kz60/1 Completed045s# kubelet 检测 livenessProbe 连续失败杀死容器容器进程退出状态短暂变为 Completedweb-79869c84fd-29kz61/1 Running1(2s ago)46s# Deployment 重启容器容器重新拉起就绪RESTARTS 由0变为1Health Check CaseHealth Check 在 Scale Up 中的应用对于多副本应用 当执行Scale Up操作时 新副本会作为backend被添加到Service的负载均衡中 与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段 比如加载缓存数据、 连接数据库等 从容器启动到真正能够提供服务是需要一段时间的。 我们可以通过Readiness探测判断容器是否就绪 避免将请求发送到还没有准备好的backend。Health Check 在滚动更新中的应用Health Check另一个重要的应用场景是Rolling Update。 试想一下 现有一个正常运行的多副本应用 接下来对应用进行更新比如使用更高版本的image Kubernetes会启动新副本 然后发生了如下事件正常情况下新副本需要10秒钟完成准备工作 在此之前无法响应业务请求。由于人为配置错误 副本始终无法完成准备工作比如无法连接后端数据库。如果没有配置Health Check 会出现怎样的情况因为新副本本身没有异常退出 默认的Health Check机制会认为容器已经就绪 进而会逐步用新副本替换现有副本 其结果就是 当所有旧副本都被替换后 整个应用将无法处理请求 无法对外提供服务。 如果这是发生在重要的生产系统上 后果会非常严重。如果正确配置了Health Check 新副本只有通过了探测才会被添加到Service 如果没有通过探测 现有副本不会被全部替换 业务仍然正常进行。环境清理rootmaster30:~# kubectl delete ns health
Kubernetes 健康检查机制详解三类探针与三种探测方法落地实践Kubernetes Health Check环境准备Health CheckProbe TypeChecking MethodsHTTP Checks-httpGetlivenessProbereadinessProbeExecution Checks-execTCP Socket Checks-tcpSocketHealth Check CaseHealth Check 在 Scale Up 中的应用Health Check 在滚动更新中的应用如果没有配置Health Check 会出现怎样的情况环境清理Kubernetes Health Check摘要本文全面介绍了 Kubernetes 中的健康检查机制包括三种探针类型LivenessProbe、ReadinessProbe、StartupProbe和三种检查方法HTTP Checks、Execution Checks、TCP Socket Checks。通过实际示例演示了如何配置和使用这些探针并探讨了健康检查在 Scale Up 和滚动更新等场景中的应用价值。文章还提供了环境准备和清理的完整操作指南帮助读者深入理解 Kubernetes 如何通过健康检查确保应用的高可用性。学习参考配置存活、就绪和启动探针环境准备rootmaster30:~# kubectl create ns healthrootmaster30:~# kubectl config set-context --current --namespace healthHealth Check应用可能会因为各种问题变的unhealthy例如临时连接断开配置错误应用本身错误。kubelet 使用probes探针周期性地监控容器中应用是否为healthy状态进一步决定什么时候要重启容器。 例如当存活探针可以探测到应用死锁应用在运行但是无法继续执行后面的步骤情况进而重启pod有助于提高应用的可用性即使其中存在缺陷。没有探测的情况看一个例子# 创建一个普通 podrootmaster30:~# kubectl run web --imagehub.laoma.cloud/library/httpd --image-pull-policyIfNotPresent[rootlaoma20 health]# kubectl describe pod web|grep ^IP:IP:10.224.73.16 rootmaster30:~# curl 10.224.73.16htmlbodyh1It works!/h1/body/html# 删除主页文件即使pod中应用数据丢失pod状态依然为Runningrootmaster30:~# kubectl exec web -- rm -f htdocs/index.html# 查看主页内容rootmaster30:~# curl 10.224.73.16!DOCTYPE HTML PUBLIC-//W3C//DTD HTML 3.2 Final//ENhtmlheadtitleIndex of //title/headbodyh1Index of //h1ul/ul/body/htmlrootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web1/1 Running051s# 清理环境rootmaster30:~# kubectl delete pod web --forceProbe Typekubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针存活探针和就绪探针成功之前不会重启确保这些探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测避免它们在启动运行之前就被杀掉。LivenessProbe用于确定pod中应用是否处于healthy状态。如果liveness probe检测的状态为unhealthy则控制器将重新启动pod。ReadinessProbe用于确定pod中应用是否可以提供服务。如果返回失败状态则**服务将从endpoints 中删除容器ip地址。**即使容器处于运行状态也不接受代理发过来的请求。StartupProbe用于确定pod是否成功初始化。 如果指定则在成功完成之前不会执行其他探测。如果此探测失败Pod 将重新启动就像 livenessProbe 失败一样。 这可用于在 Pod 生命周期开始时提供不同的探测参数此时加载数据或预热缓存可能需要比稳态操作期间更长的时间。 这无法更新。我们这里不深入讨论StartupProbe。Checking Methods探针检查容器有四种不同的方法httpGet对容器的 IP 地址上指定端口和路径执行 HTTPGET请求。如果响应的状态码大于等于 200 且小于 400则诊断被认为是成功的。exec在容器内执行指定命令。如果命令退出时返回码为 0则认为诊断成功。tcpSocket对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开则诊断被认为是成功的。 如果远程系统容器在打开连接后立即将其关闭这算作是健康的。grpc使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC 健康检查。 如果响应的状态是 “SERVING”则认为诊断成功。我们这里不讨论grpc方法。HTTP Checks-httpGet当使用HTTP Checks控制器使用webhoook判定容器健康情况。如果HTTP的响应码在200-399之间判定check成功。适应范围可以返回HTTP状态码应用。livenessProberootmaster30:~# vim deploy-httpGet-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.html# port填写时间web端口port:80# scheme指定协议HTTP或者HTTPSscheme:HTTPprobe选项说明initialDelaySeconds必选。容器启动后多长时间probe开始生效。timeoutSeconds必选。probe需要多长时间完成。如果超过该值控制器判定probe失败。默认值1s最小值是1秒。periodSeconds可选。检查频率。默认值10s最小值是1秒。successThreshold可选连续成功最少次数后判定probe成功。默认值1最小值是1。failureThreshold可选。连续失败最少次数后判定probe失败。默认值3最小值是1。rootmaster30:~# kubectl apply -f deploy-httpGet-liveness.yamlrootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-85c6ff748f-qwszz1/1 Running012m rootmaster30:~# kubectl describe pod web-85c6ff748f-j92jn|grep ^IP:IP:10.98.146.216# 删除主页文件rootmaster30:~# kubectl exec web-85c6ff748f-qwszz -- bash -c rm htdocs/index.html# 观察pod状态RESTARTS次数变位1再次访问rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-85c6ff748f-qwszz1/1 Running113m# 容器删除需要一些时间由参数terminationGracePeriodSeconds设定默认值为30s。# 只有等容器删除并创建完成后才会继续检测rootmaster30:~# curl 10.98.146.216htmlbodyh1It works!/h1/body/html# 清理环境rootmaster30:~# kubectl delete deployments.apps webreadinessProberootmaster30:~# vim deploy-httpGet-readiness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:3selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加readinessProbe部分readinessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.htmlport:80scheme:HTTP# 创建应用rootmaster30:~# kubectl apply -f deploy-httpGet-readiness.yamlrootmaster30:~# kubectl expose deployment web --port80 --target-port80rootmaster30:~# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE web ClusterIP10.98.146.216none80/TCP 4m5s rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-9479dc55c-6bpg71/1 Running02m34s web-9479dc55c-d2gbn1/1 Running02m34s web-9479dc55c-hqh8q1/1 Running02m34s# 准备3个pod主页文件rootmaster30:~# for pod in $(kubectl get pods -o name|awk -F / {print $2}); do kubectl exec $pod -- bash -c echo $pod htdocs/index.html; donerootmaster30:~# for i in {1..90};do curl -s 10.96.180.30;done|sort |uniq -c24web-9479dc55c-6bpg733web-9479dc55c-d2gbn33web-9479dc55c-hqh8q rootmaster30:~# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.73.15:80,10.224.73.34:80,10.224.73.35:80 21m# 删除 web-9479dc55c-6bpg7主页文件rootmaster30:~# kubectl exec -it web-9479dc55c-6bpg7 -- rm -f htdocs/index.html# web 服务的后端没有pod的iprootmaster30:~# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.73.15:80,10.224.73.34:80 23m# 访问svc后端无法看到 web-9479dc55c-6bpg7rootmaster30:~# for i in {1..90};do curl -s 10.96.180.30;done|sort |uniq -c50web240web3# 观察web1状态READY为0RESTARTS数量为0rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web-9479dc55c-6bpg70/1 Running08m49s web-9479dc55c-d2gbn1/1 Running08m49s web-9479dc55c-hqh8q1/1 Running08m49s# 清理环境rootmaster30:~# kubectl delete deployments.apps webExecution Checks-exec当使用容器执行检测kubelet代理将在容器内执行命令。返回值是0代表check成功。示例1检测容器自带文件rootmaster30:~# vim deploy-exec-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-cat-/usr/local/apache2/htdocs/index.html# 创建应用rootmaster30:~# kubectl apply -f deploy-exec-liveness.yamlrootmaster30:~# kubectl get podsNAME READY STATUS RESTARTS AGE web-8c9ff9b76-nm6s21/1 Running1(2s ago)18s# 删除主页文件rootmaster30:~# kubectl exec web-8c9ff9b76-nm6s2 -- bash -c rm htdocs/index.html# 观察pod状态RESTARTS次数变位1rootmaster30:~# kubectl get podNAME READY STATUS RESTARTS AGE web1/1 Running14m5s示例2检测自定义文件rootmaster30:~# kubectl run busybox --imagebusybox --image-pull-policyIfNotPresent -o yaml --dry-runclient busybox.ymlrootmaster30:~# vim deploy-exec-busybox.ymlapiVersion:v1kind:Podmetadata:creationTimestamp:nulllabels:run:busyboxname:busyboxspec:containers:-image:busyboximagePullPolicy:IfNotPresentname:busybox# 添加args参数args:-/bin/sh--c-touch /tmp/healthy; sleep 10; rm-rf /tmp/healthy; sleep 100#添加livenessProbe参数livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-ls-/tmp/healthydnsPolicy:ClusterFirstrestartPolicy:Alwaysrootmaster30~# kubectl apply -f deploy-exec-busybox.ymlrootmaster30~# kubectl get pods busybox -wNAME READY STATUS RESTARTS AGE busybox1/1 Running1(36s ago)91s rootmaster30~# kubectl delete pod/busybox --forceTCP Socket Checks-tcpSocket当使用TCP socket checkskubelet代理尝试打开容器socket。如果check可以建立连接判定check成功。示例liveness probe使用TCP Socket checkrootmaster30:~# vim deploy-tcpSocket-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10tcpSocket:port:80#部署命令kubectl apply-fweb-deploy.yaml#实时监控 Pod 状态kubectl get pods-lappweb-w#正常状态RunningRESTARTS0#制造故障复现探针失败关键实验操作# 进入podkubectlexec-it$(kubectl get pods-lappweb-oname)--sh# 容器内执行停止httpdkill$(pidof httpd)rootmaster30~# kubectl get pods -l appweb -wNAME READY STATUS RESTARTS AGE web-79869c84fd-29kz61/1 Running012s web-79869c84fd-29kz60/1 Completed045s web-79869c84fd-29kz61/1 Running1(2s ago)46s#采用 tcpSocket 方式对 80 端口进行存活探测。容器正常运行时 TCP 握手成功探针持续通过手动关闭 httpd 服务后 80 端口无法访问连续 3 次探测失败控制器重启容器RESTARTS 计数增加。TCP 探针适合验证应用端口监听状态无需应用内置接口常用于 Web、数据库类服务健康检测。web-79869c84fd-29kz61/1 Running012s# 正常运行就绪web-79869c84fd-29kz60/1 Completed045s# kubelet 检测 livenessProbe 连续失败杀死容器容器进程退出状态短暂变为 Completedweb-79869c84fd-29kz61/1 Running1(2s ago)46s# Deployment 重启容器容器重新拉起就绪RESTARTS 由0变为1Health Check CaseHealth Check 在 Scale Up 中的应用对于多副本应用 当执行Scale Up操作时 新副本会作为backend被添加到Service的负载均衡中 与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段 比如加载缓存数据、 连接数据库等 从容器启动到真正能够提供服务是需要一段时间的。 我们可以通过Readiness探测判断容器是否就绪 避免将请求发送到还没有准备好的backend。Health Check 在滚动更新中的应用Health Check另一个重要的应用场景是Rolling Update。 试想一下 现有一个正常运行的多副本应用 接下来对应用进行更新比如使用更高版本的image Kubernetes会启动新副本 然后发生了如下事件正常情况下新副本需要10秒钟完成准备工作 在此之前无法响应业务请求。由于人为配置错误 副本始终无法完成准备工作比如无法连接后端数据库。如果没有配置Health Check 会出现怎样的情况因为新副本本身没有异常退出 默认的Health Check机制会认为容器已经就绪 进而会逐步用新副本替换现有副本 其结果就是 当所有旧副本都被替换后 整个应用将无法处理请求 无法对外提供服务。 如果这是发生在重要的生产系统上 后果会非常严重。如果正确配置了Health Check 新副本只有通过了探测才会被添加到Service 如果没有通过探测 现有副本不会被全部替换 业务仍然正常进行。环境清理rootmaster30:~# kubectl delete ns health
