在Kubernetes中,可以为Pod里的容器定义一个健康检查探针(Probe),这样Kubernetes会根据这个Probe的返回值决定这个容器的状态,而不是直接以容器是否允许(来自Docker返回的信息)作为依据。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. labels:
  5. test: liveness
  6. name: test-liveness-exec
  7. spec:
  8. containers:
  9. - name: liveness
  10. image: busybox
  11. args:
  12. - /bin/sh
  13. - -c
  14. - touch /tmp/healthy; sleep ; rm -rf /tmp/healthy; sleep
  15. livenessProbe:
  16. exec:
  17. command:
  18. - cat
  19. - /tmp/healthy
  20. initialDelaySeconds:
  21. periodSeconds:

  这个Pod的容器在启动之后做的第一件事是在/tmp目录下创建一个healthy文件,以此作为自己已经正常运行的标识,而30s过后它会把这个文件删除掉。同时还定义了一个livenessProbe,类型是exec,它会在容器启动后执行指定的命令:“cat /tmp/healthy”,如果这个文件存在,这条命令返回值就是0,Pod就会认为这个容器不仅已经启动,而且是健康的,这个健康检查在启动5s后开始执行,每5s执行一次。

  1. $ kubectl create -f test-liveness-exec.yaml
  2. $ kubectl get pod
  3. NAME READY STATUS RESTARTS AGE
  4. test-liveness-exec / Running 10s
  5.  
  6. ####30s后
  7. $ kubectl describe pod test-liveness-exec
  8. FirstSeen LastSeen Count From SubobjectPath Type Reason Message
  9. --------- -------- ----- ---- ------------- -------- ------ -------
  10. 2s 2s {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
  11. $ kubectl get pod test-liveness-exec
  12. NAME READY STATUS RESTARTS AGE
  13. liveness-exec / Running 1m

  可以看到,健康检查报告容器不健康,但是Pod保存了running状态,这是为什么呢?

  认真看可以发现。RESTARTS字段已经变成1了,即这个异常的容器已经被Kubernetes重启了,在这个过程中,Pod保存Running状态不变。Kubernetes没有Docker的Stop语义,所以虽然是重启,实际却是重新创建了容器,这个功能就是Kubernetes里的Pod恢复机制(restartPolicy),它是Pod的Spec部分的一个标准字段(pod.spec.restartPolicy),默认值为Always,作为用户可以设置Pod的恢复策略

    • Always:任何情况下,只要容器不在运行状态,就自动重启容器(合理设置,如果只计算1+1=2,计算完成后退出,强制重启毫无意义)
    • OnFailure:只在容器异常时才自动重启容器
    • Never:从来不重启容器(如要关心容器退出后的日志、文件和目录,就需要设置为NEVER,否则可能丢失)

  Pod的恢复过程,永远都是发送在当前节点上,而不会跑到别的节点上去,即如果这个宿主机宕机了,这个pod也不会主动迁移到其他节点上去。如果想让Pod出现在其他可用节点上,就必须用Deployment这样的控制器来管理Pod。

  Kubernetes中restartPolicy和Pod里容器的状态以及Pod状态的对应关系的基本设计原理有两个:

    • 只要Pod的restartPolicy指定的策略允许重启异常的容器(如Always),那么这个Pod就会保持running状态,并进行容器重启,否则Pod会进入Failed状态。
    • 对于包含多个容器的Pod,只有它里面所有的容器都进入异常状态后,Pod才会进入Failed状态,在此之前,Pod都是running状态,此时Pod的REDY字段会显示正常容器的个数。

  所以假如一个Pod里只有一个容器,然后这个容器异常退出了,那么只有当restartPolicy=Never时,这个Pod才会进入Failed状态,而其他情况下,由于kubernetes都可以重启这个容器,所以Pod状态保持running不变。如果这个Pod有多个容器,仅有一个容器异常退出,它始终保持Running状态,哪怕即使restartPolicy=Never,也只有当容器也异常退出之后,这个Pod才会进入Failed状态。

  除了在容器中执行命令外,livenessProbe也可以定义为发起HTTP或者TCP请求的方式,定义格式如下:

  1. ...
  2. livenessProbe:
  3. httpGet:
  4. path: /healthz
  5. port:
  6. httpHeaders:
  7. - name: X-Custom-Header
  8. value: Awesome
  9. initialDelaySeconds:
  10. periodSeconds:
  1. ...
  2. livenessProbe:
  3. tcpSocket:
  4. port:
  5. initialDelaySeconds:
  6. periodSeconds:

[Kubernetes]容器健康检查和恢复机制的更多相关文章

  1. nginx 健康检查和负载均衡机制分析

    nginx 是优秀的反向代理服务器,这里主要讲它的健康检查和负载均衡机制,以及这种机制带来的问题.所谓健康检查,就是当后端出现问题(具体什么叫出现问题,依赖 于具体实现,各个实现定义不一样),不再往这 ...

  2. 分析NGINX 健康检查和负载均衡机制

    nginx 是优秀的反向代理服务器,这里主要讲它的健康检查和负载均衡机制,以及这种机制带来的问题.所谓健康检查,就是当后端出现问题(具体什么叫出现问题,依赖于具体实现,各个实现定义不一样),不再往这个 ...

  3. 【kubernetes入门到精通】Kubernetes的健康监测机制以及常见ExitCode问题分析「探索篇」

    kubernetes进行Killed我们服务的问题背景 无论是在微服务体系还是云原生体系的开发迭代过程中,通常都会以Kubernetes进行容器化部署,但是这也往往带来了很多意外的场景和情况.例如,虽 ...

  4. Kubernetes容器集群管理环境 - 完整部署(上篇)

    Kubernetes(通常称为"K8S")是Google开源的容器集群管理系统.其设计目标是在主机集群之间提供一个能够自动化部署.可拓展.应用容器可运营的平台.Kubernetes ...

  5. K8S节点异常怎么办?TKE"节点健康检查和自愈"来帮忙

    节点健康检测 意义 在K8S集群运行的过程中,节点常常会因为运行时组件的问题.内核死锁.资源不足等各种各样的原因不可用.Kubelet默认对节点的PIDPressure.MemoryPressure. ...

  6. Pod 健康检查和服务可用性检查

    Kubernetes 对 Pod 的健康状态可以通过两类探针来检查:LivenessProbe 和 ReadinessProbe,kubelet 定期执行这两类探针来针对容器的健康状况. Livene ...

  7. kubernetes容器编排系统介绍

    版权声明:本文由turboxu原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/152 来源:腾云阁 https://www. ...

  8. 一文带你看透kubernetes 容器编排系统

    本文由云+社区发表 作者:turboxu Kubernetes作为容器编排生态圈中重要一员,是Google大规模容器管理系统borg的开源版本实现,吸收借鉴了google过去十年间在生产环境上所学到的 ...

  9. Kubernetes容器上下文环境

    目录贴:Kubernetes学习系列 下面我们将主要介绍运行在Kubernetes集群中的容器所能够感知到的上下文环境,以及容器是如何获知这些信息的. 首先,Kubernetes提供了一个能够让容器感 ...

随机推荐

  1. CF1062D Fun with Integers

    思路: 找规律. 实现: #include <bits/stdc++.h> using namespace std; typedef long long ll; int main() { ...

  2. leetcode128 Longest Consecutive Sequence

    思路: 维护一个unordered_map,key是每个连续区间的端点,value是该区间的长度. 实现: class Solution { public: int longestConsecutiv ...

  3. Python实现扫描作业配置自动化

    持续集成平台接入扫描作业是一项繁琐而又需要细致的工作,于是趁着闲暇时间,将代码扫描作业用Python代码实现了配置自动化. 每次配置作业的过程中,都会在checkcode1或者checkcode3上 ...

  4. 增加和减少mongodb复制集中的节点

    MongoDB Replica Sets不仅提供高可用性的解决方案,同时也提供负载均衡的解决方案,增减 Replica Sets节点在实际应用中非常普通.例如,当应用的读压力暴增时,3台节点的环境已不 ...

  5. HDU 5469 Antonidas (树形DP,暴力)

    题意: 给一棵n节点的树图,每个点都是一个小写字母,要求找到两个点(a,b),从a->b的路径上形成了一个字符串为s.给出s,问是否存在这样的点对. 思路: 考虑一个点,要么从该点出发,要么在该 ...

  6. ZOJ 3627 Treasure Hunt II (贪心,模拟)

    题意:有n个城市并排着,每个城市有些珠宝,有两个人站在第s个城市准备收集珠宝,两人可以各自行动,但两人之间的距离不能超过dis,而且每经过一个城市就需要消耗1天,他们仅有t天时间收集珠宝,问最多能收集 ...

  7. HDU 1171 Big Event in HDU 杭电大事件(母函数,有限物品)

    题意: 分家问题,对每种家具都估个值,给出同样价值的家具有多少个,要求尽可能平分,打印的第一个数要大于等于第二个数. 思路: 可以用背包做,也可以用母函数.母函数的实现只需要注意一个点,就是每次以一种 ...

  8. Invalid bound statement (not found): com.ros.dao.LogMapper.insert

    org.apache.ibatis.binding.BindingException: Invalid bound statement (not found): com.ros.dao.LogMapp ...

  9. Cordova应用的JavaScript代码和自定义插件代码的调试

    我之前写过三篇Cordova相关的技术文章.当我们使用Cordova将自己开发的前端应用打包安装到手机上后,可能会遇到需要调试Cordova应用的时候. 本文就介绍Cordova应用的调试步骤. 如果 ...

  10. Java-NestedClass(Interface).

    内部类(Nested Class) 内部类:即在一个类中还包含着另外一个类,一般是作为匿名类或者是使用数据隐藏时使用的.例子: //内部类 class Out{ private int age = 1 ...