0. 为什么需要 Kurator？

在分布式云原生时代，团队往往同时面对多云、多集群、边缘节点、以及跨网络环境带来的治理复杂度：

  • 资源编排要统一（否则每个集群一套 YAML/脚本）
  • 调度要统一（否则容量与弹性策略碎片化）
  • 流量治理要统一（否则服务网格/Ingress 配置难以一致）
  • 可观测性要统一（否则指标、日志、追踪散落在各处）
  • 策略要统一（否则安全与合规“口径不一”）

Kurator 的设计思路并不是“再造轮子”，而是站在主流云原生生态之上，把多个成熟项目组合成一个“可一键装配”的分布式云原生平台：Kurator 在官方 GitHub README 中明确提到，它整合并站在 Kubernetes、Istio、Prometheus、FluxCD、KubeEdge、Volcano、Karmada、Kyverno 等主流技术栈之上，并提供多云多集群管理能力与“统一编排/统一调度/统一流量管理/统一遥测”等能力。

同时，Kurator 以 Fleet（舰队） 为核心抽象，强调“以集群组为单位的一致性管理”：包括集群加入/退出、跨集群应用同步、命名空间/ServiceAccount/Service 的一致性、跨集群服务发现与通信、聚合指标、统一策略引擎等。
这种抽象非常关键：它把运维对象从“一个个集群”提升为“一个个舰队”，把平台治理从“点状操作”变成“面状声明式治理”。

如下是Kurator项目开源首页，大家可以先看下项目介绍及说明：

1. Kurator 的核心组件与能力地图：把“平台能力”拆成可落地的模块

从 Kurator 官方文档的 Setup 入口可以看到，Kurator 的安装与使用围绕几个关键模块展开：

  • Kurator CLI（命令行工具）
  • Cluster Operator（集群生命周期相关能力的承载）
  • Fleet Manager（舰队管理与跨集群统一能力的控制面）
  • 以及围绕 Fleet 的能力插件/场景：统一应用分发、统一监控、统一网络、统一策略、统一发布（Rollout）、备份等。

下面我按“从 0 到 1 的平台搭建路径”来写：先把环境搭起来，再用一个真实的 GitOps 应用分发示例跑通，然后逐步打开统一监控、统一策略、统一流量治理（Istio + Rollout）等能力。

2. 从 0 到 1：搭建本地多集群实验环境（Kind + Kurator 脚本）

官方文档在多个页面都给出了“用 Kurator 脚本创建多集群环境”的方式：执行 hack/local-dev-setup.sh 后会创建本地 Kind 集群，并生成多个 kubeconfig（host 与 member）。例如在 Install Cluster Operator 与 Install Karmada 的文档里都使用了这条路径。

2.1 克隆代码并创建本地多集群（官方脚本）

git clone https://github.com/kurator-dev/kurator.git
cd kurator

# 使用 Kurator 提供的脚本创建本地多集群环境
hack/local-dev-setup.sh

脚本跑完后，按文档提示会生成 kubeconfig 文件，例如：kurator-host.config、kurator-member1.config、kurator-member2.config，并可通过命令查看。

官方还提示 Kind 环境可能需要调整 fs.inotify.max_user_watches 与 fs.inotify.max_user_instances。
这类参数属于“系统准备项”，生产/实验环境都建议提前检查，避免后续控制器/同步组件出现 watch 资源不足的问题。

如下是具体相关操作演示截图：

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

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

3、执行克隆命令

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

4、本地项目查看：

3. 安装 Kurator CLI：平台装配的“扳手”

Kurator CLI 的安装官方给了两条路：源码编译安装、release 包安装。

3.1 源码编译安装（更适合二次开发/自定义）

git clone https://github.com/kurator-dev/kurator.git
cd kurator
make kurator
sudo mv ./out/linux-amd64/kurator /usr/local/bin/

3.2 从 release 包安装（更适合快速体验）

文档给了以 v0.6.0 为例的命令：

curl -LO https://github.com/kurator-dev/kurator/releases/download/v0.6.0/kurator-0.6.0-linux-amd64.tar.gz
sudo tar -zxvf kurator-0.6.0-linux-amd64.tar.gz -C /usr/local/bin/

3.3 验证安装

kurator version

4. 集群生命周期能力落地：安装 Cluster Operator（并满足 cert-manager 依赖）

官方说明 Cluster Operator 依赖 cert-manager CA injector，并给出了 Helm 安装命令。

4.1 安装 cert-manager（官方步骤）

helm repo add jetstack https://charts.jetstack.io
helm repo update
kubectl create namespace cert-manager
helm install -n cert-manager cert-manager jetstack/cert-manager \
  --set crds.enabled=true --version v1.15.3

4.2 从源码构建并安装 Cluster Operator（官方步骤）

# 构建镜像与 chart
VERSION=0.6.0 make docker
VERSION=0.6.0 make gen-chart

# 将镜像加载到 kind host 集群
kind load docker-image ghcr.io/kurator-dev/cluster-operator:0.6.0 --name kurator-host
kind load docker-image ghcr.io/kurator-dev/fleet-manager:0.6.0 --name kurator-host

cd out/charts/

# 安装到管理集群（kurator-system 命名空间）
helm install --create-namespace kurator-cluster-operator cluster-operator-0.6.0.tgz -n kurator-system

4.3 验证 Cluster Operator

kubectl get pod -l app.kubernetes.io/name=kurator-cluster-operator -n kurator-system

到这里，“集群管理控制器”已经就位：它是后续 AttachedCluster/Fleet 等对象被持续调谐（reconcile）的基础。

5. 多集群编排底座：用 Kurator 安装 Karmada（官方集成路径）

Kurator 官方文档“Install Karmada with Kurator”明确给出：先编译 kurator，再执行 kurator install karmada 安装控制面，并支持通过 --set 传参覆盖安装参数。

# 编译 kurator（若你已用 release 安装，可跳过这一步，按你的环境选择）
git clone https://github.com/kurator-dev/kurator.git
cd kurator
make kurator

# 安装 Karmada 控制面（示例 kubeconfig 路径来自官方文档）
kurator install karmada --kubeconfig=/root/.kube/config

# 也可通过 --set 方式设置参数
kurator install karmada \
  --set karmada-data=/etc/Karmada-test \
  --set port=32222 \
  --kubeconfig ~/.kube/config

这一步的意义：Karmada 提供 Kubernetes 原生多集群编排能力，Kurator 在其上进一步构建“舰队管理 + 应用分发 + 统一治理”的体验。

6. 安装 Fleet Manager：让“舰队”真正成为平台统一入口

Fleet Manager 的安装官方指出两点依赖：

  1. 依赖 Cluster Operator（因此需要先完成 cluster operator 安装）
  2. 依赖 FluxCD（Kurator 使用 fluxcd 社区 helm chart 安装，并给出关闭部分 controller 的 values）。

6.1 安装 FluxCD（官方命令）

helm repo add fluxcd-community https://fluxcd-community.github.io/helm-charts
cat <<EOF | helm install fluxcd fluxcd-community/flux2 --version 2.7.0 \
  -n fluxcd-system --create-namespace -f -
imageAutomationController:
  create: false
imageReflectionController:
  create: false
notificationController:
  create: false
EOF

kubectl get po -n fluxcd-system

6.2 安装 Fleet Manager（从源码方式的关键步骤）

文档与 cluster operator 安装类似：构建镜像与 chart、加载镜像、helm 安装。
（这里不重复粘贴所有命令，你可按官方页面继续执行 “Install fleet manager into the management cluster” 部分。

7. 纳管现有集群：AttachedCluster —— 把“非 Kurator 创建的集群”装进舰队

官方定义：在 Kurator 中，不由 Kurator 创建的集群称为 AttachedClusters，通过加入 Fleet 扩展 Kurator 的控制范围。

这意味着你可以：

  • 用 Kurator 管“新建集群”（生命周期）
  • 也可以用 Kurator 纳管“已有集群”（AttachedCluster）
    两条路都能汇入 Fleet 统一治理。

7.1 AttachedCluster 的 kubeconfig secret（官方示例）

在多个 Fleet 教程（应用分发、监控、策略、网络、rollout）里，官方都使用同样方式创建访问 member 集群的 secret。比如策略管理页：

kubectl create secret generic kurator-member1 --from-file=kurator-member1.config=/root/.kube/kurator-member1.config
kubectl create secret generic kurator-member2 --from-file=kurator-member2.config=/root/.kube/kurator-member2.config

7.2 创建 AttachedCluster 对象（官方示例）

Rollout 插件安装页给出了完整 YAML（这里直接引用官方片段）。

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

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

8. 一键进入“统一应用分发”：Fleet + GitOps（FluxCD）把应用同步到多集群

官方文档《Unified Application Distribution with Kurator》明确说明：Kurator 通过 Fleet 提供跨多集群统一分发系统，并使用 FluxCD 的 GitOps 方式自动同步与部署，提升准确性与效率。

8.1 创建示例 Fleet 与 AttachedCluster（官方步骤）

应用分发文档示例会先 apply 预置的 attachedClusters 与 fleet。

kubectl apply -f examples/application/common/

8.2 创建 Application：声明式定义“源”与“分发策略”

官方给出 Application CR 的示例：来源是 Git 仓库，并包含两个 kustomization syncPolicies，目标是一个包含两个 attachedClusters 的 fleet。

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: gitrepo-kustomization-demo
  namespace: default
spec:
  source:
    gitRepository:
      interval: 3m0s
      ref:
        branch: master
      timeout: 1m0s
      url: https://github.com/stefanprodan/podinfo
  syncPolicies:
    - destination:
        fleet: quickstart
      kustomization:
        interval: 5m0s
        path: ./deploy/webapp

这一段非常“平台化”：应用交付不再是“对每个集群分别 kubectl apply”，而是把“应用源 + 同步策略 + 目标舰队”一次性声明出来。Fleet Manager 与 FluxCD 在控制面完成持续调谐，让多集群应用状态趋于一致。

而且，开源社区项目操作文档也说明的很详细：

9. 统一可观测性：Fleet 维度启用多集群监控（Prometheus + Thanos）

官方文档《Enable multi cluster Monitoring with fleet》说明：Fleet 的多集群监控构建在 Prometheus 与 Thanos 之上，并提示 Thanos 需要对象存储，示例使用 Minio，并链接到 Minio 安装指南。

9.1 安装 Minio（对象存储，官方 Helm 示例）

cat <<EOF | helm install minio oci://registry-1.docker.io/bitnamicharts/minio \
  -n monitoring --create-namespace -f -
auth:
  rootPassword: minio123
  rootUser: minio
defaultBuckets: thanos,velero
accessKey:
  password: minio
secretKey:
  password: minio123
service:
  type: LoadBalancer
EOF

kubectl get po -n monitoring

（官方还提供了可选：为 Thanos/Velero 创建 secret 的示例，包括 objstore.yaml 的 S3 配置等。

9.2 在 Fleet 上启用 metric plugin（官方示例）

监控文档给出：创建访问集群的 secret 后，直接 apply 示例 YAML 即可启用。

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

官方架构设计展示：

10. 统一策略管理：Fleet + Kyverno，让多集群“同口径”合规

官方文档《Enable Policy Management with fleet》说明：Fleet 的多集群策略管理建立在 Kyverno 之上，并给出“开启 baseline Pod Security 检查”的示例。

10.1 在 Fleet 中启用 Kyverno 策略（官方示例）

kubectl apply -f examples/fleet/policy/kyverno.yaml
kubectl wait fleet quickstart --for='jsonpath='{.status.phase}'=Ready'

10.2 验证：在舰队里创建“违规 Pod”，观察 policyreport

官方用 Application 指向仓库里的 badpod-demo，然后在 member 集群查看 policyreport。

cat <<EOF | kubectl apply -f -
apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: kyverno-policy-demo
  namespace: default
spec:
  source:
    gitRepository:
      interval: 3m0s
      ref:
        branch: main
      timeout: 1m0s
      url: https://github.com/kurator-dev/kurator
  syncPolicies:
    - destination:
        fleet: quickstart
      kustomization:
        interval: 5m0s
        path: ./examples/fleet/policy/badpod-demo
        prune: true
        timeout: 2m0s
EOF

kubectl get policyreport --kubeconfig=/root/.kube/kurator-member1.config

如下是官方的文档说明：

这一段体现了“平台治理”的关键价值：策略不再依赖“口头约定 + 人肉审查”，而是随应用交付链路自动落地，并能在各成员集群形成可查询的合规结果。

11. 统一流量治理与渐进式发布：Istio + Kurator Rollout（Flagger）把“发布”平台化

Kurator 官方文档明确两块内容：

  • Istio 集成：Kurator 提供简单命令安装多集群 Primary-Remote 模型，并把 karmada-apiserver 作为配置下发目的地。
  • Unified Rollout：Kurator 基于 Flagger 实现跨多集群统一 Rollout，并扩展 Kurator Application 配置以承载 Rollout 配置，实现“应用 + 发布策略”一体化声明。

11.1 用 Kurator 一键安装 Istio 多集群（官方命令）

kurator install istio --primary member1 --remote member2

并支持跨网络拓扑：通过给 cluster 打 topology.istio.io/network label 后再执行同样安装命令。

kubectl label cluster member1 topology.istio.io/network=network1 --overwrite --kubeconfig=/etc/karmada/karmada-apiserver.config
kubectl label cluster member2 topology.istio.io/network=network2 --overwrite --kubeconfig=/etc/karmada/karmada-apiserver.config

kurator install istio --primary member1 --remote member2

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

11.2 启用 Rollout 插件：在 Fleet 里安装 Flagger（官方示例）

Rollout 插件安装页给出：在 Fleet spec.plugin.flagger 中配置 publicTestloader 与 trafficRoutingProvider，并说明 provider 当前支持 Istio/Kuma/Nginx。

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1
      kind: AttachedCluster
    - name: kurator-member2
      kind: AttachedCluster
  plugin:
    flagger:
      publicTestloader: true
      trafficRoutingProvider: istio

11.3 Canary（Istio）示例：把“流量分析 + 渐进权重”写进 Application

在《Istio Canary Deployment》文档中，官方给出完整的操作路径：

  • 支持 Kubernetes v1.27.3+，Istio v1.18+
  • Prometheus 用于收集指标，作为是否继续 rollout 的依据
  • 创建 Ingress Gateway
  • 然后 apply examples/rollout/canary.yaml，并在 Application 的 rollout 字段里看到 trafficAnalysis、trafficRouting 等配置。

创建 Gateway（官方示例）：

kubectl apply -f -<<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"
EOF

触发统一 Canary Rollout（官方示例）：

kubectl apply -f examples/rollout/canary.yaml
kubectl get application rollout-demo -oyaml

并且，文档展示的 Application 期望结果中包含（我只摘录关键字段，避免整段过长）：

  • trafficAnalysis：检查失败次数、检查间隔、metrics 阈值（如 success-rate 的 min、duration 的 max）、webhook 压测命令（hey）
  • trafficRouting：canaryStrategy（maxWeight、stepWeight）、gateways、hosts、timeoutSeconds
    这些字段均在官方“期望输出”的 YAML 中出现。

这里的“平台价值”很直观：发布不再是一堆散落在 CI/CD、Service Mesh、脚本里的配置，而是被提升为Kurator Application 的一部分，从而实现“交付与发布策略一体化、可审计、可复用”。

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

12. 小结：用 Kurator 把“分布式云原生平台”从概念变成可操作的工程体系

回到开篇的痛点：多集群/多云/边缘场景的复杂性，本质来自“工具链分裂 + 配置漂移 + 操作不可复用”。Kurator 的解法是：

  • 用 Fleet 把多集群提升为统一治理单元（加入/退出、跨集群一致性等）。
  • 用 GitOps（FluxCD）把应用分发从“手动部署”升级为“持续调谐”。
  • 用 Prometheus + Thanos + 对象存储，把多集群指标聚合成“可观测性平台能力”。
  • 用 Kyverno 把多集群策略变成“声明式一致性”，并形成可查询的 policyreport。
  • 用 Istio + Flagger，把渐进式发布纳入 Application 声明，从而形成平台化的发布治理。

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

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

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

重构昇腾算子开发体系：CATLASS模板元编程深度实践

avatar AtomGit开源社区
cover

智能仓储技术革新潮起 2026武汉智能仓储展引领产业升级

avatar AtomGit开源社区
cover

AI陪练更快落地！AI问答完整闭环……更懂业务的企业AI培训系统

avatar AtomGit开源社区