当前位置: 首页 > backend >正文

K8S的Pod之initC容器restartPolicy新特性

一、背景

        首先回顾下Pod的restartPolicy, 针对Pod内容器exit退出时,kubelet对pod容器的一个处理策略.

        在Kubernetes中,restartPolicy 是 Pod 规范(Pod Spec)的一部分,它定义了 Kubernetes 应如何处理 Pod 内容器的重启。需要注意的是,restartPolicy 只能在 Pod 级别设置,并且适用于 Pod 中的所有容器,不能为单个容器单独设置重启策略。

以下是三种可用的 restartPolicy 选项:

  1. Always:这是默认的重启策略。无论容器是如何终止的,只要容器停止运行,Kubernetes 都会自动重启该容器。这对于那些需要持续运行的服务来说是最常用的策略。

  2. OnFailure:只有当容器以非零退出码终止时,Kubernetes 才会重启该容器。如果容器正常退出(退出码为0),则不会重启。这种策略适合批处理任务等不需要持续运行的工作负载。

  3. Never:无论容器的状态如何,Kubernetes 都不会重启该容器。一旦容器终止,它将保持终止状态。这通常用于一次性任务或调试场景。

   restartPolicy 的作用范围仅限于同一个节点上的容器重启。如果 Pod 被调度到不同的节点上(例如由于节点故障),那么新的 Pod 实例会被创建,而不是重启原有的容器。在这种情况下,是由控制器(如 Deployment、ReplicaSet 或者 Job)来确保 Pod 的期望状态得以维持。        

    此外,对于一些特定的工作负载类型,比如 Jobs 和 CronJobs,它们有自己的行为规则。Job 类型的 Pods 的 restartPolicy 只能设置为 Never 或者 OnFailure,因为这些工作负载的目标是完成某个任务,而不是无限期地运行。

     其实还有一种特殊情况可以将restartPolicy附加在initC容器的属性,附加一些特性.

二、补充

官方文档: Kubernetes API Reference Docs

RestartPolicy defines the restart behavior of individual containers in a pod. This field may only be set for init containers, and the only allowed value is "Always". For non-init containers or when this field is not specified, the restart behavior is defined by the Pod's restart policy and the container type. Setting the RestartPolicy as "Always" for the init container will have the following effect: this init container will be continually restarted on exit until all regular containers have terminated. Once all regular containers have completed, all init containers with restartPolicy "Always" will be shut down. This lifecycle differs from normal init containers and is often referred to as a "sidecar" container. Although this init container still starts in the init container sequence, it does not wait for the container to complete before proceeding to the next init container. Instead, the next init container starts immediately after this init container is started, or after any startupProbe has successfully completed. 

RestartPolicy 定义了 pod 中单个容器的重启行为。此字段仅可为 init 容器设置,且唯一允许的值为“Always”。对于非 init 容器或未指定此字段时,重启行为由 Pod 的重启策略和容器类型定义。将 init 容器的 RestartPolicy 设置为“Always”将产生以下效果:此 init 容器将在退出时不断重启,直至所有常规容器终止。一旦所有常规容器完成,所有具有 restartPolicy 为“Always”的 init 容器都将关闭。这种生命周期与普通 init 容器不同,通常被称为“sidecar”容器。尽管此 init 容器仍然按 init 容器的顺序启动,但它不会等待容器完成再继续执行下一个 init 容器。相反,下一个 init 容器会在该 init 容器启动后或任何 startupProbe 成功完成后立即启动。

1、介绍

        其实上面的内容,还有一个特点需要补充。 那就是restartPolicy 还能作用于 initC  初始化容器.  并且, restartPolicy只能设置为Always.

    存在restartPolicy: Always的initC初始化容器, 有几个特性和特点,从v1.24之后需要注意:    

        Kubernetes v1.24+ 引入的一个实验性(alpha)特性,允许在 initContainer 的定义中直接设置 restartPolicy 字段

  • 可用性:这是一个alpha 特性,需要启用 SidecarContainers 特性门控(Feature Gate)。
  • 唯一允许的值Always
  • 目的:创建一种新型的初始化容器,称为 "Sidecar Init Container" 或 "Persistent Init Container"

2、initContainer.restartPolicy: Always 的特性

        当一个 initContainer 设置了 restartPolicy: Always 时,它的行为与传统 initContainer根本性区别

  1. 不阻塞后续容器:这是最核心的区别。传统 initContainer 必须等待前一个完全成功退出才能启动下一个。而设置了 restartPolicy: Always 的 initContainer 启动后,下一个 initContainer 或主容器就会立即启动,不再等待它完成。它更像是一个“伴随”容器。
  2. 持续运行:它会像一个普通容器一样,如果退出(无论成功或失败),都会被 kubelet 重启(因为策略是 Always),直到主容器(regular containers)全部终止
  3. 生命周期与主容器绑定:只要主容器还在运行,这个 restartPolicy: Always 的 initContainer 就会持续运行和重启。一旦所有主容器都终止了,Kubernetes 会主动终止所有 restartPolicy: Always 的 initContainer
  4. 执行时机:它仍然在 initContainer 的序列中启动(即在主容器之前),但它启动后不会阻塞流程。
  5. 与 Pod.spec.restartPolicy 的关系
    • 这个 initContainer.restartPolicy 是覆盖了 Pod.spec.restartPolicy 对该特定 initContainer 的影响。
    • Pod.spec.restartPolicy 仍然控制主容器的行为。

3、使用场景

这种 restartPolicy: AlwaysinitContainer 非常适合需要在主应用启动之前就准备好,并且在整个应用生命周期内持续提供服务的初始化任务,例如:

  • 代理/边车(Sidecar):启动一个网络代理、日志收集代理或监控代理,为主容器提供网络或监控能力。
  • 数据预热/缓存:启动一个服务来预热缓存或下载数据,同时主应用可以并行启动。
  • 健康检查服务:运行一个服务来监控主应用的依赖项。        

三、总结

      restartPolicy字段除了可以一般作用于Pod, 还可以支持作用于initC容器, 存在一些新特性. 作用于initC, restartPolicy只能设置为Always.  这个是比较特殊的情况,要不然大家使用IDE编写yaml资源清单的时候, 就会很迷惑, 不是说restartPolicy只能作用于Pod资源么。看完这篇文章你就懂了.

       关注订阅我的B站视频,分享系统性学习K8S, 详细理解Pod restartPolicy:

B站最清晰讲解,掌握k8s(kubernetes)-Pod讲解(initC、mainC)-钩子hook-中

       

http://www.xdnf.cn/news/16814.html

相关文章:

  • .NET 中,Process.Responding 属性用于检查进程的用户界面是否正在响应
  • 《React+TypeScript实战:前端状态管理的安全架构与性能优化深解》
  • 音频3A处理简介之AGC(自动增益控制)
  • Python从入门到精通计划Day01: Python开发环境搭建指南:从零开始打造你的“数字厨房“
  • 北京-4年功能测试2年空窗-报培训班学测开-今天来聊聊我的痛苦
  • 防火墙配置实验2(DHCP,用户认证,安全策略)
  • Python 入门指南:从零基础到环境搭建
  • Windows 批处理(.bat)文件中,搜索文件时使用的通配符
  • 排序算法大全:从插入到快速排序
  • EPICS aSub记录示例2
  • 计算机网络:任播和负载均衡的区别
  • 【Linux系统】详解,进程控制
  • Flink2.0学习笔记:Stream API 窗口
  • 20250802让飞凌OK3576-C开发板在飞凌的Android14下【rk3576_u选项】适配NXP的WIFIBT模块88W8987A的蓝牙
  • 【深度学习新浪潮】什么是专业科研智能体?
  • python:如何调节机器学习算法的鲁棒性,以支持向量机SVM为例,让伙伴们看的更明白
  • Kubernetes 构建高可用、高性能 Redis 集群实战指南
  • AI应用标准详解:A2A MCP AG-UI
  • MySQL 运算符
  • WebForms 简介
  • 人类学家与建筑师:区分UX研究和项目管理的需求分析
  • 【云计算】云主机的亲和性策略(三):云主机 宿主机
  • Redis--day1--初识Redis
  • 第三十五章:让AI绘画“动”起来:第一个AI视频诞生-AnimateDiff的时间卷积结构深度解析
  • 初识 网络原理
  • 中科院开源HYPIR图像复原大模型:1.7秒,老照片变8K画质
  • 【数传电台P900配置指南:点对点、中继与一对多通讯详解】
  • 【高等数学】第七章 微分方程——第六节 高阶线性微分方程
  • 无图形界面的CentOS 7网络如何配置
  • 【Flutter】双路视频播放方案