云原生学习路线复盘：从 Docker run 到 K8s Operator 的路径
一、云原生不是学一个工具，是学一套思维
刚开始接触时以为云原生就是 Docker + K8s。后来发现远远不够——Service Mesh、可观测性、GitOps、Policy as Code……每个都是独立领域，每个都能让人崩溃。
但回头看，真正有价值的不是会多少工具，而是形成了一条从应用视角到基础设施视角的认知升级路径。这篇文章复盘我从零到能写 K8s Operator 的学习路径，核心不是罗列资源，而是讲清楚"为什么学这个而不是那个"的决策逻辑。
flowchart TD A[阶段1: 容器化基础] --> B[阶段2: 编排与调度] B --> C[阶段3: 网络与流量治理] B --> D[阶段4: 可观测性] C --> E[阶段5: GitOps与自动化] D --> E E --> F[阶段6: 扩展开发] A --> A1[Docker / BuildKit<br/>Dockerfile 最佳实践<br/>多阶段构建] B --> B1[K8s 核心概念<br/>Pod/Deployment/Service<br/>ConfigMap/Secret] C --> C1[CNI / Service Mesh<br/>Istio / Envoy<br/>NetworkPolicy] D --> D1[Prometheus / Grafana<br/>Loki / Tempo<br/>OpenTelemetry] E --> E1[ArgoCD / Flux<br/>Helm / Kustomize<br/>Tekton] F --> F1[CRD / Operator<br/>Controller Runtime<br/>Admission Webhook]二、六个阶段的"为什么"
阶段一：容器化（约 2 周）
为什么从这里开始？因为容器是云原生的原子单位。不理解层缓存、多阶段构建、安全基线，后面的 K8s 调度优化就无从谈起。
关键产出：能写生产级 Dockerfile，理解 BuildKit 缓存机制，知道为什么COPY . .要放在 Dockerfile 最后。
阶段二：编排调度（约 4 周）
为什么第二个学 K8s？因为它是所有编排工具的语言基础。理解了 Pod 生命周期、ReplicaSet 的调和循环、Scheduler 的打分逻辑，后面看任何编排工具（Nomad、Swarm）都能类比。
关键产出：能部署多副本服务、配置 Readiness/Liveness Probe、理解滚动更新策略。
阶段三：网络流量治理（约 3 周）
为什么需要 Service Mesh？因为微服务拆分后，服务间的可靠性治理靠应用代码做是不现实的——每个团队都要写一边重试/熔断/限流。Service Mesh 把这层下沉到基础设施。
关键产出：能配 VirtualService/DestinationRule，理解 Sidecar 的资源开销。
阶段四：可观测性（约 2 周）
为什么不在阶段一就做？因为只有服务部署起来了才有东西可以观测。先有数据源，再学采集和分析。
关键产出：能搭建 Prometheus + Grafana 栈，理解高基数问题，会写 PromQL。
阶段五：GitOps（约 2 周）
为什么需要 GitOps？因为手动kubectl apply是不可审计、不可复现的。GitOps 让 Git 成为部署的唯一来源，任何变更都有 commit 记录。
关键产出：能用 ArgoCD 管理多环境，理解 ApplicationSet 矩阵生成。
阶段六：扩展开发（约 4 周）
为什么学 Operator？因为当标准 K8s 资源（Deployment、Service）无法描述你的业务逻辑时，你需要自定义资源。Operator 让你把运维知识编码为代码，自动调和实际状态和期望状态。
关键产出：能写一个简单的 CRD + Controller，理解 reconciliation loop。
三、每个阶段的核心资源与避坑
阶段一：容器化 核心资源：Docker 官方文档 + 《Docker in Action》 避坑：别花太多时间在 Docker Compose——它不是 K8s 的替代品 验证标准：你的 Dockerfile 能在 CI 中 60 秒内构建完成 阶段二：编排调度 核心资源：《Kubernetes in Action》+ K8s 官方 Tutorials 避坑：别在集群搭建上耗太久，用 kind/k3s 就够 验证标准：能解释 ReplicaSet 和 Deployment 的区别 阶段三：网络流量治理 核心资源：Istio 官方文档 + Envoy 源码中的 filter 链 避坑：别在没理解 iptables 原理时就用 Service Mesh 验证标准：能配置 A/B 流量分割而不改代码 阶段四：可观测性 核心资源：《Prometheus: Up & Running》 避坑：别把所有东西都打上 user_id 标签 验证标准：能写出 rate/irate/histogram_quantile 查询 阶段五：GitOps 核心资源：ArgoCD 官方文档 避坑：别把 Secret 明文放在 Git 里 验证标准：能通过 Git commit 触发一次完整的自动部署 阶段六：扩展开发 核心资源：Kubebuilder 官方 Book 避坑：别一上来就想写复杂 Operator，先从单 CRD 开始 验证标准：能写一个自定义资源 + 对应的 Controller四、边际效益递减的点
Docker Swarm：学了没用。K8s 已经是事实标准，Swarm 的就业场景极窄。
Helm 深度定制：学会 Helm Chart 的基本结构就够。复杂的包管理场景会被 GitOps + Kustomize 替代。
CNI 插件开发：除非做网络基础设施，否则配置 CNI 就够。
Service Mesh 自建：不要自建 Istio 集群。用云厂商的托管版，把运维成本外包。
五、总结
从 Docker 到 Operator 不是线性的技能堆叠，而是一级级抽象认知的升级。Docker 让你理解进程隔离，K8s 让你理解资源调和，Service Mesh 让你理解网络透明代理，Operator 让你理解"软件运维化"。每个阶段学透一件事，比每个工具都浅尝辄止有效得多。