上一篇【第03篇】手把手搭建K8s学习环境——minikube/kind/k3s三选一下一篇【第05篇】Docker退役了containerd和CRI的前世今生摘要“我们公司在做云原生转型”——这句话可能是过去五年技术圈最大的政治正确。你打开任何一家公司的招聘 JD熟悉云原生技术栈几乎成了标配。但你有没有想过云原生到底是个啥是 K8s 吗是 Docker 吗还是把服务器搬上云就叫云原生都不是。云原生不是某个具体的技术或产品而是一套工程方法论——教你如何设计、构建和运维能在云上最大程度发挥价值的应用。它背后有一个庞大的技术版图CNCF Landscape上面密密麻麻挂着 200 多个项目光看一眼就够劝退的。本文的目标就是帮你快速画出这张地图——搞清楚每个区域是干嘛的、哪些项目值得关注、K8s 在整个版图里处在什么位置。读完这篇下次看到 CNCF Landscape 你不会再头晕。一、云原生不是什么高大上的东西——它就是一套工程方法论先来破除一个常见的迷思云原生 ≠ 上云。你把一台物理机上的 WAR 包原封不动地搬到云虚拟机里跑这不叫云原生——这叫把大象塞进冰箱只不过冰箱换了个牌子。云原生的核心问题不是在哪里跑而是怎么跑。CNCF 对云原生的官方定义是云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。说人话就是把你的应用设计和运行方式从精装修的独栋别墅变成乐高积木搭的可拆卸公寓。每一个组件都是标准的、可替换的、能独立伸缩的。【传统应用 vs 云原生应用】 传统应用单体 云原生应用微服务 容器化 ┌─────────────────┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │ │ │A │ │B │ │C │ │D │ │ WAR 包 │ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ │ 所有功能耦合 │ │ │ │ │ │ 一起部署 │ ┌──────┼─────┼─────┼─────┼──────┐ │ 一起扩缩容 │ │ │ │ │ │ │ │ 一起挂掉 │ │ Kubernetes (调度/编排/治理) │ └─────────────────┘ │ Prometheus (监控) │ 爆改一种功能 → 整栋拆 │ Istio (服务网格) │ 扩容 → 整栋复制 │ Helm (包管理) │ 部署 → 半天起步 └──────────────────────────────┘ 每个组件独立开发、独立测试、独立部署、独立伸缩要点云原生的本质就六个字——标准化、自动化、弹性化。标准化意味着容器镜像声明式配置自动化意味着 CI/CD 流水线和 GitOps弹性化意味着自动扩缩容和自愈。这三样一样都不能少。我第一次给团队讲云原生的时候有个同事说这东西不就是微服务容器DockerKubernetes吗我说你漏了最关键的部分——运维理念的变革。云原生不只是技术堆叠它是从养宠物到养牛羊的思维转变。养宠物传统运维每台服务器都是独一无二的有名字有感情病了要救死了要抢救养牛羊云原生运维所有实例都是一样的挂了就删掉重新拉一个不追查死因只保证数目够二、CNCF全景图——一张地图看清200项目CNCFCloud Native Computing Foundation是云原生生态的联邦政府由 Google 在 2015 年联合 Linux 基金会创立。K8s 是这个基金会的第一个项目也是其中最重量级的成员。CNCF 维护着一张著名的技术全景图CNCF Cloud Native Landscape上面密密麻麻排列着 200 个项目。每个项目被分到不同的城区里——这些城区构成了云原生的完整技术栈。【CNCF 技术版图分区速览】 ┌─────────────────────────────────────────────────────────────────┐ │ CNCF Cloud Native Landscape │ │ │ │ ┌───────────┐ ┌───────────┐ ┌─────────────┐ │ │ │ 自动配置 │ │ 编排调度 │ │ 服务网格 │ │ │ │ Terraform │ │ Kubernetes│ │ Istio │ │ │ │ Crossplane │ │ Nomad │ │ Linkerd │ │ │ └───────────┘ └───────────┘ └─────────────┘ │ │ │ │ ┌───────────┐ ┌───────────┐ ┌─────────────┐ │ │ │ 可观测性 │ │ 持续交付 │ │ 存储 │ │ │ │Prometheus │ │ ArgoCD │ │ Rook/Ceph │ │ │ │ Grafana │ │ FluxCD │ │ Longhorn │ │ │ │ Jaeger │ │ Tekton │ │ OpenEBS │ │ │ └───────────┘ └───────────┘ └─────────────┘ │ │ │ │ ┌───────────┐ ┌───────────┐ ┌─────────────┐ │ │ │ 容器运行时 │ │ 网络 │ │ Serverless │ │ │ │containerd │ │ Calico │ │ Knative │ │ │ │ CRI-O │ │ Cilium │ │OpenFunction│ │ │ └───────────┘ └───────────┘ └─────────────┘ │ │ │ │ ┌───────────┐ ┌───────────┐ ┌─────────────┐ │ │ │ 包管理 │ │ 安全合规 │ │ 服务代理 │ │ │ │ Helm │ │ Falco │ │ Envoy │ │ │ │ Kustomize│ │Trivy/OPA │ │ Contour │ │ │ └───────────┘ └───────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘ Kubernetes 处在正中央 —— 它是云原生世界的太阳要点别看这张图密密麻麻就害怕。你不需要认识上面每一个项目。根据我们团队的经验一个标准的云原生技术栈核心只需要掌握 8-10 个项目就足够了。剩下的可以根据业务需求按需了解。各分区一句话速览分区核心问题代表项目一句话解释编排调度应用放哪台机器跑KubernetesK8s 是云原生世界的操作系统容器运行时容器到底怎么跑containerd, CRI-O底层引擎你平时基本无感网络Pod之间怎么通信Calico, CiliumK8s 网络的高速公路存储数据存哪里挂了怎么办Rook, Longhorn让有状态应用也能在 K8s 上跑服务网格服务间通信怎么管Istio, Linkerd流量控制、安全、可观测性的基础设施层可观测性系统在干什么出问题了咋知道Prometheus, Grafana, Jaeger监控日志追踪三位一体持续交付代码怎么自动上线ArgoCD, FluxCDGitOps 代码仓库即控制面包管理怎么装/升级 K8s 应用Helm, KustomizeK8s 世界的 apt-get/brewServerless能不能不关心服务器Knative, OpenFunction极致弹性只为实际调用付费三、十二要素应用——云原生应用的建造规范如果说 CNCF 全景图是用什么建十二要素应用The Twelve-Factor App就是建成什么样。这套方法论由 Heroku 的工程师在 2011 年提出现在被奉为云原生应用设计的圣经。它定义了现代应用应该遵循的十二条规范【十二要素应用建造规范速览】 要素 1: 代码库 要素 2: 依赖 要素 3: 配置 一份代码多次部署 显式声明隔离打包 配置与代码分离 ┌──────────┐ ┌──────────┐ ┌──────────┐ │Git Repo │ │package.json│ │环境变量 │ │ ├dev │ │Gemfile │ │ConfigMap │ │ ├staging│ │go.mod │ │Secret │ │ └prod │ └──────────┘ └──────────┘ └──────────┘ 要素 4: 后端服务 要素 5: 构建/发布/运行 要素 6: 进程 把服务当附加资源 严格分离三阶段 无状态不共享 ┌──────────┐ ┌──┐ ┌──┐ ┌──┐ ┌──────────┐ │DBURL │ │构建│→│发布│→│运行│ │每个进程 │ │CacheURL │ │(不可变)│(配置镜像)│ │独立内存 │ │MQURL │ └──┘ └──┘ └──┘ └──────────┘ └──────────┘ 要素 7: 端口绑定 要素 8: 并发 要素 9: 可处置性 通过端口暴露服务 通过进程模型扩展 快速启动优雅关闭 ┌──────────┐ ┌──────────┐ ┌──────────┐ │app:8080 │ │横扩进程 │ │秒级启动 │ │无需Web容器│ │不搞多线程 │ │优雅终止 │ └──────────┘ └──────────┘ └──────────┘ 要素10: 环境等价 要素11: 日志 要素12: 管理进程 开发/预发/生产一致 把日志当事件流 管理任务一次性执行 ┌──────────┐ ┌──────────┐ ┌──────────┐ │容器镜像 │ │stdout │ │DB迁移 │ │一套跑所有│ │→ 集中收集 │ │一次性脚本 │ └──────────┘ └──────────┘ └──────────┘别被十二条吓到。你不需要一次全部做到但有几个核心原则是写云原生应用时必须遵守的要点配置与代码分离要素3不要把数据库密码写在代码里。用环境变量、K8s ConfigMap/Secret。代码开源了密码不至于一起漏出去。无状态要素6进程不保存状态状态交给外部服务数据库、缓存、消息队列。这样你的 Pod 删了重建也不会丢数据。环境等价要素10开发用 macOS、测试用 Ubuntu、生产用 CentOS → 这种三重天是云原生的大忌。Docker 镜像让所有环境保持一致。日志当事件流要素11不要自己写日志文件轮转直接把日志打到 stdout/stderr让 K8s/日志收集器帮你收集。我们团队曾经有个经典事故一个 Python 应用在开发环境跑得好好的上了生产就报错——因为开发用了 Python 3.10 的 match-case 语法生产是 Python 3.8。如果当时做了容器化要素10这个 bug 根本不会出生。四、K8s在云原生生态中的核心位置——太阳系模型K8s 在整个 CNCF 生态中到底处于什么位置我用一个太阳系模型来比喻【云原生太阳系模型】 ┌───────────────────────────────────────┐ │ 外围生态圈可插拔 │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ ArgoCD │ │ Knative │ │ │ │ (GitOps) │ │(Serverless)│ │ │ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ ┌────┴─────┐ ┌────┴─────┐ │ │ │ Helm │ │ Istio │ │ │ │ (包管理) │ │(服务网格) │ │ │ └────┬─────┘ └────┬─────┘ │ │ │ │ │ └────────┼─────────────────┼────────────┘ │ │ ┌────────┴──── 核心层 ─────┴────────┐ │ │ │ ┌─────────────────────────────┐ │ │ │ Kubernetes │ │ │ │ │ │ │ │ ┌─────────┐ ┌───────────┐ │ │ │ │ │ 调度器 │ │ API-Server│ │ │ │ │ └─────────┘ └───────────┘ │ │ │ │ ┌─────────┐ ┌───────────┐ │ │ │ │ │控制器 │ │ etcd │ │ │ │ │ └─────────┘ └───────────┘ │ │ │ └─────────────────────────────┘ │ │ │ └───────┬───────────┬───────────────┘ │ │ ┌───────┴───┐ ┌───┴───────────┐ │Prometheus │ │ Fluentd/ │ │ (监控) │ │ OpenTelemetry│ └───────────┘ │ (日志/追踪) │ └───────────────┘ 基础层必须配套要点K8s 不是孤立的它是整个生态的调度中心和编排核心。所有其他工具都是围绕 K8s 展开的——不是 K8s 依赖它们而是它们依赖 K8s 的 API 和扩展机制。这个模型告诉我们几件事K8s 是核心但不够用光有 K8s 只能调度容器你还缺监控、日志、CI/CD、服务网格……周边项目是可插拔的监控你可以选 Prometheus也可以用 Datadog服务网格你可以选 Istio也可以用 Linkerd——K8s 不绑死任何一个。趋势是统一到 K8s API越来越多的工具通过 CRD自定义资源和 Operator 的方式把自己的能力融入 K8s 的声明式 API 体系。最终用户只需要写 YAML操作体验完全统一。五、重点CNCF项目速览——这几个你必须认识CNCF 200 多个项目不可能全学。但以 K8s 为中心有几个项目的出现频率高到躲不开值得专门认识一下。Prometheus监控告警—— CNCF 第二个毕业项目【Prometheus 架构拉模式采集】 ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Node │ │ K8s Pod │ │ App │ │ Exporter │ │ Metrics │ │ Metrics │ │(机器指标) │ │(容器指标) │ │(业务指标) │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ scrape │ scrape │ scrape └──────────────┼─────────────┘ ▼ ┌──────────────┐ ┌──────────────┐ │ Prometheus │──────► AlertManager│ │ (TSDB 时序) │ Alert │ (告警路由) │ └──────┬───────┘ └──────────────┘ │ PromQL 查询 ▼ ┌──────────────┐ │ Grafana │ │ (面板展示) │ └──────────────┘ 特点拉模式不是被推送、多维数据模型、强大 PromQL 查询语言Prometheus 是 CNCF 中仅次于 K8s 的第二重要的项目。它的核心设计是拉模式Pull——Prometheus 服务器主动去各个目标抓取指标而不是等着被推送。这个设计非常契合 K8s 的动态环境Pod 来了又走IP 变来变去Prometheus 通过 Service Discovery 自动发现新目标。Istio服务网格—— 把流量管控下沉到基础设施【Istio 服务网格Sidecar 代理模式】 没有 Istio 有了 Istio ┌──────────┐ ┌──────────────────────┐ │ App A │ │ Pod (App A) │ │ ┌────┐ │ │ ┌────────┐ │ │ │重试 │ │ │ │ Istio │ ◄─ Sidecar │ │熔断 │ │ ◄── 治理逻辑 │ │ Proxy │ │ │ │超时 │ │ 写在应用代码里 │ └──┬─────┘ │ │ │路由 │ │ │ │ │ │ └────┘ │ │ ┌──┴─────┐ │ └──────────┘ │ │ App A │ │ │ │(纯业务逻辑)│ │ ❌ 每个语言都要重写一套 │ └────────┘ │ ❌ 业务代码混入运维逻辑 └──────────────────────┘ ❌ 升级治理规则要改代码 │ ✅ 治理逻辑下沉到 Sidecar ✅ 业务代码零侵入 ✅ 语言无关统一灰度/熔断/限流Istio 的核心思想是Sidecar 模式在每个 Pod 里注入一个代理容器Envoy所有进出 Pod 的流量都经过这个代理。流量管理、安全、可观测性全部由代理层完成业务代码完全不感知。Helm包管理—— K8s 世界的 apt-get不用 Helm 的 K8s 用户就像不用 npm 的 Node.js 开发者——可以但这日子没法过。Helm 把一组 K8s 资源打包成一个 Chart一键安装、升级、回滚。# 三行命令装一个完整的 MySQL 集群helm repoaddbitnami https://charts.bitnami.com/bitnami helminstallmy-mysql bitnami/mysql# 装好了数据库、Service、PVC、Secret 全部就绪要点Helm 的价值不只是一键安装那么简单。它解决的核心问题是K8s YAML 文件到处都是模板变量环境名、镜像版本、副本数靠手动 sed 替换又累又容易出错。Helm 把模板和值分离同一套模板 不同的 values.yaml 不同的环境。ArgoCDGitOps—— 让代码仓库成为部署的唯一真相源GitOps 的核心思想一句话Git 仓库里的 YAML 文件是什么样K8s 集群就是什么样。ArgoCD 就是这个思想的实现者——它持续监控 Git 仓库发现差异就自动同步或告警。【GitOps 工作流ArgoCD】 开发者 push 代码到 Git │ ▼ ┌──────────────┐ 同步 ┌──────────────┐ │ Git Repo │◄─────────►│ ArgoCD │ │ (期望状态) │ 比较 │ (持续调和) │ └──────────────┘ └──────┬───────┘ │ apply ▼ ┌──────────────┐ │ K8s Cluster │ │ (实际状态) │ └──────────────┘ 如果 Git 和集群不一致 → ArgoCD 会自动把集群往 Git 的状态拉 如果集群被手动改了 → ArgoCD 会检测到并告警/自动回滚其他值得关注的项目速查表项目类别一句话CoreDNS服务发现K8s 集群内置 DNS替换了原来的 kube-dnsetcd分布式存储K8s 的数据库存所有集群状态Envoy服务代理Istio 的底层代理也是独立的 L7 代理Falco安全容器运行时安全监控行为异常立即告警Harbor镜像仓库企业级私有 Docker RegistryJaeger分布式追踪追踪一次请求在微服务中的完整调用链路OpenTelemetry可观测性标准统一日志/指标/追踪的数据采集标准Vitess数据库MySQL 水平分片的集群管理方案Keda事件驱动自动伸缩不只按 CPU/内存扩缩按 Kafka 消息队列长度也行Crossplane基础设施即代码用 K8s 风格的 YAML 管理云资源数据库、VPC、负载均衡器六、云原生的真实落地——不要被PPT架构忽悠学到这里你可能觉得哇这么多牛逼的项目组合起来就是银弹但现实是——大部分公司的云原生落地比这朴素得多。【真实云原生落地分级】 Level 0: 上云跟云原生没啥关系 虚拟机 手动部署 没有容器 我们把服务器搬上阿里云了 Level 1: 容器化入门级 Docker docker-compose 生产环境终于不会我本地可以跑了 Level 2: K8s 编排及格线 K8s Prometheus Helm Pod 挂了能自愈流量高了能自动扩缩 Level 3: 完整云原生优秀 K8s Prometheus Istio ArgoCD EFK/PLG Git push 后 5 分钟自动上线灰度发布零停机 任何服务异常 30 秒内收到告警 Level 4: 平台化极致 自建内部开发者平台IDP 自服务 Portal 开发者填个表单环境/数据库/监控全自动配好我见过太多公司PPT 上画的是 Level 4 的豪华架构实际落地连 Level 1 都跌跌撞撞。这没什么丢人的——云原生转型是个渐进的过程把当前阶段做好比追求全家桶重要得多。要点云原生落地的正确顺序是先容器化Docker→ 再编排K8s→ 再可观测性Prometheus Grafana 日志→ 再 CI/CDArgoCD 等→ 最后上服务网格Istio等高级特性。跳过前面的步骤直接上 Istio那你不是在搞云原生你是在给自己找事。从我带过的几个项目来看大多数团队把 Level 2 做好就够解决 80% 的问题了。再往上走每多一个层级运维复杂度会明显上升。Istio 很强但它的 Sidecar 注入会增加延迟和资源消耗ArgoCD 很香但它需要团队接受 GitOps 的工作方式。所以——量力而行逐步推进。本篇小结云原生不是魔法是一套经过工程验证的方法论核心思想标准化、自动化、弹性化。从养宠物到养牛羊的思维转变是云原生最根本的变化。CNCF 全景图200 项目分在十几个领域——编排调度、网络、存储、可观测性、CI/CD、Serverless……K8s 是这张地图的正中心。十二要素应用容器化、配置分离、无状态、等价环境……是设计云原生应用的黄金法则。关键项目Prometheus监控、Istio服务网格、Helm包管理、ArgoCDGitOps是与 K8s 最紧密的四大护法。落地路径容器化 → K8s 编排 → 可观测性 → CI/CD → 服务网格循序渐进别被 PPT 架构忽悠了。下一篇我们来聊一个让很多人困惑的话题K8s 从 1.24 开始不支持 Docker 了这是真的吗containerd 和 CRI-O 又是什么鬼别怕你的docker build命令不会消失。上一篇【第03篇】手把手搭建K8s学习环境——minikube/kind/k3s三选一下一篇【第05篇】Docker退役了containerd和CRI的前世今生