容器组_生命周期

本文详细解释了Kubernetes中的容器组生命周期管理,包括Podphase和Podconditions的含义,容器的健康检查与就绪检查机制,以及重启策略的选择。还介绍了如何在Kuboard中配置这些设置,以及容器的不同状态和存活期规则。
在这里插入图片描述

📕作者简介: 过去日记,致力于Java、GoLang,Rust等多种编程语言,热爱技术,喜欢游戏的博主。
📘相关专栏Rust初阶教程go语言基础系列、spring教程等,大家有兴趣的可以看一看
📙Java并发编程系列,设计模式系列、go web开发框架 系列正在发展中,喜欢Java,GoLang,Rust,的朋友们可以关注一下哦!


容器组_生命周期

Pod phase

Pod phase 代表其所处生命周期的阶段。Pod phase 并不是用来代表其容器的状态,也不是一个严格的状态机。
phase 的可能取值有:

Phase描述
PendingKubernetes 已经创建并确认该 Pod。此时可能有两种情况:1.Pod 还未完成调度(例如没有合适的节
Running该 Pod 已经被绑定到一个节点,并且该 Pod 所有的容器都已经成功创建。其中至少有一个容器正在运行,或者正在启动/重启
SucceededPod 中的所有容器都已经成功终止,并且不会再被重启
FailedPod 中的所有容器都已经终止,至少一个容器终止于失败状态:容器的进程退出码不是 0,或者被系统 kill
Unknown因为某些未知原因,不能确定 Pod 的状态,通常的原因是 master 与 Pod 所在节点之间的通信故障

Pod conditions

每一个 Pod 都有一个数组描述其是否达到某些指定的条件。Pod condition 数组在 Kuboard 中的显示如下图所示:
在这里插入图片描述

该数组的每一行可能有六个字段:

字段名描述
typetype 是最重要的字段,可能的取值有:
PodScheduled: Pod 已被调度到一个节点
Ready: Pod 已经可以接受服务请求,应该被添加到所匹配 Service 的负载均衡的资源池
Initialized:Pod 中所有初始化容器已成功执行
Unschedulable:不能调度该 Pod(缺少资源或者其他限制)
ContainersReady:Pod 中所有容器都已就绪
status能的取值有:
True
False
Unknown
reasonCondition 发生变化的原因,使用一个符合驼峰规则的英文单词描述
messageCondition 发生变化的原因的详细描述,human-readable
lastTransitionTimeCondition 发生变化的时间戳
lastProbeTime上一次针对 Pod 做健康检查/就绪检查的时间戳

容器的检查

Probe 是指 kubelet 周期性地检查容器的状况。有三种类型的 Probe:

  • ExecAction: 在容器内执行一个指定的命令。如果该命令的退出状态码为 0,则成功
  • TCPSocketAction: 探测容器的指定 TCP 端口,如果该端口处于 open 状态,则成功
  • HTTPGetAction: 探测容器指定端口/路径上的 HTTP Get 请求,如果 HTTP 响应状态码在 200 到 400(不包含400)之间,则成功

Probe 有三种可能的结果:

  • Success: 容器通过检测
  • Failure: 容器未通过检测
  • Unknown: 检测执行失败,此时 kubelet 不做任何处理

Kubelet 可以在两种情况下对运行中的容器执行 Probe:

  • 就绪检查 readinessProbe: 确定容器是否已经就绪并接收服务请求。如果就绪检查失败,kubernetes 将该 Pod 的 IP 地址从所有匹配的 Service 的资源池中移除掉。
  • 健康检查 livenessProbe: 确定容器是否正在运行。如果健康检查失败,kubelete 将结束该容器,并根据 restart policy(重启策略)确定是否重启该容器。

何时使用 健康检查/就绪检查?

  • 如果容器中的进程在碰到问题时可以自己 crash,您并不需要执行健康检查;kubelet 可以自动的根据 Pod 的 restart policy(重启策略)执行对应的动作
  • 如果您希望在容器的进程无响应后,将容器 kill 掉并重启,则指定一个健康检查 liveness probe,并同时指定 restart policy(重启策略)为 Always 或者 OnFailure
  • 如果您想在探测 Pod 确实就绪之后才向其分发服务请求,请指定一个就绪检查 readiness probe。此时,就绪检查的内容可能和健康检查相同。就绪检查适合如下几类容器:
    • 初始化时需要加载大量的数据、配置文件
    • 启动时需要执行迁移任务
    • 其他

Kuboard 中配置健康检查/就绪检查
Kuboard 可以在工作负载编辑器中配置健康检查/就绪检查,界面如下所示:

Kubernetes教程:在Kuboard中配置容器的健康检查/就绪检查

容器的状态

一旦 Pod 被调度到节点上,kubelet 便开始使用容器引擎(通常是 docker)创建容器。容器有三种可能的状态:Waiting / Running / Terminated:

  • Waiting: 容器的初始状态。处于 Waiting 状态的容器,仍然有对应的操作在执行,例如:拉取镜像、应用 Secrets等。
  • Running: 容器处于正常运行的状态。容器进入 Running 状态之后,如果指定了 postStart hook,该钩子将被执行。
  • Terminated: 容器处于结束运行的状态。容器进入 Terminated 状态之前,如果指定了 preStop hook,该钩子将被执行。

重启策略

定义 Pod 或工作负载时,可以指定 restartPolicy,可选的值有:

  • Always (默认值)
  • OnFailure
  • Never
    restartPolicy 将作用于 Pod 中的所有容器。kubelete 将在五分钟内,按照递延的时间间隔(10s, 20s, 40s …)尝试重启已退出的容器,并在十分钟后再次启动这个循环,直到容器成功启动,或者 Pod 被删除。

容器组的存活期

通常,如果没有人或者控制器删除 Pod,Pod 不会自己消失。只有一种例外,那就是 Pod 处于 Scucceeded 或 Failed 的 phase,并超过了垃圾回收的时长(在 kubernetes master 中通过 terminated-pod-gc-threshold 参数指定),kubelet 自动将其删除。

01、数据简介 规模以上工业企业,是指年主营业务收入达到一定规模的工业法人单位。这一标准由国家统计局制定,旨在通过统一口径筛选出对工业经济具有显著贡献的“核心企业”,为政策制定、经济监测和学术研究提供精准数据支撑。 数据名称:地级市-规模以上工业企业相关数据 数据年份:2000-2024年 02、相关数据 原始数据:年份 省份 城市 省份代码 城市代码 规模以上工业企业单位数(个) 规模以上工业增加值增速(%) 规模以上工业企业单位数_内资企业(个) 规模以上工业企业单位数_港澳台商投资企业(个) 规模以上工业企业单位数_外商投资企业(个) 规模以上工业亏损企业单位数(个) 插值:年份 省份 城市 省份代码 城市代码 规模以上工业企业单位数(个) 规模以上工业企业单位数(个)_线性插值 规模以上工业企业单位数(个)_回归填补 规模以上工业增加值增速(%) 规模以上工业增加值增速(%)_线性插值 规模以上工业增加值增速(%)_回归填补 规模以上工业企业单位数_内资企业(个) 规模以上工业企业单位数_内资企业(个)_线性插值 规模以上工业企业单位数_内资企业(个)_回归填补 规模以上工业企业单位数_港澳台商投资企业(个) 规模以上工业企业单位数_港澳台商投资企业(个)_线性插值 规模以上工业企业单位数_港澳台商投资企业(个)_回归填补 规模以上工业企业单位数_外商投资企业(个) 规模以上工业企业单位数_外商投资企业(个)_线性插值 规模以上工业企业单位数_外商投资企业(个)_回归填补 规模以上工业亏损企业单位数(个) 规模以上工业亏损企业单位数(个)_线性插值 规模以上工业亏损企业单位数(个)_回归填补
内容概要:本文深入介绍了谷歌推出的Gemini 3 Deep Think——一种基于大模型的增强型推理模式,具备并行推理、多模态理解融合和“深度思考”能力,专为解决复杂算法重构与调试难题而设计。文章详细剖析了其核心技术优势,包括16条并行推理路径、跨模态信息整合以及模拟人类“慢思考”的迭代推理过程,并通过电商平台推荐系统优化和计算机视觉目标检测算法改进两大案例,展示了其在真实场景中显著提升算法性能与准确性的能力。同时,文章对比了其与传统工具在功能全面性、效率和准确性方面的压倒性优势,并探讨了实际应用中面临的算力需求、系统兼容性和数据安全挑战及其应对策略,最后展望了其对程序员角色转变和整个软件行业的深远影响。; 适合人群:具备一定编程经验的中高级程序员、算法工程师、AI研究人员及技术管理者;尤其适用于从事复杂系统开发、算法优化和性能调优的专业人士。; 使用场景及目标:①在大型项目中进行算法性能瓶颈分析与重构;②提升复杂代码调试效率,快速定位并修复隐蔽错误;③融合多源信息(如代码、公式、图表)进行智能算法设计与优化;④推动企业级AI系统升级与智能化开发流程转型。; 阅读建议:此资源兼具技术深度与实践价值,建议读者结合自身项目背景,重点关注技术原理与案例实现的对应关系,尝试将Gemini 3 Deep Think的思维方式融入日常开发与调试中,同时关注其在云平台部署、安全合规等方面的最佳实践,以充分发挥其潜力。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

过去日记

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值