一、企业走向分布式云原生，真正的挑战是什么？

在企业数字化转型过程中，“上云”“容器化”“Kubernetes 化”早已不是新鲜事。
但随着业务规模扩大、地域分布增加、边缘场景出现，越来越多企业开始进入一个新阶段：

多云、多集群、云边协同的分布式云原生阶段

在这一阶段，企业面临的问题已经发生了明显变化：

• ❌ 不再是“能不能部署应用”
• ❌ 不再是“Kubernetes 会不会用”
• ✅ 而是“平台是否具备规模化治理能力”
• ✅ “技术投入是否真的转化为业务价值”

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

现实中，很多企业虽然引入了大量云原生技术，却逐渐陷入一种困境：

技术栈越来越复杂，平台成本越来越高，但治理效率并没有线性提升。

Kurator 的设计初衷，正是为了解决这一类“工程投入与业务收益不匹配”的问题。

所以，我们先来进行项目下载：

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

分别执行命令：

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

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

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

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

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

二、传统多云多集群方案的隐性成本分析

在没有 Kurator 之前，企业常见的分布式云原生建设路径是：

• 使用 Karmada 或其他方案做多集群编排
• 使用 Istio 做服务网格
• 使用 Prometheus / Thanos 做监控
• 使用 Kyverno / OPA 做策略
• 使用 Flagger / Argo Rollouts 做发布
• 使用 FluxCD / Argo CD 做 GitOps

从功能上看，这套方案是“成立的”。
但从企业视角看，问题集中体现在四个方面：

2.1 平台集成成本高

• 各组件安装方式不同
• 生命周期管理割裂
• 升级、兼容性高度依赖专家经验

2.2 运维与治理成本不可控

• 每个集群需要重复配置
• 策略、监控、流量规则容易漂移
• 故障排查需跨多个系统

2.3 人才成本持续上升

• 需要“全栈云原生专家”
• 新人学习曲线陡峭
• 平台知识难以标准化传承

2.4 技术价值难以向业务解释

• 很难回答“这套平台为业务节省了多少成本”
• 很难量化“平台带来的稳定性收益”

👉 这些隐性成本，正是企业在分布式云原生阶段最容易忽视的风险点。

三、Kurator 的企业级价值定位：降低“平台系统性成本

Kurator 官方将自身定位为：

整合主流云原生技术栈的一站式分布式云原生开源解决方案，提供统一集群治理、统一应用分发、统一流量治理、统一监控与统一策略管理能力。

如果从企业价值角度重新解读，可以总结为一句话：

Kurator 的核心价值，不是“功能更多”，而是“用统一抽象降低系统性成本”。

其中，大体流程可参考如下：

四、Fleet：企业进行“规模化治理”的关键载体

4.1 Fleet 对企业意味着什么？

在 Kurator 中，Fleet 是多集群治理的核心对象。

官方文档明确指出，Fleet 支持在集群组维度统一启用应用分发、监控、策略、网络与发布能力。

从企业视角来看，Fleet 带来的变化是：

• 管理单元从“集群”升级为“集群集合”
• 运维操作从“重复执行”升级为“一次声明”
• 风险控制从“人工流程”升级为“平台机制”

4.2 Fleet 与组织结构的天然映射

在企业中，Fleet 可以自然映射为：

• 一个业务域
• 一个产品线
• 一个地域或环境（如生产 / 预发）

这使平台治理能够与组织治理保持一致，大幅降低沟通与协作成本。

五、统一应用分发：降低交付成本，提升交付确定性

Kurator 的统一应用分发基于 Fleet + FluxCD 的 GitOps 模型。

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: business-app
spec:
  source:
    gitRepository:
      url: https://github.com/stefanprodan/podinfo
  syncPolicies:
    - destination:
        fleet: production
      kustomization:
        path: ./deploy/webapp

5.1 对企业的直接收益

• 减少人工发布操作
• 降低误操作概率
• 缩短新环境上线周期

5.2 对业务的间接收益

• 应用交付更稳定
• 发布节奏更可预测
• 业务上线风险降低

👉 这些收益虽然不直接体现在代码行数上，但会持续反映在业务稳定性指标中。

5.3 安装Kurator核心组件与Volcano

参考官方Setup指南：

1. 安装Cluster Operator与Fleet Manager：

helm repo add kurator https://kurator-dev.github.io/charts
helm repo update

helm install cluster-operator kurator/cluster-operator --namespace kurator-system --create-namespace --wait
helm install fleet-manager kurator/fleet-manager --namespace kurator-fleet-system --create-namespace --wait

2. 将成员集群加入舰队（使用AttachedCluster方式）：

apiVersion: cluster.kurator.dev/v1alpha1
kind: AttachedCluster
metadata:
  name: gpu1
  namespace: kurator-fleet-system
spec:
  kubeconfigSecretRef: gpu1-config
---
apiVersion: cluster.kurator.dev/v1alpha1
kind: AttachedCluster
metadata:
  name: gpu2
  namespace: kurator-fleet-system
spec:
  kubeconfigSecretRef: gpu2-config
---
apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: ai-fleet
  namespace: kurator-fleet-system
spec:
  clusters:
  - name: gpu1
    type: Attached
  - name: gpu2
    type: Attached

3. 在舰队中统一安装Volcano：
   使用Application CRD将Volcano同步到所有成员集群。

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: volcano-install
  namespace: kurator-fleet-system
spec:
  source:
    helmRepository:
      url: https://volcano-sh.github.io/helm-charts
      interval: 10m
  syncPolicies:
  - destination:
      fleet: ai-fleet
    helm:
      releaseName: volcano
      chart:
        spec:
          chart: volcano
          version: v1.8.0
          interval: 30m
      values:
        scheduler:
          defaultSchedulerName: volcano
        controllers:
          enabled:
            - queue
            - job

kubectl apply -f volcano-install.yaml

验证Volcano组件在成员集群运行：

kubectl get pods -n volcano-system --kubeconfig=~/.kube/kurator-gpu1.config

小问题解决：

• Volcano CRD冲突：先卸载旧版本
• Scheduler未接管：检查configmap volcano-scheduler-config，确保defaultSchedulerName正确

而且，也可以参考如下示意图：

而且，也可以参考如下示意图：

六、统一监控与策略：把“风险控制”前移到平台层

6.1 多集群监控的商业意义

Kurator 通过 Prometheus + Thanos 提供多集群统一监控能力，并以 Fleet 为单位启用。

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

从企业角度看，这意味着：

• 决策基于整体数据而非局部视角
• 容量规划更准确
• 故障影响范围更清晰

6.2 策略治理：降低合规与安全风险

Kurator 在 Fleet 维度集成 Kyverno，实现统一策略管理。

kubectl apply -f examples/fleet/policy/kyverno.yaml

策略作为平台能力存在，能够：

• 降低因配置不一致导致的安全风险
• 减少人工审计成本
• 提升企业合规成熟度

七、统一发布（Rollout）：用工程手段降低业务风险

Kurator 基于 Istio + Flagger 提供统一渐进式发布能力。

plugin:
  flagger:
    trafficRoutingProvider: istio

7.1 对企业最直接的价值

• 故障不再“一次性全量爆发”
• 发布风险可控、可回滚
• 平台自动参与风险决策

从管理视角看，这是将“经验依赖”转化为“系统能力”的关键一步。

八、综合评估：Kurator 带来的 ROI 提升路径

维度	传统方案	引入 Kurator 后
平台集成成本	高	显著降低
运维复杂度	随规模线性增长	收敛到平台层
人才依赖	高度专家化	可标准化
风险控制	流程为主	平台机制
业务稳定性	难量化	可观测、可治理

👉 Kurator 的 ROI 并非一次性体现，而是随着集群规模扩大持续放大。

如下是它开源的截图展示：

九、结语：企业分布式云原生建设，需要“长期主义的平台方案”🌱

分布式云原生不是短期项目，而是企业 IT 架构的长期演进方向。

Kurator 通过“一栈统一”的方式，将多云、多集群、边缘场景下的复杂性系统性收敛，为企业提供了一条：

• 可落地
• 可演进
• 可持续投入产出的分布式云原生平台建设路径。

至此，如上演示，可能不是特别详细，如果你想要更详细的部署体验教程，可前往官方文档查阅。

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