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 的生命周期

1. Pending：Pod 已被创建，但尚未分配到节点上。

2. Running：Pod 已绑定到节点，容器已启动。

3. Succeeded：Pod 中的所有容器正常退出。

4. Failed：Pod 中的容器因错误退出。

5. 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）协作，完成以下操作：

  1. 拉取 Pod 中容器的镜像。

  2. 创建 Pause 容器（如果需要）。

  3. 启动 Pod 中的容器。

  4. 配置网络（通过 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 正在被终止，但尚未完全清理。