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企服之家，中国第一个企服评测及商务社交产业平台。 |
