目录
[1、POD 的创建流程](#1、POD 的创建流程)
[kubectl 发起创建 Pod 请求：](#kubectl 发起创建 Pod 请求：)
[API Server 接收请求并处理：](#API Server 接收请求并处理：)
[写入 Etcd 数据库：](#写入 Etcd 数据库：)
[Kubelet 监听并创建 Pod：](#Kubelet 监听并创建 Pod：)
[Pod 状态更新和汇报：](#Pod 状态更新和汇报：)
[2、POD 的状态解析](#2、POD 的状态解析)
[1. Pending Pod](#1. Pending Pod)
[2. Running Pod](#2. Running Pod)
[3. Succeeded Pod](#3. Succeeded Pod)
[4. Failed Pod](#4. Failed Pod)
[5. Unknown](#5. Unknown)
[6. CrashLoopBackOff](#6. CrashLoopBackOff)
[7. ImagePullBackOff Pod](#7. ImagePullBackOff Pod)
[8. Terminating](#8. Terminating)
[9. Evicted](#9. Evicted)
[10. OOMKilled](#10. OOMKilled)
[11. ContainerCreating](#11. ContainerCreating)
[12. Completed](#12. Completed)
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元;
Pod 中会启动一个或一组紧密相关的业务容器, 各个业务容器相当于Pod 中的各个进程, 此时就可以将Pod 作为虚拟机看待;
在创建 Pod 时会启动一个init容器, 用来初始化存储和网络, 其余的业务容器都将在init容器启动后启动, 业务容器共享init容器的存储和网络;
Pod 只是一个逻辑单元, 并不是真实存在的"主机", 这种类比主机的概念可以更好的符合现有互联网中几乎所有的虚拟化设计;
像之前运行在虚拟机中的 nginx、mysql、php均可以使用对应的镜像运行出对应的容器在Pod中, 来类比虚拟机中运行这三者;
对于 Pod 而言, 在运行的过程中, k8s为了控制其生命周期的状态, 增加了++容器探测指针++ 、++资源限额++ 、++期望状态保持++ 、++多容器结合++ 、++安全策略设定++ 、++控制器受管++ 、++故障处理策略++ 等;
Pod在平时是不能够被单独创建的, 而是需要使用控制器对其创建, 这样可以时刻保持Pod的期望状态。
1、POD 的创建流程
kubectl 发起创建 Pod 请求：
用户通过 kubectl create 命令（或其他等效方式）向 Kubernetes API Server 发起一个创建 Pod 的请求。这个请求包含了 Pod 的定义，通常是一个 YAML 或 JSON 格式的文件。
API Server 接收请求并处理：
Kubernetes API Server 接收到创建 Pod 的请求后，会对请求进行验证和授权检查。 API Server 不会直接创建 Pod，而是将这个请求转化为一个内部表示（如一个含有 Pod 创建信息的 YAML 格式的对象）。
写入 Etcd 数据库：
API Server 将这个 Pod 对象的信息写入到 Etcd 数据库。Etcd 作为 Kubernetes 的数据存储，保存了集群的状态和配置。 Scheduler 进行调度： Kubernetes Scheduler 持续监视 API Server，检查新的或未被调度的 Pod。 当 Scheduler 发现一个新的 Pod（pod.spec.Node == null 表示这个 Pod 还没有被调度到任何节点），它将根据资源需求、亲和性规则、污点和容忍度等因素选择一个合适的节点。 一旦选择了节点，Scheduler 将更新该 Pod 的信息，指定其运行在选择的节点上，并将这个更新写回到 Etcd。
Kubelet 监听并创建 Pod：
每个节点上的 Kubelet 进程持续监视 Etcd，查找分配给自己节点的新任务。 当 Kubelet 发现有新的 Pod 分配到它所在的节点，它会根据 Pod 定义开始创建和启动 Pod 中的容器。 Kubelet 调用容器运行时（如 Docker）来实际启动容器，并设置必要的网络和存储配置。
Pod 状态更新和汇报：
在 Pod 创建过程中，Kubelet 将 Pod 的状态更新回 API Server。这些状态信息包括 Pod 是否成功启动，运行中的容器等。 API Server 更新 Etcd 中的状态信息，确保集群状态的一致性。
2、POD 的状态解析
1. Pending Pod
已被 Kubernetes 系统接受，但有一个或多个容器镜像尚未创建。 Pod 等待被调度到一个节点上。 网络配置等前期准备工作正在进行中。
2. Running Pod
已经被调度到一个节点上，并且所有的容器都已创建。 至少有一个容器正在运行，或者正在启动或重启。
3. Succeeded Pod
中的所有容器都正常运行完毕，并已经退出。 这通常适用于一次性或批处理作业。
4. Failed Pod
中至少有一个容器以非零状态退出。 表明容器启动失败或运行中出现错误。
5. Unknown
由于某种原因，Pod 的状态无法确定。 通常是与 Pod 通信出现问题，如节点故障。
6. CrashLoopBackOff
表明 Pod 中的一个或多个容器尝试启动后失败，正在尝试重启。 这可能是由于应用程序错误、配置问题等引起的。
7. ImagePullBackOff Pod
无法拉取一个或多个容器镜像。 可能是因为镜像不存在，或者与容器注册中心的认证问题。
8. Terminating
当 Pod 被标记为删除并开始终止过程时，会进入此状态。 这个状态意味着 Kubernetes 正在停止 Pod 中的所有容器。
9. Evicted
当节点上的资源（如内存或磁盘空间）不足时，Pod 可能会被驱逐。 驱逐行为是 Kubernetes 为了保护节点稳定性而自动执行的操作。
10. OOMKilled
如果 Pod 中的容器使用超出其分配的内存限制，它可能会被系统的 Out-Of-Memory (OOM) killer 终止。 这通常表明容器配置的内存限制过低或应用程序内存泄露。
11. ContainerCreating
当 Kubernetes 正在创建 Pod 中的容器时，Pod 会处于此状态。 这可能涉及到拉取容器镜像、创建容器等操作。
12. Completed
这是一个非常用状态，表明 Pod 中的所有容器都已成功完成其任务并且正常退出。 这通常用于有限期或批处理任务。
希望能够帮助到大家！！！
