Kubernetes的健康检查liveness-readiness-startup探针.md
引入
在默认情况下，当 Pod 中的所有容器启动时，Kubernetes 开始向 Pod 发送流量，并在崩溃时重新启动容器。
但是如果Pod中进程启动需要一定的时间，比如springboot项目，容器启动成功后，springboot启动需要一些初始化工作，连接外部数据库，连接外部中间件等等，需要几秒，几十秒，甚至一分多钟才能启动。
Kubernetes 在设计上已经考虑到了这点，它可以通过容器探针来检查服务是否可用。
liveness probe（存活探针）
Kubelet使用liveness probe（存活探针）来确定何时重启容器。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定是否重启。如果不提供存活探针， 则默认状态为 Success。
spec:
containers:
- image: 'k8s.gcr.io/liveness'
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 8080
scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1periodSeconds 字段指定了 kubelet 每隔 10 秒执行一次存活探测。
timeoutSeconds字段指定了探测的超时时间是1秒。
failureThreshold字段指定了探测3次失败，才认为失败。
successThreshold字段指定了探测1次成功，就认为成功。
initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 30 秒，这个值一定要根据实际应用启动实际调整，设置过小有可能会引起Pod无限重启。
存活探针的主要用途是，将仍然处在运行状态但却无法正常提供服务的Pod进行重启，对于有bug的程序进行重启，尝试进行恢复。
readiness probe（就绪探针）
kubelet 使用readiness probe（就绪探针）来了解容器何时准备好开始接受流量。通过了就绪探针检查的Pod就可以处于Ready状态。如果不设置就绪态探针，则默认状态为 Success 通过。
就绪探针的一个用途是控制哪些 Pod 作为服务service的后端。当 Pod 未通过就绪探针检查时，它会从服务负载均衡器中删除。由于ingress依赖于service，所以使用了ingress的项目必须开启就绪探针；
就绪探针的另一个用途就是Rolling Updates（滚动发布），设置了就绪探针以后，Pod处于Ready状态，才会进行下一个滚动，否则只要Pod是Running状态(Ready状态会和Running状态一致)就会滚动。
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5startup probe（启动探针）
启动探针用来探测Pod内服务是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。 如果没有提供启动探测，则默认状态为 Success。
一般来讲，对于需要较长时间才能启动就绪的 Pod 而言，启动探针是有用的。 你不再需要配置一个较长的存活态探测时间间隔，只需要设置另一个独立的配置选定， 对启动期间的容器执行探测就可以了。
这个功能基本上和存活探针的initialDelaySeconds 作用类似。
参考资料
转载请注明：IPCPU-网络之路 » Kubernetes的健康检查liveness-readiness-startup探针