【探索实战】把 Kurator 写成“运维作业系统”：按 Day0/Day1/Day2 方法论落地 Fleet 多集群治理基线（交付/观测/策略/发布/备份/存储）

小白酷爱学习

564人浏览 · 2025-12-20 14:32:42

小白酷爱学习 · 2025-12-20 14:32:42 发布

开篇

说明：本文所有能力描述、组件定位、依赖关系、安装/配置命令、YAML 示例字段均基于 Kurator 官方资料（kurator.dev 官方文档、kurator-dev/kurator 官方仓库及其 examples、官方 Helm charts 等）整理与“结构化改写”。

1）为什么要把 Kurator 当作“运维作业系统”🤔⚙️

很多团队做多集群，第一阶段往往是“能跑就行”：写脚本循环 kubeconfig，挨个 kubectl apply；能装 Prometheus 就装、能配策略就配、能灰度就灰度。
但当集群数量上来（跨地域、跨云、边缘协同）后，运维的痛点会变成系统性的：

动作不可复制：每次新集群接入都要“凭经验再做一遍”，难审计、难回溯。
能力不成体系：交付、观测、策略、发布、备份、存储各装各的，升级/回滚互相影响。
一致性难保障：策略口径不同、告警体系不同、资源残留不同、配置漂移变常态。

Kurator 的价值，恰恰在于它试图提供“多集群一站式分布式云原生开源解决方案”，并整合业界主流技术栈（如 Istio、Prometheus、Karmada、KubeEdge、Volcano 等），在其之上封装出统一的生命周期治理、应用分发、流量治理、监控与策略管理等能力。
如果你从“运维作业系统”角度看，它做的不是替代这些项目，而是把这些能力装配到一个可声明、可持续对齐的控制平面里。

2）Kurator 的 OS 抽象：控制器（Controller）+ 作用域（Fleet）+ 插件装配（Plugins）🧩

把 Kurator 视为 OS，你会看到三类关键抽象：

2.1 控制器：把“动作”变成“对象状态对齐”

Cluster Operator：官方说明其以“集群 Operator”方式工作，基于 Cluster API 与 KubeSpray，并可管理集群插件（如 CNI、CSI、Ingress）。
👉 OS 视角：它管理的是“集群这台机器本身的生命周期与驱动”。
Fleet Manager：官方说明其作为 Kubernetes Operator 运行，负责 Fleet 控制面生命周期管理、集群注册/注销等。
👉 OS 视角：它管理的是“多集群这一整个作业域（Fleet）的控制平面”。

2.2 作用域：Fleet 是“运维作业域”

你不是在 N 个集群上做 N 次重复动作，而是在 Fleet 这个作用域里声明：
“这组集群要启用哪些能力？应用要怎么发？策略要怎么控？灰度怎么做？”
这类收敛在官方示例中体现得非常直接：Application 的 destination 可以指向 Fleet；各种治理能力通过 Fleet plugin 启用。

2.3 插件装配：把生态能力做成“可安装的标准组件”

官方资料中，Kurator 的多集群监控（Prometheus+Thanos）、策略（Kyverno）、渐进式发布（Flagger）、备份（Velero）、分布式存储（Rook）等，都以 Fleet 插件或示例方式体现出来：

metric plugin：Prometheus + Thanos（依赖对象存储）
policy plugin：Kyverno
rollout plugin：Flagger（trafficRoutingProvider=istio）
backup plugin：Velero（依赖对象存储，MinIO 用于验证）
distributed storage plugin：Rook（前置约束明确）

如果你们感兴趣，可直接下载该源码：

下载到本地之后

我们只需要进行项目解压即可：

可以看到清晰的目录结构，剩下的就看大家想怎么玩了。

而且附带很多文档说明，绝绝子。

3）Day0：平台装配与多集群纳管（最小可运行基线）🏗️✅

Day0 的目标只有一句话：让平台“能管到集群”，且具备后续治理能力的基础依赖。
推荐的 Day0 基线包括：

安装 Kurator CLI（统一入口）
安装 cert-manager（Cluster Operator 前置依赖）
安装 Fleet Manager（Fleet 控制面）
准备对象存储（用于 Thanos/Velero 等治理链路）
创建 AttachedCluster / Fleet（把集群纳入作业域）

3.1 安装 Kurator CLI（官方方式）

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

✅ Day0 验收点：CLI 可执行并输出版本信息（便于后续 runbook 标准化）。🙂

3.2 cert-manager：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

✅ Day0 验收点：cert-manager 命名空间内组件就绪；否则后续与证书/webhook 相关的控制器行为容易异常（官方已明确依赖）。

当然，我们还可以参考如下流程图：

3.3 Fleet Manager：用官方 Helm repo 安装（控制平面）

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

✅ Day0 验收点：kurator-system 内核心 Pod Running；平台控制面具备持续 reconcile 能力。🙂

3.4 对象存储：用 MinIO 做本地验证（官方示例包含 thanos/velero buckets）

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 生成 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 准备凭证 Secret（官方示例）：

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

✅ Day0 验收点：对象存储可用 + Secret 创建成功。
📌 官方提醒：MinIO 方式用于验证，生产建议云对象存储服务。

讲到这里，如果这里你已经感兴趣了，你可以直接去克隆代码或者下载：

3.5 纳管：创建 AttachedCluster 与 Fleet（官方示例路径）

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

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

✅ Day0 验收点：Fleet/AttachedCluster 对象存在，平台“看见”多集群了。🎉

4）Day1：交付链路（统一应用分发 + 差异化分发）🚚📦

Day1 的目标：让同一份交付定义，稳定分发到 Fleet 内集群，并可通过策略实现环境差异。
Kurator 官方示例把这件事做成了 Application CRD：source 指向 Git 仓库，syncPolicies 用 kustomization 描述部署方式，并将 destination 指向 Fleet。

4.1 最小交付：GitRepository + Kustomization + Fleet

官方示例：

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

4.2 验收：两个成员集群同时出现应用相关 Pod（官方验证方式）

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

✅ Day1 验收点：两个集群都有对应工作负载；交付从“多脚本”收敛为“单对象”。🙂

可看下如下分发示意图，以便于理解：

4.3 差异化交付：用 selector 按集群标签选择（官方示例）

给 AttachedCluster 打标签：

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

✅ Day1 进阶验收点：同源应用可按集群选择器产生差异化分发，而不是复制 N 份交付文件。

4.4 Day1 常见“残留风险”：单集群模式切换到 Fleet 的资源清理（官方明确提醒）

官方指出：单集群模式（不写 destination）部署在 Kurator 所在集群；当你切换到 Fleet 时，之前宿主集群资源不会自动删除，需要在切换前清理对应 Application。

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

✅ Day1 风险控制点：切换前清理，避免“宿主集群一份 + Fleet 再来一份”的双份资源。

5）Day2：治理链路（监控/策略/灰度/备份/存储）🔍🛡️🚦💾🧱

Day2 的目标：让平台具备可持续运营能力：
能看见（Observability）、能约束（Policy）、能稳发（Progressive Delivery）、能自保（Backup/Migration）、能供给（Distributed Storage）。
Kurator 官方示例把这些能力都往 Fleet 插件方向组织。

如果你对其部署过程有疑问，可进行其官网文档进行求解。

5.1 统一监控：metric plugin（Prometheus + Thanos + 对象存储）📈

官方说明 metric plugin 基于 Prometheus 与 Thanos，且 Thanos 需要对象存储；示例通过 apply YAML + wait Ready 完成启用。

先创建 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

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

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

✅ Day2 监控验收点：Fleet 状态 Ready；多集群监控能力被“装配进作业域”。

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

官方说明策略管理构建在 Kyverno 上，并给出示例：

同样先准备 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

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

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

官方给出的验证思路：通过 Application 从 kurator-dev/kurator 仓库下发内容到 quickstart fleet（片段示例）。

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: kyverno-policy-demo
  namespace: default
spec:
  source:
    gitRepository:
      ref:
        branch: main
      url: https://github.com/kurator-dev/kurator
  syncPolicies:
    - destination:
        fleet: quickstart
      kustomization:
        interval: 5m0s
        prune: true

✅ Day2 策略验收点：基线策略可随 Fleet 统一下发，形成“作业域级别”的合规约束。

其开源文档也写的很详细：

5.3 统一渐进式发布：rollout plugin（Flagger + Istio provider）🚦

官方说明 Unified Rollout 基于 Flagger，并给出 Fleet plugin 配置，其中 trafficRoutingProvider 使用 istio。

官方也给出了创建 AttachedCluster 的一体化 YAML（含 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

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

✅ Day2 发布验收点：作业域内集群具备统一的渐进式发布能力（装配层统一，不靠“每集群手工部署”。）

如下是它的架构图：

5.4 统一备份/恢复/迁移：backup plugin（Velero + 对象存储）💾

官方说明 Unified Backup 基于 Velero，依赖对象存储；并强调 MinIO 仅用于验证，生产建议云对象存储。
你可以直接复用 Day0 的 MinIO 与 minio-credentials Secret（官方已给）。

此外，官方对 Unified Migration 的描述为：定义 migrate 类型资源，配置源集群、目标集群与策略，即可将应用与资源从一个集群迁移到多个其他集群。
✅ Day2 备份/迁移验收点：数据保护被纳入平台对象模型（可审计、可复用），不是临时脚本工程。

5.5 分布式存储底座：distributed storage plugin（Rook）🧱

官方说明该能力构建在 Rook 之上，并列出硬性前置：Kubernetes v1.22+；Ceph 存储至少需要 raw disk/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

✅ Day2 存储验收点：满足前置约束的集群可在 Fleet 作用域下获得统一存储装配能力。

6）统一 Runbook：把“接入一个新集群”写成可执行作业模板（投稿加分项）🧾✨

这一节非常适合你投稿时拿来“体现专业度”：不需要虚构企业数据，只要把官方机制组织成 runbook。

Runbook A：新集群接入 Fleet（AttachedCluster）

准备 kubeconfig 文件（供 Kurator 访问）
创建 kubeconfig Secret（官方在多个插件示例中要求这样做）
创建 AttachedCluster 对象（官方 rollout 示例给出 YAML）
把集群加入 Fleet（官方示例 Fleet/AttachedCluster 路径）

Runbook B：把应用交付加入平台（Application）

选择 source（gitRepository）与 ref（branch）
定义 syncPolicies（kustomization path、prune、interval）
destination 指向 Fleet（quickstart 等）
在成员集群验证 Pod 落地（官方给出 kubeconfig 验证方式）

Runbook C：治理能力装配（Fleet plugins）

监控：metric-plugin.yaml + wait Ready（Prometheus + Thanos，依赖对象存储）
策略：kyverno.yaml + wait Ready（Kyverno baseline）
灰度：flagger plugin（trafficRoutingProvider=istio）+ canary demo
备份：Velero（对象存储依赖、MinIO 验证边界）
存储：Rook（前置约束）

7）Day0/Day1/Day2 角度下的“官方明确风险点”汇总（只写官方能支撑的）🧯📌

Cluster Operator 相关证书问题：官方明确依赖 cert-manager CA injector，必须先装 cert-manager。
监控链路不可用：metric plugin 基于 Thanos 且需要对象存储；官方示例用 MinIO 并创建 objstore Secret。
单集群模式切换到 Fleet 会残留旧资源：官方明确不会自动删除宿主集群资源，需先 delete 原 Application。
MinIO 的生产边界：官方提示 MinIO 用于验证，生产建议云对象存储。
分布式存储前置不满足：官方列出 Kubernetes 版本与 Ceph 存储介质约束。

最后，附上Kurator 开源地址：

Kurator分布式云原生开源社区地址：https://gitcode.com/kurator-dev

Kurator分布式云原生项目部署指南：https://kurator.dev/docs/setup/

AtomGit开源社区

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

更多推荐

TypeScript完全指南：从JavaScript到TypeScript的进阶之路

TypeScript是JavaScript的超集，由微软开发，在JavaScript的基础上添加了静态类型系统。它可以在编译时捕获错误，提高代码的可维护性和开发效率。// 1. 优先使用interface定义对象类型// 2. 使用type定义联合类型、交叉类型// 3. 避免使用any，使用unknown代替// 4. 使用readonly定义不可变数据// 5. 使用泛型提高代码复用性Tid: