k8s中pod 的创建开始到结束详细过程

1.在 k8s 里面从一个 pod 的创建开始到结束，这期间用了什么组件？他们起到 什么样的作用？

1. API Server

• 作用：接收 Pod 创建哀求，验证设置并存储到 etcd，关照其他组件。
  
• 流程：
  
  
  
  • 验证 Pod 设置文件的合法性。
    
  • 将 Pod 的界说存储到 etcd 中，作为集群的持久化存储。
    
  • 关照其他组件 Pod 的状态变化。
    
  
  

2. etcd

• 作用：存储 Pod 的界说和状态信息
  
• 流程：
  
  
  
  • 接收 API Server 写入的 Pod 界说。
    
  • 提供 Pod 状态的持久化存储。
    
  
  

3. Scheduler（调理器）

• 作用：选择合适的节点来运行 Pod，并将 Pod 绑定到节点。
  
• 流程：
  
  
  
  • 监听 API Server，查找处于 Pending 状态的 Pod。
    
  • 根据资源需求、节点状态、亲和性规则等选择最佳节点。
    
  • 将 Pod 绑定到选定的节点，并更新状态到 etcd。
    
  
  

4. Kubelet

• 作用：在节点上管理 Pod 生命周期，与容器运行时协作，启动和监控容器。
  
• 流程：
  
  
  
  • 监听 etcd 或 API Server 的变化，发现新分配到本节点的 Pod。
    
  • 与容器运行时（如 containerd）协作，拉取镜像、创建容器。
    
  • 调用 CNI 插件为 Pod 设置网络。
    
  • 监控 Pod 和容器的运行状态，并将状态信息反馈给 API Server。
    
  
  

5. 容器运行时（如 Docker、containerd）

• 作用：拉取镜像并管理容器的创建、运行和销毁。
  
• 流程：
  
  
  
  • 根据 Kubelet 的指令拉取镜像。
    
  • 创建、启动、停止和删除容器。
    
  
  

6. CNI（容器网络接口）插件

• 作用：CNI 插件负责为 Pod 提供网络功能。
  
• 流程：
  
  
  
  • 为 Pod 分配 IP 所在。
    
  • 设置网络设备和路由规则。
    
  
  

7. Pause 容器

• 作用：Pause 容器是 Pod 的底子设施容器，为其他容器提供共享的网络、PID 和 IPC 定名空间。
  
• 流程：
  
  
  
  • 在 Pod 启动时起首运行，初始化网络和存储卷。
    
  • 其他容器共享 Pause 容器的网络和定名空间。
    
  
  

8. Controller Manager

• 作用：Controller Manager 包含多个控制器，负责集群的自动化管理。
  
• 流程：
  
  
  
  • 监控 Pod 的状态，确保 Pod 副本数量符合预期。
    
  • 在节点故障时重新调理 Pod。
    
  
  

Pod 的生命周期

• Pending：Pod 已被创建，但尚未分配到节点上。
  
• Running：Pod 已绑定到节点，容器已启动。
  
• Succeeded：Pod 中的全部容器正常退出。
  
• Failed：Pod 中的容器因错误退出。
  
• Unknown：Pod 状态未知，通常是因为节点通信问题。
  

Pod 创建和分配到 Worker 节点的详细过程 

1. Pod 的创建哀求

• 用户通过 kubectl 或其他客户端工具向 Kubernetes 集群提交 Pod 创建哀求。
  
• 这个哀求起首发送到 API Server，API Server 是 Kubernetes 控制平面的核心组件，运行在 Master 节点上。
  

---

2. API Server 的处理

• API Server 接收到 Pod 创建哀求后，会验证 Pod 设置的合法性。
  
• 如果验证通过，API Server 会将 Pod 的界说存储到 etcd（集群的持久化存储，通常也运行在 Master 节点上）。
  
• 此时，Pod 的状态为 Pending，表示它已经被创建，但尚未分配到详细的节点。
  

---

3. Scheduler 的调理

• Scheduler（调理器）运行在 Master 节点上，它会监听 etcd 中处于 Pending 状态的 Pod。
  
• Scheduler 根据一系列规则（如资源需求、亲和性规则、节点状态等）选择一个合适的 Worker 节点 来运行 Pod。
  
• 一旦选择完成，Scheduler 会将 Pod 绑定到选定的 Worker 节点，并将绑定信息更新到 etcd 中。
  

---

4. Kubelet 的实行

• 每个 Worker 节点 上都运行着一个 Kubelet 署理。
  
• Kubelet 会定期从 etcd 或 API Server 中获取分配给本节点的 Pod 信息。
  
• 当 Kubelet 发现有新的 Pod 被分配到本节点时，它会与容器运行时（如 containerd 或 Docker）协作，完成以下操作：
  
  
  
  • 拉取 Pod 中容器的镜像。
    
  • 创建 Pause 容器（如果需要）。
    
  • 启动 Pod 中的容器。
    
  • 设置网络（通过 CNI 插件）。
    
  
  
• 一旦 Pod 中的全部容器都乐成启动，Pod 的状态会变为 Running。
  

Running 状态到 终止 的各个阶段 

5. Pod 的运行与监控

当 Pod 的状态变为 Running 后，Kubernetes 会连续监控 Pod 的运行状态，确保其正常运行：
5.1. 康健检查

• 存活探针（Liveness Probe）：定期检查容器是否仍在运行。如果探针失败，Kubernetes 会自动重启容器。
  
• 停当探针（Readiness Probe）：检查容器是否准备好接收流量。如果失败，Pod 会被从服务的负载平衡器中移除，直到恢复。
  
• 启动探针（Startup Probe）：用于检测容器的启动状态，确保容器能够正常启动。
  

5.2. 资源监控

• Kubelet：连续监控 Pod 的资源利用情况（如 CPU、内存），并根据设置的资源限制（Resource Limits）进行管理。
  
• 变乱记载：Kubernetes 会记载 Pod 的运行变乱，如容器重启、资源不足等，这些变乱可以通过 kubectl describe pod <pod-name> 查看。
  

5.3. 日志收集

• Pod 中的容器日志会由 Kubelet 收集，并可以通过 kubectl logs <pod-name> 查看。在生产情况中，日志通常会被发送到会合式日志体系（如 Elasticsearch、Fluentd、Kibana）。
  

---

6. Pod 的终止

Pod 的终止可能是由用户主动触发（如 kubectl delete pod），也可能是由于资源不足、节点故障或 Pod 完成任务后自动触发。
6.1. 终止哀求

• 用户通过 kubectl delete pod <pod-name> 或其他方式哀求删除 Pod。
  
• API Server 接收到哀求后，将 Pod 的状态设置为 Terminating，并关照干系组件开始终止流程。
  

6.2. 预终止钩子（PreStop Hook）

• 如果 Pod 中的容器界说了 PreStop 钩子，Kubelet 会先实行该钩子。PreStop 钩子通常用于在容器终止前实行清理操作，如关闭服务、释放资源等。
  

6.3. 终止信号

• Kubelet 向 Pod 中的容器发送 SIGTERM 信号，关照容器开始优雅退出。
  
• 容器在接收到 SIGTERM 信号后，应尽量完成当前任务并退出。如果容器在指定的终止宽限期（默认 30 秒）内未退出，Kubelet 会发送 SIGKILL 信号强制终止容器。
  

6.4. 网络隔离

• 在 Pod 被标志为 Terminating 后，Kubernetes 会立刻将其从集群的网络中隔离，Pod 的 IP 所在和端口不再接受新流量。
  

6.5. 清理资源

• Kubelet 确保 Pod 中的全部容器都已终止后，释放 Pod 占用的资源，如存储卷、网络接口等。
  
• 如果 Pod 利用了动态存储卷，存储卷可能会根据设置被保存或删除。
  

6.6. 从 etcd 中移除

• 最后，Kubelet 关照 API Server，Pod 已完全终止。API Server 从 etcd 中删除 Pod 的记载，完成整个终止流程。
  

---

7. Pod 的最终状态

• Succeeded：Pod 中的全部容器正常退出，任务完成。
  
• Failed：Pod 中的容器因错误退出，任务失败。
  
• Terminating：Pod 正在被终止，但尚未完全清理。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告