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

下图为k8s 创建pod的流程，我们来分析一下创建的过程以及各组件起的作用

一、创建过程

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 的过程中起着非常重要的作用，它不仅是命令和请求的中间人，还负责确保集群的期望状态与实际状态保持一致，并作为所有组件之间通信的枢纽。以下是 API Server 在创建 Pod 过程中的作用：

2.1.1 接收请求：

当用户通过 kubectl 命令行工具、API 客户端或通过其他方式（如 CI/CD 工具）向 API Server 发出创建 Pod 的请求时，API Server 是接收和处理这些请求的组件。

2.1.2. 验证和授权：

API Server 对请求进行验证，确保请求来自一个已经认证的用户、服务账号或其他实体。然后，它会进行授权检查，以确保发送请求的用户或服务账号具有执行请求的权限。

2.1.3. 数据持久化：

一旦请求通过验证和授权，API Server 负责将 Pod 定义存储在 etcd 中，etcd 是 Kubernetes 的分布式持久存储系统，用来保存所有集群数据。

2.1.4. 调度 Pod：

API Server 并不直接调度 Pod。取而代之，它将 Pod 状态更新为 Pending，等待调度器（Scheduler）表示有可用节点来运行该 Pod。调度器观察等待调度的 Pod（状态为 Pending），选择一个合适的节点，将 Pod 分配到该节点。

2.1.5. 启动 Pod：

在 Pod 被调度到特定节点后，API Server 向指定节点的 kubelet 发出指示，通知其有新的 Pod 要启动。kubelet 负责与节点上的容器运行环境（如 Docker、containerd）交互，创建和启动 Pod 的相关容器。

2.1.6. 状态更新：

在 Pod 启动过程中，kubelet 不断向 API Server 报告 Pod 的状态，如处于启动中、运行中或失败等。API Server 更新的这些状态信息使用户和其他集群组件能够查询 Pod 的实时状态。

2.1.7. 事件记录：

API Server 会记录 Pod 创建过程中发生的所有重要事件，并将其存储在 etcd 中。这些事件可以通过 kubectl 或 API 获取，以了解创建 Pod 过程中发生的事项。

2.1.8. 工作负载控制器的交互：

如果 Pod 由工作负载控制器（如 Deployment、StatefulSet、DaemonSet 等）管理，那么 API Server 也会与相应的控制器交互，由控制器负责维护所需数量的 Pod 副本和处理 Pod 的生命周期。

！！！API Server 并不会直接管理容器，容器是由kubelet 管理的。

2.2、ETCD

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

2.2.1. 存储 Pod 配置：

当你创建一个 Pod（或通过 Deployment、StatefulSet 等控制器间接创建 Pod）时，Pod 的配置（定义在 YAML 文件中的内容）被 API Server 接收后会存储在 etcd 中。

2.2.2. 保存 Pod 状态：

除了保存配置数据外，etcd 也会保存 Pod 的状态信息，比如它是正在启动还是正在运行，或者是否遇到了错误。

2.2.3. 调度辅助（保存节点信息）：

当 Kubernetes Scheduler 选择一个节点来运行新的 Pod 时，它会根据 etcd 中保存的信息，比如每个节点的资源利用率和现有工作负载，来做出决定。

2.2.4. 集群状态的一致性：

etcd 使用 Raft 协议来确保集群的强一致性。当创建 Pod 时，多个 API Server 在更新状态时会使用 etcd 作为事实的单一来源，以避免冲突和不一致。

2.2.5. Pod 生命周期管理：

随着 Pod 生命周期的变化，它的状态会不断被更新到 etcd。例如，如果 Pod 成功调度到一个节点，它的状态会从 “Pending” 更新为 “Running” 状态，并且反映在 etcd 数据中。

2.2.6. 恢复和故障转移：

如果 Kubernetes 集群中的某些部分遇到了失败（例如一个 API Server 宕机），etcd 中的信息可以用来恢复 Pod 的状态和集群的总体状态。

2.2.7. 事件记录：

Pod 创建和管理过程中发生的重要事件也会被存入 etcd 中，以便其他组件可以执行后续操作或提供调试信息。

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

2.3、Scheduler

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

2.3.1. Pod 创建请求

首先，用户或者自动化工具（如控制器）通过向 Kubernetes API Server 提交 YAML 文件或使用 kubectl create 命令等方式，定义一个新的 Pod。API Server 接收到这个创建请求后，会将其持久化到 etcd（Kubernetes 的分布式键值存储）中，但此时 Pod 的 status 字段通常标记为 Pending，表示 Pod 尚未被调度到任何节点上运行。

2.3.2. Scheduler 监听与发现待调度 Pod

Kubernetes Scheduler 是一个独立的控制平面组件，它持续监听 API Server，寻找那些处于 Pending 状态且未被调度的 Pods。一旦发现新的待调度 Pod，Scheduler 便开始介入其调度过程。

2.3.3. 收集可用节点信息

Scheduler 从 API Server 获取当前集群中所有可用 Node（即物理或虚拟机器）的列表，同时收集每个 Node 的详细信息，包括但不限于：

• 资源状况：如 CPU、内存、GPU、磁盘、网络带宽等资源的总量与已使用量。
• 节点状态：如节点是否健康、是否处于维护模式、是否存在临时性污点（taints）等。
• 节点标签（Labels）：用于匹配 Pod 的节点选择器（nodeSelector）或亲和性/反亲和性规则（affinity/anti-affinity）。
• 扩展属性：如节点的拓扑位置（如区域、可用区、机架）、硬件特性等。

2.3.4. 评估调度约束与偏好

针对待调度的 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）等。

2.3.5. 打分与优选

对于每个符合基本调度条件的 Node，Scheduler 会应用一系列预定义或自定义的调度策略（也称为评分规则或插件）进行打分。这些策略可能基于资源利用率、负载均衡、拓扑分布等因素为每个 Node 分配一个分数。最终，Scheduler 会选择得分最高的 Node 作为最佳调度目标。

如果存在多个 Node 得分相同且均为最高，Scheduler 通常会从中随机选择一个，以实现某种程度的负载分散。

2.3.6. 绑定决策与提交

Scheduler 作出调度决定后，会将 Pod 与选定的 Node 进行“绑定”，即将 Pod 的 spec.nodeName 字段设置为所选 Node 的名称。然后，Scheduler 通过 API Server 更新 Pod 的状态，将这一调度决定持久化到 etcd 中。

2.3.7. kubelet 启动 Pod

当 API Server 将调度结果推送给各个 Node 上运行的 kubelet 组件时，kubelet 会检测到新分配给本节点的 Pod，并开始执行必要的操作来启动 Pod，包括拉取镜像、创建容器、配置网络等。随着 Pod 的容器启动并进入运行状态，kubelet 会更新 Pod 的状态至 Running，至此，Pod 创建过程完成，应用程序在选定的 Node 上开始提供服务。

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

被驱逐的pod分配到其他节点上，scheduler 起了什么作用？

在 Kubernetes 集群中，当一个 Pod 被驱逐（evicted）时，这通常是由于它所在的节点出现了问题（如资源不足、节点维护、节点故障等），或者是因为集群管理员执行了手动驱逐操作。在这种情况下，Kubernetes 的核心组件之一——kube-scheduler 就会发挥关键作用，确保被驱逐的 Pod 能够被重新分配到健康的节点上并恢复服务。

以下是 kube-scheduler 在处理被驱逐 Pod 分配到其他节点过程中的具体职责和工作流程：

1. 监控事件与状态变化：
   kube-scheduler 会持续监听 Kubernetes API Server 中的事件和资源状态变化。当它检测到一个 Pod 被标记为“Evicted”状态（通常伴有详细的驱逐原因），它就知道这个 Pod 需要重新调度。

2. 候选节点筛选：
   基于集群中所有可用节点的信息，kube-scheduler 会根据预定义的调度策略和算法来筛选出一组候选节点。这些策略可能包括但不限于：

   • 资源可用性：检查节点是否有足够的 CPU、内存、磁盘空间等资源来容纳被驱逐 Pod 的资源请求。
   • 亲和性和反亲和性规则：考虑 Pod 的标签选择器、节点亲和性/反亲和性表达式（如节点标签、拓扑区域等），确保 Pod 被调度到满足特定规则的节点上。
   • 污点（Taints）与容忍度（Tolerations）：检查节点是否存在阻止普通 Pod 调度的污点以及被驱逐 Pod 是否具有相应的容忍度以适应这些特殊节点。
   • 服务质量要求：考虑 Pod 是否有特定的服务质量（QoS）需求，如需要运行在特定类型的节点（如专用硬件、GPU节点等）上。

3. 优先级评分与打分插件：
   kube-scheduler 可能会应用一系列内置或自定义的打分插件来为每个候选节点赋予一个优先级得分。这些插件可以根据各种因素（如资源利用率、网络延迟、负载均衡等）对节点进行评估，帮助确定最佳调度位置。

4. 确定目标节点：
   根据筛选和评分结果，kube-scheduler 会选择得分最高的节点作为被驱逐 Pod 的新目标节点。这个决策过程确保了 Pod 被调度到既满足其资源需求又符合集群整体优化目标的位置。

5. 更新调度决定：
   最后，kube-scheduler 通过向 Kubernetes API Server 发送请求，将被驱逐 Pod 的 .spec.nodeName 字段更新为所选目标节点的名称，从而正式触发 Pod 的重新调度。Kubernetes 集群中的相应节点上的 kubelet 组件随后会接收到这一变更通知，开始拉取 Pod 的容器镜像、创建容器，并最终启动 Pod，使其恢复服务。

综上所述，kube-scheduler 在被驱逐的 Pod 分配到其他节点的过程中起到了关键的决策者角色，通过综合运用多种策略和算法，确保 Pod 能够快速、有效地迁移到一个合适的替代节点上继续运行，从而维持整个集群服务的稳定性和高可用性。

2.4、kubelet

kubelet 是 Kubernetes 集群中每个节点上的核心组件，负责在节点级别上管理 Pod 和容器的生命周期。当 Kubernetes 需要在某个节点上创建一个 Pod 时，kubelet 扮演着至关重要的角色，具体作用包括以下几个方面：

2.4.1. 接收和验证 Pod 配置:

当 Kubernetes Master（包括 API Server 和 Scheduler 组件）确定了一个 Pod 应该运行在某个节点上后，会将该 Pod 的完整配置（包含容器镜像、环境变量、卷挂载、端口映射、资源限制等）发送给目标节点上的 kubelet。kubelet 通过与 API Server 建立的长连接（通常通过 TLS 加密和身份认证）接收这些配置信息。

2.4.2. 验证节点资源:

接收到 Pod 配置后，kubelet 首先检查节点上的可用资源（如 CPU、内存、磁盘空间、网络等），确保有足够的资源来启动和运行新的 Pod。如果节点资源不足，kubelet 将拒绝创建 Pod，并可能触发节点的资源压力报告，促使 Scheduler 重新调度该 Pod 到其他资源充足的节点。

2.4.3. 创建容器:

在确认节点资源足够后，kubelet 根据 Pod 配置开始创建容器。这包括：

• 与容器运行时（如 Docker、containerd、CRI-O 等）交互，拉取指定的容器镜像（如果尚未本地存在）。
• 准备 Pod 的存储卷，如挂载 PersistentVolumes、创建 EmptyDirs 或下载 Secret、ConfigMap 等。
• 设置容器的网络配置，包括为 Pod 分配 IP 地址（通常通过 CNI 插件如 Calico、Flannel 等）、配置网络命名空间和端口映射。

2.4.4. 启动容器:

在容器镜像准备就绪、存储卷挂载成功以及网络配置完成后，kubelet 向容器运行时发出指令启动容器。容器内的进程开始运行，kubelet 监控其启动过程，确保容器进入运行状态。

2.4.5. 监控容器健康与资源使用:

启动后的容器会持续受到 kubelet 的监控。kubelet 通过容器运行时提供的接口检查容器的运行状态、响应性（通过 Liveness 和 Readiness Probes）以及资源消耗（CPU、内存、磁盘 I/O、网络带宽等）。根据这些监控数据，kubelet 可能会执行以下操作：

• 如果容器未通过 Liveness Probe，表明容器内部服务可能已失效，kubelet 会按照 Pod 的 restartPolicy 规则决定是否重启容器。
• 如果容器未通过 Readiness Probe，kubelet 会将该容器标记为未就绪，影响 Service 对其流量的分发。
• 如果容器超出其请求的资源限制，kubelet 可能会对容器实施 throttling（限速）以防止节点资源耗尽。

2.4.6. 维护节点状态与上报:

kubelet 不断更新节点的状态信息，包括节点资源使用情况、正在运行的 Pod 和容器列表、节点条件（如磁盘压力、网络问题等）等，并通过心跳机制定期向 API Server 报告这些状态。这些信息对 Scheduler 进行后续调度决策至关重要。

2.4.7. 处理 Pod 更新与清理:

当 Pod 配置发生变更（如滚动更新）或 Pod 被删除时，kubelet 负责执行相应的更新操作（如重新创建容器）或清理工作（如停止容器、释放资源、卸载存储卷、清除网络配置）。

综上所述，kubelet 在 Kubernetes 中创建 Pod 的过程中承担了从接收配置、验证资源、创建和启动容器、监控运行状态到维护节点状态与上报等一系列关键职责，确保 Pod 能够在节点上正确、高效地创建并持续运行。同时，kubelet 还负责处理 Pod 的生命周期变更，确保节点资源的有效管理和回收。