Pod生命周期

Pod容器

  1. Init Container:
    • 支持应用容器的全部字段与特性,包括资源限制,存储券和安全设置
    • 由于需要在pod就绪之前运行完成,所以不支持reaadinessProbe
    • 定义多个init容器,它们会按定义顺序执行
    • init容器失败,如果restartPolicy不为Nerver,则会不断重启,直到成功为止
    作用:
    • 具有与应用容器分离的单独镜像,可包含不建议在生产镜像中包含的实用工具
    • 应用程序镜像基于它可以分离出创建和部署的角色
    • 使用linux namespace,相对应用容器来说有不同的文件系统视图,因此有访问secret的权限,应用容器则不能
    • 可以阻塞或延迟应用容器的启动
  2. Pod Hook 如果postStart,postStop失败,会杀死容器
    • postStart:容器创建后立即执行,不保证钩子在容器EntryPoint之前运行。主要用于资源部署、环境准备等。如果运行时间过长以至不能运行或者挂起容器将无法到达Running状态
    • preStop:容器终止之前立即调用,阻塞,同步的,必须在删除容器调用发出之前完成。主要用于优雅关闭应用程序、通知其它系统等。如果执行期间被挂起,pod将永远在running状态,并不会到达failed状态
  3. 健康检查

Pod状态

PodStatus.phase字段

  1. 挂起(Pending)信息已提交集群,但没有被调度器调度到合适的节点或pod镜像正在下载
  2. 运行中(Running)已绑定到一个节点,所有容器已被创建。至少一个正在运行,或者处理启动或重启状态
  3. 成功(Successed)所有容器成功终止,并且不会重启
  4. 失败(Failed)所有容器已终止,并且至少一个容器是因为失败终止,也就是说容器以非0状态退出或被系统终止
  5. 未知(UnKnow)无法获得状态,通常是主机通信失败导致的

PodStatus.PodCondition

描述当前Status的具体原因

  1. PodScheduled:pod已调度到某节点
  2. ContainersReady:pod内所有容器已就绪
  3. Initialized:所有的init容器都已成功完成
  4. Unschedulable
  5. Ready:可以提供服务,并且应该被添加到对应服务的负载均衡池中

Pod

  1. 资源定义(CPU、内存)
  2. 调度
  3. Volume
    • Projected Volume 投射数据卷 存在不是为了存放容器中的数据,也不是容器与宿主之间数据交换,为容器提供预先定义好的数据
      • Secret
      • ConfigMap
        • 不需要加密的,应用所需要的配置文件
      • Downward API
        • 获取到Pod API对象本身的信息,进程启动之前就能确定的信息
      • SeviceAccountToken

restartPolicy

  1. Always:容器失效时,kubelet自动重启
  2. OnFailure:终止运行并且退出码不为0,由kubelet自动启动
  3. Never:不论容器运行状态如何,都不重启

ReplicationController,DaemonSet必须为always,需要保证容器持续运行

Job:onFailure或Never,确保执行完成后不再重启

探针

readinessProbe

检查结果决定这个Pod能不能通过Service的方式访问到,而不会影响Pod的生命周期。探测失败,端点控制器将从与 pod匹配的所有服务的端点列表中删除这个pod的ip地址

livenessProbe

配置参数太多,有模板:PodPresent。指示容器是否存活,如果探活失败,则kubelet会杀死容器,并且通过重启策略决定未来

startupProbe 指示容器内应用是否已经启动,提供了此探针,则所有其它控针都会被禁用,直到这个探针成功为止。

容器状态 kubectl describe pod <pod名字>

  1. Waiting:等待,仍在运行完成它启动所需要的操作,比如拉镜像、应用secret数据等
  2. Running:运行中,容器正在执行,并且没有问题产生
  3. Terminated:已终止,容器已经执行并且或者正常结束,或者因为其它原因失败

pod终止

体面退出

容器运行时会向每个容器的主进程发送TERM信号,一旦超出了体面退出终止限期,容器运行时会向所有剩余进程发送kill信号,之后pod会从api服务器上移除

例子:

  1. 使用kubectl手动删除某个pod,pod的体面终止时间默认为30s
  2. api服务中pod对象被更新,pod状态会被标记为“terminating“正在终止,超出所计算的体面终止限期时间点则认为pod dead
  3. kubelet看到pod被标记为正在终止(已设置了体面终止限期),则马上开始本地pod关闭过程
    • 检查并执行preStop回调,如果到达体面终止时间,仍在运行,则一次性给予宽限期2秒(可通过terminationGracePeriodSeconds参数配置)
    • 接下来kubelet触发容器运行时发送TERM信号给容器中的进程,如果需要容器按顺序关闭,可以考虑使用preStop回调逻辑来协调
  4. 控制器会将pod从对应的端点列表中移除,ReplicaSets与其它工作负载资源不再将关闭进程中的pod视为合法,可提供服务的副本。服务在终止宽限期开始的时候负载均衡器已经从端点列表肿移除了,所以pod即使还没有关闭完成,也无法继续处理请求
  5. 超出宽限期,kubelet会触发强制关闭,容器进行时向所有运行中容器发送sigkill信息。同时如果使用了pause容器的话,kubelet也会清理隐藏的pause容器
  6. api服务器删除pod的api对象,所有客户端之后则无法再看到这个容器

强制关闭

宽限期限--grace-period=<seconds>设置为0,并且设置--force参数,api服务器直接删除pod对象,节点侧,被终止的pod仍然会在被强制终止前获得一点点宽限时间

This entry was posted in Kubernetes and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.