What are the stages of a pod's lifecycle in Kubernetes?
- 内容介绍
- 文章标签
- 相关推荐
本文共计465个文字，预计阅读时间需要2分钟。
这篇文章将深入探讨Pod的生命周期，并解释kubelet的一些关键组成部分。我已经撰写了一篇关于Pod生命周期的详细博客，该博客内容丰富，值得一读。接下来，本文将更加深入地探讨Pod的生命周期。
Pod的生命周期包括以下几个主要阶段：
1. Pod创建：当Pod被创建时，kubelet负责启动Pod中的容器。
2.容器启动：kubelet启动Pod中的每个容器，并确保它们运行正常。
3.容器运行：容器在Pod中运行，执行其任务。
4.容器退出：当容器完成其任务或发生错误时，它将退出。
5.Pod终止：当所有容器都退出后，kubelet将Pod标记为终止状态。
kubelet的关键组成部分包括：
1. API服务器：kubelet与API服务器通信，接收Pod和其他资源的状态。
2.容器运行时：例如Docker或rkt，用于启动和运行容器。
3.CRI（容器运行时接口）：kubelet使用CRI与容器运行时通信。
4.Pod sandbox：Pod启动时，kubelet创建一个Pod sandbox，它是一个隔离的环境，用于运行Pod中的所有容器。
了解Pod的生命周期和kubelet的关键组成部分对于理解Kubernetes集群的工作原理至关重要。
这篇文章会写得比较泛。要知道pod的lifecycle需要事先了解一下kubelet的一些主要组成结构我已经挑出了一篇不错的blog这篇文章会写得比较泛。
要知道pod的lifecycle需要事先了解一下kubelet的一些主要组成结构我已经挑出了一篇不错的blog可以直接跳转去事先了解一下ref
blog.csdn.net/jettery/article/details/78891733
大的视角可以使得对kubelet有一个比较泛泛的认识比如哪些manager发挥了什么样的作用但实际上于事无补如果不追踪代码没有详细了解pod的生命周期发生了何种变化。
当然了对于pod的资源的管理还有很多refownerance好学者可以深入controller-manager看看我这边把statefulset深入了解了一下其他controller大同小异。
还是先从pod的创建开始吧。
几个重要的前提
1. 需要事先了解watch机制kubelet只watch pod的变动相应的有三种事件类型 ADDED MODIFIED DELETED
2. 类似Deployment和statefulset都是一种上层资源他们一般检查副本数来决定自己的状态同样的他们也会调用apiserver的接口来创建删除pod
3. 创建pod的步骤比删除pod的逻辑要简单得多主要是runtimeGC和killcontainer是分开处理pod和container的
还有几个简单玩意
1. 一个是podCache它主要靠runtime来获取pod的真实状态这个玩意还会生成事件驱动PLEG管道使得触发container和sandbox的状态更新
2. 一个是statusManager它本来没什么状态全靠kubelet syncPod函数向内注入status信息包含container和sandbox的status由这个manager来对比决定是否向apiserver同步status信息
3. 一个是workqueue 这个queue十分有趣它是保证kubelet水平触发的重要一环所有的信息经由dispatch到具体的函数后由podWorker来处理每个pod流程无论处理成功还是失败都会将它扔到workqueue内区别是处理失败的pod会延时10s再enqueue
那么创建pod的思路就简单明了了。
1. kubelet收到ADD pod的操作 并被dispatch到 HandlePodAdditions函数处理pod的创建过程
2. 在syncPod时会由podCache内的status生成一个状态从而同步到apiserver由于此时啥也没有只会同步一个带pod name的pod框架信息出去
3. volumeManager创建卷
4. 计算sandbox和container的状态来决定是否要创建sandbox以及container
5. 2-4步任意一步失败都会导致该pod信息被投递到workqueue然后等待syncCh 1秒触发来进行重新SYNC
6. sandbox和container的变化都会被PLEG感知然后状态被记入podCache并生成事件由PLEGCh触发处理pod的状态的sync从而回到第二步syncPod
7. 当pod创建完毕后PLEG感知到container和sandbox暂时不会发生状态变化则不会生成事件剩下的则是syncPod的结果无论成功失败都会enqueue到workqueue操作等待resync pod
8. 值得注意的是statusManager内维护的status信息是带版本的一旦有相应的cache并且cache内的status和即将同步给apiserver的status不一致则会向apiserver同步status并且version1
转:www.cnblogs.com/diagnose/p/9724376.html
本文共计465个文字，预计阅读时间需要2分钟。
这篇文章将深入探讨Pod的生命周期，并解释kubelet的一些关键组成部分。我已经撰写了一篇关于Pod生命周期的详细博客，该博客内容丰富，值得一读。接下来，本文将更加深入地探讨Pod的生命周期。
Pod的生命周期包括以下几个主要阶段：
1. Pod创建：当Pod被创建时，kubelet负责启动Pod中的容器。
2.容器启动：kubelet启动Pod中的每个容器，并确保它们运行正常。
3.容器运行：容器在Pod中运行，执行其任务。
4.容器退出：当容器完成其任务或发生错误时，它将退出。
5.Pod终止：当所有容器都退出后，kubelet将Pod标记为终止状态。
kubelet的关键组成部分包括：
1. API服务器：kubelet与API服务器通信，接收Pod和其他资源的状态。
2.容器运行时：例如Docker或rkt，用于启动和运行容器。
3.CRI（容器运行时接口）：kubelet使用CRI与容器运行时通信。
4.Pod sandbox：Pod启动时，kubelet创建一个Pod sandbox，它是一个隔离的环境，用于运行Pod中的所有容器。
了解Pod的生命周期和kubelet的关键组成部分对于理解Kubernetes集群的工作原理至关重要。
这篇文章会写得比较泛。要知道pod的lifecycle需要事先了解一下kubelet的一些主要组成结构我已经挑出了一篇不错的blog这篇文章会写得比较泛。
要知道pod的lifecycle需要事先了解一下kubelet的一些主要组成结构我已经挑出了一篇不错的blog可以直接跳转去事先了解一下ref
blog.csdn.net/jettery/article/details/78891733
大的视角可以使得对kubelet有一个比较泛泛的认识比如哪些manager发挥了什么样的作用但实际上于事无补如果不追踪代码没有详细了解pod的生命周期发生了何种变化。
当然了对于pod的资源的管理还有很多refownerance好学者可以深入controller-manager看看我这边把statefulset深入了解了一下其他controller大同小异。
还是先从pod的创建开始吧。
几个重要的前提
1. 需要事先了解watch机制kubelet只watch pod的变动相应的有三种事件类型 ADDED MODIFIED DELETED
2. 类似Deployment和statefulset都是一种上层资源他们一般检查副本数来决定自己的状态同样的他们也会调用apiserver的接口来创建删除pod
3. 创建pod的步骤比删除pod的逻辑要简单得多主要是runtimeGC和killcontainer是分开处理pod和container的
还有几个简单玩意
1. 一个是podCache它主要靠runtime来获取pod的真实状态这个玩意还会生成事件驱动PLEG管道使得触发container和sandbox的状态更新
2. 一个是statusManager它本来没什么状态全靠kubelet syncPod函数向内注入status信息包含container和sandbox的status由这个manager来对比决定是否向apiserver同步status信息
3. 一个是workqueue 这个queue十分有趣它是保证kubelet水平触发的重要一环所有的信息经由dispatch到具体的函数后由podWorker来处理每个pod流程无论处理成功还是失败都会将它扔到workqueue内区别是处理失败的pod会延时10s再enqueue
那么创建pod的思路就简单明了了。
1. kubelet收到ADD pod的操作 并被dispatch到 HandlePodAdditions函数处理pod的创建过程
2. 在syncPod时会由podCache内的status生成一个状态从而同步到apiserver由于此时啥也没有只会同步一个带pod name的pod框架信息出去
3. volumeManager创建卷
4. 计算sandbox和container的状态来决定是否要创建sandbox以及container
5. 2-4步任意一步失败都会导致该pod信息被投递到workqueue然后等待syncCh 1秒触发来进行重新SYNC
6. sandbox和container的变化都会被PLEG感知然后状态被记入podCache并生成事件由PLEGCh触发处理pod的状态的sync从而回到第二步syncPod
7. 当pod创建完毕后PLEG感知到container和sandbox暂时不会发生状态变化则不会生成事件剩下的则是syncPod的结果无论成功失败都会enqueue到workqueue操作等待resync pod
8. 值得注意的是statusManager内维护的status信息是带版本的一旦有相应的cache并且cache内的status和即将同步给apiserver的status不一致则会向apiserver同步status并且version1
转:www.cnblogs.com/diagnose/p/9724376.html