K8S之pod生命周期

K8S之pod生命周期

Pod的生命周期是通过Replication Controller来管理的。Pod的生命周期过程包括:通过模板进行定义,然后分配到一个Node上运行,在Pod所含容器运行结束后Pod也结束。在整个过程中,Pod处于一下4种状态之一:

  • Pending:Pod定义正确,提交到Master,但其所包含的容器镜像还未完成创建。通常Master对Pod进行调度需要一些时间,之后Node对镜像进行下载也需要一些时间;正在初始化中的Pod处于Pending状态
  • Running:Pod已被分配到某个Node上,且其包含的所有容器镜像都已经创建完成,并成功运行起来;
  • Succeeded:Pod中所有容器都成功终止,并且不会被重启,这是Pod的一种最终状态(所有容器都以“0”的状态退出);
  • Failed:Pod中所有容器都结束了,至少有一个容器以非0状态退出。
  • Unknown:因为某些原因无法取得 Pod 的状态,通常是因为与 Pod 所在主机通信失败。

Kubernetes为Pod设计了一套独特的网络配置,包括:为每个Pod分配一个IP地址,使用Pod名作为容器间通信的主机名等。关于Kubernetes网络的设计原理将在第2章进行详细说明。
另外,不建议在Kubernetes的一个Pod内运行相同应用的多个实例。

Pod生命周期的几个阶段

K8S之pod生命周期_第1张图片

1.当kubectl创建指令下达到api接口,被调度到kubelet上,kubelet首先调用CRI完成容器环境的初始化。

2.开始进入pod的生命周期,pod开始创建。

3.首先进行Pause基础容器创建,Pause负责网络和存储卷的共享等基础操作。

4.如果定义了Init容器,先进行Init容器(Init C)的创建,Init容器叫初始化容器,可以做一些初始化的操作,比如生成一些应用容器需要的文件。Init C只是用来初始化的,在初始化完成后Init C就会死亡,并不会跟随一直跟随pod的生命周期存在。Init C可以是多个,它不是必须的,也可以没有。多个Init C不能并行运行,一个Init C完成后,才能进行下一个Init C的构建。如果Init容器失败,k8s会不断重启该Pod,直到Init容器运行成功为止。然而,如果pod对应的restartPolicy为Never,那么它不会重启。在所有的nit容器没有成功之前,Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。

需要注意的是:Init容器具有与应用程序容器分离的单独镜像,所以它们的启动相关代码具有如下优势:

  • 他们可以包含并运行实用工具,但是出于安全考虑,是不建议在应用程序容器镜像中包含这些实用工具的
  • 它们可以包含实用工具和定制化代码来安装,但是不能出现在应用程序镜像中
  • 应用程序镜像可以分离出创建和部署的角色,而没有必要联合它们构建一个单独的镜像。
  • Linux Namespace,所以相对应用程序容器来说具有不同的文件系统视图。因此,它们能够具有访问Secret的权限,而应用程序容器则不能。
  • 它们必须在应用程序容器启动之前运行完成,而应用程序容器是并行运行的,所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法,直到满足了一组先决条件。

5.开始创建主容器(Main C)

6.主容器Main C运行过程中,如果定义了start操作,首先进行一个start操作。

7.然后如果定义了readiness就绪检测,就执行readiness就绪检测,readiness检测成功完成后,pod才会显示running,才会对外提供服务。

8.如果定义了liveness存活检测,也会同时开始执行,如果liveness检测失败,kubelet杀死该Pod,然后根据重启策略restartPolicy决定是否对pod执行重启。若容器中不包含liveness探针,则kubelet认为该pod的liveness探针返回值永远是success。liveness存活检测是持续过程,一直持续到stop操作完成之后,Main C结束之前。

9.主容器Main C结束退出时,如果定义了stop操作,则先进行stop操作,stop操作完成以后才允许退出。

Pod的重启策略:

Pod 的重启策略有 3 种,默认值为 Always。

  • Always : 容器失效时,kubelet 自动重启该容器;
  • OnFailure : 容器终止运行且退出码不为0时重启;
  • Never : 不论状态为何, kubelet 都不重启该容器。

失败的容器由 kubelet 以五分钟为上限的指数退避延迟(10秒,20秒,40秒…)重新启动,并在成功执行十分钟后重置。

如果 restartpolicy 没有设置,那么默认值是 Always。RC 和 DaemonSet 必须指定重启策略为 Always。

Pod 的活性与就绪探针

探针机制

在 Kubernetes 中 Pod 是最小的计算单元,而一个 Pod 又由多个容器组成,相当于每个容器就是一个应用,应用在运行期间,可能因为某也意外情况致使程序挂掉。那么如何监控这些容器状态稳定性,保证服务在运行期间不会发生问题,发生问题后进行重启等机制,就成为了重中之重的事情,考虑到这点 kubernetes 推出了活性探针机制。

有了活性探针后能保证程序在运行中如果挂掉能够自动重启,但是还有个经常遇到的问题,比如说,在 Kubernetes 中启动 Pod,显示明明 Pod 已经启动成功,且能访问里面的端口,但是却返回错误信息。还有就是在执行滚动更新时候,总会出现一段时间,Pod 对外提供网络访问,但是访问却发生 404,这两个原因,都是因为 Pod 已经成功启动,但是 Pod 的的容器中应用程序还在启动中导致,考虑到这点 Kubernetes 推出了就绪探针机制。

Pod 两种探针

**LivenessProbe(存活探针):**存活探针主要作用是,用指定的方式进入容器检测容器中的应用是否正常运行,如果检测失败,则认为容器不健康,那么Kubelet将根据Pod中设置的restartPolicy (重启策略)来判断,Pod 是否要进行重启操作,如果容器不提供存活探针,则默认状态为Success

**ReadinessProbe(就绪探针):**用于判断容器中应用是否启动完成,当探测成功后才使 Pod 对外提供网络访问,设置容器 Ready 状态为 true,如果探测失败,则设置容器的 Ready 状态为 false。对于被 Service 管理的 Pod,Service 与 Pod、EndPoint (端点)的关联关系也将基于 Pod 是否为 Ready 状态进行设置,如果 Pod 运行过程中 Ready 状态变为 false,则系统自动从 Service 关联的 EndPoint (端点)列表中移除,如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint (端点)列表。通过这种机制就能防止将流量转发到不可用的 Pod 上。

容器探针的探测方式:

探针是由 kubelet 对容器执行的定期诊断。要执行诊断,kubelet 调用由容器实现的 Handler。有三种类型的处理程序:

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

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

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

两种探测方式的区别

ReadinessProbe 和 livenessProbe 可以使用相同探测方式,只是对 Pod 的处置方式不同:

  • livenessProbe 当检测失败后,将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。
  • readinessProbe 当检测失败后,将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。

你可能感兴趣的:(kubernetes,kubernetes,linux)