1. 为什么需要“一栈统一”的分布式云原生平台

当业务进入跨云、跨地域、边缘协同阶段，“多集群”往往不是可选项，而是默认形态。难点随之放大：

• 集群治理碎片化：不同集群的生命周期、插件、策略、监控、网络各自为政。
• 应用交付不一致：多套 CI/CD 脚本、多份 values/kustomize、不同集群出现配置漂移。
• 运维观测割裂：指标、告警、仪表盘散落，跨集群排障成本高。
• 安全与合规难落地：策略要么“只管一个集群”，要么“复制粘贴一堆 YAML”且难审计。

Kurator 的定位，是把这些分布式场景的“统一入口”工程化：它作为开源分布式云原生平台，站在多个主流云原生技术栈之上，提供统一资源编排、统一调度、统一流量管理、统一可观测等能力。

我们先来结合官方所给的Kurator产品架构图，进行辅助学习：

2. Kurator 全景：两大核心组件 + 一套 Fleet 插件化能力

从官方仓库与文档描述看，Kurator 的核心能力可以概括为两部分：

2.1 Kurator 依托的主流技术栈（官方列举）

Kurator “站在巨人肩膀上”，集成/借力 Kubernetes、Istio、Prometheus、FluxCD、KubeEdge、Volcano、Karmada、Kyverno 等云原生栈。
这点很关键：Kurator 的“统一”，不是重复造轮子，而是把这些项目在分布式场景中的组合与治理做成 可声明、可安装、可复用 的平台能力。

2.2 Cluster Operator：面向集群生命周期的“集群级 Operator”

官方文档明确：Kurator Cluster Operator 以“集群 Operator”的方式工作，基于 Cluster API 与 KubeSpray，并可管理集群插件（如 CNI、CSI、Ingress）。
其基本思想是：用声明式 API 表达集群期望状态，控制器监听对象变化并驱动底层集群创建与插件安装，从而将集群生命周期管理工程化。

小提示（也是常见踩坑点）：Cluster Operator 依赖 cert-manager 的 CA injector，官方安装指引要求先确保 cert-manager 就绪再安装 Cluster Operator。

2.3 Fleet Manager：以 Fleet 为单位的多集群统一管理入口

Fleet Manager 作为 Kubernetes Operator 运行，负责 Fleet 控制面生命周期管理以及 集群注册/注销等。
在 Fleet 的抽象下，Kurator 才能把应用分发、监控、策略、发布、备份、分布式存储等能力，变成“对一组集群统一生效”的平台级动作。

当然，这个项目是直接开源的，你们可以去拉取：

如果你本地按照了Git，那么拉取起来是非常轻松地，只需要执行如下命令即可：

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

我们执行克隆命令可见：

在你拉取的文件夹中，可看见完整的项目结构：

3. 实战规划：用最小闭环跑通“统一治理”的平台骨架

为了让路径最短、动作可复用，本文按官方文档示例的方式构建一个最小闭环：

• 一个 Kurator 所在的宿主集群（Host Cluster）：部署 Fleet Manager、相关控制组件。
• 两个用于测试的 AttachedCluster：官方示例在应用分发场景中使用两个本地 attachedClusters 进行测试，并通过 kubeconfig 访问它们。

注意：本文不会杜撰具体集群创建命令（例如 kind create cluster 等），因为官方文档在我们引用的页面里并未给出固定命令；但只要你能拿到两个集群的 kubeconfig，就可以按官方示例完成后续步骤。

4. 从 0 到 1：安装与前置准备（严格按官方资料）

4.1 安装 Kurator CLI（官方文档给出的最短路径）

官方 Setup 中给出通过脚本安装 kurator CLI 的方式（Linux/macOS 示例）：

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

CLI 的价值在于：后续很多安装/初始化动作可以用统一入口完成（即使你最终在生产中用 GitOps 固化，也建议先用 CLI 跑通闭环）。

4.2 安装 Cluster Operator（含 cert-manager 前置）

官方安装页明确指出：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

实战建议：在企业环境中，把 cert-manager 版本与集群版本的兼容性纳入平台基线；Cluster Operator 的稳定性很大程度依赖它。

4.3 安装 Fleet Manager（两种“官方线索”组合验证）

Fleet Manager 的 Helm 安装方式在官方 helm-charts README 中给出：先 add repo、再 helm install。

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

安装后检查（官方文档/变更稿示例）：

kubectl get pods -n kurator-system

说明：由于 kurator.dev 的部分页面在抓取时出现超时（非内容缺失），本文用“官方 helm-charts README + 官方文档变更稿中的检查命令”交叉印证安装路径，仍属于官方资料范围。

如下是其相关架构流程图：

4.4 安装 MinIO（用于 Thanos / Velero 等对象存储场景的本地验证）

官方明确：Kurator 使用 bitnami 的 MinIO Helm Chart，并给出一段可直接执行的 values inline 安装方式，同时默认创建 thanos、velero 两个 bucket。

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 准备对象存储 Secret，官方也给出 objstore.yaml 的生成方式（含从 Service LoadBalancer 里取 IP 的命令）。

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 也可用一个简单 Secret 保存 access/secret key（官方示例）：

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

5. 统一入口的第一块拼图：把集群纳入 Fleet（AttachedCluster 思路）

在 Kurator 的体系里，不是 Kurator 创建的集群可以作为 AttachedCluster 纳入统一管理。统一应用分发示例中，官方直接通过 kubectl apply -f examples/application/common/ 创建两个 AttachedCluster 与一个 Fleet（quickstart）。

kubectl apply -f examples/application/common/
# 输出示例（官方文档展示）：
# attachedcluster.cluster.kurator.dev/kurator-member1 created
# attachedcluster.cluster.kurator.dev/kurator-member2 created
# fleet.fleet.kurator.dev/quickstart created

这一步是“平台化”的关键：只要 AttachedCluster 进入 Fleet，你后续的应用、监控、策略、发布、备份、存储，都可以以 Fleet 为作用域统一下发。

6. 功能实战一：统一应用分发（GitOps + Fleet）

Kurator 的统一应用分发，官方明确由 Fleet 驱动，并采用 GitOps 思路借助 FluxCD 做同步与部署自动化。
下面我们完全按官方示例跑通一次跨集群分发。

6.1 创建示例 Application（跨 Fleet 分发）

官方文档给出示例：直接 apply examples/application/gitrepo-kustomization-demo.yaml。

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

该示例 Application 的核心内容（官方展示）是：

• source：gitRepository（podinfo 仓库）
• syncPolicies：两个 kustomization，目的地都指向 fleet=quickstart（也就是对 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
        prune: true
        timeout: 2m0s
    - destination:
        fleet: quickstart
      kustomization:
        targetNamespace: default
        interval: 5m0s
        path: ./kustomize
        prune: true
        timeout: 2m0s

6.2 验证分发结果（在两个集群上看到同一套工作负载）

官方验证方式：分别用两个集群 kubeconfig 查看 Pod 列表，对比是否出现 podinfo 与 webapp 相关 Pod。

# 替换为你真实 kubeconfig 路径
kubectl get po -A --kubeconfig=/root/.kube/kurator-member1.config
kubectl get po -A --kubeconfig=/root/.kube/kurator-member2.config

运维意义（基于官方机制做专业解读）：

• 单一事实源：Git 仓库内容 + Application CRD 定义成为“交付事实源”。
• 一次声明，多处生效：destination 指向 Fleet，让“多集群交付”从脚本问题转成声明式对象问题。
• 内建清理策略：kustomization.prune=true 让资源回收跟随 Git 状态，降低僵尸资源风险。

6.3 进阶：用“集群选择器”实现差异化分发（同源不同策）

官方提供了 Application Policies 的 selector 机制：先给 AttachedCluster 打 label，再在策略里用 selector 选择目标集群，从而实现“同一个 source，分发到不同集群”。

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

这背后的平台价值在于：你不需要在 Git 里拆成 N 份应用配置，而是在 **“分发策略层”**解决环境差异；这更符合平台工程的分层原则。

6.4 一个必须记住的“单集群模式”坑点（官方明确提醒）

Kurator 支持不写 destination，让应用直接部署在 kurator 所在集群（单集群简化模式）。
但官方同时明确：当你把 destination 从“无”改为“fleet”时，之前部署在宿主集群的资源不会被删除；要在切换前清理掉该 Application。

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

这条在真实平台落地时非常关键：否则你会得到“宿主集群遗留一份 + Fleet 集群再来一份”的双份资源，带来观测与流量上的混乱。

7. 功能实战二：统一监控（Prometheus + Thanos + Fleet）

Kurator 的多集群监控插件（metric plugin）官方说明：其架构基于 Prometheus 与 Thanos，并且 Thanos 需要对象存储；文档示例使用 MinIO 并引用了安装页。

7.1 前置：为 AttachedCluster 准备访问 Secret（官方命令）

官方在 metric 插件文档中要求创建两个 Secret，用 kubeconfig 文件作为数据来源。

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 创建启用 metric plugin 的 Fleet（官方示例）

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

以上命令与“等待 Fleet Ready”的写法来自官方 metric 插件文档。

专业解读：

• 这一步体现了 Kurator 的“平台化安装”——监控能力不是“每个集群手工装一套”，而是作为 Fleet 插件统一装、统一升级、统一治理。
• 同时也解释了为什么前面要先装 MinIO：Thanos 需要对象存储，Kurator 把这个依赖显式化了。

8. 功能实战三：统一策略管理（Kyverno + Fleet）

Kurator 的策略管理插件官方说明：多集群策略管理构建在 Kyverno 之上。

8.1 前置：同样需要访问 AttachedCluster 的 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

8.2 启用“基线（baseline）Pod 安全检查”的 Fleet（官方示例）

官方给出的启用方式是 apply 一个示例 YAML：

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

8.3 用一个“无效 Pod”示例验证策略生效（官方提供思路）

官方验证方式：创建一个 Application，从 kurator-dev/kurator 仓库拉取内容并下发到 quickstart fleet。

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
        # 其余字段见官方示例继续部分

平台价值（基于官方机制推导，不新增事实）：
你可以把“策略”当作平台基线能力：当新集群加入 Fleet，只要它进入这个 Fleet 的作用域，策略就会随之统一下发与约束，从而把“安全一致性”变成系统特性，而不是流程要求。

9. 功能实战四：统一渐进式发布（Flagger Rollout Plugin）

Kurator 的 Unified Rollout 官方说明：需要先为 Fleet 配置 rollout 插件，且该插件基于 Flagger。

9.1 创建 AttachedCluster（官方给出“Secret + AttachedCluster”一体化 YAML）

官方 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

9.2 创建启用 Flagger 的 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

专业解读：

• 这里的“统一”体现在：灰度发布引擎作为 Fleet 插件被安装到一组集群，而不是在每个集群单独装 Flagger/配一套。
• trafficRoutingProvider=istio 也解释了为何 Kurator 在生态上强调与 Istio 等栈协同。

9.3 一个可参考的 Canary 应用示例（官方文档片段）

在 Nginx 金丝雀发布文档中，官方给出了通过 kubectl apply -f examples/rollout/canaryNginx.yaml 启动 demo 的方式，并展示了 Application 中 rollout 字段的关键结构（包含 trafficRouting、trafficAnalysis、webhooks 等）。

kubectl apply -f examples/rollout/canaryNginx.yaml

由于该示例 YAML 很长，本文不逐行粘贴全量内容（避免高重复）；建议你直接以官方 examples 文件作为起点，再把“指标/流量规则/检测脚本”替换为你的企业指标与网关域名。

10. 功能实战五：统一备份 / 恢复 / 迁移（Velero + Fleet + 对象存储）

Kurator 的 Unified Backup 官方说明：要先安装备份引擎插件；该插件基于 Velero，并依赖对象存储来保存备份数据。

10.1 备份插件的核心前置（官方明确）

• Velero 需要对象存储；文档同时给出 MinIO（本地验证）与华为云 OBS（云对象存储示例）。
• 官方特别说明：MinIO 方法仅用于验证，生产建议使用云厂商存储服务。

你可以复用前文 MinIO 安装与 minio-credentials Secret 的创建方式。

10.2 “迁移”能力的概念边界（官方定义）

官方对 Unified Migration 的定义是：将应用与资源从一个集群迁移到多个其他集群；用户只需定义 migrate 类型资源，该配置包含源集群、目标集群与进一步策略。
这意味着：Kurator 把“跨集群迁移”也抽象成声明式对象，避免了手工导出/导入与脚本拼装。

11. 功能实战六：统一分布式存储（Rook + Fleet）

Kurator 的 Unified Distributed Storage 官方说明：该能力构建在 Rook 之上，作为 Fleet 的 distributedStorage 插件启用。

11.1 关键前提（官方列出的硬性约束）

• Kubernetes v1.22+
• Ceph 存储至少需要 raw device / raw partition / LVM LV / block 模式 PV 等其一；并指出“最简单方式是给节点挂载 raw disk”。

11.2 创建启用分布式存储插件的 Fleet（官方示例片段）

官方示例展示了在 Fleet spec.plugin.distributedStorage 下配置 dataDirHostPath 与 monitor 等参数：

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

平台侧建议：把“存储插件启用条件”作为集群准入门槛（节点磁盘、标签、拓扑等），否则 Rook/Ceph 的落地会受到环境差异影响更大。该建议不新增官方事实，只是基于其前置约束做的工程化推导。

12. 典型问题与排查清单（只写官方明确提到的点）

为了满足征文对“安装问题与解决办法”的要求，同时保证不编造，这里仅列出官方材料中已经明确指出/暗示的“必踩点”：

1. Cluster Operator 安装失败 / webhook、证书相关异常：先检查 cert-manager 是否已安装并 ready；官方明确 cluster operator 依赖 cert-manager CA injector。
2. Thanos/监控相关组件无法工作：先确认对象存储可用；metric 插件文档明确依赖 Thanos 且需要 Object Storage，并在示例中使用 MinIO。
3. 从单集群模式切到 Fleet 分发后“资源重复”：官方明确不会自动删除宿主集群已部署资源，需先 delete 原 Application。
4. 备份场景把 MinIO 当生产方案：官方明确 MinIO 仅用于验证，生产建议云对象存储。

13. 平台化落地总结：把“能力”变成“基线”，把“动作”变成“声明”

回看本文的闭环，你会发现 Kurator 的工程化优势集中体现在三个关键词：

• 声明式：无论是 Application、Fleet、AttachedCluster，还是备份/发布等动作，本质都在向“对象模型”收敛。
• Fleet 作用域统一：多集群不再是“for 循环 + kubectl”，而是“对一个 Fleet 对象生效”。
• 生态组合可复用：Prometheus+Thanos（监控）、Kyverno（策略）、Flagger（发布）、Velero（备份）、Rook（存储）被统一封装成 Fleet 插件式能力。

当然，讲到这里，感兴趣的话，直接去clone 代码体验下吧：

并附上相关资料：

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