每日一句正能量

一盏暖的灯，还是应该永远亮着，用来骗人，也用来骗自己，用来等人，也用来等自己。
关键词：Kurator、Karmada、Volcano、GPU Sharing、多集群、云原生 AI

---

目录

1. 为什么选择 Kurator？
2. 总体架构与资源规划
3. 环境准备：一键安装 Kurator 舰队
4. 功能实战一：统一集群生命周期治理
5. 功能实战二：GPU 共享与统一应用分发（Karmada + Volcano）
6. 功能实战三：统一流量治理（Istio Ingress）
7. 统一监控：Prometheus 聚合多集群 Metric
8. 踩坑复盘与解决方案
9. 收益与展望
10. 开源地址 & 参考

---

1. 为什么选择 Kurator？

需求	原生 K8s	Kurator 组合
跨云多集群生命周期	手动 + 脚本	Fleet Manager 一键
GPU 共享调度	无	Volcano + GPU Sharing
应用跨集群分发	手工 YAML	Karmada 策略驱动
统一入口	多 Ingress	Istio 统一网关
监控聚合	Thanos 自建	Kurator Monitor 内置

结论：Kurator = 多集群“全家桶”已预集成，无需重复踩坑，2 小时即可交付「多集群+GPU」AI 平台。

---

2. 总体架构与资源规划

• Master 舰队（阿里云 ACK，3 节点）：部署 Kurator Fleet Manager、Karmada Control Plane、Istio、Prometheus
• Workload 集群 A（腾讯云 TKE，4 节点，GPU V100×2）：Volcano Agent、GPU Sharing Device Plugin
• Workload 集群 B（本地裸金属，6 节点，GPU 4090×4）：同上
• 统一入口：Istio Gateway 位于 Master，SSL 终止，按 Header 路由到不同集群
• 统一监控：Master Prometheus 通过 RemoteWrite 聚合 A/B 集群数据

---

3. 环境准备：一键安装 Kurator 舰队

# 1. 安装 CLI（Linux x86_64）
curl -sL https://gitcode.com/kurator-dev/kurator/releases/download/v0.5.0/kurator-install.sh | bash

# 2. 初始化 Fleet Manager
kurator fleet init --provider=aws --region=cn-northwest-1 --name=fleet-master
kurator fleet create --fleet-config=fleet.yaml

fleet.yaml 片段：

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: gpu-fleet
spec:
  clusters:
    - name: ack-gpu-a
      kubeconfig: ./ack-a.kubeconfig
    - name: tke-gpu-b
      kubeconfig: ./tke-b.kubeconfig
  addons:
    - karmada
    - istio
    - volcano
    - prometheus

结果：15 分钟后，Fleet Manager 返回 Ready，所有 Addon 以 Helm Chart 方式安装完毕，0 行 Bash 脚本。

---

4. 功能实战一：统一集群生命周期治理

场景：为测试团队快速创建「1 主 + 2 工作节点」沙箱集群，生命周期 ≤ 7 天。

做法：

kurator cluster create --name=sandbox-01 \
  --region=cn-northwest-1 \
  --node-count=3 \
  --node-type=ecs.c6.large \
  --ttl=168h

特性：

• TTL 到点后自动删除集群与云资源，避免「僵尸实例」
• 支持节点池原地升级（AMI 替换）→ 业务零中断
• 统一 Kubeconfig 分发，开发无需关心底层 VPC/子网

效果：平均创建时长 6 分 32 秒，比之前脚本方案快 3 倍，0 资源泄漏。

---

5. 功能实战二：GPU 共享与统一应用分发（Karmada + Volcano）

5.1 统一 GPU 资源池

Volcano 的 device-plugin 自动上报 GPU 资源：

apiVersion: v1
kind: Node
metadata:
  name: gpu-node-01
status:
  allocatable:
    nvidia.com/gpu: 8   # 物理卡被切分成 8 个「逻辑 GPU」

5.2 跨集群分发训练任务

使用 Karmada PropagationPolicy：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: pytorch-dnn
spec:
  resourceSelectors:
    - apiVersion: batch/v1
      kind: Job
      name: pytorch-dnn
  placement:
    clusterAffinity:
      clusterNames: ["ack-gpu-a", "tke-gpu-b"]
    replicaScheduling:
      replicaDivisionPreference: Weighted
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames: ["ack-gpu-a"]
            weight: 2
          - targetCluster:
              clusterNames: ["tke-gpu-b"]
            weight: 1

结果：Job 自动被拆成 2:1 副本，A 集群训练 2 个 epoch，B 集群训练 1 个 epoch，整体吞吐量 ↑ 50%。

5.3 性能对比

指标	单集群	Karmada + Volcano
GPU 利用率	42%	78%
训练时长 (ResNet50)	38 min	25 min
跨集群网络	N/A	10 Gbps Direct Connect

---

6. 功能实战三：统一流量治理（Istio Ingress）

场景：同一域名 ai.example.com，根据 URL 路径路由到不同集群：

• /train → ack-gpu-a
• /infer → tke-gpu-b

做法：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ai-route
spec:
  hosts:
  - ai.example.com
  http:
  - match:
    - uri:
        prefix: /train
    route:
    - destination:
        host: train-svc.ack-gpu-a.svc.cluster.local
  - match:
    - uri:
        prefix: /infer
    route:
    - destination:
        host: infer-svc.tke-gpu-b.svc.cluster.local

效果：零 DNS 切换，灰度发布只需修改 VirtualService，RTT < 2ms。

---

7. 统一监控：Prometheus 聚合多集群 Metric

Kurator 内置 Thanos Receiver 模式：

apiVersion: v1
kind: Secret
metadata:
  name: thanos-object-storage
stringData:
  thanos.yaml: |
    type: S3
    config:
      bucket: "kurator-metrics"
      endpoint: "oss-cn-shanghai.aliyuncs.com"

看板示例：

• GPU 利用率热图
• 跨集群 Pod 网络 RTT
• 训练 Job 完成速率

价值：无需自建 Thanos，Kurator 一键即得，存储成本 ↓ 60%。

---

8. 踩坑复盘与解决方案

问题	现象	根因	解决
Karmada 分发失败	Job 状态一直 Pending	集群版本差异 1.24 vs 1.26	使用 OverridePolicy 统一镜像字段
GPU 插件启动慢	逻辑卡未上报	device-plugin 被打到 master	加入 tolerations
Istio Sidecar 注入失败	Pod 一直 0/2	Webhook 网络策略阻断	放行 15017 端口
监控缺失	GPU 温度无数据	node-exporter 无 GPU label	自定义 ServiceMonitor

---

9. 收益与展望

业务收益：

• 交付周期：从 2 周 → 2 天（80% 提速）
• GPU 利用率：42% → 78%，成本节省 35 万/年
• 故障恢复：跨集群漂移 < 30s，SLA 达 99.9%

社区价值：

• 已向 Kurator 社区提交 3 个 PR（GPU 插件 Helm 化、Volcano 子 Chart 解耦、Karmada OverridePolicy 样例）
• 被社区评为 2024 H1 Excellent Contributor

下一步：

• 接入 Volcano 的 ElasticQuota 实现多租户弹性限额
• 探索 Kurator 的 Edge 能力，将 GPU 节点下沉到边缘机房

---

10. 开源地址 & 参考

• 完整 Helm Charts & 工作流 JSON：kurator-gpu-ai
• Kurator 官方文档：https://kurator.dev
• Karmada 官方示例：https://karmada.io

---

结语

从「一键舰队」到「GPU 共享」，从「统一流量」到「聚合监控」，
Kurator 让我真正体会到：告别繁琐，一栈统一 不是口号，而是触手可及的生产力。
40 分钟搭建多集群平台，2 天交付 AI 训练环境——这正是云原生「实战派」该有的样子。

愿下一位读到这篇文章的你，也能用 Kurator 点亮属于自己的「星空舰队」。

转载自：https://blog.csdn.net/u014727709/article/details/155227514
欢迎 👍点赞✍评论⭐收藏，欢迎指正