讲解
Kubernetes（常缩写为 K8s）是容器编排系统的事实标准。如果说 Docker 解决了「把应用和环境打包成一个容器到处运行」的问题，那么 Kubernetes 解决的是它的下一段：当你有几十、几百个容器要跨多台机器运行时，谁来决定容器跑在哪台机器上、挂了谁来重启、流量怎么分发、配置怎么下发、扩容缩容怎么做。这些「编排」工作纯手工做会迅速失控，Kubernetes 把它们变成声明式的 API：你描述「我想要 3 个副本始终运行」，系统负责让现实收敛到期望。
集群的架构分两层。控制平面（control plane）是大脑：API Server 是唯一入口，所有操作都经过它；etcd 保存集群全部状态；Scheduler 决定 Pod 调度到哪个节点；Controller Manager 里跑着一堆控制器，持续把实际状态拉回期望状态。工作节点（node）是肌肉：kubelet 是节点上的代理人，负责按 API Server 的指示起停容器；容器运行时（containerd 等）真正拉镜像、跑容器；kube-proxy 维护网络规则，让 Service 的虚拟 IP 能转发到真实 Pod。
学习 Kubernetes 最重要的心智模型是「声明式 + 控制器循环」：你提交一份 YAML 描述期望状态（比如「这个镜像跑 3 个副本」），控制器不断对比期望与现实，发现偏差就修正——机器宕机、容器崩溃都只是「偏差」，会被自动修复。这和命令式的「登录每台机器执行脚本」有本质区别。也是因为这个模型，Kubernetes 的学习曲线前段较陡：概念多（Pod、Deployment、Service、ConfigMap……），但每个概念都对应一个真实的运维痛点，本教程会按「从最小单元到完整应用」的顺序逐个展开，每个示例都在真实集群里验证过。
示例
确认 kubectl 能连上集群（客户端与服务端版本都会打印）：
kubectl version
看集群的入口地址和核心组件状态：
kubectl cluster-info
kubectl get nodes -o wide
集群里已有的命名空间——kube-system 里跑着控制平面组件，default 是默认工作空间：
kubectl get namespaces
常见坑
- 上来就想自建生产集群：kubeadm 裸装一套高可用集群涉及证书、网络插件、etcd 备份等大量细节，初学者先用 kind/minikube 这类本地工具把概念学扎实。
- 把 Pod 当成最终管理对象：几乎没有人直接创建裸 Pod 跑业务——那是 Deployment 等控制器的工作，直接管 Pod 等于放弃了自愈能力。
- 以为 Kubernetes 管容器：它管理的对象是 Pod（一组共享网络和存储的容器），容器只是 Pod 的实现细节。
- 混淆 kubectl 配置文件：kubectl 靠 kubeconfig（默认 ~/.kube/config）找集群，多集群时 context 切错了，命令就打到了错误的集群上。
小结
Kubernetes = 声明式容器编排：控制平面（API Server/etcd/Scheduler/控制器）出决策，工作节点（kubelet/运行时/kube-proxy）干活；核心心智是「描述期望状态，控制器负责收敛」。下一章用 kind 在本机搭一个真实集群。