什么是云原生¶

云原生不是“把程序放到云服务器”，也不是 Kubernetes 的另一个名字。它是一套面向分布式系统的架构与交付方式：应用被拆成可独立交付的服务，以容器作为标准运行单元，通过声明式配置、自动化控制、可观测性和弹性机制，让系统能够频繁变更并在故障中恢复。

云原生既能运行在公有云，也能运行在私有云、物理机或虚拟化平台上。关键不在服务器属于谁，而在应用是否采用可自动调度、自动恢复、可扩缩、可版本化交付的运行方式。

它要解决什么问题¶

传统单机部署通常依赖人工选择服务器、复制安装包、修改配置、启动进程和配置负载均衡。当应用和服务器数量增加后，会出现：

环境差异导致“测试正常、生产失败”。
人工发布步骤多，容易漏操作且难以回滚。
服务器故障后需要人工迁移应用。
多个应用争抢 CPU、内存和端口，缺少统一资源边界。
实例地址不断变化，服务之间难以稳定发现。
配置、密钥、发布版本和实际运行状态无法统一追踪。

云原生通过标准化和控制循环解决这些问题：

应用代码
  → CI 测试与构建
  → 不可变容器镜像
  → 声明期望副本、资源、网络、配置和存储
  → 平台持续把实际状态调整到期望状态
  → 日志、指标、事件和 Trace 验证运行结果

核心思想¶

思想	含义	实际效果
容器化	应用与运行依赖打包成镜像	减少环境差异，制品可追溯
声明式配置	描述最终要什么，而不是手工写每一步	配置可评审，平台自动收敛状态
不可变交付	发布新镜像替换旧实例，不登录机器改程序	版本清晰，便于回滚
自动调度与自愈	平台选择节点，实例失败后重新创建	降低单机故障影响
弹性	根据负载或计划调整副本和资源	应对流量变化
可观测性	统一日志、指标、事件和调用链	能发现并定位分布式故障
GitOps	Git 保存部署期望状态，控制器持续同步	发布可审计，减少手工漂移

云原生不等于“自动不会出故障”。错误的健康检查会造成重启风暴，错误的资源限制会触发 OOM，错误的自动同步可能快速扩散配置问题。自动化越强，越需要测试、权限、灰度、监控和回滚。

Kubernetes、Helm 和 Argo CD 的关系¶

Docker：制作并运行单个容器
   ↓
Kubernetes：在集群中调度和管理大量容器化工作负载
   ↓
Helm：把一组 Kubernetes YAML 模板化、参数化和版本化
   ↓
Argo CD：以 Git 为准，持续对比并同步 Kubernetes 实际状态

工具	解决的核心问题	不负责什么
Kubernetes	调度、运行、自愈、网络入口、配置和存储编排	不构建源代码和镜像，也不规定 CI/CD 产品
Helm	Kubernetes 应用资源的打包、参数化、升级和回滚	不负责持续监听 Git，也不运行容器
Argo CD	GitOps 持续交付、状态对比、同步与漂移修复	不负责编译代码或构建镜像

一次完整发布¶

开发提交代码
  → GitLab Runner 测试并构建 image:commit-sha
  → 修改部署仓库中的 Helm Values 镜像版本
  → Merge Request 审核
  → Argo CD 发现 Git 变化并同步
  → Kubernetes 滚动创建新 Pod
  → Readiness 通过后 Service 才转发流量
  → 日志、指标和业务检查确认发布结果

学习顺序¶

应用入口与 AI 服务治理见 Higress：AI 网关与高可用，串起负载均衡、网关副本、配置下发和模型服务。

Kubernetes：先理解集群组件、声明式对象和工作负载运行链路。
Helm：再将多份 Kubernetes Manifest 打包成可复用 Chart。
Argo CD：最后把发布期望状态放进 Git，由控制器持续同步。

官方参考：Kubernetes Overview。