目录
引言
一、List-Watch机制概述
（一）基本概念
（二）工作机制
1.List操作
2.Watch操作
（三）数据流向
1.按模块划分
2.按整体总结
二、Pod生命周期
（一）生命周期
1.创建
2.调度
3.初始化容器启动
4.镜像拉取
5.容器创建与运行
6.健康检查与就绪检测
7.重启策略
8.清理
9.终止
（二）生命周期状态
1.Pending
2.Running
3.Succeeded
4.Failed
5.Unknown
引言
在Kubernetes（K8s）这个庞大的分布式系统中，资源的实时更新和响应对于维持集群的稳定性和高效性至关重要。而List-Watch机制正是Kubernetes实现这一目标的核心手段。本文将详细介绍Kubernetes中的List-Watch机制，与容器的生命周期。包括其工作原理、应用场景以及性能优化等方面。
一、List-Watch机制概述
（一）基本概念
List-Watch是Kubernetes API Server提供的一种资源监控机制。它允许客户端通过API Server获取资源对象的列表（List），并通过建立长连接（Watch）来实时监控资源对象的变化。当资源对象发生创建、更新或删除等操作时，API Server会向订阅了相关资源的客户端发送事件通知，实现资源的实时同步和响应
（二）工作机制
List-Watch机制的工作原理可以简单概括为以下两个步骤
1.List操作
客户端向Kubernetes API Server发送List请求，指定要获取的资源类型和筛选条件。API Server根据请求返回符合条件的资源对象列表。客户端可以根据这个列表来初始化自己的状态或进行其他操作。
2.Watch操作
客户端在获取到资源对象列表后，可以继续向API Server发送Watch请求，建立与API Server的长连接。API Server会持续监控指定资源的变化，并将变化事件以流的形式发送给客户端。客户端可以解析这些事件通知，并触发相应的处理逻辑。
（三）数据流向
1.按模块划分
初始化阶段：Kubernetes的各种组件（如Controller Manager、Scheduler、kubelet等）在启动时，会与APIServer建立连接，并初始化List-Watch机制。
List操作：组件向APIServer发送List请求，获取当前集群中指定资源类型的所有资源对象列表。例如，Controller Manager可能会请求获取所有Pod的列表。APIServer处理List请求，查询etcd存储系统，并将结果返回给组件。
Watch操作：组件向APIServer发送Watch请求，建立一个长连接，用于监听指定资源类型的变化。APIServer处理Watch请求，并在内部与etcd建立Watch连接，以监听etcd中对应资源的变化。
事件触发：当etcd中的资源发生变化（如Pod的创建、更新或删除）时，etcd会发送一个事件通知给APIServer。APIServer接收到事件通知后，会将事件封装成HTTP响应，并通过之前建立的长连接发送给对应的组件。
组件处理：组件接收到APIServer发送的事件通知后，会解析通知中的信息，并根据事件的类型（如ADD、UPDATE、DELETE）执行相应的操作。例如，如果Controller Manager接收到Pod被创建的事件，它可能会触发相应的控制器逻辑，如ReplicaSet控制器会根据Pod的创建来调整副本集的状态。
数据同步：通过List-Watch机制，Kubernetes的各个组件能够实时感知集群中资源的变化，并据此进行相应的操作，从而保持数据的同步和一致性。
2.按整体总结
1）这里有三个 List-Watch，分别是 Controller Manager（运行在 Master），Scheduler（运行在 Master），kubelet（运行在 Node）。 它们在进程已启动就会监听（Watch）APIServer 发出来的事件
2）用户通过 kubectl 或其他 API 客户端提交请求给 APIServer 来建立一个 Pod 对象副本。
3）APIServer将Pod对象的元数据信息存入ETCD当中，待存储完毕后，APIServer会将确认信息返回给客户端，同时ETCD会将创建Pod副本的事件发送给APIServer
4）由于Controller-Manager 一直在监听（Watch，通过https的6443端口）APIServer 中的事件。此时 APIServer 接受到了Create（创建Pod副本）事件，又会发送给Controller Manager
5）Controller Manager 在接到 Create 事件以后，调用其中的 Replication Controller 来保证 Node 上面需要创建的副本数量。一旦副本数量少于 RC 中定义的数量，RC 会自动创建副本。总之它是保证副本数量的 Controller（PS：扩容缩容的担当）
6）在Controller-Manager创建Pod副本以后，APIServer会在ETCD中记录这个Pod的详细信息。例如Pod的副本数，Container的内容是什么
7）同样的ETCD会将创建Pod的信息通过事件发送给APIServer
8）由于Scheduler在监听（Watch）APIServer，APIServer会将Create事件发送到Scheduler，Scheduler接收到事件后，会根据预选与优选策略，为该事件选择合适的node节点，
9）Scheduler 调度完毕以后会更新Pod的信息，此时的信息更加丰富了。除了知道Pod的副本数量，副本内容。还知道部署到哪个Node上面了。并将上面的Pod信息更新至API Server，
10） APIServer更新至ETCD中，保存起来
11）ETCD将更新成功的事件发送给 APIServer，APIServer 也开始反映此 Pod 对象的调度结果
12）kubelet是在Node上面运行的进程，它也通过List-Watch的方式监听（Watch，通过https的6443端口）APIServer发送的Pod更新的事件。kubelet会尝试在当前节点上调用Docker启动容器，并将Pod以及容器的结果状态回送至APIServer，同时kubelet会负责Pod的整个生命周期
13）最后，APIServer将Pod状态信息存入ETCD中。在ETCD确认写入操作成功完成后，APIServer将确认信息发送至相关的kubelet，事件将通过它被接受
注释：kubelet持续监控Pod状态，当kubectl发送删除、扩容、缩容等指令时，会将以上流程重复一遍，而后根据最新的情况，在node节点中调整部署资源
二、Pod生命周期
Pod的生命周期从创建开始，经历一系列阶段直至最终终止或被删除。
（一）生命周期
1.创建
用户通过创建一个新的Pod对象来请求Kubernetes调度器为Pod分配资源。
Kubernetes系统会赋予Pod一个唯一的ID（UID）。
2.调度
Pod被提交到集群后，调度器根据节点资源可用性和Pod的资源需求、亲和性/反亲和性规则等选择合适的节点，并将Pod绑定到该节点上。
3.初始化容器启动
若Pod定义中包含初始化容器（init containers），这些容器会在主容器启动前按顺序执行，用于设置运行主容器所需的条件或环境。
每个Init容器都必须在下一个Init容器启动之前成功完成。
如果Pod的Init容器失败，并且Pod的重启策略（restartPolicy）值为“Always”，则kubelet会不断地重启该Init容器直到该容器成功为止。但如果Pod的重启策略值为“Never”，则Kubernetes不会重新启动Pod。
4.镜像拉取
主容器对应的镜像如果没有在节点上，则kubelet负责从注册表中拉取镜像。
5.容器创建与运行
kubelet根据Pod Spec创建并启动主容器。
容器状态会经历从Pending（等待中）到Running（运行中）的变化。
6.健康检查与就绪检测
在容器运行期间，kubelet可以配置并执行健康检查（liveness probes）和就绪检查（readiness probes）以确保容器正常工作。
Liveness Probe用于判断容器是否存活，若失败则可能重启容器。
Readiness Probe用于决定容器是否准备好接收流量，只有当容器处于ready状态时，Service才会将其添加到服务端点列表中。
7.重启策略
根据Pod的重启策略（Always、OnFailure或Never），kubelet会决定在容器退出时应采取何种行动。
8.清理
当Pod被删除或者由于某种原因需要终止时，kubelet会按照预定义的优雅关闭策略通知容器停止服务，并等待一段时间让容器完成任何必要的清理操作。
清理完成后，kubelet会真正删除Pod及其相关的容器实例和其他资源。
9.终止
Pod完全从节点上移除。
此外，Pod生命周期中还包括容器启动后钩子（post-start hook）和停止前钩子（pre-stop hook），这些钩子允许在容器启动后和停止前执行特定的操作。
（二）生命周期状态
Pod的生命周期状态主要包括
1.Pending
Pod已经被Kubernetes系统接受，但是有一个或多个容器镜像尚未创建。
Pod等待被调度到一个节点上。可能涉及下载镜像、分配IP地址、执行初始化容器等操作。
如果Pod一直处于等待中，可能是由于资源不足、调度问题或其他原因导致。
2.Running
Pod已经被调度至某节点，所有容器都已经被kubelet创建完成，且至少有一个容器处于启动、重启或运行过程中。
3.Succeeded
Pod中的所有容器都已成功完成并退出。
通常适用于一次性或批处理作业。
4.Failed
Pod中的一个或多个容器由于某种原因失败。
这可能是由于容器的退出代码非零、初始化容器失败、依赖资源不可用等原因导致。
5.Unknown
由于某种原因，Pod的状态无法确定。
这可能是由于与API服务器的通信问题或其他异常情况导致。
