从零开始掌握Kubernetes: Pod和Deployment的幕后故事

1. 引言

在如今的技术世界中，随着微服务架构的广泛应用和云原生理念的兴起，应用程序的开发、部署和管理发生了翻天覆地的变化。容器技术的出现使得开发者可以轻松地将应用及其所有依赖打包在一个轻量级、可移植的容器中，这种方式大大提升了应用的部署效率和一致性。然而，随着应用规模的扩大和微服务数量的增加，管理成百上千个容器变得愈加复杂。这时，容器编排工具应运而生，而 Kubernetes（简称 k8s）无疑是其中最为流行和强大的平台。

1.1 Kubernetes 的诞生背景

Kubernetes 由 Google 开发，并于 2014 年捐赠给 CNCF（云原生计算基金会）。它源于 Google 内部十几年来运行大规模容器化应用的经验，并集成了自动化和分布式系统管理的最佳实践。Kubernetes 被设计为一个开源的容器编排平台，用于自动化容器的部署、扩展、管理和网络配置，帮助开发者轻松应对大规模容器化应用的管理挑战。

在传统的服务器管理模式下，运维人员通常需要手动部署应用、配置负载均衡、监控系统健康等，这些工作不仅复杂，而且容易出错。特别是在面对容器化应用时，随着容器数量的增加，手动管理变得几乎不可能。Kubernetes 的出现，正是为了自动化这一过程，使得无论是小型应用还是大规模分布式系统，都可以通过简单的声明式配置文件来管理所有的容器和服务。

1.2 Kubernetes 的优势

Kubernetes 的强大之处不仅在于其对容器管理的自动化，还在于它具有以下几大优势：

自我修复：如果某个容器出现故障或崩溃，Kubernetes 能够自动检测到，并根据定义好的策略重新启动或替换该容器，从而确保应用的高可用性。
自动扩展：当流量增大时，Kubernetes 可以根据实际的负载自动扩展 Pod 的数量，保证应用能够平稳应对高峰流量。相反，当流量下降时，它也能自动缩减资源，从而节省计算资源。
滚动更新和回滚：Kubernetes 支持在不中断服务的情况下，逐步更新应用的镜像和配置，并且如果更新失败，可以快速回滚到之前的稳定版本。
灵活的网络模型：Kubernetes 提供了强大的网络配置能力，确保集群中的各个 Pod 之间能够顺畅通信，并且支持外部流量的访问和负载均衡。
跨云平台的支持：Kubernetes 可以在多种环境中运行，包括公有云（如 AWS、GCP、Azure）、私有云和本地数据中心，从而具备高度的可移植性和灵活性。

1.3 Kubernetes 解决了哪些问题？

在容器化应用的管理过程中，开发者面临着多个复杂的问题，Kubernetes 通过其强大的编排能力解决了以下几大核心挑战：

资源分配与调度：Kubernetes 能够根据资源的可用性、应用的需求，智能地将容器调度到最合适的工作节点上，确保资源利用最大化。
自动化容器管理：当应用规模增大时，手动管理每个容器变得不现实。Kubernetes 通过自动化的方式，确保容器的生命周期、健康检查、重启等操作能够平稳进行。
服务发现与负载均衡：在传统的集群中，手动配置服务之间的通信是一件麻烦的事。而 Kubernetes 提供了内置的服务发现机制和负载均衡功能，使得不同服务可以轻松通信，并且根据流量自动调整负载分配。
扩展与弹性：无论是手动还是自动扩展，Kubernetes 都能根据实际需要动态调整容器副本数量，以应对瞬时的流量增长，并在流量回落后自动缩减资源消耗。
一致的开发和运维环境：Kubernetes 的声明式配置文件（如 YAML 或 JSON）能够让开发人员定义应用的期望状态，而 Kubernetes 会负责确保集群的实际状态与期望状态一致。这种模式不仅提高了开发和运维的协作效率，也使得应用的跨环境迁移（开发、测试、生产）变得更加容易。

1.4 本文内容预告

在本文中，我们将带你详细了解 Kubernetes 的各个组件，以及它们如何协同工作来管理容器化应用。此外，我们还会深入探讨创建 Pod 和 Deployment 的过程，帮助你从零开始掌握 Kubernetes 的基础操作。

具体内容包括：

Kubernetes 的核心架构：控制平面和工作节点的详细介绍。
Pod 的定义、特性及生命周期管理。
Deployment 如何帮助你实现零停机更新、自动扩展与回滚。
创建 Pod 和 Deployment 的详细步骤，以及幕后发生的故事。
以及 Kubernetes 如何通过调度、管理和网络配置来实现应用的自动化运维。

通过这篇文章，你将逐步掌握 Kubernetes 的核心概念和操作，具备管理和部署容器化应用的基础能力。

转载请在文章开头注名来源：https://www.cnblogs.com/Sunzz/p/18420782

2. Kubernetes 的基础架构

Kubernetes 的架构可以分为两大部分：控制平面（Control Plane） 和 工作节点（Worker Nodes）。控制平面负责管理整个集群和所有应用的运行状态，而工作节点则是实际运行容器化应用的地方。下面将对这些组件的功能和角色进行详细解释。

2.1 控制平面（Control Plane）

控制平面是 Kubernetes 的“大脑”，负责全局的控制和管理，确保应用运行的期望状态与实际状态相符。控制平面可以部署在多个节点上，以增强其高可用性。

控制平面的主要组件包括：

API Server：
- 功能：API Server 是 Kubernetes 的核心组件，所有操作都通过它进行。无论是用户通过 kubectl 命令行工具发起请求，还是其他 Kubernetes 组件之间的通信，API Server 都是它们的“入口”。
- 工作原理：API Server 提供 RESTful API 接口，处理所有 CRUD（创建、读取、更新、删除）操作。它将用户的操作转化为资源对象，比如 Pod、Service、Deployment 等，并将这些操作发送到后端的 etcd 进行持久化存储。
- 重要性：API Server 的可用性至关重要，如果它宕机，整个集群的操作就会暂停，无法接收新的操作请求。
etcd：
- 功能：etcd 是 Kubernetes 的分布式键值数据库，存储着整个集群的所有数据，包括节点信息、Pod 状态、配置文件、资源分配等。它是 Kubernetes 的数据中心和“记忆库”。
- 工作原理：每当控制平面发生变更（比如创建新 Pod 或更新某个 Deployment），这些变更都会被 API Server 写入 etcd 中，然后其他组件从 etcd 中获取最新的状态。
- 高可用性：etcd 通常配置为一个高可用的集群，确保数据的持久性和一致性，即使某个节点失效，其他节点仍然能继续提供服务。
Scheduler：
- 功能：Scheduler 是 Kubernetes 的调度器，负责将 Pod 分配到集群中的工作节点上。它决定哪些节点可以运行新的 Pod，并确保资源分配平衡。
- 工作原理：Scheduler 会根据节点的资源可用性（如 CPU、内存）和 Pod 的要求，找到最佳节点进行调度。它会优先选择资源富余的节点，以避免过度负载某个节点。
- 调度策略：Scheduler 支持自定义调度策略，如节点亲和性、污点与容忍、优先级等，用户可以根据应用的需求进行优化调度。
Controller Manager：
- 功能：Controller Manager 是 Kubernetes 中的“监管者”，它负责保证集群的状态与期望的状态一致。
- 工作原理：Controller 是 Kubernetes 中一系列控制器的统称，例如 Node Controller、ReplicaSet Controller、Job Controller 等。这些控制器会不断检查集群的实际状态与期望状态是否一致，如果有偏差，它们会采取相应的操作来纠正。例如，ReplicaSet Controller 负责确保 Deployment 的 Pod 副本数量，如果某个 Pod 崩溃，它会自动创建新的 Pod 来替代。
- 重要性：Controller Manager 的职责是保持集群的自我修复能力。如果集群状态发生变化，比如节点失效或 Pod 崩溃，控制器将自动执行恢复操作。

2.2 工作节点（Worker Nodes）

工作节点是 Kubernetes 集群的执行者，负责实际运行应用和处理流量。每个工作节点都会运行一些关键组件，以确保应用能够正常运行。

Kubelet：
- 功能：Kubelet 是每个工作节点上运行的主要代理进程，它负责管理和运行 Pod。Kubelet 会从 API Server 获取 Pod 的配置，并确保这些 Pod 在节点上正常运行。
- 工作原理：Kubelet 不直接管理容器，而是通过容器运行时（如 Docker 或 containerd）来实际启动、停止容器。如果某个 Pod 出现问题，Kubelet 会尝试重启容器，确保应用的正常运行。
- 健康检查：Kubelet 还负责定期进行健康检查，确保节点上的 Pod 处于运行状态，并将健康状态报告给控制平面。
Kube-proxy：
- 功能：Kube-proxy 是 Kubernetes 的网络组件，它负责管理节点间的网络通信，确保 Pod 可以相互通信，并允许外部流量访问 Pod。
- 工作原理：Kube-proxy 维护了所有服务的网络规则，管理服务到 Pod 之间的网络连接。它会在节点上创建网络规则，以确保网络流量正确路由到对应的 Pod。
- 负载均衡：当一个服务有多个 Pod 时，Kube-proxy 会在这些 Pod 之间实现负载均衡，确保流量能够均匀地分配到不同的 Pod 上。
容器运行时：
- 功能：容器运行时负责实际运行容器。Kubernetes 支持多种容器运行时，包括 Docker、containerd 和 CRI-O。
- 工作原理：Kubelet 会通过容器运行时接口（CRI）与容器运行时进行通信，指示它启动或停止容器。容器运行时会根据 Kubelet 的命令拉取容器镜像、创建容器并运行应用。

2.3 核心组件之间的协作

控制平面和工作节点通过网络进行通信，以确保整个集群的一致性和稳定性。以下是核心组件之间的工作流程：

Pod 创建流程：
- 用户通过 API Server 提交一个 Pod 创建请求。
- API Server 将这个请求记录在 etcd 中，并通知 Scheduler 进行调度。
- Scheduler 决定将 Pod 放在哪个节点上，并将调度结果反馈给 API Server。
- API Server 将 Pod 的配置信息发送给相应节点的 Kubelet，Kubelet 通过容器运行时启动容器。
- Kube-proxy 配置相应的网络规则，确保新创建的 Pod 能接收流量。
状态同步与修复：
- Controller Manager 定期检查集群中的实际状态与期望状态是否一致。如果某个 Pod 崩溃或节点失效，它会通过 API Server 通知 Kubelet 创建或迁移 Pod。
- Kubelet 负责监控节点上的所有容器，并定期向 API Server 汇报运行状态。API Server 会将这些状态信息保存在 etcd 中。

通过理解 Kubernetes 的控制平面和工作节点的各个组件，你可以深入了解它如何协同工作，自动化地处理应用的部署、扩展和恢复。这种分层架构让 Kubernetes 具备了强大的弹性和扩展性，使其成为容器编排领域的领军者。

3. Pod：Kubernetes 的最小计算单元

Pod 是 Kubernetes 中的基础组成部分，就像一艘小船，每个 Pod 都可以承载一个或多个容器（也就是应用程序）。如果你想把某个应用放入 Kubernetes 进行管理，它必须先被打包进一个 Pod 中。可以说，Pod 是 Kubernetes 世界中的基础单位，所有的应用程序、服务都在这个单位上运行。

3.1 Pod 的秘密武器

虽然 Pod 看起来只是装载容器的“船”，但它有一些非常强大的特性，让它不仅仅是一个简单的容器组。

IP 地址共享

Pod 内的所有容器共享同一个 IP 地址，就像同一艘船上的乘客，他们在同一个空间里，不需要像在不同船上的人那样用对讲机（网络通信）沟通。这个共享的网络空间意味着容器之间的通信非常简单，它们可以直接通过 localhost 来互相联系，而不需要像两个不同服务器那样进行复杂的网络连接。

存储共享

除了共享 IP 地址，Pod 内的所有容器还可以共享存储资源。你可以把 Pod 看作是一个共享的仓库，船上的乘客（容器）可以随时存取仓库里的货物（数据）。比如，你可以把一些文件或者数据库放在共享存储中，所有的容器都可以访问它们。这在运行多个协作应用时非常有用。

生命周期管理

Pod 的生命周期非常灵活。Pod 可以容纳多个容器一起工作，比如你有一个主应用和一个辅助的日志收集服务，它们可以打包到同一个 Pod 中。Kubernetes 还会监控 Pod 的运行状态，如果其中一个容器挂了，Kubernetes 可以帮你重新启动整个 Pod，保证应用的高可用性。

3.2 为什么 Pod 是 Kubernetes 的最小单元？

Pod 是 Kubernetes 中最小的可部署单元，这是什么意思呢？简单来说，Kubernetes 并不会直接去管理每个容器，它管理的是 Pod。每个 Pod 里面可以运行一个或多个容器，而这些容器必须“团结协作”来完成任务。

为什么不用单个容器？

单个容器虽然也能运行应用，但它无法满足复杂应用的需求。举个例子，假设你有一个 Web 服务器和一个日志收集程序，这两个应用需要一起工作。你可以把它们放在不同的容器里，但为了让它们高效协作，它们需要在同一个 Pod 中，这样它们就可以共享 IP 地址和存储资源，并且同步工作。

Pod 的设计就是为了解决这种场景——容器间的协作、资源共享。Pod 为多个容器提供了一个共享的操作环境，确保它们能无缝协作、互相支持。

Pod 的自愈能力

Kubernetes 监控每个 Pod 的状态，如果某个容器出现了问题，Kubernetes 可以自动重新调度、重启这个容器。Pod 作为一个整体，拥有 Kubernetes 的调度管理功能，不管是增加副本、修复故障，还是更新应用，都由 Kubernetes 帮你管理。

3.3 Pod 的其他特点

短暂性：Pod 的设计是短暂的，它们可能会因为各种原因被重新调度、销毁或重启。即便 Pod 被删除，Kubernetes 也会根据需要重新创建新的 Pod 来保持服务的高可用性。
状态不可持久：Pod 自身是短暂的，如果 Pod 失效，其内部数据会丢失。所以在需要持久化数据的场景下，你需要将数据保存在外部存储（如 Persistent Volume）中。

小结

Pod 是 Kubernetes 中的“基本构件”，它为容器提供了一个共享环境，允许它们在同一个 IP 和存储空间下协作工作。Pod 之所以是 Kubernetes 中的最小计算单元，是因为它不仅封装了容器，还提供了资源共享、生命周期管理和自愈功能。通过 Pod，你可以轻松管理复杂的应用，并确保它们能够高效、安全地运行。

转载请在文章开头注名来源：https://www.cnblogs.com/Sunzz/p/18420782

4. 深入 Deployment：确保 Pod 的一致性与可扩展性

如果把 Pod 比作一艘小船，Deployment 就像是船队的总指挥官。它不仅负责调度和管理这些船，还能在你需要的时候扩展船队规模，或进行升级改造。通过 Deployment，Kubernetes 确保你的应用始终保持最佳状态，避免了你亲自管理每艘小船的麻烦。

4.1 Deployment 的作用

Deployment 是 Kubernetes 中一个强大的控制器，它不仅能管理多个 Pod，还提供了一系列自动化的功能，帮助你轻松应对各种场景。

保持一致性

Deployment 的一个重要功能就是确保 Pod 数量一致。假如你定义了需要 3 个 Pod，Deployment 会不断监控集群，确保始终有 3 个 Pod 在运行。如果某个 Pod 挂了，Deployment 会自动启动一个新的 Pod 来补位。

举个例子，想象你有一支运输船队（Pod），你告诉 Deployment 需要 3 艘船来运输物资。如果其中一艘船沉了，Deployment 不会让你在海上少一艘船，它会立刻派出一艘新的来顶替沉没的那艘，保证船队规模始终符合要求。

零停机更新

更新应用是个大麻烦，因为你不想因为升级中断服务。Deployment 提供了“零停机更新”的功能，它能够在不中断服务的情况下为你的应用进行逐步更新。它会一个接一个地更新 Pod，这样即使有些 Pod 在更新中途失败了，其他 Pod 仍在工作，保证服务不中断。如果更新出现问题，Deployment 还能自动回滚到上一个版本，确保系统稳定运行。

你可以想象，船队要升级装备，Deployment 不会一次性让所有船停航改装，而是让它们轮流靠岸，装备好后继续出航。这样即使装备升级，运输任务也能继续进行。

自动扩展

有时候，应用突然需要处理更多的请求，这就像突然有一大群乘客需要坐船。Deployment 能迅速“造船”（启动更多的 Pod），以应对大量的请求。这就是 自动扩展 的功能。它根据应用负载自动增加或减少 Pod 数量，确保在任何情况下，应用都能应对自如。

比如说，如果你的应用平时只需要 2 艘船（2 个 Pod），但某天突然有 100 名乘客需要运输，Deployment 可以立刻增加船只，扩展为 5、10 甚至更多的 Pod 来处理这批乘客的需求。当高峰期过去后，它还会自动减少船只数量，避免资源浪费。

4.2 Deployment 的强大之处

Deployment 让 Kubernetes 变得更智能，它为应用提供了自动化的管理机制，减少了人工干预的需求。这里是 Deployment 的一些强大功能：

1. 自动修复

如果你亲自管理 100 艘船（100 个 Pod），发现某艘船失效了，你需要赶紧调度一艘新船来替代它。可如果有了 Deployment，你就不用操心了。Deployment 会自动检测到 Pod 出现问题并迅速创建一个新的 Pod。自动修复的功能确保了即使个别 Pod 出现故障，整个应用仍然能平稳运行。

2. 回滚机制

假设你给船队更新了一些新设备，结果发现新设备有问题，这时候你可能会紧张得不知所措。但是 Deployment 提供了 回滚机制，如果更新失败，你可以迅速回滚到上一个稳定的版本，恢复旧设备，让船队继续正常运行。

3. 逐步扩展

有时候你需要小心翼翼地扩展你的服务，比如你想在生产环境中测试新功能，但又不希望一下子扩展太多。Deployment 提供了 滚动更新 和 扩展功能，允许你逐步增加或减少 Pod 的数量，确保在扩展过程中服务始终稳定。

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

说明：

apiVersion：定义使用的 Kubernetes API 版本。
kind：这里指定的是 Pod，表示我们创建的是一个 Pod。
metadata：Pod 的元数据部分，包括名称和标签。
spec：是 Pod 的核心部分，定义了容器信息。
containers：这里指定了容器名称为 nginx-container，使用 nginx:1.24.0 镜像，并暴露了 80 端口。

2. 提交到集群

当你定义好 Pod 的 YAML 文件后，你可以使用 kubectl 命令将其提交到 Kubernetes 集群中。

kubectl apply -f pod-definition.yaml

这条命令会把 YAML 文件内容提交给 API Server，API Server 负责验证并保存 Pod 的定义，随后将任务分发给调度器（Scheduler）。

3. Kubernetes 开始工作

在你提交 YAML 文件后，Kubernetes 进入工作流程。幕后发生了很多事情，下面我们接着聊

5.2 幕后发生了什么？

在你提交了 Pod 定义之后，Kubernetes 各个组件会协调合作，完成 Pod 的创建和调度。下面我们一步步分析每个组件的工作。

1. API Server 接收请求

首先，kubectl 命令通过 REST API 向 API Server 发送 Pod 定义。API Server 是 Kubernetes 控制平面的核心，它会负责接收用户的请求，并验证请求内容是否有效。

验证和保存：API Server 会检查 Pod 定义文件的语法和参数是否正确，如果一切正常，它会将这个 Pod 定义保存到 etcd（Kubernetes 的分布式数据库）中。

2. Scheduler 调度 Pod

当 API Server 保存了 Pod 定义后，Pod 并没有立刻运行，而是进入了一个“Pending（待调度）”状态。此时，Scheduler（调度器）开始工作。

Scheduler 的任务是：

检查节点资源：它会扫描所有可用的节点（Worker Node），检查每个节点的 CPU、内存和存储等资源是否充足。
选择合适的节点：根据 Pod 的资源请求和节点的资源状况，Scheduler 会选择最合适的节点来运行 Pod。

例如，假设有三台 Worker 节点：

节点 A：CPU 负载高
节点 B：内存不足
节点 C：资源充足

Scheduler 可能会选择节点 C 来运行这个 Pod。

3. Kubelet 接管并启动 Pod

当 Scheduler 决定了 Pod 运行的节点后，它会将调度决定通知 Kubelet。Kubelet 是运行在每个 Worker 节点上的代理，它负责实际管理 Pod 的生命周期。

Kubelet 的任务是：

拉取镜像：Kubelet 会检查 Pod 定义中指定的容器镜像（如 nginx:1.24.0），如果本地没有这个镜像，它会从镜像仓库（如 Docker Hub）拉取该镜像。
启动容器：镜像拉取完成后，Kubelet 会调用容器运行时（如 Docker 或 containerd）来启动容器。
健康检查：Kubelet 还会对运行中的容器进行健康检查，如果容器异常，它会自动重启该容器。

4. CNI 配置网络

当 Pod 在节点上启动后，Kubernetes 还需要为这个 Pod 配置网络。Kubernetes 使用 CNI（Container Network Interface） 插件来完成这项工作。

CNI 插件的工作包括：

分配 IP 地址：为每个 Pod 分配一个独立的 IP 地址，这样每个 Pod 都可以通过 IP 和其他 Pod 通信。
配置网络规则：确保 Pod 能够访问集群中的其他服务，同时遵循集群中的网络策略。

5. kube-proxy 处理服务发现和负载均衡

Pod 运行起来后，Kubernetes 的 kube-proxy 组件负责配置网络规则，确保 Pod 能与外界通信。它的主要任务是：

负载均衡：kube-proxy 会根据服务的配置，将流量分发到相应的 Pod 上，即使有多个 Pod，流量也能均匀地分布。
服务发现：kube-proxy 通过更新 iptables 或 IPVS 规则，确保外部客户端或其他 Pod 能够通过服务（Service）访问目标 Pod。

6. Controller Manager 监控和维护 Pod

Kubernetes 的 Controller Manager 是负责确保集群状态符合期望状态的组件。例如，如果某个 Pod 因为节点故障而被终止，Controller Manager 会根据 Deployment 的定义，重新创建新的 Pod 副本。

整个过程总结

API Server 接收并验证 Pod 定义。
Scheduler 决定将 Pod 调度到哪台 Worker 节点。
Kubelet 在选定的节点上启动 Pod 的容器。
CNI 插件 为 Pod 配置网络，并分配 IP 地址。
kube-proxy 负责服务发现和负载均衡，确保 Pod 能够正常通信。
Controller Manager 持续监控 Pod 状态，并在必要时进行调整。

通过这些组件的协作，Kubernetes 能够在集群中高效地管理和调度 Pod，确保应用的稳定运行。

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 的主要区别

你可以把 Pod 想象成一个普通的“工人”，只要你告诉他该做什么，他就会去执行。但如果这个工人出了问题，比如“累趴下了”，那你就得亲自去“重新雇一个工人”来代替他。如果你要雇好几个工人，那每个工人你都得自己安排，感觉有点麻烦吧？

这时 Deployment 就像是一个“工头”登场了。它会管理一群工人（也就是 Pod），负责指挥他们怎么干活。如果某个工人“翘班”了，Deployment 会自动找一个新的工人补上。而且它还能根据工作量的大小，自动增加或减少工人的数量。这就是 Deployment 的强大之处！

区别 1：管理能力

Pod 就是干活的“工人”，它们自己不能修复问题，也不能增加“伙伴”。
Deployment 是“工头”，通过“副本控制器”（ReplicaSet）管理工人队伍。它可以自动修复故障、增加工人数量，还能让工人们自动升级工具。

区别 2：自动化操作

如果 Pod 挂掉了，作为老板的你必须亲自“重雇”一个。
如果你使用 Deployment，它会自动处理这些事情，随时替换掉故障的 Pod，保持工作顺利进行，你只需要坐着喝咖啡就行。

区别 3：滚动更新

想象一下，你要给工人们发一套新工具。如果直接替换所有工人的工具，可能会导致工作停滞。这时 Deployment 就会逐个替换工人的工具，保证所有工人都能继续工作而不会有停工的情况。

总结：Pod 是 Kubernetes 的最小执行单元，Deployment 则是对 Pod 的管理层，能够自动扩展、故障恢复、滚动更新等。用 Deployment 管理 Pod 就像有了一个聪明的工头，帮你处理所有琐碎的工作，让你的系统保持稳定运行。

这样一来，你不用再为每个 Pod 的管理操心，Deployment 会确保一切顺利进行！

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

幕后发生了什么？

API Server 首先接收到你的 Deployment 定义，然后将其存储在 etcd 数据库中。
Controller Manager 检查是否存在与 Deployment 定义匹配的 ReplicaSet，如果没有，它会创建一个 ReplicaSet。
ReplicaSet 是 Deployment 创建的控制器，负责确保指定数量的 Pod 一直在运行。如果你定义了 5 个副本，ReplicaSet 会启动 5 个 Pod，并监控它们的状态。
Scheduler 决定这些 Pod 应该在哪些节点上运行，并通知这些节点的 Kubelet。
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。

幕后发生的事情：

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

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

8.2 资源管理

Kubernetes 的 资源管理 机制十分智能，它不光会在调度时考虑资源，还能在运行过程中动态调整 Pod 的资源使用情况，以确保系统的稳定和高效。

资源限制和请求

在 Kubernetes 中，Pod 的每个容器可以设置 资源请求（Resource Requests）和 资源限制（Resource Limits）。这些参数就像是餐厅客人点的“菜单”，表示这个 Pod 需要多少 CPU 和内存才能正常运行，同时设置了它能使用的最大资源量。

资源请求（Requests）：是指容器需要的最少资源。如果一个 Pod 的容器请求了 500m（0.5 个 CPU 核）和 200Mi 内存，调度器就会确保分配给它的节点至少有这些资源可用。
资源限制（Limits）：是指容器能使用的最大资源。如果设置了 1 个 CPU 核和 500Mi 内存，那么即使容器想要更多，Kubernetes 也不会允许它占用超过这些上限的资源，避免资源浪费或“抢占”其他 Pod 的资源。

动态资源调整

Kubernetes 还能根据当前集群中的资源使用情况，自动调整 Pod 的数量和资源分配。这主要通过 Horizontal Pod Autoscaler（HPA） 和 Vertical Pod Autoscaler（VPA） 实现。

HPA（水平自动扩展）
假如你的应用突然流量暴增，HPA 能够检测到 Pod 的 CPU 或内存使用率上升，自动扩展更多的 Pod 来处理增加的工作负载。反之，当流量减少时，HPA 也会相应减少 Pod 数量，节省资源。

比如，你的 Web 服务在高峰期流量大增，HPA 会自动增加 Pod 副本，从 5 个扩展到 10 个。当高峰过去后，Pod 副本数可能会降回 5 个，这样就不会浪费多余的资源。
VPA（垂直自动扩展）
VPA 则会监控单个 Pod 的资源使用情况。如果某个 Pod 的内存或 CPU 经常超限，VPA 会调整这个 Pod 的资源请求和限制，让它更好地适应当前的需求。

举例来说，如果某个 Pod 的 CPU 使用率持续超出预期，VPA 可以自动调整这个 Pod 的资源限制，从 1 个 CPU 核增加到 2 个。

节点资源利用率管理

当某个节点的资源接近耗尽时，Kubernetes 会停止向这个节点调度新的 Pod，并寻找其他节点来承载新的任务。此外，Kubernetes 还能通过 资源驱逐机制 来释放资源。例如，当一个节点的内存不足时，Kubernetes 会根据优先级驱逐一些消耗较多内存的 Pod，以保证关键任务能够继续运行。

通过这些调度和资源管理机制，Kubernetes 实现了资源的高效利用和自动化管理。无论你的集群是小型测试环境，还是需要管理数千个 Pod 的生产环境，Kubernetes 都能够智能地调度和管理资源，确保你的应用平稳、高效地运行。

9. 常见问题及优化建议

学习 Kubernetes 的路上，你可能会遇到各种奇怪的现象和问题。有时 Pod 不启动，有时它们“莫名其妙”地崩溃。别慌！这就像你刚学会骑车，难免会有些摔跤，但只要你掌握了常见问题的原因和一些优化技巧，你就能顺利掌控 Kubernetes 的强大功能。让我们来看看常见问题及一些实用的优化建议。

9.1 常见问题

Pod 无法启动

这是很多初学者遇到的常见问题。Pod 的启动失败可能有多种原因，最常见的包括资源不足或配置错误。

原因 1：资源不足
Kubernetes 的调度器可能找不到一个有足够资源的节点来运行你的 Pod。如果节点的 CPU 或内存都耗尽了，Pod 就会处于 Pending 状态，而不是启动成功。

解决方案：你可以通过 kubectl describe pod <pod_name> 来检查详细的错误信息。如果是资源不足的问题，可能需要扩展集群的节点数，或者降低 Pod 的资源请求。
原因 2：镜像拉取失败
如果 Kubernetes 无法从镜像仓库中拉取你的应用镜像，Pod 也无法启动。这通常是因为镜像名称错误，或网络连接不稳定。

解决方案：检查 YAML 文件中的镜像地址是否正确，以及你的节点是否能够访问镜像仓库（特别是在私有镜像仓库的情况下）。你可以通过 kubectl describe pod <pod_name> 查看镜像拉取的日志。

Pod 无法访问外部服务

如果你的 Pod 需要访问外部服务（例如数据库或第三方 API），但总是连接失败，那么很有可能是网络策略配置有问题。

原因：网络策略错误或 Service 配置问题
Kubernetes 提供了灵活的网络策略，允许你控制 Pod 能够与哪些外部服务或内部资源通信。如果网络策略配置错误，Pod 可能会被阻止访问外部服务。

解决方案：检查你的网络策略配置，确保没有阻止 Pod 与外部服务的通信。你也可以检查 Service 配置，确保 Pod 能够通过正确的 DNS 名称或 IP 地址连接到外部服务。

Pod 一直重启

如果一个 Pod 一直处于 CrashLoopBackOff 状态，这通常是因为应用在启动过程中出现了错误，或者探针（Probes）配置不当，Kubernetes 认为 Pod 运行不健康，于是不断尝试重启。

原因：健康检查探针配置错误
Kubernetes 使用 Liveness Probe 和 Readiness Probe 来检测 Pod 是否健康。如果这些探针配置得不好，Pod 可能在刚启动时被错误地标记为“健康状况不佳”，导致它被频繁重启。

解决方案：仔细检查探针的配置，确保 Liveness Probe 和 Readiness Probe 的时间间隔合理，不要让它们过早或过晚检测应用状态。你可以通过 kubectl describe pod <pod_name> 查看探针的执行结果。

9.2 优化建议

现在我们来看看如何预防这些问题，并通过一些优化措施让 Kubernetes 集群运行得更加顺畅。

使用 HPA（水平 Pod 自动扩展）

如果你的应用偶尔会遇到高负载情况（例如流量激增），手动扩展 Pod 数量显然不太现实。这时候，Kubernetes 的 Horizontal Pod Autoscaler（HPA） 可以大显身手。它能够根据 Pod 的 CPU 或内存使用情况，自动扩展或缩减 Pod 的数量。

什么是 HPA？
HPA 监控每个 Pod 的资源使用情况，并在资源使用超过或低于某个阈值时，自动调整 Pod 副本数。

优化建议：设置合适的扩展规则，例如当 CPU 使用率超过 70% 时，自动增加 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

这个探针将在 Pod 启动 10 秒后开始检查 /healthz 路径，如果 5 秒内未响应，就会认为 Pod 出现了问题，并进行重启。

日志和监控

在 Kubernetes 中，日志和监控是排查问题、优化性能的利器。无论是 Pod 崩溃，还是网络延迟，通过日志和监控，你都能快速定位问题的根源。

日志：使用 kubectl logs 命令可以查看 Pod 的日志。如果你有多个副本运行，建议使用集中化的日志管理工具，比如 ELK（Elasticsearch, Logstash, Kibana）或 Fluentd。
监控：Kubernetes 提供了 Prometheus 这样的监控系统，它可以帮你监控集群的各个部分，从 CPU、内存使用率到网络流量应有尽有。通过监控仪表板（如 Grafana），你可以轻松查看集群的健康状况。

优化建议：设置报警规则，例如当 CPU 使用率超过 80% 或 Pod 数量异常增加时，自动触发警报通知你。

通过掌握这些常见问题和优化技巧，你可以避免很多初学者常遇到的坑，还能让你的 Kubernetes 集群跑得更加高效、稳定。 Kubernetes 不再是一个神秘的黑盒，它其实只是一个强大的工具，只要你掌握了它的调度和资源管理机制，就能轻松驾驭它！

10. 总结与展望

Kubernetes 已经成为容器编排领域的领导者，它不仅仅是一个工具，更像是你的应用的“总指挥官”，负责指挥 Pod 和 Deployment 等多个组成部分高效协作。无论你是开发者还是运维工程师，Kubernetes 都能帮助你轻松管理从小规模的实验性项目到大规模的生产级应用。

通过这篇文章，我们深入了解了 Kubernetes 的核心组件、创建 Pod 和 Deployment 的过程，以及 Kubernetes 如何高效地调度和管理资源。也许一开始，Kubernetes 让你感觉有点复杂，但随着时间的推移，你会发现它的设计是如此巧妙、灵活，正是它解决了现代应用部署中很多棘手的问题。

10.1 Kubernetes 的力量

Kubernetes 之所以如此受欢迎，是因为它解决了很多现代应用面临的痛点。比如：

自动扩展：Kubernetes 可以根据流量变化自动扩展或缩减应用的实例数量。你不需要手动调整资源分配，Kubernetes 会帮你完成。
自愈能力：当 Pod 或节点出现故障时，Kubernetes 会自动检测并重新调度容器，保持服务的高可用性。
灵活的部署策略：通过 Deployment 和 StatefulSet 等高级资源，你可以控制应用的升级、回滚等操作，减少停机时间，保证系统稳定。

可以说，Kubernetes 帮助你从繁重的运维工作中解放出来，让你更专注于应用本身。

10.2 未来的发展

Kubernetes 还在快速演进中，它不仅仅是一个强大的工具，未来还将变得更加智能和自动化。你可以期待 Kubernetes 继续在以下几个方面提供更强大的功能：

更智能的资源管理：未来的 Kubernetes 将更加智能地处理资源调度问题，甚至能预测流量高峰并提前准备好资源。你将不再需要手动干预，Kubernetes 会为你解决很多运维难题。
更高级的故障恢复机制：虽然 Kubernetes 现在已经具备自愈能力，但未来它可能会在故障恢复上更进一步，能更快、更准确地检测和修复问题，减少服务中断的可能性。
更高的安全性：随着 Kubernetes 的普及，安全性也成为了重点关注的领域。未来，你会看到更多内置的安全工具，帮助你轻松管理容器和集群的安全策略，防止潜在的攻击和数据泄露。

10.3 Kubernetes 的未来属于你！

无论你是 Kubernetes 的新手，还是已经熟练掌握这个平台的老手，Kubernetes 都会继续发展，并提供灵活高效的解决方案来应对现代应用的复杂性。

对于新手：Kubernetes 一开始可能会显得有些复杂，但不用担心！它的社区非常活跃，资源丰富，从文档到教程，你都能轻松找到帮助。你会发现它的设计是为了简化你的运维和开发流程。
对于老手：Kubernetes 正在不断变得更加智能和自动化。未来，你将会看到更多关于自动化扩展、智能调度、安全防护的功能，这些都会让你在大规模应用管理中如虎添翼。

总的来说，Kubernetes 是一个值得深入学习的平台，不论你是在管理一个简单的小型项目，还是在构建复杂的分布式系统，它都能为你提供强大的支持。我们欢迎你加入 Kubernetes 的大家庭，一起探索它的无限可能！

在 Kubernetes 的帮助下，无论未来的技术趋势如何变化，你都能从容应对。拥抱 Kubernetes，迎接未来的挑战吧！

转载请在文章开头注名来源：https://www.cnblogs.com/Sunzz/p/18420782

posted @ 2024-09-19 17:07 Sunzz 阅读(488) 评论(0) 编辑收藏举报

刷新页面返回顶部

Today is a nice day

Every day is a new day

从零开始掌握Kubernetes: Pod和Deployment的幕后故事

1. 引言

1.1 Kubernetes 的诞生背景

1.2 Kubernetes 的优势

1.3 Kubernetes 解决了哪些问题？

1.4 本文内容预告

2. Kubernetes 的基础架构

2.1 控制平面（Control Plane）

API Server：

etcd：

Scheduler：

Controller Manager：

2.2 工作节点（Worker Nodes）

2.3 核心组件之间的协作

3. Pod：Kubernetes 的最小计算单元

3.1 Pod 的秘密武器

IP 地址共享

存储共享

生命周期管理

3.2 为什么 Pod 是 Kubernetes 的最小单元？

为什么不用单个容器？

Pod 的自愈能力

3.3 Pod 的其他特点

小结

4. 深入 Deployment：确保 Pod 的一致性与可扩展性

4.1 Deployment 的作用

保持一致性

零停机更新

自动扩展

4.2 Deployment 的强大之处

1. 自动修复

2. 回滚机制

3. 逐步扩展

5. 从零开始创建一个 Pod

5.1 创建 Pod 的步骤

1. 定义 Pod

2. 提交到集群

3. Kubernetes 开始工作

5.2 幕后发生了什么？

1. API Server 接收请求

2. Scheduler 调度 Pod

3. Kubelet 接管并启动 Pod

4. CNI 配置网络

5. kube-proxy 处理服务发现和负载均衡

6. Controller Manager 监控和维护 Pod

整个过程总结

6. 从零开始创建一个 Deployment

6.1 创建 Deployment 的步骤

1. 定义 Deployment

2. 提交到集群

3. 检查结果

6.2 Deployment 是如何管理 Pod 的？

Deployment 的幕后运作

1. API Server 接收 Deployment 定义

2. Controller Manager 创建 ReplicaSet

3. Scheduler 调度 Pod

4. Kubelet 启动 Pod

5. 自动故障恢复

6. 滚动更新

6.3 Deployment 与 Pod 的主要区别

区别 1：管理能力

区别 2：自动化操作

区别 3：滚动更新

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

7.1 从单一 Pod 到大规模集群

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

大规模应用：召唤舰队！

7.2 Pod 和 Deployment 如何配合工作？

Pod：士兵，负责执行任务

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

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

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

8.1 调度器的工作

8.2 资源管理

资源限制和请求

动态资源调整

节点资源利用率管理

9. 常见问题及优化建议