当kubernetes重新启动容器或扩展集群时会发生什么？

问题描述

我们正在使用 Helm Chart 在 Kubernetes 集群中部署应用程序。

我们有状态服务和无头服务。为了初始化mTLS，我们创建了一个'job'类型，并且在'command'中传递了shell和python脚本作为参数。并创建了一种“ cronjob”类来更新证书。

我们在'docker image'内写了'docker-entrypoint.sh'进行一些初始化工作并生成TLS证书。

要问的问题：

• 谁（Helm Chart / Kubernetes）负责扩展/监视/重新启动容器？
• 如果pod失败/重新启动，是否部署新的docker映像？
• 在容器失败/重启后，docker ENTRYPOINT 是否将执行？
• 如果容器重新启动，'job'和'cronjob'是否执行？

Kubernetes还采取了哪些其他步骤？您还会分享容器见解吗？

解决方法

除非您在Pod spec中设置restartPolicy: Never，否则默认情况下，Kubernetes而不是Helmer将重新启动失败的容器

重新启动容器与第一次启动完全相同。因此，在重新启动时，您可以期待与第一次启动容器时一样的事情。

在每个kubernetes节点中运行的内部kubelet代理将启动容器的任务委托给OCI投诉容器运行时，例如docker，contained等，然后将docker镜像作为节点上的容器旋转。

我希望入口点脚本都将在启动容器重启时执行。

如果pod失败/重启，是否部署新的docker镜像？

它会创建一个新容器，其容器与容器规范中指定的图像相同。

如果容器重新启动，'job'和'cronjob'是否执行？

如果作为cronjob一部分的容器失败，则kubernetes将继续重启（除非在pod spec中为restartPolicy: Never），直到该时间作业不被视为失败为止。 cronjob无法在失败时重新启动容器。您可以指定backoffLimit来控制它将被视为失败之前重试的次数。

向上扩展等效于在相同或完全不同的Kubernetes节点上调度并启动同一容器的另一个实例。

作为旁注，您应该使用更高层次的抽象，例如部署而不是pod，因为当pod失败时，Kubernetes会尝试在同一节点上重新启动它，但是当部署失败时，Kubernetes也会尝试在其他节点上重新启动它。无法在其当前调度的节点上启动Pod。