健康检查
健康检查（Health Check）可⽤于服务运⾏的状态监控，⽐如腾讯旗下的DNSPOD的D监控，要求配置⼀个访问路径以判断⽹站是否可以正常访问实际上就是⼀个健康检查，当发现健康检查失败时会发送⼀个邮件通知或者短信来告知⽹站管理员进⾏维修。
K8S流量转发
⽽在现代⼀些分布式系统中，⽤户访问不再是单台主机，⽽是⼀个由成百上千台实例组成的集，⽤户请求通过负载均衡器分发到不同的实例，负载均衡帮助解决单台服务器的访问压⼒，同时提⾼了系统的⾼可⽤性，⽽健康检查常常作为当前实例是否“可⽤”的判断标准。即：当系统发现某台实例健康检查不通过，负载均衡器将不会把流量导向该实例。 现在的云服务⼚商⽐如AWS⼀般都为负载均衡配备了健康检查，⽽Kubernetes提供了两种探针来检查容器的状态，Liveliness和Readiness，根据官⽅⽂档，Liveliness探针是为了查看容器是否正在运⾏，翻译为存活探针（livenessProbe），Readiness探针是为了查看容器是否准备好接受HTTP请求，翻译为就绪探针（readinessProbe）。 在Kubernetes中，Pod是Kubernetes创建及管理的最⼩的可部署的计算单元，⼀个Pod由⼀个或者多个容器（Docker，rocket等等）组成，这些容器共享内存，⽹络以及运⾏容器的⽅式。
在Kubernetes上下⽂中存活探针和就绪探针被称作健康检查。这些容器探针是⼀些周期性运⾏的⼩进程，这些探针返回的结果（成功，失败或者未知）反映了容器在Kubernetes的状态。基于这些结果，Kubernetes会判断如何处理每个容器，以保证弹性，⾼可⽤性和更长的正常运⾏时
间。
就绪探针
就绪探针旨在让Kubernetes知道你的应⽤是否准备好为请求提供服务。Kubernetes只有在就绪探针通过才会把流量转发到Pod。如果就绪探针检测失败，Kubernetes将停⽌向该容器发送流量，直到它通过。
存活探针
Liveness探测器是让Kubernetes知道你的应⽤是否活着。如果你的应⽤还活着，那么Kubernetes就让它继续存在。如果你的应⽤程序已经死了，Kubernetes将移除Pod并重新启动⼀个来替换它。
⼯作过程
让我们看看两个场景，来看看就绪探针和存活探针怎样帮助我们构建更⾼可⽤的的系统。
就绪探针
⼀个应⽤往往需要⼀段时间来预热和启动，⽐如⼀个后端项⽬的启动需要连接数据库执⾏数据库迁移等等，⼀个Spring项⽬的启动也需要依赖Java虚拟机。即使该过程已启动，您的服务在启动并运⾏之前也⽆法运⾏。应⽤在完全就绪之前不应接收流量，但默认情况下，Kubernetes会在容器内的进程启
动后⽴即开始发送流量。通过就绪探针探测，直到应⽤程序完全启动，然后才允许将流量发送到新副本。
就绪探针的⼯作过程
存活探针
让我们想象另⼀种情况，当我们的应⽤在成功启动以后因为⼀些原因“宕机”，或者遇到死锁情况，导致它⽆法响应⽤户请求。
在默认情况下，Kubernetes会继续向Pod发送请求，通过使⽤存活探针来检测，当发现服务不能在限定时间内处理请求（请求错误或者超时），就会重新启动有问题的pod。
存活探针的⼯作过程
探针类型
探针类型是指通过何种⽅式来进⾏健康检查，K8S有三种类型的探测：HTTP，Command和TCP。
HTTP
HTTP探测可能是最常见的探针类型。即使应⽤不是HTTP服务，也可以创建⼀个轻量级HTTP服务器来响应探测。⽐如让Kubernetes通过HTTP 访问⼀个URL，如果返回码在200到300范围内，就将应⽤程序标记为健康状态，否则它被标记为不健康。
更多关于HTTP探测可参考这⾥。
命令
对于命令探测，是指Kubernetes在容器内运⾏命令。如果命令以退出代码0返回，则容器将标记为正常。否则，它被标记为不健康。
更多关于命令探测可参考这⾥。
TCP
最后⼀种类型的探测是TCP探测，Kubernetes尝试在指定端⼝上建⽴TCP连接。如果它可以建⽴连接，容器被认为是健康的; 如果它不能被认为是不健康的。这常⽤于对gRPC或FTP服务的探测。
更多关于TCP探测可参考这⾥。
初始探测延迟
我们可以配置K8S健康检查运⾏的频率，检查成功或失败的条件，以及响应的超时时间。可参考有关配置探针的⽂档。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议