Forrest
返回归档
☁️Kubernetes

云原生

更新于 2024/10/126 分钟阅读

云原生不是某一种产品，也不是把应用搬到云上。它是面向云计算环境、从设计之初就为云而生的软件构建、部署和运行方法论。

文章目录

云原生（Cloud Native）不是某一种具体产品，也不是「把应用搬到云上就算云原生」。它是一套面向云计算环境、从设计之初就为云而生的软件构建、部署和运行方法论。

一句话：让应用「生于云、长于云」，把弹性伸缩、故障自愈、资源调度、发布变更等非业务能力尽量交给平台，开发者聚焦业务本身。

CNCF 的定义

目前业界最常引用的是云原生计算基金会（CNCF）的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，工程师能够对系统作出频繁、可预测的重大变更。

来源：CNCF Cloud Native Definition。

注意三点：

  • 云原生强调的是运行方式与架构范式，不是「必须跑在公有云上」。私有云、混合云、甚至自建 Kubernetes 集群都可以实践云原生。
  • 它是一套可组合的技术与实践，而不是单一标准。
  • 目标是：弹性、可观测、可管理、可频繁变更，同时尽量减少人工运维负担（toil）。

它和「上云」有什么区别

这几个概念经常被混在一起：

概念 含义
云计算 / 上云 用云厂商的计算、存储、网络资源，按需付费
Cloud Ready / 云就绪 传统应用稍作改造后能在云上跑（常见是虚拟机迁移）
云原生 应用从架构、交付、运维全链路按云的特性重新设计

区别可以这样理解：

  • 传统单体：一个大包，一起编译、一起发布、一起扩容。扩容往往是加更大的机器（垂直扩展），发布周期长，一次故障可能整站受影响。
  • 仅上云：把这套单体放到云虚拟机里，资源更灵活，但架构没变，弹性、发布、故障隔离能力有限。
  • 云原生：拆成多个可独立部署的小服务，用容器打包，用编排系统调度，用声明式配置描述「期望状态」，平台负责把实际状态调过去。

云原生的核心不是「用了 Kubernetes」，而是：把应用做成可独立演进的小单元，把基础设施当成可编程、可声明、可自动调和的系统。

核心思想

1. 以应用为中心，把非功能需求下沉到平台

弹性扩缩、滚动发布、健康检查、服务发现、流量调度、证书轮换、日志采集等，传统做法往往写进业务代码或靠运维手工做。云原生希望这些能力由平台提供，业务代码尽量只表达业务。

2. 松耦合、可独立演进

系统拆成多个职责单一的服务，通过 API / 事件通信。某个服务可以单独扩容、单独发布、单独回滚，而不必整站停机。

3. 声明式，而不是命令式

告诉系统「我要 5 个副本、健康检查失败就重启、流量灰度 10%」，而不是一步步下发「先停这台、再启那台」。平台持续对比期望状态与实际状态并自动修复。这就是 Kubernetes 等系统的核心工作方式。

期望写 5 个副本，实际只剩 3 个时由控制器拉起

4. 不可变基础设施

服务器或容器部署后原则上不再登录进去「打补丁、改配置」。要变就换新镜像、新版本。这样环境可复现，避免「这台机器只有我知道怎么配」。

5. 自动化与持续交付

构建、测试、发布、回滚尽量流水线化。变更应该是频繁、小步、可预测的，而不是季度大版本。

代表技术（CNCF 点名的几块）

这些是「云原生长什么样」的技术画像，不是必须全部用齐：

  1. 容器
    把应用和依赖打成一致的运行单元（Docker / containerd 等）。解决「在我机器上能跑、到生产就不行」。

  2. 容器编排
    以 Kubernetes 为代表，负责调度、扩缩、自愈、滚动更新、服务发现。业界常把它比作「云原生操作系统」。

  3. 微服务
    按业务能力拆分，独立部署、独立扩容。微服务是手段，不是目的；拆得过细会带来分布式复杂度和运维成本。

  4. 服务网格（Service Mesh）
    如 Istio、Linkerd。把超时、重试、熔断、mTLS、流量镜像等从业务代码抽到边车代理里，统一治理服务间通信。

  5. 不可变基础设施 + 声明式 API
    配置即代码（YAML / JSON / CRD），系统自动调和。GitOps（Argo CD、Flux）是这一思想在交付侧的常见实践。

周边还会自然延伸到：

  • CI/CD：Jenkins、GitLab CI、Tekton、Argo
  • 可观测性：Prometheus、Grafana、OpenTelemetry、ELK / Loki
  • Serverless / 函数计算：进一步把「服务器」抽象掉
  • 策略与安全：OPA、Falco、网络策略、零信任

CNCF Landscape 把这个生态画成一张全景图，说明云原生已经是一整套分层体系，而不只是 Docker + K8s。

云原生应用通常长什么样

典型特征：

  • 由多个微服务组成，而不是一个巨大单体
  • 每个服务打包成容器镜像
  • 由编排系统管理生命周期
  • 通过 API、消息或事件协作
  • 可水平扩展（加实例，而不是只加更大的机器）
  • 具备健康检查、就绪探针、优雅关闭
  • 日志、指标、链路追踪可观测
  • 发布支持滚动、蓝绿、金丝雀
  • 尽量无状态；状态放到托管数据库、缓存、对象存储

为什么要做云原生

常见收益：

  • 更快交付：小步发布，功能可以按天甚至按小时上线
  • 更好弹性：流量上来自动加副本，下去自动缩，提高资源利用率
  • 更高韧性：单点故障被隔离，平台可自动重启、迁移
  • 环境一致：镜像从开发到生产同一份制品
  • 可移植性：相对减少对某一家云厂商虚拟机形态的绑定（完全避免锁定很难，但工作负载迁移成本通常更低）
  • 团队协作方式变化：开发与运维通过平台和流水线协作（DevOps），而不是甩锅式交接

也要看到代价和边界：

  • 分布式系统本身更难：一致性、延迟、部分失败、数据拆分
  • 平台复杂度高：Kubernetes、网格、可观测性栈都有学习曲线
  • 小团队、简单业务上全套云原生，可能是过度设计
  • 微服务拆分错误会变成「分布式单体」：部署还是要一起发，复杂度却上去了
  • 安全面变大：容器逃逸、镜像供应链、服务间权限、密钥管理都要重新设计

所以云原生是能力，不是教条。很多团队走的是渐进路线：先容器化，再上编排，再拆关键服务，最后才上网格和全套 GitOps。

发展脉络

  • 2013 年前后，Pivotal 的 Matt Stine 等人开始系统讨论 Cloud Native，早期常和 12-Factor App、微服务、持续交付放在一起。
  • 2013–2014：Docker 让容器普及，应用打包方式改变。
  • 2014–2015：Google 开源 Kubernetes，并在 2015 年与 Linux 基金会成立 CNCF，K8s 成为首个核心项目。
  • 2018 年左右，CNCF 把定义从「容器 + 微服务 + 编排」扩展为包含服务网格、不可变基础设施、声明式 API。
  • 之后生态迅速膨胀：可观测性、GitOps、策略引擎、Serverless、多集群、边缘，再到和 AI 基础设施结合。

定义一直在演化，这也是「云原生到底是什么」经常说不清的原因——它既是技术栈，也是工程文化，还是一套持续更新的最佳实践。

怎么判断一个系统算不算云原生

没有一张合格证，但可以用这些问题自检：

  • 应用能否以容器镜像作为唯一交付物？
  • 扩容是加实例，还是只能换更大机器？
  • 发布能否滚动/灰度，且多数情况不必停机？
  • 节点挂了，工作负载会不会被自动调度走？
  • 配置是声明在版本库里，还是靠人登录机器改？
  • 出了问题，能否从指标、日志、链路较快定位？
  • 单个服务能否独立发布，而不绑死整站？

满足得越多，越接近云原生；只买了云主机，通常还只是「在云上跑传统应用」。

小结

云原生可以分三层理解：

  1. 理念：为动态、分布式、弹性的云环境设计软件，把平台能力用起来，而不是把旧架构原样搬上去。
  2. 架构：微服务（或至少模块化）、API 协作、无状态优先、可观测、可独立发布。
  3. 工程体系：容器、编排、声明式 API、自动化流水线、服务治理与不可变交付。

它解决的是软件在规模变大、变化变快之后，如何仍然可扩展、可维护、可频繁变更的问题。对大流量、多团队、需要持续迭代的业务，价值通常很明显；对小型、变化慢、团队很少的系统，应按需采用，避免为了「云原生」而云原生。