【探索实战】从 0 到 1 打造分布式云原生应用管理平台：我与 Kurator 的一栈之旅！

一、为什么我最终选了 Kurator？

先说结论：如果你正面临下面这些痛点，Kurator 非常值得一试 👇

• 多云多集群：公有云 K8s、自建 K8s、边缘 K8s 全都要管；
• 跨云跨边业务：一部分业务在中心云，一部分在边缘（门店、工厂、IoT 网关等）；
• 运维割裂严重：每个集群一套 YAML、一套监控、一套策略，升级扩容靠人工脚本拼凑；
• 应用发布风险高：线上变更缺少金丝雀 / A/B / 蓝绿等渐进式发布能力，回滚慢；
• Dev / Ops 脱节：CI/CD 与多集群分发、流量治理彼此割裂，GitOps 很难真正落地。

而 Kurator 本身的定位，就是一个面向分布式云原生的开源平台，通过整合 Karmada、Istio、Prometheus、KubeEdge、Volcano 等主流技术栈，在其之上构建出舰队管理、多集群应用分发、统一流量治理、统一监控和策略管理等能力，为企业提供一站式分布式云原生解决方案。

它做的事情可以简单概括成一句话：

“把一堆好用但分散的云原生组件，变成一套开箱即用、有统一模型、有统一控制面的分布式云原生平台。”

在这篇文章里，我会以一个「从 0 到 1 构建分布式云原生平台」的小项目为主线，系统地拆解我用 Kurator 的完整过程和踩坑体感。

二、Kurator 的整体架构与技术栈解构

2.1 Kurator 是什么？它不是什么？

从官方定位看，Kurator 是一个开源的分布式云原生平台，帮助用户构建自己的分布式云原生基础设施，推动企业数字化、分布式化升级。

它不是一个「替代 Kuber***es」的系统，而是：

• 站在 Kuber***es、Karmada、Istio、Prometheus、KubeEdge、Volcano、Kyverno 等上层；
• 提供一个更高层次的统一控制平面和声明式 API；
• 帮你把「集群生命周期 + 舰队管理 + 应用分发 + 流量治理 + 监控 + 策略」打通。

换句话说：Kuber***es 解决“一个集群里怎么编排”，Kurator 解决“跨云、跨边、跨集群，全局怎么编排”。

2.2 核心技术栈与能力地图

可以把 Kurator 大致拆成几块能力（下面是我自己的“心智模型”，不完全等同于官方模块划分）：

1. 集群管理与集群生命周期（Cluster Operator）

   • 基于 Cluster API 及相关自定义 CRD，负责多种环境中 Kuber***es 集群的创建、扩容、升级、清理等。
   • 支持本地数据中心集群、AWS 自建集群等，提供声明式 API 表达集群期望状态。

2. 舰队管理（Fleet Manager）

   • 引入“舰队（Fleet）”的概念，将多个物理集群抽象为一个逻辑编组，形成统一的多集群视图；
   • 为后续的统一应用分发、统一流量治理和统一监控打下基础。

3. 多集群应用管理与统一应用分发

   • 基于 Karmada 的多集群编排能力，扩展出统一的应用分发控制器；
   • 支持按地域/机房/云厂商/标签进行拓扑分发；
   • 与 CI/CD、GitOps、渐进式发布能力深度打通。

4. 统一流量治理（Service Mesh / Istio 集成）

   • 使用 Istio 提供服务网格能力，统一处理跨集群、跨云的流量调度和治理；
   • 支持金丝雀、A/B 测试、蓝绿发布中对流量的精准控制；

5. 统一监控与可观测性（Prometheus + Thanos 等）

   • 内置集成 Prometheus / Thanos，实现跨集群、跨区域的统一指标采集与查询；
   • 可以结合告警、看板，为应用发布策略提供可观测指标。

6. 策略与安全（Kyverno 等）

   • 集成策略引擎，用统一的策略 CRD 管控多集群资源（镜像白名单、安全基线等）；

7. CI/CD + GitOps + 渐进式发布（Pipeline + Rollout）

   • 在 0.6.0 版本中，引入 CI/CD 流水线管理、预定义任务模板（git-clone、go-test、go-lint、build-and-push-image 等）以及渐进式发布（Canary / A/B / 蓝绿）；
   • 将代码仓库、流水线、统一应用分发和流量治理整合为完整的 GitOps 工作流。

8. 云边协同（KubeEdge / Volcano / AI & Batch）

   • 通过与 KubeEdge 集成，将 Kuber***es 能力扩展到边缘侧；
   • 结合 Volcano，在批处理、大模型训练等场景提供调度加速能力。

在这个基础上，我们可以围绕一个比较真实的场景来展开一次完整的实践。

再则，我们可以借助图来清晰下其大体的技术架构：

三、从 0 到 1：基于 Kurator 搭建试验性分布式云原生环境

3.1 场景设定：一个典型的中型互联网 / SaaS 公司

假设我们有这样一个环境：

• 云上生产集群（prod-cloud）：跑核心业务 Web / API 服务，部署在某公有云；
• 云上预生产集群（pre-cloud）：回归测试 / 灰度环境；
• 本地数据中心集群（on-prem）：承载部分对合规要求更高的服务；
• 边缘集群（edge-x）：部署在门店 / 边缘节点，通过 KubeEdge 管理 IoT 与本地推理应用；
• 统一管理平面（kurator-mgmt）：部署 Kurator 控制平面与舰队管理能力。

目标非常明确：

用 Kurator 把这几个“散装”的集群统一进一套分布式云原生平台里，实现「一套 API 管所有集群、一套流水线发所有应用、一套观测面看所有指标」。

3.2 安装 Kurator CLI 与 Cluster Operator 的大致步骤

根据官方文档，Kurator 当前包括 Cluster Operator 和 Kurator CLI 两大组件：

1. 准备一个基础 Kuber***es 管理集群（kurator-mgmt）

   • Kuber***es 版本建议与 Kurator 官方推荐版本对齐；
   • 网络插件（如 Calico / Cilium）稳定可用；
   • 有可用的存储类（用于存放 Kurator 自身组件的状态数据）。

2. 安装 Kurator CLI（示意流程，非逐字命令）

   • 从官方仓库下载源码或 Release 包；
   • 构建 kurator 可执行文件，将其移动至 PATH 所在目录；
   • 通过 kurator version 验证 CLI 可用。

3. 在管理集群安装 Cluster Operator

   • 按文档说明应用 CRD 与 Operator 部署清单；
   • 确认 cluster-operator、相关 Controller Pod 处于 Running 状态；
   • 准备好访问各目标集群节点的 SSH Key、云凭证等。

实际安装过程里，我遇到的主要问题集中在：

• Go / Docker 构建环境版本不匹配；
• 管理集群 RBAC 权限不足导致 CRD 安装失败；
• 节点之间网络互通性检查疏漏（特别是本地机房与云上的互通）。

这些问题虽然不复杂，但一旦放到分布式环境里排查会变得有点“玄学”，因此我建议——在一切开始之前，把 ***work / DNS / 证书这三件事先搞干净。

3.3 用声明式 API 创建首批集群

Kurator 基于 Cluster API，提供了一套声明式的 API 对集群进行生命周期管理。实践下来最大感受是：

“以前是写 Ansible / Shell 脚本去创建集群；现在是写 CRD 去描述一个‘期望中的集群’，剩下的交给 Cluster Operator。”

例如，可以用类似下述 CR 来描述一个本地数据中心集群（仅示意，非官方完整 YAML）：

apiVersion: cluster.kurator.dev/v1alpha1
kind: Cluster
metadata:
  name: onprem-cluster
  namespace: kurator-system
spec:
  infraType: vm               # 本地虚机
  kuber***esVersion: v1.29.0
  ***work:
    podCIDR: 10.244.0.0/16
    serviceCIDR: 10.96.0.0/12
  machines:
    controlPlane:
      replicas: 3
      sshSecretRef: onprem-ssh
      template:
        # 省略 CPU / 内存 / 镜像等配置
    workers:
      replicas: 5
      sshSecretRef: onprem-ssh
      template:
        # 省略

Kurator 的 Cluster Operator 会基于这些声明，完成：

• 控制平面节点创建、初始化 kubeadm；
• 工作节点加入集群；
• 网络插件部署；
• 集群状态回写到 CR 状态字段中。

相比直接用 Kubespray 执行一堆 Ansible Playbook，Kurator 的方式更贴近 “基础设施即代码” + “云原生声明式管理” 的理念。

为 AWS 自建集群场景，Kurator 也通过 Cluster Operator 简化了 Cluster API 本身较复杂的部署模型，屏蔽了 IAM 配置、资源校验等大量细节。

当然，使用 Kubespray，用户也可以选择执行一个 Ansible 脚本，然后 Ansible 会使用 SSH 协议与各个目标主机进行通信，并基于该脚本实现集群部署、清理、升级等任务，示图如下所示：

3.4 将集群纳入“舰队”，形成统一视图

当本地 / 云上 / 边缘的集群被创建或接入之后，下一步就是把它们纳入 Kurator 的舰队（Fleet）。

可以将一个 Fleet 理解为：

“一组逻辑相关的 Kuber***es 集群，它们共享同一套统一管理策略（应用分发、监控、流量治理等）。”

典型的映射方式例如：

• fleet-global：所有生产相关集群（prod-cloud、on-prem 部分集群）
• fleet-pre：预生产 / 测试集群
• fleet-edge：边缘计算集群（通过 KubeEdge 接入）

这一层抽象的好处是：

• 对运维而言：操作对象从“单个集群”提升为“舰队”，减少重复操作；
• 对应用而言：部署目标可以是“某个舰队 + 拓扑规则”，而不是逐个集群；
• 对策略与监控而言：天然有一个 Fleet 维度可以聚合。

Kurator 在 v0.3.0 开始引入舰队概念，并基于此构建统一编排、流量治理、监控运维等能力。

而且，我们，除了集群的创建和删除，集群节点扩缩容和升级等也是相同的流程。例如，进行升级时，只需要在 KubeadmControlPlane中修改version字段即可。同样地，进行扩缩容时，只需增删 CustomMachine中的节点信息字段。

整个执行流程如下图所示：

四、实战一：集群生命周期治理——从“养集群”变成“写期望状态”

在生产环境里，集群生命周期治理通常包含几类场景：

• 扩容：业务高峰期需要快速扩容 Worker 节点；
• 缩容：活动结束 / 夜间低峰节省成本；
• 升级：Kuber***es 小版本升级、***I / Core 组件升级；
• 高可用：控制平面多副本、VIP 管理等。

4.1 扩缩容：从手工脚本到声明式批量操作

以前扩容我的做法大概是：

1. 手写一套 Terraform / Ansible / Shell；
2. 调云厂商 API 拉新节点；
3. 安装依赖、加入集群；
4. 调整流量策略确认无误。

在 Kurator 里，我只需要修改 Cluster CR 里 Worker 的 replicas 数量：

spec:
  workers:
    replicas: 5  # -> 8

Cluster Operator 会自动：

• 创建或回收底层节点（云上是 VM，本地是物理机 / 虚机）；
• 更新 kubelet 配置；
• 加入 / 退出集群；
• 同步状态，直到期望状态与实际状态一致。

体验差异非常明显：
以前扩容是一次“操作”，现在扩容是一次“状态变更”。

4.2 集群版本升级：减少“升级脚本焦虑症”

升级 Kuber***es 一直是令很多运维同学焦虑的操作，原因主要有：

• 步骤太多，文档与脚本容易脱节；
• 一旦升级失败，恢复成本高。

Kurator 对此也给了一套声明式方案：在 Cluster 对象中声明目标版本，由 Cluster Operator 负责逐节点升级。

典型流程是：

1. 修改 spec.kuber***esVersion 到目标兼容版本；
2. Cluster Operator 触发升级流程，对控制平面、工作节点逐步滚动升级；
3. 升级过程中利用 Prometheus 监控、告警确认服务健康。

实践中有几点经验：

• 严格控制跨大版本升级跨度：比如 1.25 → 1.26，而不是 1.22 → 1.26 一步到位；
• 将应用发布窗口与集群升级窗口错开；
• 在预生产环境先完整演练，用 Kurator 的统一分发将同一应用部署到不同版本的集群上做兼容性验证。

4.3 高可用控制面：用 VIP 提升鲁棒性

Kurator 提供了基于 VIP 的高可用控制面方案，典型实现方式是结合 kube-vip 对多个控制平面节点做负载均衡。

与传统的 keepalived + haproxy 等方案相比，一大优势是：

• 与 Kuber***es 生态耦合更紧密（Operator 持续维护状态）；
• 更符合“所有东西都由声明式对象表达”的理念。

而且，Kurator还为用户提供了一种基于VIP的增强集群控制面高可用的方案，架构设计图如下所示，仅供参考：

五、实战二：统一应用分发 + 渐进式发布的完整链路

接下来是“Kurator·云原生实战派”中我个人最感兴趣的一部分：统一应用分发 + CI/CD + 渐进式发布。

5.1 多集群应用发布的典型需求

以一个“推荐服务”微服务为例，我们的目标是：

• 代码提交 → 触发流水线 → 构建镜像并签名 → 更新应用模板 → 多集群统一分发；
• 在部分流量上进行金丝雀验证 / A/B 测试；
• 符合指标要求后，再将流量逐步扩展到全量。

Kurator 在 0.6.0 中已经把这些能力串成了一个完整闭环：

1. CI/CD 流水线：构建与发布自动化；
2. 统一应用分发：跨集群、跨舰队部署；
3. 渐进式发布：Canary/A/B/蓝绿策略；
4. GitOps 工作流：以代码仓库为中心进行全流程驱动。

5.2 使用 Kurator 流水线：模板化任务降低门槛

Kurator 在流水线里预置了一批常用任务模板，例如：

• git-clone：从代码仓库拉取源码；
• go-test：执行 Go 单元测试；
• go-lint：进行静态检查；
• build-and-push-image：构建镜像并推送仓库。

对初学者来说，这意味你可以不用从 Tekton Task 开始啃起，而是直接复用这些模板；对有经验的用户，则可以通过自定义任务补足个性化流程（安全扫描、License 检查、SCA 等）。

流水线的一个典型片段（示意）：

apiVersion: pipeline.kurator.dev/v1alpha1
kind: Pipeline
metadata:
  name: re***mender-ci
spec:
  tasks:
    - name: clone
      templateRef: git-clone
    - name: unit-test
      templateRef: go-test
      runAfter: [clone]
    - name: lint
      templateRef: go-lint
      runAfter: [clone]
    - name: build-image
      templateRef: build-and-push-image
      runAfter: [unit-test, lint]

通过这套流水线，Kurator 还能在构建镜像时自动添加数字签名和源头证明，提升软件供应链安全。

5.3 金丝雀发布：用指标驱动的渐进式上线

在统一应用分发能力之上，Kurator 引入了 Canary 发布策略。核心思想是：

“先把新版本放给少量流量，借助指标判定健康，再逐步扩大流量入口。”

在 Kurator 中，可以定义一个 Rollout 对象，指定：

• 目标工作负载（Deployment / DaemonSet 等）；
• 健康性指标（请求成功率、平均时延等）；
• 流量递增策略（每次增加 5%/10%，最大 50% 等）。

示意配置要点（伪代码级）：

spec:
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: re***mender
  metrics:
    - name: request-su***ess-rate
      thresholdRange:
        min: 0.99
    - name: request-duration
      thresholdRange:
        max: 0.5s
  canaryStrategy:
    steps:
      - setWeight: 10
      - setWeight: 25
      - setWeight: 50

在实际演练中，我会配套：

• 在 Prometheus / Thanos 中预先定义好相关指标；
• 用 Grafana 看板或告警系统实时关注金丝雀阶段的性能波动。

相比纯手写 Istio VirtualService 配置，Kurator 的 Rollout 对象的优势在于：

• 提供了语义化的发布策略对象，易懂易维护；
• 将“流量决策逻辑”与“指标采集逻辑”打通；
• 更适合被 GitOps 拉入版本管理体系。

而且，我还知道，Kurator Fleet Manager它作为一个Kuber***es Operator运行，负责Fleet控制平面生命周期管理，也负责集群的注册和注销，这点大家不清楚的应当了解，大家请看，如下图所示：

5.4 A/B 测试：按用户特征切流量

A/B 测试与金丝雀最大的区别在于：

• 金丝雀关注“新版本是否可用、安全可上线”；
• A/B 更关心“哪个版本在特定人群上的效果更好”。

在 Kurator 中，A/B 测试同样通过 Rollout 对象进行配置，只是多了分组匹配规则，例如：

• 根据 HTTP Header（User-Agent、X-User-Group 等）；
• 根据 Cookie（如 type=insider）；
• 根据 URI / 端口等。

这样的配置使得我们可以做一些更细粒度的实验：

• 只对“内测用户”放出新版本 UI；
• 只对特定渠道（如 Android 客户端）使用新推荐算法；
• 只对内部员工或 beta 用户启用实验功能。

5.5 蓝绿发布：追求极致稳定时的选择

蓝绿发布是一种更“保守”的策略：

• 蓝环境：当前线上稳定版本；
• 绿环境：新版本完整跑一套；
• 切流量时，要么全部切到绿，要么全部回滚到蓝。

在一些对“中途混流”非常敏感的系统里（如金融核心账务、订单计费），蓝绿会比金丝雀更受青睐。

Kurator 的蓝绿发布同样通过 Rollout 对象配置，关注点包括：

• 测试迭代次数（analysisTimes）；
• 容许失败次数（checkFailedTimes）；
• 测试过程中的全量流量切换及自动回滚逻辑。

其中，针对Kurator CI/CD 的结构图，如下图所示，仅供参考：

六、实战三：统一流量治理——把复杂流量视图“交给网格”

Kurator 在流量治理层面，依托的是 Istio 等服务网格能力：

• 在单集群场景下，主要负责服务间调用的路由、熔断、限流、重试等；
• 在多集群场景下，进一步提供跨集群流量调度、同城容灾 / 多活等能力。

实践中几个很现实的好处：

1. 统一入口管理
   配置少量 Gateway / VirtualService 资源，即可在 Kurator 层设计跨集群流量策略，而不必在每个集群重复配置 Nginx / Ingress。

2. 故障演练与降级策略统一

   • 在多集群布署中，可以通过 Istio 规则设置主备集群切换；
   • 可以全局启用熔断 / 限流策略，减少雪崩风险。

3. 与渐进式发布深度耦合

   • Rollout 策略底层依赖网格能力，实现精细化流量拆分；
   • 无需在多个技术栈之间来回切换概念，学习曲线更平滑。

其中，Kurator 它也大幅简化了流水线配置和管理的难度，如下图所示：

七、实战四：统一监控与策略管理——从“图表拼凑”到“统一可观测性”

7.1 Prometheus + Thanos 打通多集群指标

Kurator 集成了 Prometheus / Thanos 等监控组件，用于构建跨集群的统一指标管理能力：

• 每个集群本地运行 Prometheus，负责采集 Node / Pod / Service 指标；
• Thanos 作为上层聚合查询层，把多集群指标统一在一个视图中；
• 可以基于 Fleet / Cluster / Namespace / Service 维度进行筛选。

这对运维效率的提升是立竿见影的：

• 排查“跨集群”的性能问题时，再也不用登录不同 Grafana / Prometheus；
• 针对某个业务服务，可以看到它在多个集群中的整体表现。

7.2 策略管理：Kyverno 等构建多集群策略中枢

策略管理更多是“长线收益”，但对合规、安全、成本非常关键。

通过在 Kurator 中集成 Kyverno 等策略引擎，我们可以：

• 定义统一的镜像仓库白名单策略（禁止从非可信仓库拉镜像）；
• 强制所有命名空间开启资源配额 / 限制；
• 限制特权容器、HostPath 挂载等高风险行为；
• 统一配置日志采集、Sidecar 注入等。

结合舰队和多集群视图，这套策略可以：

• 对某些“敏感舰队”（如金融、政务）施加更严格策略；
• 对测试/研发舰队施加更宽松策略；
• 将策略变更纳入 GitOps 流程，做到审计可追溯。

而且，在镜像仓库中可以直接查看镜像签名和证明的详细情况，如下图所示。

八、云边一体：Kurator + KubeEdge + Karmada 在边缘场景的玩法

Kurator 与 KubeEdge 的集成，是我特别看好的一个方向：

• KubeEdge 将 Kuber***es 扩展到边缘，解决“边缘节点如何被管起来”的问题；
• Karmada 为多集群提供编排抽象；
• Kurator 在这之上引入舰队管理、应用统一分发和统一监控。

8.1 示例场景：冷链物联网监控系统

设想这样一个场景：

• 每个城市有若干冷链仓库，每个仓库里有一套边缘集群（KubeEdge）；
• 边缘节点负责采集温度 / 湿度 / 开关门状态，并在本地做一定规则判断（超出阈值本地告警）；
• 中心云集群负责统一可视化、算法训练、跨仓库调度。

使用 Kurator 的方式是：

1. 将各地仓库的边缘集群纳入 fleet-edge；

2. 定义边缘应用模板（如 edge-agent），由 Karmada 将其分发到所有 edge 集群；

3. 通过统一监控查看各边缘集群的运行状态和指标；

4. 在需要更新边缘代理版本时：

   • 利用 Kurator 的统一应用分发，只对某部分仓库做金丝雀；
   • 结合本地指标（异常率、本地响应时延）判断；
   • 逐步扩展到所有仓库。

借助 Karmada 与 KubeEdge 协同，企业可以构建真正弹性、可靠的边缘计算设施，为 IoT、工业场景提供支撑。

8.2 与传统边缘管理方案对比

• 传统方案：每个边缘集群单独运维，升级靠人工小批量滚动或自定义脚本；
• Kurator 方案：将边缘集群当作一个独立舰队，通过统一分发、一套策略、一套监控统一管理。

最大的优势是：边缘不再是“被放弃的角落”，而是完整纳入同一套云原生治理框架。

接下来，我将展示一个在 Kurator 中创建一个流水线的示例，仅供参考：

九、实践收益与团队维度的复盘

经过一段时间的试验性落地，我们总结了一些比较具体的收益（这里用的是“量级”而非精确数字，避免和真实业务数据混淆）：

1. 多集群运维人力下降

   • 之前：一个 SRE 全年很大精力在“建集群 / 升级 / 扩缩容”；
   • 现在：绝大部分工作通过修改 CR 和 Pipeline 实现，人力成本显著降低。

2. 发布失败率 / 回滚时间明显优化

   • 引入 Canary / A/B / 蓝绿发布后，线上事故主要集中在“指标未设计好”，而非“部署脚本错误”；
   • 回滚从“刷新文档 + 手工比对配置”变成“调整 Rollout 对象”。

3. 研发与运维协作模式改善

   • 应用层面的“发布行为”越来越多被编码为 Rollout、Pipeline、Application 等声明；
   • Dev 可以在 Git 仓库中直接看到自己的服务在不同环境与舰队上的分发策略；
   • Ops 从“写脚本的人”变成“设计平台模型和策略的人”。

4. 架构复杂度转化为“可观测的复杂度”

   • 多云、多集群、云边一体带来的复杂度不可避免；
   • Kurator 的价值在于让这种复杂度通过统一 API、统一监控、统一策略变得“可见、可控”。

当然，整个引入过程也不是一路平坦的，主要踩坑点包括：

• 安装阶段对 Kuber***es 版本、网络拓扑、证书等前置条件的忽略；
• 一开始把“所有东西都想统一”，导致迁移节奏太快；
• GitOps 工作流和原有发布流水线的融合需要反复打磨。

大家可以参阅以下的操作示例，了解如何使用 Kurator 进行配置金丝雀发布：

十、前瞻创想：从 Kurator 看分布式云原生的下一步

结合这次实践，我对 Kurator 以及分布式云原生未来有几点个人的“前瞻创想”（也算呼应一下征文里的【前瞻创想】方向）：

1. 更开放的多云 Provider 生态

   • 希望在 Kurator 侧有更多云厂商 / 虚拟化平台的 Provider 接入；
   • 将现在针对 AWS / 本地数据中心的实践复制到更多环境。

2. Serverless 与分布式云的融合

   • 未来如果 Kurator 能在应用层对接 Knative 等 Serverless 技术栈，实现“按函数维度”进行多集群编排，将进一步简化业务开发门槛；

3. AI-Native 场景的原生支持

   • 结合 Volcano 在 AI、大模型训练场景的调度能力，Kurator 有机会成为“AI 训练集群 + 在线推理集群”一站式管理平台。

4. 统一安全 / 信任链路的加强

   • 在现有镜像签名、供应链安全能力之上，引入更多端到端的安全度量（SBOM、运行时安全策略、合规审计等）；

5. 更易扩展的插件化框架

   • 对于希望将 Kurator 与内部系统打通的企业来说，一个更加“Operator / 插件友好”的扩展体系很关键；
   • 例如让企业可以很容易地在舰队视图中挂接自己的监控、告警、成本分析、容量规划等模块。

总体来看，我更愿意把 Kurator 理解为：

“分布式云原生时代的基础设施中台”，
它不替代任何单一技术栈，而是串起整套链路，让多云、多集群、云边协同这件事真正落地。

当然，了解如何在 Kurator 配置蓝绿发布的操作示例，大家可以参考下方：

十一、结语：成为“云原生实战派”的几个建议

最后，用几条落地建议来收个尾，也算给准备参与这次「Kurator·云原生实战派」征文的同学一点点参考 😄：

1. 先选一个具体业务场景再上 Kurator
   不要一上来就想“统一全公司所有集群”，从一个实际可落地的小场景开始（如推荐服务、多集群灰度、一个边缘项目）。

2. 把“状态对象”当核心资产来设计
   尽量用 Kurator 提供的 Cluster / Fleet / Application / Rollout / Pipeline 等 CRD 表达你的需求，而不是用脚本硬拼。

3. 建立可观测性优先的习惯
   在开启金丝雀、A/B、蓝绿之前，先把 Prometheus / Thanos / 告警 / Dashboard 设计好，否则策略只是一纸空文。

4. 把 GitOps 做“浅而广”的渗透
   先做到“所有关键配置都有 Git 记录”，再逐步过渡到“完全自动化的 GitOps”。

5. 拥抱社区，多看 Issue / PR / 文档
   Kurator 本身是开源项目，背后有社区和实践经验积累。多关注官方文档和社区文章，更容易少踩坑。

OK，以上部分配图与内容有参考互联网公开内容，若有造成侵权，请联系删除。

-End-