第 2 章　用一张地图认识集群

集群、节点、Pod

集群（Cluster）是一组受 Kubernetes 管理的计算资源。节点（Node）通常是一台虚拟机或物理机，在 kind 中则由容器模拟。节点提供 CPU、内存和网络等资源。

Pod 是 Kubernetes 调度和管理应用的基本单位。最常见的 Pod 只运行一个业务容器；某些紧密协作的容器也可以放在同一个 Pod 内，共享网络和指定的卷。你扩容的是多个 Pod 副本，而不是把同一应用的十个副本塞进一个 Pod。

集群
├── 控制平面：接收请求，记录状态，做出调度与协调决策
└── 工作节点
    ├── Pod A → 网页容器
    └── Pod B → 网页容器

图表示逻辑职责。本书的单节点 kind 集群会在同一个节点中承担控制平面和工作负载，适合练习；生产常会把这些职责分开，并配置冗余。

kube-apiserver 是 API 入口。kubectl 提交资源描述，首先与它交互。etcd 保存集群的关键状态；它并不是供你随意存放业务数据的数据库。kube-scheduler 为还没有绑定节点的 Pod 选择合适节点。控制器持续观察状态，例如副本数不足时触发补建。

每个节点上的 kubelet 负责让分配给这个节点的 Pod 按要求运行，并上报状态。容器运行时负责实际拉取镜像、启动容器。网络组件让 Pod 互通；Service 转发常由 kube-proxy 或其他替代实现提供。

不要把 Docker 和 Kubernetes 的关系理解成“集群必须装 Docker”。现代 Kubernetes 通过 CRI 接口使用容器运行时，例如 containerd。本书用 Docker 是为了运行 kind 的节点容器。

命令式表达是“现在帮我启动三个实例”。声明式表达是“这个应用的副本数应该是三个”。后者允许系统持续纠偏。

YAML 是描述期望状态的常见文本格式，kubectl 是提交与查询这些描述的工具。它们不是 Kubernetes 本身。你可以把 YAML 理解为订单，API 是接单窗口，控制器是不断检查订单是否落实的工作人员。

本章自测：kubectl 在你的电脑上还是集群里运行？谁负责选择节点？Pod 被删除后，为什么有时会自动出现一个新的？