1.2. 学习路线：从零到生产

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

层级:

L1 · 入门

难度:

入门到进阶

周期:

6–10 周

前置:

Linux 基础、网络基础

1.2.1. 你将学到

  • 一条不会「学着学着卡住」的路径与顺序

  • 每个阶段必须完成的实验和验收标准

  • 实验集群的拓扑、网络规划与资源预算

  • 如何用「故障驱动」的方式训练排错能力

  • 哪些内容可以跳过，哪些不能

1.2.2. 先做一次前置自检

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

  • 能在 Linux 上用 systemctl 管理服务，看得懂 journalctl -u

  • 理解 IP、子网、路由、NAT、DNS 的基本概念

  • 会用 SSH、scp、tmux，能在多台机器上同时操作

  • 知道 YAML 的缩进、列表、映射，能读懂一份 Kubernetes 清单

  • 能接受「先看日志，再猜原因」的排错方式

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

1.2.3. 五个阶段

架构图

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

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

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

要学

产出

验收

环境选型与系统预检

一份节点检查脚本

4 台机器全部通过检查

kubeadm 集群

1 master + 3 worker

kubectl get nodes 全部 Ready

CNI 安装

Calico / Cilium / Flannel 三选一

CoreDNS Running，Pod 跨节点互通

第一个应用

Deployment + Service

curl 能访问，滚动更新成功

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

1.2.3.2. 阶段 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？

1.2.3.3. 阶段 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 分钟内定位

  • 能说清这个组件挂了会影响谁

  • 能完成一次备份与恢复演练

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

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

至少完整做完一个案例：

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

1.2.3.5. 阶段 05 · 生产化（持续）

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

  • 用 排错手册 建立自己的故障库

  • 用 命令速查 提升定位速度

  • 为集群建立备份、升级、容量、告警四份 Runbook

  • 做一次节点故障演练：关机、摘除、恢复、重新加入

  • 做一次控制平面故障演练：备份 etcd、恢复、验证

1.2.4. 实验拓扑

推荐用 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。

1.2.5. 本地最快路径：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.2.6. 怎么学才不「一看就会，一跑就废」

  1. 先预测，再执行：执行 kubectl apply 前，先写下你认为会创建哪些对象、Pod 会处于什么状态。

  2. 用证据说话：排错时先收集 get、describe、logs、events 四类证据，再提出假设。

  3. 主动破坏：每章至少做一次「删除 / 改错 / 打满」的故障实验，观察系统如何反应。

  4. 写成自己的 Runbook：把命令、现象、根因、修复写成三行，未来能省几小时。

  5. 不要复制粘贴到底：关键 YAML 手敲一遍，尤其是 selector、port、volumeMount 这些高频错误点。

1.2.7. 里程碑检查

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

  • 阶段 01：不看文档，能从零重建一个三节点集群

  • 阶段 02：给你一份报错的 Pod，能在 5 分钟内判断是镜像、配置、存储还是网络问题

  • 阶段 03：能画出你的平台架构图，并说清每个组件的故障影响

  • 阶段 04：能在一个新环境里，用一条流水线部署一个多组件应用

  • 阶段 05：能在 30 分钟内完成一次 etcd 备份恢复演练

1.2.8. 小结

  • 学习顺序比学习速度重要：环境 → 对象 → 平台 → 交付 → 生产化。

  • 每个阶段都要有可验收的产出，而不是「看完了」。

  • 实验环境可以随时销毁，这是你最大的优势：大胆破坏，认真复盘。

1.2.9. 延伸阅读