1. 背景：从“工具堆叠”走向“平台化一栈统一”💡

在多云、多集群、云边协同的现实里，很多团队会在不同集群分别部署：应用分发（GitOps/CI）、监控（Prometheus/Thanos/Grafana）、网络互通（Submariner 等）、策略（Kyverno 等）、发布（灰度/金丝雀）……但最终常见的痛点是：

  • 一致性难：同一套命名空间、ServiceAccount、Service 规范与权限，很难在多个集群完全一致落地；
  • 运维分裂：监控数据、策略报告、发布进度在不同集群里各看各的；
  • 规模效应差：新增一个集群意味着“再来一套”，平台团队被 Day2 反复消耗；
  • 变更风险高：跨集群发布/策略下发缺少统一的控制面与可回滚路径。

Kurator 在官方文档里把方向概括得很清楚：它把一组物理集群抽象为逻辑单元 Fleet，并围绕 Fleet 做一致性管理与统一编排；Fleet Manager 作为 Kubernetes Operator，负责 Fleet 控制面生命周期与集群注册/注销等。

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

2. Kurator 的组件分层与对象模型：先把“骨架”搞清楚 🧱

2.1 Setup 章节给出的“安装视图”

官方 Setup 明确指出：Kurator 当前包含两个组件 cluster operator 与 kurator cli（并提供源码构建与 release 包方式）。

注意：Fleet Manager 是文档中独立的管理面能力体系（Fleet manager 章节），并在多个教程里作为前置条件出现（“先按 installation guide 安装 fleet manager”）。

2.2 Cluster Operator：把“集群生命周期”变成 Kubernetes 风格 API

在 Cluster operator 的 quickstart 教程里，Kurator 直接引导你用 Cluster API 的方式部署一个 vanilla 集群，并通过 clusterctl get kubeconfig 拉取 kubeconfig。

你可以把它理解为：

  • 你不再把“建集群/扩缩容/升级/删除”当成一堆脚本；
  • 而是当成声明式对象（CRD），让 controller 去 reconcile。

2.3 Fleet Manager：把“多集群一致性治理”变成一等能力

Fleet manager 文档给出“它能做什么”的清单（非常关键，决定你后续平台化能走多远）：

  1. 提供逻辑单元 Fleet 表示物理集群组
  2. Fleet 控制面生命周期管理
  3. 支持集群注册/注销
  4. Fleet 范围的应用编排
  5. Fleet 内跨集群保持 Namespace/ServiceAccount/Service 的一致性
  6. 提供跨集群服务发现与通信
  7. 聚合 Fleet 内所有集群的指标（metrics）

这段清单就是你写“平台能力边界”的官方依据：它明确写出了“一致性对象”“服务发现与通信”“指标聚合”等平台基座能力。

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

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

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

我们执行克隆命令可见：

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

3. 环境准备：用官方脚本一键拉起 Kind 多集群（Host + Member）🧪

Cluster Operator 安装页给了一个非常实用的本地体验路径：
先克隆 Kurator 仓库，然后用脚本部署本地 Kind 集群。

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

# 使用官方脚本拉起本地集群
hack/local-dev-setup.sh

脚本跑完后，官方文档说明会生成并提示 kubeconfig 路径：

  • Host：/root/.kube/kurator-host.config
  • Member：/root/.kube/kurator-member1.config、/root/.kube/kurator-member2.config

一个很“真实”的小坑🙂：
很多人第一遍失败不是工具问题，而是环境变量 KUBECONFIG 指错。官方输出里明确告诉你如何 export。

4. 安装 Kurator CLI：两种方式 + 验证命令 ✅

官方提供两条路：源码编译与 release 包。

4.1 源码编译安装

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

（可执行文件路径、需要放进 PATH 的说明在官方文档里写得很清楚。）

4.2 Release 包安装（示例以 v0.6.0 / linux-amd64）

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/

4.3 验证

kurator version

官方文档展示了输出字段结构（gitVersion / gitCommit / goVersion / platform 等）。

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

5. 安装 Cluster Operator：cert-manager、三种安装路径与验证 🔧

Cluster Operator 安装页给出了“先决条件 + 安装方式 + 验证方式”的完整闭环。

5.1 前置：安装 cert-manager（Kurator cluster operator 依赖 CA injector）

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

5.2 方式 A：从源码构建镜像与 Helm Chart

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

# 加载镜像到 kind（host 集群名为 kurator-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/
helm install --create-namespace kurator-cluster-operator cluster-operator-0.6.0.tgz -n kurator-system

这里有个“平台工程视角”的细节：官方在同一段里也加载了 fleet-manager 镜像，说明这套本地演示路径天然面向“多组件协同体验”。

5.3 方式 B：从 Release 包安装 Chart

curl -LO https://github.com/kurator-dev/kurator/releases/download/v0.6.0/cluster-operator-0.6.0.tgz
helm install --create-namespace kurator-cluster-operator cluster-operator-0.6.0.tgz -n kurator-system

5.4 方式 C：从 Helm Repo 安装

helm repo add kurator https://kurator-dev.github.io/helm-charts
helm repo update
helm install --create-namespace kurator-cluster-operator kurator/cluster-operator \
  --version=0.6.0 -n kurator-system

5.5 验证

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

官方示例期望看到 cluster operator Pod Running。

而且，未来 3～5 年，“策略即代码”、“安全即代码”的重要程度，只会继续上升。

6. 用 Kurator Cluster API 创建一个 vanilla 集群（官方 quickstart）🏗️

Cluster operator 的教程把最小闭环写得非常短——这也正是“从 0 到 1”最需要的：能跑起来、能拿到 kubeconfig、能看到 nodes。

6.1 创建集群

kubectl apply -f examples/cluster/quickstart.yaml
kubectl get cluster -w

6.2 获取 kubeconfig

clusterctl get kubeconfig quickstart > /root/.kube/quickstart.kubeconfig

6.3 查看节点

kubectl --kubeconfig=/root/.kube/quickstart.kubeconfig get nodes

6.4 清理（官方特别强调：要删 cluster 对象以确保基础设施清理正确）

kubectl delete cluster --all

并可选卸载 cluster operator、清理 CRDs、删除 namespace、卸载 cert-manager、删除 kind 集群等。

7. Fleet Manager：把“多集群治理”抽象为 Fleet（平台化的关键一步）🧠

Fleet manager 文档明确：Fleet manager 目标是让一组集群被一致性管理，这组集群被称为 fleet。
它以 Operator 方式运行，负责 Fleet 控制面生命周期与集群注册/注销。

从平台设计角度，你可以把 Fleet 当成“租户/业务域/环境（prod、staging）/地域（region）”的统一边界：

  • 在 Fleet 里做应用编排（统一分发）
  • 在 Fleet 里做指标聚合（统一监控）
  • 在 Fleet 里做策略下发（统一策略）
  • 在 Fleet 里做跨集群通信（服务互通）
    这些都在官方“what can fleet manager do”清单中对应得到。

8. 把已有集群接入统一视图：AttachedCluster + Secret（官方示例）🔌

现实里，你不可能只管理“新建集群”，更多时候要把既有集群纳入平台统一治理。Kurator 用 AttachedCluster 表达“非 Kurator 创建的集群”，并通过 kubeconfig Secret 进行接入（示例在 Rollout Plugin 前置步骤中给出）。

8.1 为 member 集群 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

8.2 创建 AttachedCluster 资源（两段 YAML）

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

工程化解读：这个模型非常“平台友好”。你可以把“集群接入”标准化为：

  • 交付 kubeconfig（或未来扩展为更严格的凭据体系）
  • 平台侧生成 Secret
  • 用 AttachedCluster 统一登记
    后续所有能力（应用/策略/监控/网络/发布）都围绕 Fleet + Cluster 列表展开，不再在脚本里散落。🙂

9. 创建 Fleet：把集群组装成逻辑单元（官方示例）🧩

“Get Started with Kurator Fleet” 教程给出最短路径：直接 kubectl apply 一个 fleet manifest，然后观察 fleet ready。

kubectl apply -f examples/fleet/fleet.yaml

查看 ready 状态的示例输出中，status.phase: Ready、readyClusters: 1 等字段展示了 Fleet 的控制面状态。

10. 统一应用分发：Application CRD + GitOps（FluxCD）+ Fleet 🚚

Kurator 的“统一应用分发”明确采用 GitOps 方式，并指出是通过 FluxCD 做同步与部署自动化。

10.1 架构要点（官方表述的转译）

  • Fleet 作为“目标集群集合”
  • Application 描述“应用源（Git）+ 同步策略（kustomization 等）+ 分发目标（fleet）”
  • 通过 GitOps 自动同步，使分发更快、更精准（官方原文强调 quick & precise）

10.2 直接跑官方示例（最省心）

官方给了一个“预准备的 attachedClusters 与 fleet”的目录，一条命令创建：

kubectl apply -f examples/application/common/

然后再创建一个示例 Application：

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

10.3 Application 示例 YAML（官方示例片段，理解字段比背命令更重要）

下面是官方文档直接展示的 Application 资源结构（我保持字段一致，便于你对照理解）：

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

运维价值分析（基于官方模型做推导，不引入新事实）：
这套模型的关键不是“又一个 GitOps”，而是把 “目标从单集群 → Fleet（集群组）”。你不再为每个集群写一份同步对象，而是让 Application 的 destination 指向 fleet，这就是平台化的规模杠杆。🙂

11. 统一监控：Metric Plugin（Prometheus + Thanos）+ MinIO（对象存储）📈

11.1 官方架构与依赖

监控教程明确：Fleet 的多集群监控构建在 Prometheus 与 Thanos 之上，并且 Thanos 需要对象存储；教程示例里使用 MinIO。

11.2 先装 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

检查 Pod：

kubectl get po -n monitoring

（官方还给了可选项：创建 Thanos secret、Velero secret 等，用于对象存储接入与凭据管理。

11.3 创建开启 metric plugin 的 Fleet（官方示例文件）

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

等待 fleet ready（官方给了 kubectl wait 的 jsonpath 用法）：

kubectl wait fleet quickstart --for='jsonpath='{.status.phase}'=Ready'

看到 Thanos / Grafana 相关 Pod Running（官方示例输出展示了 thanos-query、storegateway、grafana 等）。

11.4 用 Fleet Application 下发更多监控配置（官方示例：avalanche + ServiceMonitor）

监控教程给了一个 Application 示例，把 source 指向 https://github.com/kurator-dev/kurator，并用 kustomization path 指向示例目录：

cat <<EOF | kubectl apply -f -
apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: metric-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/metric/monitor-demo
        prune: true
        timeout: 2m0s
EOF

平台化视角：
你可以把“监控栈”当成 Fleet 的一个插件/能力包（metric plugin），而把“业务监控对象（ServiceMonitor/自定义 exporter）”当成 Application 去下发。这样“平台能力”和“业务接入”职责边界更清晰。🙂

12. 多集群网络与互通：Submariner Plugin（官方示例）🌐

Submariner 教程同样是 Fleet plugin 思路：在一组集群上统一安装与配置。

12.1 前置：Secret + gateway 节点打标

# Create secrets for the attached clusters
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

# Label a gateway node for each attached cluster
kubectl label node kurator-member1-control-plane submariner.io/gateway=true --kubeconfig=/root/.kube/kurator-member1.config
kubectl label node kurator-member2-control-plane submariner.io/gateway=true --kubeconfig=/root/.kube/kurator-member2.config

12.2 生成 PSK 并套用示例 YAML

export SUBMARINER_PSK=$(LC_CTYPE=C tr -dc 'a-zA-Z0-9' < /dev/urandom | fold -w 64 | head -n 1)
envsubst < examples/fleet/network/submariner-plugin.yaml | kubectl apply -f -

等待 fleet ready：

kubectl wait fleet quickstart --for='jsonpath='{.status.phase}'=Ready'

12.3 验证（官方给了 subctl diagnose / verify）

subctl diagnose all --kubeconfig /root/.kube/kurator-member1.config

export KUBECONFIG=/root/.kube/kurator-member1.config:/root/.kube/kurator-member2.config
subctl verify --context kurator-member1 --tocontext kurator-member2
subctl verify --context kurator-member2 --tocontext kurator-member1

13. 统一策略管理：Policy（Kyverno）+ PolicyReport 验证闭环 🛡️

策略教程写得很“平台工程”——不仅告诉你装策略引擎，还告诉你如何制造一个违规对象并用报告/事件验证。

13.1 架构：Fleet policy built on Kyverno

官方明确：多集群策略管理构建在 Kyverno 之上。

13.2 开启 pod security policy（baseline）

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

13.3 下发一个“违规 Pod”示例（通过 Application）

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

13.4 看 PolicyReport 与事件（形成“策略→拦截→可观测”闭环）

kubectl get policyreport --kubeconfig=/root/.kube/kurator-member1.config
kubectl describe pod badpod --kubeconfig=/root/.kube/kurator-member1.config | grep PolicyViolation

官方示例输出里清楚展示了被 Kyverno 扫描出 FAIL/WARN，以及事件里对 hostIPC 等字段的校验信息。

运维价值：
“统一策略管理”的核心不是“能下发规则”，而是能给到平台可审计的报告与可定位的事件。PolicyReport 让“合规性”从口头要求变成可查询对象。🙂

14. 统一发布与流量治理入口：Rollout Plugin（Flagger；Istio/Kuma/Nginx）🚦

Rollout 插件安装指南明确：需要先在 Fleet 中配置 rollout plugin，Rollout 基于 Flagger；并给出 trafficRoutingProvider 字段，当前支持 Istio、Kuma、Nginx。

14.1 创建带 rollout plugin 的 Fleet（官方示例 YAML）

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

14.2 验证（示例查看 istio-system 下 Pod）

kubectl get pod -n istio-system --kubeconfig=/root/.kube/kurator-member1.config
kubectl get pod -n istio-system --kubeconfig=/root/.kube/kurator-member2.config

平台化解读：
“统一发布”在平台里通常是最难统一的，因为它牵涉到流量入口、服务网格/Ingress 能力差异。Kurator 用 trafficRoutingProvider 把差异显式化（Istio/Kuma/Nginx），这意味着你可以在同一套 Fleet 模型上逐步扩展更多流量治理实现，而不是推翻重来。

15. 清理与回收：为什么官方反复强调“删 cluster 对象”🧹

在多个教程的 cleanup 段落里，官方都会强调：为了正确清理基础设施，应删除 cluster 对象，否则可能残留资源需要手工清理。

典型清理动作包括（按需选择）：

  • 删除 Application / Fleet：
kubectl delete application metric-demo
kubectl delete application kyverno-policy-demo
kubectl delete fleet quickstart
  • 卸载组件（示例：fleet manager / cluster operator）：
helm uninstall kurator-fleet-manager -n kurator-system
helm uninstall kurator-cluster-operator -n kurator-system
  • 可选清理 CRDs / namespace / cert-manager / kind：
kubectl delete crd $(kubectl get crds | grep cluster.x-k8s.io | awk '{print $1}')
kubectl delete crd $(kubectl get crds | grep kurator.dev | awk '{print $1}')
kubectl delete ns kurator-system
helm uninstall -n cert-manager cert-manager
kind delete cluster --name kurator

16. 把这些“教程能力”拼成“平台能力”的关键点（专业视角总结）🧠✨

本节是工程化总结：不新增官方未提到的功能点，只讨论如何用官方给出的对象与插件机制，搭出可长期演进的平台化落地形态。

16.1 统一控制面：以 Fleet 为“平台治理域”

官方已经把 Fleet 定义为“物理集群组的逻辑单元”，并列出一致性对象、服务发现/通信、指标聚合等能力。
平台落地时建议把 Fleet 映射为：

  • 业务域/产品线（一条线一个 fleet）
  • 环境（prod/staging 各自独立 fleet）
  • 地域（跨 region 按网络条件拆 fleet）

16.2 “纳管集群”的标准化：AttachedCluster 先打通

很多团队平台化失败，是因为“接入成本”太高。Kurator 的 AttachedCluster 模型把接入简化为：Secret + AttachedCluster CR。
你可以进一步在组织流程上把它标准化为：

  • 申请接入 → 提供 kubeconfig（或更严格的准入方式）
  • 平台生成 Secret/对象 → 纳入 fleet
  • 后续所有能力都通过 fleet 统一下发

16.3 应用交付与治理：Application 作为“业务入口”

统一应用分发章节明确采用 FluxCD GitOps，并展示了 Application 的 source 与 syncPolicies（destination 指向 fleet）。
平台团队可以把它作为唯一入口：

  • 业务只提交 Git 仓库/路径与同步策略
  • 平台负责目标 fleet、策略与观测能力

16.4 可观测与合规：监控（Prometheus/Thanos）+ 策略（Kyverno）形成闭环

  • 监控教程提供了从 fleet plugin 安装到用 Application 下发 ServiceMonitor 的路径。
  • 策略教程提供了从启用 baseline 到用 PolicyReport/事件验证的路径。

这两者组合起来，你就得到：
“部署一致性 + 观测一致性 + 合规一致性” 的平台最小闭环。

16.5 发布与流量治理：Rollout plugin 把差异收敛到 provider

Rollout plugin 通过 trafficRoutingProvider 显式表达底座差异（Istio/Kuma/Nginx），并基于 Flagger。
平台团队可以据此制定路线：

  • 先统一一类 provider（例如先 Istio）
  • 再逐步扩展到其他 provider
  • 将发布策略与观测（metrics）联动，形成自动化发布门禁（这属于平台工程策略设计，Kurator 提供了插件与对象基础）

17. 结语：用“官方对象 + 官方示例”走通从 0 到 1 的平台化路径

如果你只做一遍 demo，Kurator 的价值可能像“又一个工具”；
但当你把官方文档里的对象模型串起来：

  • Cluster API 解决“集群生命周期声明式化”
  • Fleet 解决“多集群统一视图与一致性治理”
  • Application + GitOps（FluxCD） 解决“统一分发与持续同步”
  • Metric（Prometheus+Thanos） 解决“统一监控与指标聚合”
  • Policy（Kyverno） 解决“统一策略与可审计合规”
  • Submariner plugin 解决“跨集群互通与验证工具链”
  • Rollout plugin（Flagger） 打开“统一发布/流量治理的可扩展入口”

你就能把“分布式云原生开源技术栈”从堆叠变成体系化平台能力。加油！

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

并附上相关资料：

  • Kurator分布式云原生开源社区地址：https://gitcode.com/kurator-dev
  • Kurator分布式云原生项目部署指南：https://kurator.dev/docs/setup/
# 分布式 # 云原生
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

基于大数据+Hadoop+深度学习的淘宝用户购物可视化与行为预测系统设计与开发

avatar 亚马逊云科技技术品牌专区
cover

基于大数据爬虫+Hadoop+深度学习的旅游推荐系统设计与开发

avatar 亚马逊云科技技术品牌专区
cover

基于大数据爬虫+Hadoop+深度学习的个性化音乐推荐系统设计与开发

avatar 亚马逊云科技技术品牌专区