学习路线：从零到生产

这是一条按依赖关系设计的路线，而不是一份组件清单。每个阶段都有明确的产出物：一个能运行的集群、一个能自愈的应用、一条能回滚的流水线。完成验收，再进入下一阶段。

难度 · 入门到进阶 周期 · 6–10 周 前置：Linux 基础、网络基础

你将学到

• 一条不会「学着学着卡住」的路径与顺序
• 每个阶段必须完成的实验和验收标准
• 实验集群的拓扑、网络规划与资源预算
• 如何用「故障驱动」的方式训练排错能力
• 哪些内容可以跳过，哪些不能

先做一次前置自检

本站默认你已经具备下面这些能力。如果有一项不熟，先补，不然会在集群部署阶段反复卡住：

• 能在 Linux 上用 systemctl 管理服务，看得懂 journalctl -u
• 理解 IP、子网、路由、NAT、DNS 的基本概念
• 会用 SSH、scp、tmux，能在多台机器上同时操作
• 知道 YAML 的缩进、列表、映射，能读懂一份 Kubernetes 清单
• 能接受「先看日志，再猜原因」的排错方式

不需要提前学 Docker 的全部细节，但要知道镜像、容器、联合文件系统、端口映射是什么。

五个阶段

flowchart LR
  A["01 环境<br/>3–5 天"] --> B["02 核心对象<br/>2 周"]
  B --> C["03 平台能力<br/>3 周"]
  C --> D["04 交付实战<br/>2 周"]
  D --> E["05 生产化<br/>持续"]

图：建议顺序。02 和 03 的部分章节可以穿插，但不要跳过 02 直接学平台组件。

阶段 01 · 建立环境（3–5 天）

目标：拥有一个可以反复销毁、重建的三节点集群。

要学	产出	验收
环境选型与系统预检	一份节点检查脚本	4 台机器全部通过检查
kubeadm 集群	1 master + 3 worker	kubectl get nodes 全部 Ready
CNI 安装	Calico / Cilium / Flannel 三选一	CoreDNS Running，Pod 跨节点互通
第一个应用	Deployment + Service	curl 能访问，滚动更新成功

对应章节：环境与工具 → 集群部署 → 第一个应用

阶段 02 · 掌握核心对象（2 周）

目标：看到任意一份 YAML，能说出它会创建什么、控制器会做什么、失败时先看哪里。

章节	必须完成的实验	验收问题
架构与对象模型	用 kubectl -v=6 观察一次 apply	请求经过哪些组件？
Pod 与容器	探针、Init、Sidecar、资源限制	探针失败时 Pod 会怎样？
工作负载	滚动更新、回滚、StatefulSet 扩容	为什么删 Pod 后 Deployment 会重建？
配置与密钥	ConfigMap 热更新、Secret 挂载	改 ConfigMap 后进程会自动重载吗？
存储与持久化	动态 PVC、StatefulSet 卷	PVC 为什么一直 Pending？
服务与网络	ClusterIP/NodePort/Headless、NetworkPolicy	Service 没有 Endpoint 说明什么？
认证与安全	RBAC、ServiceAccount、SecurityContext	为什么 kubectl auth can-i 说 no？

阶段 03 · 补齐平台能力（3 周）

目标：让集群具备「可观测、可访问、可存储、可恢复」的能力。

按 平台能力总览 的顺序推进，不要一次装完。每周选 2–3 个能力域：

• 第 1 周：metrics-server、HPA、KEDA；Prometheus + Grafana
• 第 2 周：CNI 深入、MetalLB、ingress-nginx、灰度发布
• 第 3 周：OpenEBS / NFS CSI、Loki 或 ELK、cert-manager、Velero、Karmada

验收标准不是「Pod Running」，而是：

• 能用一个 Dashboard / 查询证明系统健康
• 能人为制造一次故障，并在 10 分钟内定位
• 能说清这个组件挂了会影响谁
• 能完成一次备份与恢复演练

阶段 04 · 交付实战（2 周）

目标：把前面所有能力组合成一条可重复的交付链路。

至少完整做完一个案例：

• WordPress：单应用、全对象，适合第一次串联
• 微服务商城：多组件、依赖顺序、可观测性
• 私有云案例：基础设施 + 平台 + 应用

然后补上 Helm 与 Jenkins / GitLab，把手工命令变成流水线。

阶段 05 · 生产化（持续）

目标：从「能跑」到「敢让它跑业务」。

• 用 排错手册 建立自己的故障库
• 用 命令速查 提升定位速度
• 为集群建立备份、升级、容量、告警四份 Runbook
• 做一次节点故障演练：关机、摘除、恢复、重新加入
• 做一次控制平面故障演练：备份 etcd、恢复、验证

实验拓扑

推荐用 4 台 Ubuntu 22.04 / 24.04 虚拟机（VMware、Proxmox、UTM、OpenStack 均可）：

主机	IP	角色	最低配置	建议
k8s-master01	192.168.10.6	control-plane	2C / 4G / 40G	4C / 8G / 60G
k8s-node01	192.168.10.11	worker	2C / 4G / 40G	4C / 8G / 80G
k8s-node02	192.168.10.12	worker	2C / 4G / 40G	4C / 8G / 80G
k8s-node03	192.168.10.13	worker	2C / 4G / 40G	4C / 8G / 80G

网络规划：

• 节点网段：192.168.10.0/24
• Pod CIDR：10.244.0.0/16
• Service CIDR：10.96.0.0/12
• MetalLB 地址池：与节点同网段的空闲 IP，例如 192.168.10.51–192.168.10.80
• 域名：实验可用 *.magedu.com，通过本机 hosts 或内网 DNS 解析

不要在生产环境照搬

这是实验拓扑。生产环境至少需要 3 个 control-plane 节点、独立的 etcd 磁盘、带外管理网络和真实的负载均衡 VIP。

本地最快路径：kind

如果你只想先体验核心对象，不想开 4 台虚拟机，可以用 kind 在 macOS / Linux 上跑一个单节点集群：

brew install kind kubectl helm
kind create cluster --name k8s-lab --image kindest/node:v1.31.0
kubectl cluster-info --context kind-k8s-lab

kind 的边界：

• 不支持 LoadBalancer 的真实外部 IP（可用 cloud-provider-kind 或 NodePort）
• 存储默认是 standard（hostPath），不适合演练 NFS / 快照
• 节点故障、kubelet 配置、系统内核参数类实验无法真实模拟

所以：kind 用来学对象，虚拟机用来学集群。平台与交付章节建议在虚拟机上完成。

怎么学才不「一看就会，一跑就废」

1. 先预测，再执行：执行 kubectl apply 前，先写下你认为会创建哪些对象、Pod 会处于什么状态。
2. 用证据说话：排错时先收集 get、describe、logs、events 四类证据，再提出假设。
3. 主动破坏：每章至少做一次「删除 / 改错 / 打满」的故障实验，观察系统如何反应。
4. 写成自己的 Runbook：把命令、现象、根因、修复写成三行，未来能省几小时。
5. 不要复制粘贴到底：关键 YAML 手敲一遍，尤其是 selector、port、volumeMount 这些高频错误点。

里程碑检查

完成一个阶段，给自己做一次口头验收：

• 阶段 01：不看文档，能从零重建一个三节点集群
• 阶段 02：给你一份报错的 Pod，能在 5 分钟内判断是镜像、配置、存储还是网络问题
• 阶段 03：能画出你的平台架构图，并说清每个组件的故障影响
• 阶段 04：能在一个新环境里，用一条流水线部署一个多组件应用
• 阶段 05：能在 30 分钟内完成一次 etcd 备份恢复演练

小结

• 学习顺序比学习速度重要：环境 → 对象 → 平台 → 交付 → 生产化。
• 每个阶段都要有可验收的产出，而不是「看完了」。
• 实验环境可以随时销毁，这是你最大的优势：大胆破坏，认真复盘。

延伸阅读

• Kubernetes 官方教程
• kubeadm 安装文档
• CNCF 云原生路线图
• 下一步：环境与工具