Kubernetes（简称 K8s）已成为云原生时代容器编排的事实标准。它并非一个简单的容器管理工具，而是一个具备自我修复、自动扩缩容和声明式管理能力的分布式操作系统。
要理解 K8s 的强大之处，首先要理解它的架构。一个标准的 Kubernetes 集群由两个核心部分组成：控制平面（Control Plane）和工作节点（Worker Nodes）。
如果把集群比作一家公司：
- 控制平面是“管理层”，负责全局决策和下达指令。
- 工作节点是“一线员工”，负责实际执行任务——运行你的应用程序。
下图清晰地展示了 Kubernetes 集群的组件关系与交互流程：
控制平面（Control Plane）：集群的“大脑”
控制平面是集群的核心，负责管理和协调整个集群。它包含四个关键组件。
1. API Server (kube-apiserver)：唯一的“前台接待”
API Server 是操作集群的唯一入口。所有对集群的操作（无论是通过kubectl、UI 还是程序）都必须经过它。
它的主要职责包括：
- 认证（Authentication）：确认你的身份。
- 授权（Authorization）：确认你是否有权限执行该操作。
- 准入控制（Admission Control）：对请求进行拦截和修改。
- 数据持久化：将资源对象存储到后端存储（etcd）中。
你可以将 API Server 视为集群的“前台”和“安检口”，所有访问请求都必须在此通过验证才能进入。
2. etcd：可靠的“数据库”
etcd 是一个分布式、高可用的键值存储数据库。它是 Kubernetes 的唯一数据源，存储了整个集群的所有数据，包括 Pod、Service、Deployment 的配置和状态信息。
只有 API Server 能直接与 etcd 通信。你可以把 etcd 想象成公司的“中央档案室”，所有重要的配置和状态信息都安全地存放在这里。
3. Scheduler (kube-scheduler)：精明的“调度员”
Scheduler 负责为新创建的 Pod 选择一个最合适的节点来运行。
它的决策过程会综合考虑多种因素，例如节点的资源是否充足、节点是否满足 Pod 的亲和性要求等。Scheduler 就像一个“调度员”，会根据每个“任务”（Pod）的需求，把它分配到最合适的“员工”（Node）身上。
4. Controller Manager (kube-controller-manager)：勤劳的“监工”
Controller Manager 负责运行各种控制器，以确保集群的实际状态始终向用户定义的期望状态靠拢。
例如，当 Deployment 定义了需要 3 个副本时，ReplicaSet 控制器就会确保集群中始终运行着 3 个 Pod。如果某个 Pod 意外退出，控制器会立即创建新的 Pod 来维持副本数。这就是 Kubernetes 实现自愈能力的核心机制。Controller Manager 就像一个“监工”，不断巡视，确保工作进度符合计划。
工作节点（Worker Node）：真正干活的“员工”
工作节点是运行应用程序的机器，它们接收并执行控制平面下发的指令。每个工作节点至少包含以下三个组件。
1. Kubelet：节点的“管家”
Kubelet 是运行在每个工作节点上的代理进程。它负责与 API Server 通信，接收创建 Pod 的指令，并确保 Pod 中的容器处于健康运行状态。它就像一个“管家”，负责管理节点上所有容器的生命周期。
2. Container Runtime：真正的“劳工”
容器运行时是真正负责下载镜像和运行容器的软件。Kubernetes 支持多种容器运行时，如 Docker、containerd 等。它直接与容器交互，是真正“干活”的组件。
3. Kube-proxy：网络“交通警”
Kube-proxy 是运行在每个节点上的网络代理。它负责维护节点上的网络规则，实现 Service 的负载均衡和网络代理功能。简单来说，它决定了网络流量该如何分发到正确的 Pod 上。
核心概念：Kubernetes 如何管理应用
理解了集群的骨架，再来看看它管理应用的核心对象。
Pod：最小的调度单元
Pod 是 Kubernetes 中可以创建和管理的最小部署单元。一个 Pod 可以包含一个或多个紧密相关的容器，这些容器共享网络、存储等资源。你可以把 Pod 看作一个“豆荚”，里面的容器就像“豆子”一样，紧密地生活在一起。
Service：稳定的访问入口
由于 Pod 是临时性的，IP 会变化，Service 就为解决这个问题而生。它为动态变化的一组 Pod 提供了一个固定的访问入口（IP 和 DNS 名称）。无论后端的 Pod 如何伸缩或重启，客户端都可以通过这个不变的 Service 地址访问到服务。
Deployment：无状态应用的部署蓝图
Deployment 定义了无状态应用的期望状态，比如使用哪个镜像、需要运行多少个副本等。它负责管理 Pod 的创建、更新和回滚。通过 Deployment，你可以轻松实现应用的滚动更新和版本回滚。
适用场景：Web 服务、API 网关等无状态应用。
StatefulSet：有状态应用的部署蓝图
StatefulSet 是专门为有状态应用设计的工作负载控制器。与 Deployment 不同，StatefulSet 为每个 Pod 提供稳定的、唯一的网络标识和持久化存储。
StatefulSet 的核心特性包括：
稳定的网络标识：每个 Pod 都有一个固定的主机名，格式为
$(statefulset-name)-$(ordinal)（如mysql-0、mysql-1）。即使 Pod 被重新调度到其他节点，其网络标识（包括 DNS 名称）也不会改变，便于服务发现。有序的部署和伸缩：Pod 按序号从 0 到 N-1 依次创建和启动，停止和缩容时则按逆序（从 N-1 到 0）进行。这种有序性保证了有状态应用（如数据库集群）的主从初始化顺序。
有序的滚动更新：更新时从最高序号的 Pod 开始，逐个更新并等待就绪后，再更新下一个。这避免了所有节点同时升级导致的服务中断。
持久化存储：StatefulSet 通常配合PersistentVolume（PV）和PersistentVolumeClaim（PVC）使用，确保每个 Pod 拥有自己独立的存储卷。即使 Pod 被删除后重建，数据也不会丢失。
典型应用场景：
- 数据库（MySQL、PostgreSQL、MongoDB）
- 消息队列（Kafka、RabbitMQ）
- 分布式存储系统（Elasticsearch、ZooKeeper、etcd）
Deployment 与 StatefulSet 对比：
| 特性 | Deployment | StatefulSet |
|---|---|---|
| Pod 标识 | 随机名称（如web-5d8c4b6f7c-x2k9j） | 有序名称（如web-0、web-1） |
| 网络标识 | 不固定，Pod 重建后 IP 和名称均变化 | 固定，DNS 名称稳定不变 |
| 启停顺序 | 并行，无序 | 有序（0→N-1 创建，N-1→0 删除） |
| 存储 | 可共享存储卷（或临时存储） | 每个 Pod 独立 PVC，数据持久化 |
| 适用场景 | 无状态应用 | 有状态应用（需要存储状态和数据） |
声明式 API：Kubernetes 的设计哲学
Kubernetes 的核心设计思想是声明式 API和控制器模式。
- 声明式 API：你只需通过 YAML 文件“声明”你想要的最终状态（例如，“我要 3 个 Nginx 副本”），而不需要关心如何一步步去实现它。
- 控制器模式：集群内的各种控制器会持续工作，不断将实际状态“调整”到你声明的期望状态。
这种“声明意图，而非执行步骤”的模式，是 Kubernetes 能够实现自动化和自愈能力的基础。
总结
Kubernetes 的精妙之处，在于它将复杂的分布式系统管理，抽象为了一套清晰、一致、可扩展的 API 和架构。
- 控制平面：由 API Server、etcd、Scheduler 和 Controller Manager 组成，是集群的“大脑”，负责管理和决策。
- 工作节点：由 Kubelet、Kube-proxy 和容器运行时组成，是集群的“肌肉”，负责执行和运行业务负载。
- 核心对象：Pod 是最小部署单元，Service 提供稳定访问入口，Deployment 适用于无状态应用，而 StatefulSet 则为有状态应用提供了稳定网络标识和持久化存储的能力。
理解这套架构，是深入掌握 Kubernetes 的第一步。
