K8S_Pod

Pod是什么？

Pod是Kubernetes中的最小调度单元
Pod里的容器共享存储、网络等
把整个pod看作虚拟机，然后每个容器相当于运行在虚拟机的进程。
Pod是需要调度到k8s集群的工作节点来运行的，根据scheduler调度器实现。

Pod如何管理多个容器？

Pod中可以同时运行多个容器。同一个Pod中的容器会自动的分配到同一个 node 上。
同一个Pod中的容器共享资源、网络环境，它们总是被同时调度。
在一个Pod中同时运行多个容器是一种比较高级的用法，只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件。

一个 Pod 包含N(N>=0)个 Init 容器（初始化容器），M个(M>=1)应用容器（主容器）

怎么理解？我们可以通过“生命周期”和“职责分工”来把 Pod 里的容器分为两类：

应用容器（Main Containers）

定义：这是 Pod 的核心，承载你的业务应用（比如 Java、Go、Nginx 等）。

生命周期：一旦所有 Init 容器完成，应用容器就会并行启动，并且一直运行（除非崩溃或重启）。如果它们退出，Pod 的生命周期就结束了。

特点：它们共享 Pod 的网络命名空间、存储卷等资源，通常用于实现主要业务逻辑。

Init 容器（Init Containers）

定义：在应用容器启动之前运行的专用容器。

生命周期：它们按顺序执行（一个执行完才执行下一个），必须全部成功完成（退出码为 0），应用容器才会启动。一旦完成，它们就会终止，退出历史舞台

Pod网络

在k8s中，启动Pod时，会先启动⼀个pause 的容器，然后将后续的所有容器都 "link 到这个pause 的容器，以实现⽹络共享。

Pod存储

创建Pod的时候可以指定挂载的存储卷。 POD中的所有容器都可以访问共享卷，允许这些容器共享数据。 Pod只要挂载持久化数据卷，Pod重启之后数据还是会存在的。

Pod工作方式

自主式Pod-->直接定义一个Pod资源

控制器管理的Pod-->控制器管理的Pod可以确保Pod始终维持在指定的副本数运行。

组件间的基本交互流程

第一阶段：用户创建 Pod 对象

用户发送请求：用户向 API Server 发送“创建 Pod”的请求（注意：虽然图里写的是直接创建 Pod，但如果是 Deployment，这里其实是创建 Deployment，然后由 Controller 自动生成 Pod 对象发给 API Server）。

API Server 写入 etcd：API Server 收到请求后，进行认证、授权、准入控制。注意：此时 API Server 并没有去创建容器，它只是将这个 Pod 的期望状态（JSON 数据）写入到 etcd 中。

etcd 返回确认：etcd 写入成功后，返回信息给 API Server。

API Server 响应用户：API Server 告诉用户：“收到，Pod 对象已记录在案。”（此时 Pod 状态为 Pending，还没有节点）。

第二阶段：调度器分配节点（Scheduling）

调度器监控到新建 Pod：调度器 一直在监听（Watch）API Server。它发现有新的 Pod 被创建，且 spec.nodeName 是空的。

调度器绑定 Pod：调度器 经过一系列过滤（Filter）和打分（Score），选出了最合适的一个 Node 节点。然后向 API Server 发送“绑定（Bind）”请求，告诉它：“把这个 Pod 分配给 Node A 吧”。

API Server 更新 etcd：API Server 收到绑定请求，更新 etcd 中该 Pod 的信息（写入 nodeName: Node A）。

etcd 返回确认：etcd 更新成功，返回信息给 API Server。

API Server 响应调度器：API Server 告诉调度器：“绑定成功”。（此时 Pod 状态变为 ContainerCreating，准备开始创建容器）。

第三阶段：节点上启动容器（Kubelet 干活）

kubelet 监控到已绑定的 Pod：目标节点上的 kubelet 也在一直监听 API Server。它发现有一个 Pod 被绑定到了自己所在的节点。

kubelet 调用容器运行时：kubelet 根据 Pod 的详细定义，调用底层的 容器运行时（CRI），说：“去把 Nginx 镜像拉下来，启动容器”。

容器运行时返回结果：容器运行时 完成拉取镜像、创建容器、启动容器等一系列操作后，将运行结果（成功或失败）返回给 kubelet。

kubelet 更新 Pod 状态：kubelet 将 Pod 的最新实际状态（比如 Running 或 Error）发送给 API Server。

API Server 更新 etcd：API Server 将最新的状态写入 etcd。

etcd 返回确认：etcd 更新成功，返回信息给 API Server。

API Server 响应 kubelet：API Server 告诉 kubelet：“状态已更新”。

API Server 是唯一的“总线”：图中所有的箭头，没有任何一个组件是直接跨过 API Server 去和 etcd 或其他组件通信的。etcd 只和 API Server 说话，调度器只和 API Server 说话，kubelet 也只和 API Server 说话。这是 K8s 安全性和解耦的关键。

“Watch” 机制（异步监听）：图中的“监控到...” 体现了 K8s 的声明式 API。组件之间不互相发指令（不推），而是大家去盯住 API Server 看状态变化（拉）。API Server 就像一个公告板，谁有变化就往上一贴，需要关心的人自己去看。

状态持久化（etcd）：每一笔状态变更（从创建、绑定到运行）都立刻写入 etcd。这意味着哪怕此时整个集群断电，重启后也能根据 etcd 里的记录恢复出整个集群的状态。