5. 从零开始创建一个 Pod

5.1 创建 Pod 的步骤

1. 定义 Pod

在 Kubernetes 中，你需要用一个 YAML 文件来定义 Pod 的配置，包括容器的镜像、资源需求、端口等信息。以下是一个基本的 Pod YAML 文件示例:

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
  labels:
    app: myapp
spec:
  containers:
    - name: nginx-container
      image: nginx:1.24.0
      ports:
        - containerPort: 80

kubectl apply -f pod-definition.yaml

6. 从零开始创建一个 Deployment

虽然直接创建 Pod 是 Kubernetes 的基础操作，但在实际工作中，大多数情况下我们会使用 Deployment 来管理 Pod。Deployment 提供了更多高级功能，比如自动修复故障、滚动更新、负载均衡和扩展副本等，因此它成为 Kubernetes 集群管理中的核心方式.

6.1 创建 Deployment 的步骤

1. 定义 Deployment

Deployment 的定义同样需要通过 YAML 文件。与 Pod 不同，Deployment 需要描述更多内容，比如：想要启动多少个 Pod 副本、如何进行更新、选择的策略等等.

以下是一个基本的 Deployment YAML 文件nginx-deployment.yaml示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3  # 指定要运行的 Pod 副本数
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24.0
        ports:
        - containerPort: 80

说明:

• apiVersion：apps/v1 是 Deployment 使用的 API 版本。
• kind：这里指定为 Deployment。
• metadata：定义 Deployment 的名称和标签。
• spec：Deployment 的具体定义。
  • replicas：指定要启动的 Pod 副本数，这里设置为 3。
  • selector：定义匹配的 Pod 标签，确保 Deployment 只管理特定的 Pod。
  • template：Pod 的模板部分，几乎与直接创建 Pod 的 YAML 文件相同，指定容器镜像和端口等。

2. 提交到集群

使用 kubectl apply -f nginx-deployment.yaml 命令将 Deployment YAML 文件提交到 Kubernetes 集群:

kubectl apply -f nginx-deployment.yaml

这个命令会将 Deployment 的定义提交到 API Server，API Server 会负责验证并保存 Deployment 的定义.

3. 检查结果

通过以下命令查看 Deployment 和 Pod 的状态:

kubectl get deployments
kubectl get pods
kubectl describe deployment nginx-deployment

这些命令可以查看 Deployment 和它所管理的 Pod 副本的运行情况。你可以看到 Kubernetes 会启动多个副本，并且它会自动管理这些 Pod 的状态。  。

6.2 Deployment 是如何管理 Pod 的？

创建 Deployment 后，Kubernetes 会生成相应数量的 Pod 副本，并通过 Deployment 管理它们的生命周期。如果其中某一个 Pod 发生故障，Deployment 会立即启动一个新的 Pod 副本替代故障 Pod。这样，Deployment 能够确保应用的高可用性.

Deployment 的幕后运作

创建 Deployment 和创建 Pod 的主要区别在于：Deployment 不仅仅是创建 Pod，它还负责 管理 Pod 的生命周期。它通过 ReplicaSet 来确保 Pod 的数量一致，ReplicaSet 是在 Kubernetes 中用来保持某个数量的 Pod 副本始终可用的控制器.

让我们看看具体幕后运作流程:

1. API Server 接收 Deployment 定义

当你提交 Deployment 定义时，API Server 负责验证 Deployment 文件的语法和配置，然后将其保存到 etcd 数据库.

2. Controller Manager 创建 ReplicaSet

API Server 通过调用 Kubernetes 的 Controller Manager 来创建一个 ReplicaSet。ReplicaSet 是控制器，负责维持所需数量的 Pod 副本。ReplicaSet 本身是由 Deployment 管理的，Deployment 告诉它需要启动多少个 Pod 副本.

ReplicaSet 的任务包括:

• 监控 Pod 副本数量：它会确保系统中始终运行指定数量的 Pod。例如，如果 Deployment 要求 3 个副本，ReplicaSet 会检查实际数量是否符合要求。
• 创建新 Pod：如果有 Pod 挂掉或需要扩展副本，ReplicaSet 会创建新的 Pod。

3. Scheduler 调度 Pod

ReplicaSet 负责创建 Pod，但这些 Pod 最终还是需要由 Kubernetes 的 Scheduler 来调度到适当的节点上。Scheduler 会根据节点的资源状况，选择最合适的节点运行 Pod.

4. Kubelet 启动 Pod

Scheduler 确定了节点后，节点上的 Kubelet 会负责启动新 Pod。Kubelet 会与容器运行时（如 Docker 或 containerd）协作，拉取容器镜像并启动容器.

5. 自动故障恢复

如果某个 Pod 因为某些原因挂掉了，Kubelet 会向 Controller Manager 报告 Pod 的状态。ReplicaSet 监测到副本数不够时，会立即创建一个新的 Pod，以确保总副本数符合 Deployment 的要求。这就是 Deployment 自动故障恢复的原理.

6. 滚动更新

Deployment 还支持 滚动更新，这是它的一个强大功能。滚动更新允许你在不影响应用正常运行的情况下升级容器镜像。比如，当你想要将 nginx:1.24.0 更新为 nginx:1.19 时，Deployment 会逐步替换旧的 Pod，而不会同时停止所有 Pod。这种方式确保了应用的高可用性.

通过以下命令可以进行滚动更新:

kubectl set image deployment/nginx-deployment nginx=nginx:1.19

此时，Deployment 会启动新的 Pod 副本，并在新 Pod 运行正常后，终止旧的 Pod。这个过程是逐步完成的，不会造成服务的中断.

6.3 Deployment 与 Pod 的主要区别

7. Pod 和 Deployment 的协作：从单一 Pod 到大规模部署

要理解 Pod 和 Deployment 的协作，可以把它们比作一支舰队里的小船和指挥官。一个 Pod 就像一艘小船，能够执行特定的任务；而 Deployment 就是舰队的指挥官，负责管理所有船只，确保它们始终按照计划航行，并在出现问题时迅速做出反应.

7.1 从单一 Pod 到大规模集群

小规模应用：一艘船就能搞定

在一些简单的场景下，比如你想快速测试一个应用或者部署一些简单服务，一个 Pod 就够了。Pod 是 Kubernetes 中最小的计算单元，它封装了容器、存储和网络等资源，让你的应用可以正常运行。这个场景下，你可能不需要太复杂的部署，只需要一个单独的 Pod 运行在节点上.

例子： 假设你想运行一个 Nginx 容器作为 Web 服务器，最简单的操作就是创建一个包含 Nginx 容器的 Pod，像这样:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.24.0
    ports:
    - containerPort: 80

这个 YAML 文件定义了一个 Pod，它会启动一个 Nginx 容器监听 80 端口，Pod 就像一艘小船，独自执行着任务.

大规模应用：召唤舰队！

但在现实中，大多数应用不会仅仅依靠一个 Pod。想象一下，你的应用突然迎来了成千上万的用户，只有一艘小船显然应对不了。这个时候你需要更多的船——更多的 Pod 来分摊任务。于是，Deployment 就派上用场了.

Deployment 允许你指定要运行的 Pod 数量，并且自动管理它们的生命周期。无论你需要 5 个、50 个，甚至 500 个 Pod，Deployment 都能帮你快速、自动地在多个节点上分发这些 Pod，从而实现大规模部署.

通过 Deployment，你可以像管理士兵一样，轻松地控制一支庞大的舰队.

7.2 Pod 和 Deployment 如何配合工作？

Pod 和 Deployment 是 Kubernetes 中密不可分的两部分。简单来说，Pod 是计算的基本执行单元，而 Deployment 是负责管理这些 Pod 的指挥系统。两者就像是士兵与指挥官的关系:

Pod：士兵，负责执行任务

Pod 本身并不具备自动修复、扩展等高级功能。它可以运行一个或多个容器，处理特定的任务，例如响应用户的请求、处理数据或执行计算任务。Pod 是 Kubernetes 中最基础的计算单元，但它的生命周期较短，容易受到硬件故障或网络问题的影响.

Deployment：指挥官，确保一致性和高可用

Deployment 负责管理 Pod 的生命周期，确保所有 Pod 始终在健康状态下运行。如果某个 Pod 挂掉了，Deployment 会迅速启动一个新的 Pod 替代它。这样，你不用担心个别 Pod 失效而导致服务中断。Deployment 还能帮助你轻松扩展应用的规模，比如从 3 个 Pod 扩展到 30 个，只需修改 YAML 文件中的副本数即可.

例子： 你想通过 Deployment 运行 5 个 Nginx Web 服务器，并确保它们一直保持在线。那么你可以定义一个 Deployment 文件，内容如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24.0
        ports:
        - containerPort: 80

幕后发生了什么?

1. API Server 首先接收到你的 Deployment 定义，然后将其存储在 etcd 数据库中。
2. Controller Manager 检查是否存在与 Deployment 定义匹配的 ReplicaSet，如果没有，它会创建一个 ReplicaSet。
3. ReplicaSet 是 Deployment 创建的控制器，负责确保指定数量的 Pod 一直在运行。如果你定义了 5 个副本，ReplicaSet 会启动 5 个 Pod，并监控它们的状态。
4. Scheduler 决定这些 Pod 应该在哪些节点上运行，并通知这些节点的 Kubelet。
5. Kubelet 在相应节点上启动 Pod，拉取 Nginx 容器镜像并启动服务。

Deployment 会监控所有 Pod 的运行状态，并且一旦发现某个 Pod 失效，它会立刻启动一个新的 Pod 作为替代。这样，你的 Web 服务将始终保持高可用状态.

Pod 和 Deployment 的协作，保障高效部署

总结来说，Pod 是 Kubernetes 中最基本的计算单元，适合用于处理简单的、短期的任务，而 Deployment 则是管理 Pod 的高级控制器，能够确保高可用性、自动扩展和滚动更新等功能。通过 Deployment，你可以轻松地将单一 Pod 扩展到大规模集群，确保应用在任何情况下都能高效、可靠地运行.

• Pod 是执行者：负责具体的计算任务。
• Deployment 是指挥官：负责调度和管理多个 Pod，确保一致性和高可用性。

  。

8. 幕后工作：Kubernetes 如何调度和管理资源

在 Kubernetes 的世界中，调度和资源管理是它高效运行的核心。你可以把它想象成一个超级智能的“交通指挥员”和“资源管理员”，每天忙着把成百上千的 Pod 送到最合适的节点上去“工作”。而且它不仅要确保每个 Pod 都找到“家”，还要保证每台服务器的资源不被浪费或过度使用。Kubernetes 背后的这一套机制是如何运行的呢？让我们来深入探讨！ 。

8.1 调度器的工作

Kubernetes 中的 调度器 是专门负责将每个 Pod 安排到合适的节点上运行的核心组件。它的任务就像是餐厅的座位安排员，不仅要看哪张桌子空着，还要考虑客人是否有特别需求（比如需要靠窗的位置或特定的菜单）.

调度器在安排 Pod 的过程中会综合考虑许多因素:

• 节点的资源情况 调度器首先会查看各个节点的资源，比如 CPU、内存、存储空间等是否足够。如果某个节点资源已经很紧张了，它就不会再安排新的 Pod 到这个节点上，而是会选择一个空闲的节点.

  比如，你的 Pod 需要 2 个 CPU 核心和 1 GB 的内存来运行，调度器会去寻找一个有足够资源的节点，确保这个 Pod 不会因为资源不足而崩溃.

• Pod 的需求 有些 Pod 可能有特殊要求，比如必须运行在某台具备 GPU 的节点上，或者需要访问某种特定类型的存储设备。调度器会根据这些要求筛选合适的节点.

  举个例子，假如你有一个需要 GPU 加速的机器学习任务，调度器会把这个 Pod 分配到拥有 GPU 的节点上，而不会让它跑在普通的节点上.

• 节点的标签和污点 Kubernetes 中的节点可以打上不同的 标签 或者设置 污点（taints），用来区分节点的功能或用途。调度器可以根据 Pod 的定义（通过 亲和性规则 和 容忍度）决定是否将某些 Pod 安排到这些特殊的节点上.

  比如，你可能有一些高性能计算任务只允许在标记为 "high-performance" 的节点上运行，调度器就会专门寻找这些节点来放置你的 Pod.

幕后发生的事情:

1. API Server 收到你的 Pod 创建请求，并将 Pod 信息存储到 etcd 数据库中。
2. 调度器（Scheduler） 开始工作，扫描所有节点的资源状况以及每个 Pod 的要求，筛选出符合条件的节点。
3. 一旦找到了合适的节点，调度器会将这个节点分配给 Pod，然后通知 Kubelet 去启动 Pod。

通过这种方式，调度器不仅能确保每个 Pod 都能找到合适的节点运行，还能平衡集群内各个节点的负载，避免资源浪费或过度使用.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

• 上述配置意味着当 Pod 的 CPU 使用率超过 70% 时，Kubernetes 会在 2 到 10 个副本之间自动扩展.

合理配置探针

健康检查探针（Probes）是确保应用正常运行的重要手段，配置得当可以极大提高应用的稳定性。如果探针配置不当，可能会导致 Pod 频繁重启，甚至错误地认为健康 Pod 不健康.

• 优化建议：为每个 Pod 配置合适的 Liveness Probe 和 Readiness Probe。Liveness Probe 确保应用的进程没有卡住，而 Readiness Probe 确保应用已经准备好处理请求.

  Liveness Probe 示例：  。

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5