乐趣区

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

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

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

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

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

囧么肥事 - 胡言乱语

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

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 权威指南 PDF
链接:https://pan.baidu.com/s/11huL… 提取码:sa88

k8s 系列所有问题更新记录:GitHub Gitee

退出移动版