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 中的所有容器都已成功完成其任务并且正常退出。
这通常用于有限期或批处理任务。
3、Kubernetes 架构中一般有几个主节点，为什么
单个主节点:
对于小型或开发环境，通常只有一个主节点。
这简化了配置，但缺点是没有高可用性。如果主节点出现故障，整个集群可能会受到影响。
多个主节点 (高可用性配置):
在生产环境中，为了实现高可用性（HA），通常会有多个主节点。
常见配置是三个主节点，这样即使一个节点失败，集群的控制平面仍然可以继续运行。
使用三个或更多节点可以防止“脑裂”（split-brain）情况，这是当网络分区发生时，避免出现多个主节点同时认为自己是活动的情况。
为什么选择三个节点:
在分布式系统中，使用奇数个节点可以更好地处理脑裂和投票决策。当存在偶数个节点时，可能会出现投票平局的情况，从而使集群难以决定哪个版本的数据是最新的。
三个节点是高可用性配置的最小数量，提供了故障转移能力，同时在资源和管理复杂性方面保持平衡。
更多节点:
对于大型或特别关键的环境，可能会有超过三个主节点。
随着节点数量的增加，管理复杂性和资源需求也会增加，因此需要权衡成本和可用性的需求
Comments NOTHING