云原生学习路线复盘：从 Docker run 到 K8s Operator 的路径（续篇）

云原生学习路线复盘：从 Docker run 到 K8s Operator 的路径（续篇）

不是"先学 Docker 再学 K8s"就完事了——真正的路线是理解每一层为什么要存在。

一、起点：为什么从 Docker 开始

大多数人学云原生的起点是 docker run。这不是因为 Docker 最简单，而是因为容器是云原生的最小单元——不理解容器就无法理解 K8s 的 Pod、Service、Deployment，这些概念都建立在容器的抽象之上。

但很多人停在 Docker 层：学会了写 Dockerfile、用 docker-compose 编排多容器、知道 volume 和 network，就以为自己"懂云原生了"。实际上这只到了云原生技术的第一层——容器运行时。真正的云原生路线至少还有四层要走。

二、底层机制与原理剖析

2.1 云原生技术的五层模型

2.2 每层的学习时间和深度

2.3 关键跳跃点

每两层之间有一个"跳跃点"——需要理解新层存在的根本原因才能继续：

• L1→L2：为什么要编排？单机容器够用吗？不够——多容器需要调度、自愈、网络互通
• L2→L3：为什么需要 Service Mesh？K8s Service 不够吗？不够——Service 只做服务发现，不做流量管理、链路追踪、故障注入
• L3→L4：为什么需要 GitOps？手动部署不行吗？不行——手动部署不可重复、不可审计、不可回滚
• L4→L5：为什么需要 Operator？Helm 不够吗？不够——Helm 只做模板渲染，不做状态监控和自动纠正

三、学习路线的实操建议

3.1 容器运行时层（2 周）

学习路径：不是"学 Docker 命令"，而是"理解容器为什么存在"。

# 容器运行时学习清单

## 第一周：镜像与容器原理
1. 写一个 Dockerfile，理解每一条指令的镜像层变化
– 运行 `docker history <image>` 看每一层的大小和命令
– 修改一条 RUN 指令，重新构建，观察哪些层被缓存了
2. 理解 Union FS（OverlayFS）：为什么镜像层可以共享
– 两个基于相同 base image 的容器，共享了 base 层
– 容器层是 COW（Copy-on-Write）：修改文件时才复制
3. 理解容器隔离：namespaces + cgroups
– `docker exec` 进容器，用 `ls /proc` 看进程列表（只有容器内的进程）
– `cat /proc/1/cgroup` 看资源限制配置

## 第二周：Volume 与 Network
1. 用 bind mount 和 named volume 分别挂载数据，对比行为差异
2. 创建自定义 network，两个容器通过容器名通信（DNS 自动解析）
3. 理解容器网络模型：veth pair + bridge
– `docker network inspect bridge` 看网络配置

3.2 容器编排层（4 周）

学习路径：不是"学 K8s YAML 语法"，而是"理解每个对象为什么存在"。

# K8s 核心对象学习清单

## 第一周：Pod——最小调度单元
1. 为什么 K8s 不直接调度容器？Pod 的存在意义是什么？
– Pod 是一组共享网络和存储的容器：sidecar 模式的基础
– 同 Pod 内容器共享 localhost 和 volume
– 调度粒度是 Pod 不是容器：保证同 Pod 容器在同一节点
2. 创建一个多容器 Pod（应用 + sidecar），观察容器间通信
3. 理解 Pod 的生命周期：Pending → Running → Succeeded/Failed

## 第二周：Deployment——自愈与滚动更新
1. Deployment 不是直接管理 Pod，而是管理 ReplicaSet
– ReplicaSet 确保 Pod 数量：Pod 挂了自动重建
– Deployment 控制更新策略：滚动更新 vs 重建更新
2. 实操：手动删除一个 Pod，观察 Deployment 自动重建
3. 实操：修改 Deployment 的 image 版本，观察滚动更新过程
– `kubectl rollout status deployment/<name>` 看更新进度

## 第三周：Service——服务发现与负载均衡
1. Service 的底层实现：iptables 或 IPVS 规则
– `iptables -t nat -L -n` 看 Service 的 NAT 规则
– 每个 Service 创建一组 iptables 规则：ClusterIP → PodIP
2. Service 类型对比：ClusterIP / NodePort / LoadBalancer
3. Headless Service：不分配 ClusterIP，DNS 直接返回 PodIP
– 用途：StatefulSet 的 Pod 需要稳定的网络标识

## 第四周：ConfigMap + Secret + Ingress
1. ConfigMap：环境变量 vs Volume 挂载两种使用方式
2. Secret：Base64 编码不是加密，理解安全风险
3. Ingress：HTTP 路由规则，理解 Ingress Controller 的实现

3.3 Operator 层（4 周）

学习路径：Operator 是"将运维知识编码为软件"的实现。核心是理解 K8s 的声明式 API 和控制器循环。

# Operator 开发学习清单

## 第一周：理解控制器模式
1. K8s 的所有控制组件（Deployment Controller、ReplicaSet Controller）都遵循同一个模式：
– Watch：监听资源变化事件
– Compare：比较当前状态与期望状态
– Act：执行操作使当前状态收敛到期望状态
– 这个循环叫 reconciliation loop（调和循环）
2. 手动实现一个简单的控制器：Watch ConfigMap 变化，自动创建 Pod

## 第二周：CRD（自定义资源定义）
1. 定义一个 CRD：自定义资源的 schema
2. 创建自定义资源实例：`kubectl apply -f my-resource.yaml`
3. `kubectl get my-resources`：自定义资源像原生资源一样可用

## 第三周：Operator SDK / Kubebuilder
1. 用 Kubebuilder 创建 Operator 项目骨架
2. 实现 Reconcile 逻辑：Watch CRD 变化 → 创建/更新/删除底层资源
3. 状态更新：将底层资源的状态回写到 CRD 的 status 字段

## 第四周：Webhook（准入控制）
1. Validating Webhook：拦截非法的 CRD 创建请求
2. Mutating Webhook：自动修改 CRD 字段（注入默认值）
3. Webhook 的 TLS 配置：K8s API Server 到 Webhook 的通信必须加密

四、边界分析与现实权衡

4.1 不是每个人都要走到第五层

90% 的开发者只需要走到第二层（K8s 核心对象）。第三层（Service Mesh）是 SRE/架构师的领域，第四层（GitOps）是 DevOps 工程师的领域，第五层（Operator）是平台开发者的领域。

选择标准：你的角色决定了你需要走到哪一层。前端开发者走到第二层就够了，后端开发者走到第三层，运维走到第四层，平台开发者走到第五层。

4.2 学习时间的现实约束

完整路线最短 14 周（3.5 个月），大部分开发者不可能投入这么多时间。现实方案：按需学习，不按顺序学习。你需要解决什么问题就学什么层级——当你遇到"Pod 经常被杀不知道为什么"的问题时，自然会深入到第二层的 Pod 生命周期和资源限制。

4.3 跳过 Docker 直接学 K8s 的可行性

理论上可以——K8s 不依赖 Docker（用 containerd 作为运行时）。但实操上不建议跳过：不理解容器就无法理解 Pod 的行为（为什么容器共享网络、为什么容器间可以通过 localhost 通信）。

4.4 学习路线与职业路线的对齐

五、结语

云原生学习路线不是线性递进，而是按角色按需深入。五层模型：容器运行时→编排→服务治理→平台工程→扩展开发。每层之间的跳跃点是"理解新层存在的根本原因"。90% 的开发者只需要走到第二层，不需要学 Service Mesh 和 Operator。按需学习优于按顺序学习——遇到问题时学对应层级，不提前学不相关的内容。容器运行时的原理（镜像分层、隔离机制）是所有层的基础，不能跳过。Operator 是最高层但不是每个人都需要——只有平台开发者需要"将运维知识编码为软件"。