探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?

探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?

探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?

线上多个服务应用陷入了死循环,大量服务访问不通,陷入死循环的应用长时间搁置,并没有进行自愈。

k8s应用容器没有检测到应用陷入了故障,容器未及时重启?

探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?

囧么肥事-胡说八道

探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?

探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?

探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?

弄清楚为什么要使用容器探针?

kubernetes 集群的好处是可以监测应用容器健康状态,在必要时候进行故障自愈。Pod管家一旦调度到某个节点,该节点上的Kubelet就会运行Pod的容器。

如果应用程序中有一个导致它每隔一段时间就会崩溃的bug,Kubernetes会自动重启应用程序,所以即使应用程序本身没有做任何特殊的事,在Kubernetes中运行也能自动获得自我修复的能力。

默认情况下,kubelet根据容器运行状态作为健康依据,不能监控容器中应用程序状态,例如程序假死。这就会导致无法提供服务,丢失流量。因此引入健康检查机制确保容器健康存活。

Pod通过两类探针来检查容器的健康状态。分别是LivenessProbe(存活探针)和 ReadinessProbe(就绪探针)。

还有一种启动探针监控应用启动状态:StartupProbe(启动探针)

  • livenessProbe:指示容器是否正在运行。如果存活态探针失败,则 kubelet 会杀死容器, 并且容器将根据其重启策略决定未来。如果容器不提供存活探针, 则默认状态为 Success

  • readinessProbe:指示容器是否准备好为请求提供服务。如果就绪态探针失败, 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针,则默认状态为 Success

  • startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被 禁用,直到此探针成功为止。如果启动探针失败,kubelet 将杀死容器,而容器依其重启策略进行重启。 如果容器没有提供启动探针,则默认状态为 Success。

特殊场景如何选择正确的探针?

kubelet 使用存活探针来知道什么时候要重启容器

例如,存活探针可以捕捉到死锁(应用程序在运行,但是无法继续执行后面的步骤)。 这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。

kubelet 使用就绪探针判断容器什么时候准备好了并可以开始接受请求流量

当一个 Pod 内的所有容器都准备好了,才能把这个 Pod 看作就绪了。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 在 Pod 还没有准备好的时候,会从 Service 的负载均衡器中被剔除的。

kubelet 使用启动探针监测应用程序容器什么时候启动了

如果配置了这类探针,就可以控制容器在启动成功后再进行存活性和就绪检查, 确保这些存活、就绪探针不会影响应用程序的启动。 这可以用于对慢启动容器进行存活性检测,避免它们在启动运行之前就被杀掉。

何时该使用存活态探针?

如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃,则不一定需要存活态探针; kubelet 将根据 Pod 的restartPolicy 自动执行修复操作。

如果你希望容器在探测失败时被杀死并重新启动,那么请指定一个存活态探针, 并指定restartPolicy 为 "Always" 或 "OnFailure"。

何时该使用就绪态探针?

如果要仅在探测成功时才开始向 Pod 发送请求流量,请指定就绪态探针。

在这种情况下,就绪态探针可能与存活态探针相同,但是规约中的就绪态探针的存在意味着 Pod 将在启动阶段不接收任何数据,并且只有在探针探测成功后才开始接收数据。

如果你希望容器能够自行进入维护状态,也可以指定一个就绪态探针

检查某个特定于就绪态的不同于存活态探测的端点

如果你的应用程序对后端服务有严格的依赖性,你可以同时实现存活态和就绪态探针。

当应用程序本身是健康的,存活态探针检测通过后,就绪态探针会额外检查每个所需的后端服务是否可用。

这可以帮助你避免将流量导向只能返回错误信息的 Pod。

如果你的容器需要在启动期间加载大型数据、配置文件或执行迁移,你可以使用 启动探针。

然而,如果你想区分已经失败的应用和仍在处理其启动数据的应用,你可能更倾向于使用就绪探针。

说明:

请注意,如果你只是想在 Pod 被删除时能够排空请求,则不一定需要使用就绪态探针; 在删除 Pod 时,Pod 会自动将自身置于未就绪状态,无论就绪态探针是否存在。 等待 Pod 中的容器停止期间,Pod 会一直处于未就绪状态。

何时该使用启动探针?

对于所包含的容器需要较长时间才能启动就绪的 Pod 而言,启动探针是有用的。 你不再需要配置一个较长的存活态探测时间间隔,只需要设置另一个独立的配置选定, 对启动期间的容器执行探测,从而允许使用远远超出存活态时间间隔所允许的时长。

如果你的容器启动时间通常超出 initialDelaySeconds + failureThreshold × periodSeconds 总值,你应该设置一个启动探测,对存活态探针所使用的同一端点执行检查。 periodSeconds 的默认值是 10 秒。你应该将其 failureThreshold 设置得足够高, 以便容器有充足的时间完成启动,并且避免更改存活态探针所使用的默认值。 这一设置有助于减少死锁状况的发生。

例如使用启动探针保护慢启动容器

有时候,会有一些现有的应用程序在启动时需要较多的初始化时间

要不影响对引起探针死锁的快速响应,这种情况下,设置存活探针参数是要技巧的。

技巧就是使用一个命令来设置启动探针,针对HTTP 或者 TCP 检测,可以通过设置 failureThreshold * periodSeconds 参数来保证有足够长的时间应对糟糕情况下的启动时间。

探针执行的三种方式?

Probe 是由 kubelet对容器执行的定期诊断。 要执行诊断,kubelet 有三种类型的处理程序:

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

每次探测都将获得以下三种结果之一:

  • Success(成功):容器通过了诊断。
  • Failure(失败):容器未通过诊断。
  • Unknown(未知):诊断失败,因此不会采取任何行动。

探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?


《Kubernetes-企业级容器应用托管》-持续胡说八道

第一段:推荐阅读:【云原生新时代弄潮儿k8s凭什么在容器化方面独树一帜?】

第二段:推荐阅读:【趁着同事玩游戏偷偷认识k8s一家子补补课】

第三段:推荐阅读:【Kubernetes家族容器小管家Pod在线答疑❓】

第四段:推荐阅读:【同事提出个我从未想过的问题,为什么Kubernetes要"多此一举"推出静态Pod概念?】

第五段:推荐阅读:【探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?】

第六段:待更新?推荐休闲阅读:【囧么肥事】

上一篇:k8s pod故障分类与排查


下一篇:leetcode-46. 全排列-不含重复元素的全排列-dfs-swap