1. 为什么用“资源模型（CRD）”视角理解 Kurator？🧠

传统多集群做法往往是“脚本驱动”：一堆 kubeconfig + for 循环 + kubectl apply。短期有效，但当你要做平台化（统一交付、统一观测、统一策略、统一发布、统一备份、统一存储）时，脚本模型会遇到三个致命问题：

• 不可审计：脚本怎么执行、执行到哪、哪些集群成功失败，很难像 K8s 对象一样有统一状态面。
• 不可组合：监控、策略、发布、备份、存储各自是另一堆脚本，互相依赖难表达。
• 不可复用：新集群接入相当于“再走一遍手工流程”，一致性天然脆弱。

Kurator 的官方定位强调“整合主流技术栈，并提供一站式分布式云原生开源解决方案”，核心就是把这些能力收敛为可声明、可治理、可装配的对象模型。
因此，与其从“功能列表”看 Kurator，不如从“它让你新增了哪些对象、对象之间如何组合”来看：这正是平台工程最关心的“可复制系统”。✅

而 Kurator 给了我一个完全不同的感受。

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

2. Kurator 的三类核心对象：AttachedCluster / Fleet / Application 🧩

下面用一句话概括三类对象（后文逐一实操）：

• AttachedCluster：把“一个外部集群 + 访问凭据”变成一个 K8s 对象（可被 Fleet 引用）。官方 examples 在多个场景（应用分发、rollout 等）都体现了这个对象的存在与创建方式。
• Fleet：把“一组集群”变成一个治理域对象；并在这个域上“装配插件能力”（观测/策略/发布/备份/存储）。官方对 Fleet Manager 的定位也强调其负责 Fleet 控制面生命周期与集群注册/注销。
• Application：把“Git 仓库作为事实源 + 同步策略（kustomization）+ 目标域（Fleet）”写成一个对象，从而实现统一应用分发（GitOps 思路）。

当然，如果感兴趣的同学，可以项目下载一波：

然后我们找到Kurator的https地址，通过git将其拉取到本地：

分别执行命令：

# 复制项目地址
https://gitcode.com/kurator-dev/kurator.git

# 克隆到本地
git clone https://gitcode.com/kurator-dev/kurator.git

如下是实际克隆项目演示效果：

如下便是完整的项目源码：

下载完成后，我们便可以进行项目部署及实战演练了。

3. 控制面与前置：把“对象能跑起来”的地基先铺好 🔧

3.1 安装 Kurator CLI（官方最短路径）🧰

官方 Setup 给出了脚本安装方式：

curl -sfL https://kurator.dev/install.sh | sudo bash -s
kurator version

投稿写法建议：在 CSDN 里配一张“CLI 作为统一入口”的小图（文本描述即可），但不要添加非官方命令参数，保持和官方一致即可。✅

3.2 cert-manager：Cluster Operator 相关前置（官方明确依赖 CA injector）🔐

官方安装说明指出 Cluster Operator 依赖 cert-manager CA injector，并给出 cert-manager 的 Helm 安装示例：

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

同时，官方对 Cluster Operator 的描述包括：其基于 Cluster API 与 KubeSpray，并可管理集群插件（CNI/CSI/Ingress）。

注意：本文不扩写“如何创建集群”具体脚本（如 kind/kubespray 命令），因为在我们引用的官方片段里没有统一固定命令，避免引入非官方细节 ✅

3.3 安装 Fleet Manager（官方 Helm charts 路径）🧠

官方 helm-charts README 给出安装方式：

helm repo add kurator https://kurator-dev.github.io/helm-charts
helm install fleet-manager kurator/fleet-manager -n kurator-system --create-namespace

安装后检查 Pod（官方示例/变更稿中的检查方式）：

kubectl get pods -n kurator-system

此外，官方对 Fleet Manager 的定位强调它作为 Operator 运行，负责 Fleet 控制面生命周期管理、集群注册/注销等。

如果有任何疑问，可提Issues

3.4 对象存储：MinIO 用于 Thanos/Velero 验证（官方示例）🪣

官方明确使用 bitnami MinIO Helm Chart，并示例创建 thanos、velero buckets，同时给出 Thanos objstore 以及 Velero credentials 的创建方式。

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

生成 objstore.yaml 并创建 thanos-objstore Secret（官方示例）：

export MINIO_SERVICE_IP=$(kubectl get svc --namespace monitoring minio \
  --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")

cat <<EOF > objstore.yaml
type: S3
config:
  bucket: "thanos"
  endpoint: "${MINIO_SERVICE_IP}:9000"
  access_key: "minio"
  insecure: true
  signature_version2: false
  secret_key: "minio123"
EOF

kubectl create secret generic thanos-objstore --from-file=objstore.yml=./objstore.yaml

Velero credentials Secret（官方示例）：

kubectl create secret generic minio-credentials \
  --from-literal=access-key=minio \
  --from-literal=secret-key=minio123

官方也提醒：MinIO 方法用于验证，生产建议云对象存储服务。

社区开源相关代码如下：

4. AttachedCluster：把 kubeconfig 变成“可治理对象” 🔗

Kurator 的多集群治理离不开“平台如何访问成员集群”。官方在多个插件示例中都采用“把 kubeconfig 做成 Secret，再由 AttachedCluster 引用”的方式。

以 rollout 插件文档中的官方一体化示例为代表：先创建 Secret，再创建 AttachedCluster（两套成员集群）。

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

kubectl apply -f - <<EOF
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
EOF

这段写作技巧：你可以在文章里强调 AttachedCluster 的价值是“把接入动作对象化”，但不要延伸出官方未提及的字段或状态机细节，保持与示例一致 ✅

5. Fleet：把多集群变成一个“治理域”，并用插件装配能力 🧭

5.1 用官方 examples 一键创建 Fleet（quickstart）🌐

在统一应用分发示例里，官方直接通过 examples/application/common/ 创建两个 AttachedCluster 与一个 Fleet（quickstart）。

kubectl apply -f examples/application/common/
# attachedcluster... created
# fleet... created

5.2 Fleet 为什么是“域对象”？看它怎么被引用与被装配 🧩

你会在官方多个能力示例中看到一种稳定模式：

• Application 的 destination 直接写 fleet: quickstart，把交付目标从“具体集群”提升到“域”。
• metric/policy/rollout/backup/storage 等能力则以 Fleet 插件/示例 YAML 形式启用，并通过 kubectl wait fleet ... status.phase=Ready 表达域能力就绪。

官方对 Fleet Manager 的定位也印证了这一点：它负责 Fleet 控制面生命周期与集群注册/注销。

相关资料也很详细：

6. Application：把 GitOps 分发写成一个可审计对象 📦

官方统一应用分发示例明确：由 Fleet 驱动，采用 GitOps 思路并借助 FluxCD 做同步与部署自动化；示例通过 Application CRD 表达 gitRepository source 与 kustomization 同步策略。

6.1 官方示例：gitrepo-kustomization-demo

kubectl apply -f examples/application/gitrepo-kustomization-demo.yaml

官方展示的关键结构如下（保持原字段，不杜撰）：

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
        prune: true
        timeout: 2m0s
    - destination:
        fleet: quickstart
      kustomization:
        targetNamespace: default
        interval: 5m0s
        path: ./kustomize
        prune: true
        timeout: 2m0s

6.2 官方验证方式：分别使用两个 kubeconfig 查看结果

kubectl get po -A --kubeconfig=/root/.kube/kurator-member1.config
kubectl get po -A --kubeconfig=/root/.kube/kurator-member2.config

6.3 官方示例：按集群标签 selector 做差异化分发

kubectl label attachedcluster kurator-member1 env=test
kubectl label attachedcluster kurator-member2 env=dev
kubectl apply -f examples/application/cluster-selector-demo.yaml

6.4 官方明确的边界：单集群模式切换到 Fleet 不会自动清理旧资源

官方说明：如果 Application 不写 destination 会部署在 kurator 所在集群；当你改为 fleet destination 时，旧资源不会自动删除，需要先 delete 该 Application。

kubectl apply -f examples/application/gitrepo-kustomization-demo-without-fleet.yaml
kubectl delete applications.apps.kurator.dev without-fleet-demo

架构设计：

7. 统一监控（metric plugin）：Prometheus + Thanos + Object Storage 📈

官方说明 metric 插件架构基于 Prometheus 与 Thanos，且 Thanos 需要对象存储；并给出启用方式与等待 Ready 的命令。

1）先创建 kubeconfig 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

2）启用插件并等待 Fleet Ready（官方示例）：

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

写作建议：这里你可以强调“metric plugin 依赖对象存储”并引用 MinIO 示例（thanos-objstore），但不要补充任何官方未给出的 dashboard/指标列表，避免越界 ✅

当然，该项目还有官网页：

8. 统一策略（policy plugin）：Kyverno baseline 🛡️

官方说明策略管理插件构建在 Kyverno 上，并给出示例 YAML 与等待 Ready 的方式。

1）创建 kubeconfig 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

2）启用 Kyverno baseline 并等待 Fleet Ready（官方示例）：

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

3）官方给出的验证思路：通过 Application 下发 demo（片段示例）：

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
        prune: true

9. 渐进式发布（rollout plugin）：Flagger + trafficRoutingProvider=istio 🚦

官方说明 Unified Rollout 需要为 Fleet 配置 rollout 插件，且该插件基于 Flagger；示例中 trafficRoutingProvider 使用 istio。

Fleet 插件示例片段（官方）：

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

官方 Nginx 金丝雀 demo 入口：

kubectl apply -f examples/rollout/canaryNginx.yaml

合规写法提醒：官方 demo YAML 很长，全文照贴会导致重复率上升；你可以像本文这样只引用“入口命令 + 关键结构字段”，其余建议读者直接参考官方 examples 文件（不超 25 词引用限制也更安全）。✅

10. 统一备份（backup plugin）：Velero + Object Storage；以及迁移（Migration）概念边界 💾

官方说明 Unified Backup 基于 Velero，依赖对象存储，并提示 MinIO 方法用于验证、生产建议云对象存储服务。
因此写作时建议把“对象存储准备”作为备份插件的前置条件，引用 MinIO 与 credentials Secret 示例即可（已在第 3 节给出）。

此外，官方对 Unified Migration 的描述是：将应用与资源从一个集群迁移到多个其他集群；用户只需定义 migrate 类型资源，配置源集群、目标集群与策略。

注意：此处不写 migrate 的具体字段 YAML，是为了避免引入未在我们引用片段中出现的字段（严格遵守“不杜撰”）。✅

官方网页也提供相关部署步骤：

11. 分布式存储（distributed storage plugin）：Rook 前置约束与 Fleet 配置 🧱

官方说明 Unified Distributed Storage 构建在 Rook 之上，并列出关键前提：Kubernetes v1.22+；Ceph 存储至少需要 raw device/raw partition/LVM LV/block 模式 PV 等，并指出最简单方式是挂载 raw disk。

官方 Fleet 配置示例片段：

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:
    distributedStorage:
      storage:
        dataDirHostPath: /var/lib/rook
        monitor:
          count: 3
          labels:
            role: MonitorNodeLabel

12. 常见边界与官方明确注意事项汇总（便于投稿写“踩坑与解决”）🧯

以下每条都能在官方资料中找到依据或明确提示：

1. cert-manager 前置不可省：官方明确 Cluster Operator 依赖 cert-manager CA injector。
2. 监控链路依赖对象存储：metric plugin 基于 Thanos，官方示例要求 Object Storage，并提供 MinIO/objstore Secret 方式。
3. 单集群模式 → Fleet 模式切换会残留资源：官方明确不会自动删除宿主集群已部署资源，需要 delete 原 Application。
4. 备份插件 MinIO 仅用于验证：官方明确生产建议云对象存储服务。
5. 分布式存储前置条件：官方明确 Kubernetes 版本与 Ceph 介质要求。

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