Kubernetes-05-容器健康检测

• Liveness探测
• Readiness探测
• Liveness和Readiness
• HealthCheck的功能

关于健康检测这边，会具体讲述K8S自身如何对Pod进行健康存活检测，如何可以对应用进行存活和健康检测。让应用在K8S上实现完美的无缝切换，实现更为安全、零停服的版本滚动升级

K8S默认的健康检测，主要监测Pod启动的进程，进程退出返回码非0就是代表故障，需要根据重启策略执行
restartPolicy： 默认Always，可选OnFailure

但是经常应用程序的故障场景是，比如内存溢出，系统进程还在但无法对外提供服务了，这种情况K8S的默认规则就无法识别，需要使用
Liveness探测

Liveness探测

使用livenessProbe指定自定义健康的条件:

• initialDelaySeconds是程序初始化后多久开始做Liveness探测
• periodSeconds 探测检测周期

Readiness探测

• Liveness是告诉容器什么情况pod需要通过重启后自愈
• Readiness是告诉容器什么情况下应用已经启动完成具备对外提供服务的能力
• 使用ReadinessProbe指定自定义健康的条件
  • initialDelaySeconds是程序初始化后多久开始做Readiness探测
  • periodSeconds 探测检测周期
• Pod的状态会从not ready到ready，ready后就代表可以对外提供服务

Liveness和Readiness

采用一致的配置格式，可以使用exec:command 或者httpGet 进行配置，httpGet返回值在200_{400之间是正常的，如果非200}400就是非就绪，连续3次失败就会将服务从负载均衡中移除，无法再访问，直到下次成功再加入

readinessProbe:
  httpGet:
    schema: HTTP
    path: /health
    port:8080
  initialDelaySeconds: 10
  periodSeconds: 5  

springboot 2.3.X 自动兼容K8S的Liveness & Readiness探测

HealthCheck的功能

在ScaleUp中，当一个Pod符合Readiness验证，才加入负载均衡中对外提供服务，避免无效的请求

在RollingUpdate中，可以避免服务更新期间应用尚未启动加载完全就认为Pod启动完成，持续替换，导致可能最终无法对外提供服务。Redisness探测可以检测到应用真实能提供服务后，再向后逐步替换，达到真正的不停服。异常的副本无法加入负载均衡，不会对外提供服务。

maxSurge:
参数控制滚动更新过程中副本总数超过DESIRED的上限
因为DESIRED是目标可用值，滚动更新中最终可用的Pod数，在感动更新的过程中，会新增并行更新的Pod数。向上取整，最大默认是Desired数量的*25%，控制初始创建的新副本数
资源充足可以配置多一些，那整体资源占用会多，但更新流程变快

maxUnavailable:
参数控制滚动更新过程中不可用副本占DESIRED的最大比例，向下取整，最大默认是Desired*25%，控制初始销毁的旧副本数

strategy:
  rollingUpdate:
    maxSurge: 35%
    maxUnavailable: 35%