1. 视角切换：为什么应用架构师会爱上 Kurator？

如果你是平台/SRE，看 Kurator 的关键词是：Fleet、生命周期、统一监控、统一策略。
但如果你是应用架构师 / 研发效能负责人，你关心的其实是另一组问题：

• 我的应用怎么跨云跨集群“同构交付”？
• 多活 / 主备 / 就近部署的架构如何落地成自动化流水线？
• 服务拆分后，流量灰度、回滚、容量评估能不能变成“工程默认值”？
• 同一个业务域（比如“用户域”）能不能像一个产品一样一次定义、处处生效？

Kurator 官方定位是“开源分布式云原生平台”，其核心机制是：

• 以 Fleet（舰队） 为多集群的统一抽象边界
• 基于声明式 API + GitOps，把应用分发、流量治理、观测、策略等能力按 Fleet 维度一体化落地
• 站在 Kubernetes、Istio、Prometheus、FluxCD、Karmada、KubeEdge、Volcano、Kyverno 等成熟开源能力之上统一编排

从交付体系角度讲，Kurator 最“杀手级”的价值就是一句话：

把“分布式云原生架构”的复杂度，从业务研发手里拿走，塞进平台工程范式里。

下面我用一个应用架构演进 + 交付工程化的主线，重新拆一遍 Kurator 的实战落地。

如下是Kurator的相关架构流程图，可参考：

2. 分布式应用架构的三连问：你是不是也被这些问题折磨过？

在多云多集群环境里，架构师常常面对“三连问”：

1. 应用放哪？

   • 哪些服务必须就近？
   • 哪些可以跨地域调度？
   • 哪些需要边缘副本？

2. 一致性怎么保证？

   • 同一服务在不同集群的版本、配置、探针、资源限制要一致
   • 否则“跨区行为不同”的 bug 会把人折磨疯

3. 交付怎么工业化？

   • 不能每上一个新集群，就复制粘贴一套 YAML + Pipeline
   • 不能每做一次灰度，就临时手写一堆 Istio 规则
   • 不能每出一次事故，就靠人肉逐集群回滚

传统多集群方案最大的问题是：

它解决了“能跑”，没解决“工程化交付”。

Kurator 的 Fleet + GitOps + 一栈式治理，恰好把“工程化交付”变成平台默认能力。

---

3. Kurator 的“交付语言”：Fleet 是应用架构落地的最小工程单元

从应用架构师角度，你可以把 Fleet 理解成：

• 一个 跨云跨地域的“部署域（Deployment Domain）”
• Fleet 里是一组具有共同交付、治理、SLO 的集群
• Fleet 是你写交付规范、灰度规范、策略规范的最小作用域

Kurator 提供 Fleet Manager 进行舰队级管理与统一治理。

3.1 Fleet 的推荐分层法（工程化常用）

你可以按“业务 + 环境 + 风险”拆 Fleet：

• fleet-canary：灰度&实验集群（风险最低）
• fleet-core-prod：核心在线生产
• fleet-edge-prod：边缘/门店/IoT（延迟敏感）
• fleet-batch：离线/AI/批处理（成本敏感）

这相当于把应用架构里的“部署拓扑”提前写成工程边界。

大体流程可参考如下：

4. 入门体验：用 Kurator 搭一个“跨云交付实验室”

为了让交付实战可跑，我们先搭一个最小实验室：

• 管理集群（host）
• 成员集群 A：云上 prod-cloud
• 成员集群 B：IDC prod-idc
• 成员集群 C：边缘 edge

Kurator 通过 Fleet 把它们统一进 global-fleet。

4.1 创建 Fleet（最小示例）

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: global-fleet
  namespace: kurator-system
spec:
  clusters:
    - name: prod-cloud
    - name: prod-idc
    - name: edge-gateway

4.2 交付实验室的“评价指标”

作为架构/交付负责人，你应该给实验室定可度量目标：

• 多集群发布一致性（版本/配置/副本）
• 灰度与回滚耗时
• overlay 差异控制在可解释范围
• 服务性能在不同部署域可对比

这些指标会贯穿后面的实战。

---

5. 功能实战 A：统一应用分发 = “架构同构交付”的基础设施

Kurator 的多集群应用分发走 Fleet + GitOps（FluxCD）路线。

5.1 交付仓库的“架构友好结构”

假设我们有一个典型微服务系统：

• user（用户域）
• order（订单域）
• pay（支付域）
• edge-cache（边缘加速）

推荐仓库结构：

gitops-arch/
  base/                       # 架构同构基线
    user/
    order/
    pay/
    edge-cache/
  overlays/                   # 部署域差异
    prod-cloud/
    prod-idc/
    edge/
  domains/                    # 业务域“产品化交付”
    domain-user.yaml
    domain-trade.yaml
  fleets/
    user-fleetapp.yaml
    trade-fleetapp.yaml

解释：

• base/ 里写“架构期望态”
• overlays/ 里只写“部署域差异”
• domains/ 把一组微服务作为“业务域交付单元”
• fleets/ 把域按 Fleet 扩散

5.2 FleetApplication（一次定义，多集群同构落地）

apiVersion: fleet.kurator.dev/v1alpha1
kind: FleetApplication
metadata:
  name: domain-user
  namespace: kurator-system
spec:
  fleetRef:
    name: global-fleet
  gitRepositoryRef:
    name: gitops-arch
  targets:
    - cluster: prod-cloud
      path: ./overlays/prod-cloud/user
    - cluster: prod-idc
      path: ./overlays/prod-idc/user
    - cluster: edge-gateway
      path: ./overlays/edge/user
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

5.3 作用分析（架构视角）

• 发布域差异被显式隔离（overlay）
• base 是唯一真相，避免“集群漂移”
• 业务域交付从“多 pipeline”变成“一个 fleetapp”
• 应用架构的逻辑被工程化固化

而且，也可以参考如下示意图：

6. 功能实战 B：统一流量治理 = “多活架构工程化”的关键一环

Kurator 集成 Istio 提供流量治理能力，并能按 Fleet 做统一落地。

6.1 架构场景：支付服务跨地域双活

你的架构目标是：

• 本地请求优先本地集群
• 本地故障自动跨云切换
• 灰度发布先在云上做，确认后再扩散到 IDC/边缘

6.2 Istio 策略（版本化 + Fleet 扩散）

DestinationRule：定义多版本 + 多地域子集

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: pay-svc
  namespace: trade
spec:
  host: pay-svc
  subsets:
  - name: v1-cloud
    labels:
      version: v1
      zone: cloud
  - name: v1-idc
    labels:
      version: v1
      zone: idc
  - name: v2-cloud
    labels:
      version: v2
      zone: cloud

VirtualService：灰度 + 故障逃逸

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: pay-svc
  namespace: trade
spec:
  hosts:
  - pay-svc.trade.svc.cluster.local
  http:
  - match:
    - headers:
        x-zone:
          exact: "cloud"
    route:
    - destination:
        host: pay-svc
        subset: v2-cloud
      weight: 10
    - destination:
        host: pay-svc
        subset: v1-cloud
      weight: 90
  - match:
    - headers:
        x-zone:
          exact: "idc"
    route:
    - destination:
        host: pay-svc
        subset: v1-idc
      weight: 100
    retries:
      attempts: 3
      perTryTimeout: 2s

这套规则放到 GitOps 仓库里，Kurator 通过 Fleet 扩散到指定集群，就能把“多活/灰度/故障切换”变成工程默认能力。

6.3 作用分析（工程视角）

• 灰度策略不再“集群手写”
• 路由规则可审计、可回滚
• 多活切换由网格策略自动化兜住
• 你的应用架构第一次有了可复制、可演进的落地载体

如下是Kurator产品的官方架构图，很清晰可以看到Kurator的设计组成等：

7. 功能实战 C：统一监控 = “架构验证”的事实来源

Kurator 的统一监控基于 Prometheus + Thanos + Grafana 的多集群聚合能力，按 Fleet 统一部署。

7.1 为什么架构师关心统一监控？

因为跨云架构最怕两件事：

1. 你以为“云上更快”，但没证据
2. 你以为“边缘稳定”，但没对比

Kurator 让你可以在一个大盘里对比：

• prod-cloud vs prod-idc 的 P95 延迟
• 失败率在不同部署域的趋势
• 灰度前后 Fleet 级的全局指标变化

7.2 FleetMonitoring（示意）

apiVersion: observability.kurator.dev/v1alpha1
kind: FleetMonitoring
metadata:
  name: global-observe
  namespace: kurator-system
spec:
  fleetRef:
    name: global-fleet
  prometheus:
    retention: 15d
    scrapeInterval: 30s
  thanos:
    enable: true
    objectStorageConfig:
      secretName: thanos-objstore
  grafana:
    enable: true

7.3 作用分析

• 统一口径 = 架构对比有意义
• 指标聚合 = 架构验证更快
• Fleet 新增集群自动纳入观测
• 跨云架构优化有了数据闭环

---

8. 功能实战 D：统一策略管理 = “架构守门员”

Kurator 基于 Kyverno 做 Fleet 级策略治理。

架构师关心的是：

我设计的“安全与资源边界”，能否不走样地跨集群落地？

8.1 示例：强制所有域服务必须有资源限制 + 探针

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-limits-and-probes
spec:
  validationFailureAction: enforce
  rules:
  - name: check-limits
    match:
      any:
      - resources:
          kinds: ["Deployment"]
    validate:
      message: "Workloads must define resources & probes."
      pattern:
        spec:
          template:
            spec:
              containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"
                  requests:
                    cpu: "?*"
                    memory: "?*"
                livenessProbe: "?*"
                readinessProbe: "?*"

用 FleetPolicy 扩散到 global-fleet：

apiVersion: policy.kurator.dev/v1alpha1
kind: FleetPolicy
metadata:
  name: arch-baseline
  namespace: kurator-system
spec:
  fleetRef:
    name: global-fleet
  policies:
  - name: require-limits-and-probes
    source:
      gitRepositoryRef:
        name: gitops-arch
        path: ./policies/require-limits-and-probes.yaml

8.2 作用分析

• 资源边界一致 -> 性能对比更可信
• 探针一致 -> 灰度/回滚风险降低
• 新集群自动接入架构基线
• 架构规范不再靠人肉评审兜底

如下是它开源的截图展示：

而且，如下是它的一些开源数据。

9. 案例实战：把“分布式微服务架构”做成 Kurator 工程范式

下面用一个完整的落地故事把能力串起来。

9.1 企业背景（虚构但真实感很强）

企业：霓虹出行（Neon Mobility）

• 一家跨城出行 + 实时调度平台

• 架构核心是高可用、低延迟

• 部署在：

  • 公有云多地域集群（低延迟入口）
  • IDC 集群（核心数据与调度）
  • 城市边缘集群（就近派单）

9.2 技术选型

平台底座：Kurator

• Fleet Manager 统一多集群治理
• FluxCD/GitOps 统一交付
• Istio 统一流量、多活、灰度
• Prometheus/Thanos/Grafana 统一观测
• Kyverno 统一策略治理

9.3 工程化落地步骤

Step 1：按应用架构拆 Fleet

• fleet-city-edge：各城市边缘集群
• fleet-cloud-entry：云上入口集群
• fleet-idc-core：IDC 核心调度/数据库
• fleet-canary：灰度池（1 城市 + 1 云区）

Step 2：基线同构（base）+ 域差异（overlay）

• dispatch-service（调度）
• order-service（订单）
• geo-service（定位）

base 里统一：

• HPA、PDB、探针、资源限制
• 日志与指标 sidecar
• 关键 label（region/city/zone/version）

overlay 里仅差异：

• 副本数
• 节点亲和（边缘 vs 云）
• 城市参数

Step 3：GitOps + FleetApplication 域级发布

业务域发布对象：

• domain-dispatch
• domain-order

FleetApplication 一次扩散三个部署域。

Step 4：Istio 支持“云入口 -> 边缘就近派单”的流量架构

• 云入口按城市 header 路由到对应边缘 Fleet
• 云入口不可用则转 IDC
• 灰度时只在 fleet-canary 的 subset 放量

Step 5：统一观测做架构验证

在 Grafana 上按 Fleet 对比：

• 城市边缘 vs 云入口延迟
• 灰度前后全局错误率
• 某城市异常可快速定位

Step 6：策略基线做守门

• 资源/探针强制
• 禁止特权容器
• 镜像源限制
• 命名空间配额

新城市上车即自动合规。

9.4 业务收益（合理虚构）

落地后 4 个月：

• 城市新增上线周期从 2 周缩到 2 天
• 跨域服务版本一致率 99.5%
• 调度链路 P95 延迟下降 18%
• 事故回滚从逐集群 40 分钟缩到 5 分钟
• 平台团队能把精力从“对齐环境”转向“优化架构”

所以说，如果你感兴趣，可以参考官方文档部署：

10. 前瞻创想：Kurator 让“架构即代码（Architecture as Code）”成为可能

Kurator 的最大想象力在于：
它把分布式云原生技术栈统一进一个“声明式工程语法”里。

我认为下一步可以走向“架构即代码”：

1. Fleet 成为架构层 DSL 的运行时

   • 你声明“业务域 -> 部署域 -> 流量域 -> 策略域”
   • Kurator 负责落地为对应 CRD

2. 跨域 SLO 自动编排

   • 让 SLO 约束（延迟/可用性/成本）成为 Fleet 的属性
   • 调度、灰度、回收自动遵循 SLO

3. 边缘与批任务深度协同

   • KubeEdge + Volcano 的组合已经在 Kurator 里有座位
   • 未来可形成“在线就近 + 离线集中”的全局架构调度范式

11. 结语：Kurator 的“交付侧意义”比你想象更大

从应用架构与交付体系角度看，Kurator 的意义不是“再多一个平台”，而是：

• 把部署拓扑抽象成 Fleet
• 把架构基线固化成 GitOps base
• 把多活/灰度写成可回滚的流量代码
• 把观测与策略变成工程默认值

最终让分布式云原生交付变成一种可复用的工程范式，而不是靠人肉堆出来的“临时工程”。