【云原生】Kubernetes----List-Watch机制详解与容器生命周期

目录

引言

一、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服务器的通信问题或其他异常情况导致。

  • 11
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值