【探索实战】从“工具堆叠”到“平台治理”：基于 Kurator 构建统一分布式云原生管理底座的实践与思考

一、背景：当云原生进入"分布式时代"，平台复杂度成为第一挑战

随着企业 IT 架构从"单集群 Kubernetes"逐步演进到 多集群、多云、边缘计算 的形态，云原生面临的问题已经不再是"能不能用 Kubernetes"，而是：

• 多个 Kubernetes 集群如何统一管理生命周期
• 应用如何一次声明、多集群一致交付
• 服务网格、监控、策略、发布流程如何避免重复建设与配置漂移
• 运维、平台团队如何从"救火式操作"转向平台化治理

在实践中，很多团队会自然地走向"工具堆叠"模式：

Karmada 负责多集群、Istio 负责流量治理、Prometheus 负责监控、Kyverno 负责策略、FluxCD 负责 GitOps......
但问题在于：这些组件彼此独立，缺乏统一的治理抽象。

Kurator 的出现，正是为了解决这一层"平台治理缺失"的问题。

Kurator 官方定位为：

一个整合主流云原生技术栈的一站式分布式云原生开源解决方案，帮助用户在多集群、多云、边缘场景下实现统一治理。

如下是Kurator项目开源首页：

二、Kurator 的核心思想：不是"再造平台"，而是"平台级封装"

2.1 Kurator 没有重新实现 Kubernetes 生态能力

从 Kurator GitHub README 与官方文档可以清晰看到，Kurator 并不替代 现有云原生项目，而是：

• 以 Kubernetes 为基础运行环境
• 以 Karmada 作为多集群编排与控制平面
• 以 FluxCD 实现 GitOps 驱动的应用分发
• 以 Istio 实现多集群流量治理
• 以 Prometheus / Thanos 实现统一监控
• 以 Kyverno 实现统一策略管理
• 以 Flagger 实现渐进式发布（Rollout）

Kurator 的价值，在于 统一抽象与统一入口。

2.2 Fleet（舰队）：Kurator 的关键平台抽象 ⭐

Kurator 引入了一个非常重要的概念 ------ Fleet（舰队）。

在 Kurator 中，Fleet 并不是简单的"集群列表"，而是一个：

• 可被统一纳管的 集群集合
• 承载统一插件能力（监控、策略、网络、发布等）
• 面向平台治理的 最小运维单元

官方文档明确指出，Fleet 支持的能力包括：

• 多集群应用分发
• 统一监控与可观测性
• 统一策略管理
• 统一网络通信
• 统一发布与回滚

这意味着：

平台团队不再"面向单集群运维"，而是"面向 Fleet 治理"。

1、我们先打开开源项目地址：https://gitcode.com/kurator-dev/kurator

2、点击clone，通过Git插件，将项目进行clone下载

3、执行克隆命令

git clone https://gitcode.com/kurator-dev/kurator.git

4、本地项目查看：

三、实战环境设计：以"平台视角"构建 Kurator 多集群环境

在本次探索实战中，我选择官方推荐的 本地多集群实验方式，使用 Kurator 提供的脚本快速构建管理集群与成员集群。

3.1 使用官方脚本创建多集群环境

git clone https://github.com/kurator-dev/kurator.git
cd kurator
hack/local-dev-setup.sh

该脚本会基于 Kind 创建：

• 一个管理集群（Host）
• 多个成员集群（Member）

并生成对应 kubeconfig 文件，供后续 Kurator 纳管使用。

当然，如果你对步骤部署有疑问，可以参考官方资料：官方开源文档

3.2 安装 Kurator CLI（平台控制入口）

make kurator
sudo mv ./out/linux-amd64/kurator /usr/local/bin/
kurator version

Kurator CLI 是后续安装 Karmada、Istio 等平台能力的统一入口，这一点在后续实践中会非常明显。

四、统一集群治理：Cluster Operator 与 AttachedCluster

4.1 Cluster Operator：集群生命周期治理基础

Kurator 使用 Cluster Operator 管理集群相关对象，其依赖 cert-manager 提供证书能力。

helm install cert-manager jetstack/cert-manager \
  -n cert-manager --create-namespace \
  --set crds.enabled=true

随后安装 Cluster Operator：

helm install kurator-cluster-operator cluster-operator-0.6.0.tgz \
  -n kurator-system --create-namespace

4.2 AttachedCluster：纳管已有集群的统一方式

Kurator 支持将 非 Kurator 创建的集群 通过 AttachedCluster 纳管，这对于真实企业场景非常关键。

apiVersion: cluster.kurator.dev/v1alpha1
kind: AttachedCluster
metadata:
  name: kurator-member1
spec:
  kubeconfig:
    name: kurator-member1
    key: kurator-member1.config

通过这种方式，Kurator 可以统一治理"历史遗留集群"与"新建集群"。

官方架构设计展示：

五、统一应用分发：Fleet + GitOps 的平台化交付实践

Kurator 的应用分发能力构建在 Fleet + FluxCD 之上。

5.1 Application：声明式的跨集群应用模型

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: demo-app
spec:
  source:
    gitRepository:
      url: https://github.com/stefanprodan/podinfo
      ref:
        branch: master
  syncPolicies:
    - destination:
        fleet: quickstart
      kustomization:
        path: ./deploy/webapp

这一模型带来的变化是：

✅ 应用不再"部署到某个集群"

✅ 而是"交付给一个 Fleet"

Kurator 控制面会确保 Fleet 中所有集群的应用状态一致。

如下是官方的文档说明：

六、统一监控：多集群可观测性的"平台级视图"

Kurator 官方文档中，统一监控基于 Prometheus + Thanos，并通过 Fleet 插件统一启用。

kubectl apply -f examples/fleet/metric/metric-plugin.yaml

该能力的关键价值在于：

• 指标不再"分散在各个集群"
• 而是形成 跨集群聚合视图
• 为后续发布策略、容量规划提供数据基础

最后，我们再结合如下这张，技术架构图起来理解：

七、统一策略管理：用 Kyverno 把治理"写进平台"

Kurator 支持在 Fleet 维度启用 Kyverno，实现多集群策略一致性。

kubectl apply -f examples/fleet/policy/kyverno.yaml

通过 policyreport，平台团队可以清晰地看到：

• 哪些集群
• 哪些资源
• 违反了哪些策略

这使"平台治理"从人工规范 升级为系统能力。

八、统一发布：Istio + Rollout，让发布成为平台能力

Kurator 通过 Flagger 实现统一 Rollout，并与 Istio 流量治理深度集成。

plugin:
  flagger:
    trafficRoutingProvider: istio

发布策略（如 Canary）直接成为 Application 的一部分，实现：

• 应用
• 流量
• 指标
• 回滚

全链路声明式管理。

而且，如下架构流程，我们也可以学到一些精髓。

九、总结：Kurator 带来的不仅是"效率"，而是"平台演进路径" 🌟

通过本次探索实战可以看到，Kurator 的价值并不局限于"减少安装成本"，而在于：

• 把 分散的云原生能力整合为平台级能力
• 把 多集群运维提升为 Fleet 治理
• 把 交付、监控、策略、发布纳入统一控制面

对于正在向多云、多集群、边缘场景演进的团队来说，Kurator 提供了一条 清晰、可落地、可持续演进的分布式云原生平台建设路径。

最后，附上相关开源学习地址：

• Kurator分布式云原生开源社区地址：https://gitcode.com/kurator-dev
• Kurator分布式云原生项目部署指南：https://kurator.dev/docs/setup/