本篇文章1653字，读完约4分钟
阿里云国际站经销商，主营阿里云，腾讯云，华为云，亚马逊aws，谷歌云gcp,微软云az，免费开户，代充值优惠大，联系客服飞机@jkkddd
背景信息
K8s中的健康检查主要分为两种：
Liveness：存活检测，负责判断容器是否需要重启。
Readiness：就绪检测，负责判断容器是否需要承接流量。
核心参数：
检查方式：TCP/HTTP/CMD。
延迟时间：容器启动后，多久开始检测。
检查周期：决定检查的频率，灵敏度相关。
超时时间：检查的超时等待时间。
成功阈值：探针在失败后，被视为成功的最小连续成功数。Liveness必须设置为1。
失败阈值：判定总体失败的连续失败数。
参数详解（进阶版）
延迟时间
对于Livness的配置，需要重点理解参数“延迟时间”，其作用是帮助健康检查探针在合适的时候去探测业务容器的状态。如果Livness健康检查在不合适的时候去探测（延迟时间过短），会导致不断重启这一严重后果。
例如，一个Java应用启动可能需要耗时2分钟，如果全部按照默认配置，即延迟时间为10秒，检查周期为30秒，失败阈值为3，该应用将永远不可能启动成功。因为在上述设置中，Livness探针的三次健康检查全部是在应用启动完毕之前完成的，而应用启动完毕之前进行健康探测，持续失败就是预期中的结果。所以，该应用必然会不断重启。
因此，当初次部署应用时，如果无法确定应用的启动时间，可以尽量将延迟时间调长一点（例如5分钟），等应用成功启动后，再根据业务日志确定大致的启动耗时来修正延迟时间。需要注意的是，延迟时间过长也存在弊端，因为可能会让整个发布时间过长。
TCP与HTTP方式的选择
Liveness另一个容易踩坑的点是检查方式，用户需要为Readiness与Liveness配置不同的检查方式。但是，许多用户为了省事，将Readiness与Liveness设置成相同的检查，其实这是非常危险的行为。因为Liveness与Readiness是两种完全不同的探针，有着完全不同的作用。有时候业务由于流量拥塞导致不可用，只需摘除当前实例的流量，无需重启容器。当前请求被正常处理完成后，就可以重新负载流量并接收请求。但是，如果此时重启容器，可能会产生以下影响：
当前已有请求无法被顺利处理。
由于当前实例重启，可能会导致更长的时间无法负载流量，甚至出现雪崩。
例如，对于Java应用，Spring Boot框架提供了内置的健康检查。该健康检查会检测多个组件的情况，例如与Redis、Nacos等组件连接与心跳是否正常，并判断是否需要重启应用。由于网络抖动以及相关组件服务的可用性无法完全确定，这类异常无法成为当前应用是否需要重启的判断依据。
因此，为了减少因下游链路的抖动造成预期外的实例重启，必须区分Liveness与Readiness。如果不方便单独实现一个接口来检查应用自身的情况，可以通过Liveness采用TCP、Readiness采用HTTP的方式探测。重启这一操作需要谨慎对待，因此检测容错率更高的TCP方式更适合Liveness。HTTP方式的检测更容易反映业务的真实处理情况，更适合Readiness这一处理流量的检测。
失败阈值与成功阈值
对于Livenss而言，其实只有一个动作，即失败重启。因此，成功阈值固定为1，且不可修改（由于成功没有显式动作，所以成功阈值大于1也没有意义）。而失败阈值默认为3，即连续失败三次，会认为真正失败，并开始重启容器。
对于Readiness而言，其实有两种动作，成功则接入流量，失败则切出流量。因此，为保证可用性，成功阈值与失败阈值都推荐设置为1，即当出现检测失败时立即切出流量，从而尽可能短时间内避免流量有损，而当检测成功（即应用已经做好接收流量的准备）后立即切入流量。但是，快速切流可能导致剩余实例平均网络负载进一步增加，因此建议配合指标弹性一起使用。
标题：阿里云账号实名注册，阿里云服务器购买
地址：http://www.ok-sl.com/xwzx/32414.html
