资讯

历史

科技

环境与自然

成长

游戏

财经

文学与艺术

美食

健康

家居

文化

情感

汽车

三农

军事

旅行

运动

教育

生活

星座命理

k8s创建pod过程以及各组件的作用

创作时间:

作者:

@小白创作中心

k8s创建pod过程以及各组件的作用

引用

CSDN

https://blog.csdn.net/yuelai_217/article/details/137588535

Kubernetes（简称k8s）作为最流行的容器编排平台，其Pod创建过程涉及多个核心组件的协同工作。本文将详细解析从客户端请求到Pod就绪的整个流程，并深入介绍API Server、etcd、Scheduler和kubelet等关键组件的作用。

一、创建过程

1.1 客户端请求创建Pod

用户通过kubectl、API调用或其他方式提交Pod YAML配置文件到Kubernetes集群。

1.2 API Server处理请求

API Server接收并验证Pod定义，然后将其存储在etcd中。此后各组件的交互由API Server主导。

1.3 调度Pod

调度器(Scheduler)根据资源需求和节点条件，使用调度算法选择一个合适的Node，并将Pod绑定到选定的Node上，这一信息再次被更新到etcd。

1.4 kubelet动作

被选中的Node上的kubelet监听etcd的变化，发现新的Pod需要在其上启动时，kubelet开始执行本地Pod的创建过程。

1.5 容器运行时准备

kubelet与Container Runtime Interface (CRI)进行交互，如通过cri-o或containerd等实现，指示它为Pod创建所需的网络命名空间和挂载点。

1.6 CNI网络插件介入

在容器实例化之前，kubelet会调用CNI插件为Pod内的每个容器设置网络环境。CNI插件会在适当的时候被调用，为Pod分配IP地址，配置网络设备，设置路由规则，以及可能的网络策略。CNI通过ADD命令为新Pod创建网络配置，这包括：

分配IP地址。
创建网络命名空间。
设置网络接口（veth pairs, OVS ports等）。
配置网络策略（如果适用）。

1.7 容器启动

当网络配置完成后，CRI会实际拉取并启动容器镜像。

1.8 Pod就绪

当所有容器启动并运行后，kubelet通过CNI的CHECK命令（如果有此功能的CNI插件）进行健康检查和状态汇报，当Pod内所有容器均报告就绪时，Pod会被标记为Ready。

二、各组件作用

2.1 API Server

Kubernetes API Server在创建Pod的过程中扮演着中心协调者的重要角色。API Server是Kubernetes控制平面的一部分，并且是与集群交互的主接口。以下是API Server在创建Pod过程中的作用：

接收请求：当用户通过kubectl命令行工具、API客户端或其他方式向API Server发出创建Pod的请求时，API Server是接收和处理这些请求的组件。
验证和授权：API Server对请求进行验证，确保请求来自一个已经认证的用户、服务账号或其他实体。然后，它会进行授权检查，以确保发送请求的用户或服务账号具有执行请求的权限。
数据持久化：一旦请求通过验证和授权，API Server负责将Pod定义存储在etcd中，etcd是Kubernetes的分布式持久存储系统，用来保存所有集群数据。
调度Pod：API Server并不直接调度Pod。取而代之，它将Pod状态更新为Pending，等待调度器（Scheduler）表示有可用节点来运行该Pod。调度器观察等待调度的Pod（状态为Pending），选择一个合适的节点，将Pod分配到该节点。
启动Pod：在Pod被调度到特定节点后，API Server向指定节点的kubelet发出指示，通知其有新的Pod要启动。kubelet负责与节点上的容器运行环境（如Docker、containerd）交互，创建和启动Pod的相关容器。
状态更新：在Pod启动过程中，kubelet不断向API Server报告Pod的状态，如处于启动中、运行中或失败等。API Server更新的这些状态信息使用户和其他集群组件能够查询Pod的实时状态。
事件记录：API Server会记录Pod创建过程中发生的所有重要事件，并将其存储在etcd中。这些事件可以通过kubectl或API获取，以了解创建Pod过程中发生的事项。
工作负载控制器的交互：如果Pod由工作负载控制器（如Deployment、StatefulSet、DaemonSet等）管理，那么API Server也会与相应的控制器交互，由控制器负责维护所需数量的Pod副本和处理Pod的生命周期。

需要注意的是，API Server并不会直接管理容器，容器是由kubelet管理的。

2.2 ETCD

在Kubernetes中，etcd是一个分布式的键值存储，用于持久保存所有集群数据，它是Kubernetes最重要的数据存储组件，用于存储集群的配置和状态信息。以下是etcd在创建Pod过程中的作用：

存储Pod配置：当你创建一个Pod（或通过Deployment、StatefulSet等控制器间接创建Pod）时，Pod的配置（定义在YAML文件中的内容）被API Server接收后会存储在etcd中。
保存Pod状态：除了保存配置数据外，etcd也会保存Pod的状态信息，比如它是正在启动还是正在运行，或者是否遇到了错误。
调度辅助（保存节点信息）：当Kubernetes Scheduler选择一个节点来运行新的Pod时，它会根据etcd中保存的信息，比如每个节点的资源利用率和现有工作负载，来做出决定。
集群状态的一致性：etcd使用Raft协议来确保集群的强一致性。当创建Pod时，多个API Server在更新状态时会使用etcd作为事实的单一来源，以避免冲突和不一致。
Pod生命周期管理：随着Pod生命周期的变化，它的状态会不断被更新到etcd。例如，如果Pod成功调度到一个节点，它的状态会从“Pending”更新为“Running”状态，并且反映在etcd数据中。
恢复和故障转移：如果Kubernetes集群中的某些部分遇到了失败（例如一个API Server宕机），etcd中的信息可以用来恢复Pod的状态和集群的总体状态。
事件记录：Pod创建和管理过程中发生的重要事件也会被存入etcd中，以便其他组件可以执行后续操作或提供调试信息。

总之，在创建Pod的过程中，etcd的作用是存储Pod的所有相关信息，包括配置、状态和事件，以及集群中的其他重要信息（如服务、密钥、配置映射等）。这使得Kubernetes集群能够在多个组件协同工作的情况下保持信息的一致性和可靠性。由于etcd存储的数据至关重要，因此运维人员应确保etcd的高可用性和定期备份。

2.3 Scheduler

在Kubernetes (k8s) 中创建Pod的过程中，Scheduler起到了至关重要的作用。以下是Scheduler在这一过程中详细的工作流程和功能说明：

Pod创建请求：首先，用户或者自动化工具（如控制器）通过向Kubernetes API Server提交YAML文件或使用kubectl create命令等方式，定义一个新的Pod。API Server接收到这个创建请求后，会将其持久化到etcd（Kubernetes的分布式键值存储）中，但此时Pod的status字段通常标记为Pending，表示Pod尚未被调度到任何节点上运行。
Scheduler监听与发现待调度Pod：Kubernetes Scheduler是一个独立的控制平面组件，它持续监听API Server，寻找那些处于Pending状态且未被调度的Pods。一旦发现新的待调度Pod，Scheduler便开始介入其调度过程。
收集可用节点信息：Scheduler从API Server获取当前集群中所有可用Node（即物理或虚拟机器）的列表，同时收集每个Node的详细信息，包括但不限于：
资源状况：如CPU、内存、GPU、磁盘、网络带宽等资源的总量与已使用量。
节点状态：如节点是否健康、是否处于维护模式、是否存在临时性污点（taints）等。
节点标签（Labels）：用于匹配Pod的节点选择器（nodeSelector）或亲和性/反亲和性规则（affinity/anti-affinity）。
扩展属性：如节点的拓扑位置（如区域、可用区、机架）、硬件特性等。
评估调度约束与偏好：针对待调度的Pod，Scheduler会依据以下因素来评估其能否被放置到某个Node上：
资源需求：确保目标Node有足够的可用资源（CPU、内存等）来满足Pod的资源请求。
节点选择器：检查Pod的spec.nodeSelector是否与目标Node的标签相匹配。
亲和性与反亲和性规则：评估Pod的spec.affinity或spec.antiAffinity设置，确保Pod能按照指定的规则与其他Pods或Nodes保持或避免特定关系。
污点与容忍度（Taints & Tolerations）：检查目标Node是否有阻止普通Pods被调度的污点，以及待调度Pod是否具有相应的容忍度来接受这些污点。
其他高级调度策略：如优先级（priorityClass）、抢占（preemption）、延迟调度（scheduling delays）等。
打分与优选：对于每个符合基本调度条件的Node，Scheduler会应用一系列预定义或自定义的调度策略（也称为评分规则或插件）进行打分。这些策略可能基于资源利用率、负载均衡、拓扑分布等因素为每个Node分配一个分数。最终，Scheduler会选择得分最高的Node作为最佳调度目标。如果存在多个Node得分相同且均为最高，Scheduler通常会从中随机选择一个，以实现某种程度的负载分散。
绑定决策与提交：Scheduler作出调度决定后，会将Pod与选定的Node进行“绑定”，即将Pod的spec.nodeName字段设置为所选Node的名称。然后，Scheduler通过API Server更新Pod的状态，将这一调度决定持久化到etcd中。
kubelet启动Pod：当API Server将调度结果推送给各个Node上运行的kubelet组件时，kubelet会检测到新分配给本节点的Pod，并开始执行必要的操作来启动Pod，包括拉取镜像、创建容器、配置网络等。随着Pod的容器启动并进入运行状态，kubelet会更新Pod的状态至Running，至此，Pod创建过程完成，应用程序在选定的Node上开始提供服务。

总结来说，Kubernetes Scheduler在Pod创建过程中承担着关键的决策角色，负责根据集群状态和用户提供的调度策略，智能地将待调度Pod分配到最适合的Node上运行，确保资源的有效利用、服务的高可用性和用户的定制化需求得到满足。

2.4 kubelet

kubelet是Kubernetes集群中每个节点上的核心组件，负责在节点级别上管理Pod和容器的生命周期。以下是kubelet在创建Pod过程中的具体作用：

接收和验证Pod配置：当Kubernetes Master（包括API Server和Scheduler组件）确定了一个Pod应该运行在某个节点上后，会将该Pod的完整配置（包含容器镜像、环境变量、卷挂载、端口映射、资源限制等）发送给目标节点上的kubelet。kubelet通过与API Server建立的长连接（通常通过TLS加密和身份认证）接收这些配置信息。
验证节点资源：接收到Pod配置后，kubelet首先检查节点上的可用资源（如CPU、内存、磁盘空间、网络等），确保有足够的资源来启动和运行新的Pod。如果节点资源不足，kubelet将拒绝创建Pod，并可能触发节点的资源压力报告，促使Scheduler重新调度该Pod到其他资源充足的节点。
创建容器：在确认节点资源足够后，kubelet根据Pod配置开始创建容器。这包括：
与容器运行时（如Docker、containerd、CRI-O等）交互，拉取指定的容器镜像（如果尚未本地存在）。
准备Pod的存储卷，如挂载PersistentVolumes、创建EmptyDirs或下载Secret、ConfigMap等。
设置容器的网络配置，包括为Pod分配IP地址（通常通过CNI插件如Calico、Flannel等）、配置网络命名空间和端口映射。
启动容器：在容器镜像准备就绪、存储卷挂载成功以及网络配置完成后，kubelet向容器运行时发出指令启动容器。容器内的进程开始运行，kubelet监控其启动过程，确保容器进入运行状态。
监控容器健康与资源使用：启动后的容器会持续受到kubelet的监控。kubelet通过容器运行时提供的接口检查容器的运行状态、响应性（通过Liveness和Readiness Probes）以及资源消耗（CPU、内存、磁盘I/O、网络带宽等）。根据这些监控数据，kubelet可能会执行以下操作：
如果容器未通过Liveness Probe，表明容器内部服务可能已失效，kubelet会按照Pod的restartPolicy规则决定是否重启容器。
如果容器未通过Readiness Probe，kubelet会将该容器标记为未就绪，影响Service对其流量的分发。
如果容器超出其请求的资源限制，kubelet可能会对容器实施throttling（限速）以防止节点资源耗尽。
维护节点状态与上报：kubelet不断更新节点的状态信息，包括节点资源使用情况、正在运行的Pod和容器列表、节点条件（如磁盘压力、网络问题等）等，并通过心跳机制定期向API Server报告这些状态。这些信息对Scheduler进行后续调度决策至关重要。
处理Pod更新与清理：当Pod配置发生变更（如滚动更新）或Pod被删除时，kubelet负责执行相应的更新操作（如重新创建容器）或清理工作（如停止容器、释放资源、卸载存储卷、清除网络配置）。