Kubernetes 核心概念
Kubernetes 把运维对象的方方面面抽象成一批"资源类型"，一切操作——无论是 kubectl 命令还是 YAML 文件——都是在读写这些资源。这一章先建立全局概念地图，后文各章再逐一深入展开。
概念总览表
先把最常用的资源一次看清：
| 概念 | 一句话说明 | 对应章节 |
|---|---|---|
| 集群 Cluster | 控制面与工作节点的整体 | 03 架构 |
| 节点 Node | 集群里的一台工作机器 | 03 架构 |
| 命名空间 Namespace | 集群内部的逻辑分区 | 06 |
| Pod | 可调度的最小部署单元，内含一个或多个容器 | 07 |
| Deployment | 无状态应用的副本保持与滚动更新 | 11 |
| Service | 稳定的访问入口与负载均衡 | 15 |
| Ingress | 集群入口的 HTTP 路由 | 16 |
| ConfigMap / Secret | 普通配置与敏感信息 | 17 / 18 |
| PV / PVC | 持久化存储 | 20 |
| 探针 Probe | 容器健康检查 | 21 |
集群与节点
集群是 Kubernetes 的顶层单位，由控制面（大脑）与节点（手脚）组成。节点可以是一台物理机或虚拟机，节点上运行着 kubelet 代理，负责与集群通信、执行调度指令。
命名空间与 Pod
命名空间把集群切成若干逻辑区域，不同团队各用各的、互不干扰。Pod 是最小的部署单元：Kubernetes 并不直接调度容器，而是把一组"同生共死"的容器打包成一个 Pod 再调度：
apiVersion: v1
kind: Pod
metadata:
name: web-pod
namespace: default
spec:
containers:
- name: nginx
image: nginx:1.27
工作负载控制器
Pod 一旦被删除不会自己回来，控制器负责维持"期望数量"。常用控制器有：Deployment（无状态应用）、StatefulSet（有状态应用）、DaemonSet（每节点一个）、Job 与 CronJob（一次性与定时任务）。控制器的工作模式都是同一个循环：对比 spec 中的期望值与实际数量，有偏差就纠正。
Service 与 Ingress
Pod 的 IP 是临时的，Service 提供稳定的虚拟 IP 与 DNS 名，把请求负载均衡到一组 Pod 上。集群对外提供 HTTP 服务时，通常再用 Ingress 按域名或路径路由，并在入口层终结 TLS。
配置与存储
- ConfigMap：存放非敏感配置，如配置文件、环境变量。
- Secret：存放密码、密钥等敏感数据（在 YAML 中以 Base64 呈现）。
- 存储：容器内的文件随容器消亡而丢失，Volume 提供挂载能力，需要跨节点共享或真正持久化时，由 PV 与 PVC 承接。
声明式 API 与 etcd
Kubernetes 的核心思想是"声明式"：你提交的是期望状态，而不是一步步的操作指令。所有资源的期望状态与实际状态都存放在 etcd（分布式键值数据库）中；kube-apiserver 是唯一读写入口，各类控制器对比"期望 vs 实际"并不断纠正偏差，这套循环叫控制回路：
kubectl apply -f deploy.yaml # 声明：我要 3 个副本
# 控制器发现当前只有 0 个，便持续创建，直到实际数量变为 3 个
小结：Kubernetes 的世界观是"一切皆资源、状态皆声明"。先把总览表里的概念分工记住，下一章学习架构时，就能明白每个组件在守护哪一类资源。