1. 13.2 应用的健康检查

1.1.1. Liveness探测

Kubernetes有两种探测机制,Liveness和Readiness,配置都是相似的,只是实现的功能不同。 Liveness探测是针对Pod健康状态的探测,类似于集群中的健康检查,用户可以自定义这个健康检查的条件,如果探测失败,Kubernetes将会重启容器。 如果您希望容器在探测失败时被杀死并重新启动,那么请指定一个Liveness配置,并指定restartPolicy 为 Always 或 OnFailure。 配置案例

livenessProbe:
exec:
    command:
    - ps aux | grep nginx
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 3

1.1.2. Readiness探测

Readiness探测是探测Pod是否准备好对外提供访问,例如我们在Pod里面运行一个Tomcat的容器,里面运行了一个Jenkins的应用,那么等Jenkins完全启动能提供服务可能需要1分钟,所以在在1分钟之前是不能提供给用户访问的,也就是不能加入Service的负载均衡中,这个就靠Readiness探测来控制。 Readiness用来控制告诉Kubernetes什么时间可以将容器加入到Service的负载均衡中,配置方法和Liveness一样,只需要修改livennessProbe替换为readinessProbe即可。

1.2. 健康检查的方法

Kubernetes的健康检查是由运行在各个Node上的kubelet来完成的,kubelet目前支持以下三种健康检查的方法:

  • ExecAction:在容器中执行指定的命令。如果命令退出时状态码为0,则认为诊断成功。
  • TCPSocketAction:对指定端口上容器的IP地址执行TCP检查。如果端口是打开的,则认为诊断是成功的。
  • HTTPGetAction:对指定端口和路径上容器的IP地址执行HTTP Get请求。如果响应的状态码大于或等于200,小于400,则认为诊断是成功的。

以上三种健康检查的方法会有三种返回结果:

  • Success:成功,容器通过诊断。
  • Failure:失败,容器诊断失败。
  • Unknown:探测失败,无法执行探测,所以不应该采取任何行动。

    针对于探针有以下配置参数,需要注意不管是Liveness还是Readiness探测,探针的使用都是相同的,唯一的不同是探测完毕后,执行操作的不同。

  • initialDelaySeconds: 探测的延迟时间,单位是秒。也就是说在容器启动多少秒之后开始进行第一次探测,例如你启动一个Java的应用需要50秒,那么这个值就需要大于50s。所以这个值是需要根据应用的具体情况来设置。
  • periodSeconds:探测执行的周期时间,单位是秒。是指每隔多长时间执行一次探测,频率越高,发现故障的时间也就越短,并不是越短越好。如果应用服务不够稳定,太高的频率反而会导致很多你认为的“误报”。默认是10秒,最小值是1秒。
  • timeoutSeconds: 探测超时时间,单位是秒,执行探测如果超过这个时间没有返回结果,变意味着探测的结果是失败。默认为1秒。最小值是1秒。
  • failureThreshold:探测成功后,最少连续探测失败多少次才被认定为失败。这个是Kubernetes将在放弃之前尝试失败阈值时间。放弃生命探测意味着重新启动Pod。一旦准备就绪,Pod将被标记为未准备就绪。默认为3。最小值是1。
  • successThreshold: 在探测失败后,最少连续探测成功多少次才被认定为成功。默认为1,也就是必须探测成功1次,才能认为状态恢复,最小值是1。
Copyright © 赵班长@新运维社区 2019 all right reserved,powered by Gitbook该文件修订时间: 2019-11-07 21:35:37

results matching ""

    No results matching ""