POD创建与删除简单描述

创建一个 Pod 的过程可以分为以下几个步骤：

• 用户使用 kubectl create 命令或 YAML 文件向 API 服务器发送创建 Pod 的请求。
• API 服务器将请求转换为 Kubernetes 的内部对象，并将 Pod 的状态设置为 Pending。
• 调度器根据 Pod 的资源需求和节点的资源情况，将 Pod 调度到合适的节点上。
• 节点上的 kubelet 接收调度器调度过来的 Pod，并将其状态设置为 Running。
• kubelet 为 Pod 创建容器，并为容器分配资源。
  容器启动，并开始运行。

白话解释:

用户向 API 服务器说：“我要创建一个 Pod。”
API 服务器把用户的话转换成 Kubernetes 内部的语言，然后告诉调度器：“这个 Pod 要创建了。”
调度器把这件事告诉 kubelet，kubelet 就开始准备创建 Pod。
kubelet 为 Pod 创建容器，并为容器分配资源。
容器启动，并开始运行。

用户->>API 服务器: 提交 Pod 创建请求
  API 服务器->>调度器: 转换 Pod 创建请求
  调度器->>节点: 调度 Pod
  节点->>kubelet: 接收 Pod
  kubelet->>容器: 创建容器
  容器->>: 启动

删除一个 Pod 时，Kubernetes 会执行以下步骤：

• 1. 用户使用 kubectl delete 命令或 YAML 文件向 API 服务器发送删除 Pod 的请求。
• 2. API 服务器将请求转换为 Kubernetes 的内部对象，并将 Pod 的状态设置为 Terminating。
• 3. 调度器将 Pod 的状态设置为 Terminating。
• 4. kubelet 将 Pod 的状态设置为 Terminating，并向 Pod 中的每个容器发送 SIGTERM 信号，通知容器准备退出。
• 5. 容器在指定的超时时间内退出。如果容器在超时时间内未退出，则 kubelet 会向容器发送 SIGKILL 信号，强制容器退出。
• 6. kubelet 删除 Pod 的相关资源，包括 Pod 的定义、容器的镜像、容器的日志等。

• etcd 是 Kubernetes 集群的核心组件，负责存储 Kubernetes 的所有数据。在删除 Pod 时，etcd 需要执行以下操作：

• 1. 删除 Pod 的定义。
• 2. 删除 Pod 的相关资源，包括容器的镜像和容器的日志等。

白话解释

* 用户向 API 服务器说：“我要删除一个 Pod。”
* API 服务器把用户的话转换成 Kubernetes 内部的语言，然后告诉调度器：“这个 Pod 要删除了。”
* 调度器把这件事告诉 kubelet，kubelet 把这件事告诉 Pod 中的容器：“你们要被删除了。”
* 容器听到 kubelet 的话，就开始准备退出。如果容器在规定的时间内没有退出，kubelet 就会强行让它退出。
* 容器退出后，kubelet 会把 Pod 的相关资源都删除掉。

etcd 是 Kubernetes 的记事本，负责记住 Kubernetes 的所有信息。在删除 Pod 时，etcd 要把 Pod 的相关信息都删除掉。

---

• Kubernetes 中的 Pod 遵循一个预定义的生命周期，该生命周期由以下几个阶段组成：

• Pending：Pod 尚未被调度到任何节点。
• Running：Pod 已被调度到一个节点，并且所有容器都已启动并正在运行。
• Succeeded：Pod 中的所有容器都已成功终止。
• Failed：Pod 中的至少一个容器已失败。
• Unknown：Pod 的状态无法确定。

Pending 阶段

在 Pending 阶段，Pod 尚未被调度到任何节点。Pod 处于此阶段的原因可能有以下几种：

• Pod 尚未被用户创建。
• Pod 已被创建，但调度器尚未将其调度到任何节点。
• Pod 已被调度到一个节点，但该节点尚未准备好运行 Pod。

Running 阶段

在 Running 阶段，Pod 已被调度到一个节点，并且所有容器都已启动并正在运行。Pod 处于此阶段的时间可能会持续很长，直到 Pod 被终止。

Succeeded 阶段

在 Succeeded 阶段，Pod 中的所有容器都已成功终止。Pod 处于此阶段的原因可能是以下几种：

• Pod 的定义中包含了 terminationGracePeriodSeconds 字段，并且该字段指定的超时时间已过。
• Pod 的定义中包含了 restartPolicy 字段，并且该字段指定的策略为 Never。

Failed 阶段

在 Failed 阶段，Pod 中的至少一个容器已失败。Pod 处于此阶段的原因可能是以下几种：

• Pod 的定义中包含了 restartPolicy 字段，并且该字段指定的策略为 Always 或 OnFailure。
• Pod 的定义中包含了 terminationGracePeriodSeconds 字段，并且该字段指定的超时时间已过，但 Pod 中的容器仍未成功终止。

Unknown 阶段

在 Unknown 阶段，Pod 的状态无法确定。Pod 处于此阶段的原因可能是以下几种：

• Pod 的定义中包含了 restartPolicy 字段，并且该字段指定的策略为 Never。
• Pod 的定义中包含了 terminationGracePeriodSeconds 字段，并且该字段指定的超时时间已过，但 Pod 仍未被调度到任何节点。

Pod 的状态转换

Pod 的状态可能会从一个阶段转换到另一个阶段。以下是 Pod 状态转换的可能情况：

• Pending -> Running：Pod 已被调度到一个节点，并且所有容器都已启动。
• Running -> Succeeded：Pod 中的所有容器都已成功终止。
• Running -> Failed：Pod 中的至少一个容器已失败。
• Pending -> Unknown：Pod 的定义中包含了 restartPolicy 字段，并且该字段指定的策略为 Never。
• Running -> Unknown：Pod 的定义中包含了 terminationGracePeriodSeconds 字段，并且该字段指定的超时时间已过，但 Pod 仍未被调度到任何节点。

控制 Pod 的状态

可以使用 Kubernetes 的 API 或命令行工具来控制 Pod 的状态。使用 kubectl delete 命令来终止 Pod。

还可以使用 Pod 的 restartPolicy 字段来控制 Pod 在失败时是否重启。如果您将 restartPolicy 字段设置为 Never，则 Pod 将不会在失败时重启。

---

Deployment 和 ReplicaSet 都是 Kubernetes 中用于管理 Pod 副本的对象。它们的主要区别在于：

• **Deployment 是一个更高级的抽象。**它提供了一些 ReplicaSet 没有的功能，例如：
  • 滚动更新：Deployment 可以自动滚动更新 Pod 副本，而不会影响应用程序的可用性。
  • 回滚：Deployment 可以自动回滚到以前的版本。
  • 伸缩：Deployment 可以自动伸缩 Pod 副本的数量。
• **ReplicaSet 是一个更简单的对象。**它只负责管理 Pod 副本的数量。

1.28.x 版本的 Kubernetes 仍然支持 ReplicaSet。但是，新版本的 Kubernetes 建议使用 Deployment 来管理 Pod 副本。Deployment 提供了 ReplicaSet 没有的功能，可以简化应用程序的部署和管理。

以下是 Deployment 和 ReplicaSet 的具体用途：

• **Deployment 适合需要进行滚动更新、回滚和伸缩的应用程序。**例如，Web 应用程序、微服务等。
• **ReplicaSet 适合不需要进行滚动更新、回滚和伸缩的应用程序。**例如，批处理应用程序、数据库等。

具体选择哪种对象，需要根据应用程序的实际需求来决定。

StatefulSet 更新 Pods 很慢的原因主要有以下几个：

• **StatefulSet 的更新策略是滚动更新。**在滚动更新过程中，StatefulSet 会逐个更新 Pod，并将旧 Pod 从集群中删除。这会导致应用程序的不可用时间。
• **StatefulSet 的存储卷是持久化的。**在更新 Pod 时，StatefulSet 需要将旧 Pod 的存储卷数据复制到新 Pod。这会导致更新过程变慢。

如果没有存储的情况下，StatefulSet 更新 Pods 仍然很慢的原因是，StatefulSet 仍然需要将旧 Pod 从集群中删除。这会导致应用程序的不可用时间。

以下是一些可以提高 StatefulSet 更新速度的建议：

• **使用自定义的更新策略。可以使用“暂停更新”策略，在更新所有 Pod 之前暂停应用程序。
• **使用快照存储。**快照存储可以加快存储卷数据的复制速度。
• **使用复制 Pod。**复制 Pod 可以提高应用程序的可用性。