【前瞻创想】搞定多云边缘协同，从此告别如山压力的运维脱发烦恼

海心焱

873人浏览 · 2025-12-20 22:22:18

海心焱 · 2025-12-20 22:22:18 发布

【前瞻创想】搞定多云边缘协同，从此告别如山压力的运维脱发烦恼

今天不跟你们扯杂七杂八的东西，咱们直接来点干货。你知道现在搞云原生最头疼的是啥吗？不是集群搭不起来，而是集群太多、太散，一会儿在云上，一会儿在边缘端，管理起来简直要命。Kurator 这玩意儿，说白了就是咱们运维人的“瑞士军刀”。它不是一个单一的工具，而是一个整合了多云、边缘、调度和监控的开源平台。它就像个大管家，把你那些散落在各地的 K8s 集群、甚至只有几个 G 内存的边缘设备，统统给你管得服服帖帖。咱们今天就从实操的角度，把它的底裤……啊不，底层逻辑给扒一遍。

第一章：先别废话，先把环境搭起来再说

咱们既然是实操文，就不能光说不练。要玩转 Kurator，第一步肯定是得先把本地环境给弄好。很多兄弟在这一步就卡壳了，其实没那么复杂。

1.1 源码拉取与初次见面

听我的，别去到处找什么乱七八糟的压缩包，直接去官方库拉代码，这样才能保证你拿到的是热乎的、没被篡改的版本。打开你的终端，咱们先把 Kurator 的仓库给克隆下来。这一步是基础中的基础，后续所有的配置模版、示例代码都在这里面。

执行下面这个命令：

# 兄弟们，找个干净的目录，直接把仓库拉下来
# 这一步网络不好可能稍微要等会儿
git clone https://gitcode.com/kurator-dev/kurator.git

cd kurator
# 进去之后最好切到一个稳定的 release 分支，别直接用 main 分支在生产环境搞
# git checkout v0.6.0  <-- 举个例子，按需操作
echo "Kurator 代码库已就位，准备开干！"

如果显示下面的问题
在这里插入图片描述
表示没用设置git代理，我们可以先设置git代理；先看一下电脑上的代理端口

再设置git的代理端口，设置成本地代理

git config --global http.proxy http://127.0.0.1:7890

然后再拉取

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

在这里插入图片描述
就可以拉取资源了，当然也可以换源，你们可以试试

1.2 依赖检查与本地集群准备

代码下来了，你得准备个底座。通常我们在测试环境或者为了快速上手，Kind 或者 Minikube 是必不可少的。Kurator 本身是运行在 K8s 之上的“元集群”管理工具。你需要确保你的 Docker 已经跑起来了，而且 Helm 也要装好，因为 Kurator 的很多组件部署是依赖 Helm Chart 的。

这就好比你要盖房子，地基（K8s）得先打好，Kurator 就是那个盖房子的工程队。先把 kind create cluster 跑起来，或者用你现有的测试集群，把 ~/.kube/config 配置好，咱们就可以进入正题了。

第二章：从中心到边缘，KubeEdge 与部署架构的那些事儿

环境搭好了，咱们先聊聊最棘手的场景——边缘计算。很多公司现在的业务不仅在机房，还在路边的摄像头里、工厂的机械臂上。这时候，Kurator 整合的 KubeEdge 就派上大用场了。

2.1 KubeEdge 的详细架构剖析

这是KubeEdge的详细架构参考图，展示了云端核心组件、边缘节点及其与设备之间的完整管理、通信与应用部署链路：在这里插入图片描述

咱们得知道，KubeEdge 之所以牛，是因为它把 K8s 的能力无缝延伸到了边缘。在 Kurator 的视野里，KubeEdge 的架构分为“云端（CloudCore）”和“边缘端（EdgeCore）”两部分。

在云端，CloudCore 就像是一个接线员，它监听 K8s 的 API Server，把云端的指令（比如“给我起个 Pod”）拦截下来。它里面有个组件叫 EdgeController，专门负责把这些指令同步给边缘。还有一个 CloudHub，这是个 WebSocket 的服务端，专门等着边缘节点来建立长连接。

到了边缘端，EdgeCore 可是个全能选手。它里面有个 EdgeHub，负责跟云端的 CloudHub 连线，收发消息。最绝的是它还有个 MetaManager，这玩意儿是个本地数据库（SQLite），它会把云端发来的配置存下来。为啥要存？因为边缘网络不稳定啊！万一断网了，边缘节点靠着 MetaManager 里的缓存，照样能干活，这叫“离线自治”。最后，Edged 就像是个轻量级的 Kubelet，负责真正的拉起容器。

2.2 真实的云边协同应用部署架构

这张图展示了云边协同应用的部署架构，从设备层到边缘层、企业层再到产业平台，层层联动，实现工业数据在本地和云端的高效协同处理，支持智能制造和数字化转型：在这里插入图片描述

懂了架构，那应用咋部署？在 Kurator 的体系下，云边协同部署架构是非常优雅的。

你不需要登录到那个远在千里之外的边缘盒子上敲命令。你只需要在 Kurator 管理的中心云集群里操作。Kurator 会利用 KubeEdge 的通道，将应用下发。

在这个架构里，通常会有一个“云边通道”。你的应用可能包含两部分：一部分是跑在云端的“大脑”（比如数据分析服务），另一部分是跑在边缘的“手脚”（比如数据采集服务）。Kurator 允许你定义这种跨地域的部署策略。你可以给边缘节点打上标签，比如 location=factory-1，然后在 Deployment 里写上 NodeSelector。Kurator 会确保这些“手脚”精准地落在指定的边缘节点上，而“大脑”则留在云端，两者通过 KubeEdge 提供的边云通信机制进行数据交互。

第三章：算力不够智商凑，Volcano 的调度艺术

搞定了边缘，咱们再聊聊算力。现在的业务，动不动就是 AI 训练、大数据分析，原生的 K8s 调度器在处理这种批量计算（Batch Job）时，稍微有点“力不从心”。这时候，Kurator 里的 Volcano 就登场了。

3.1 Volcano 调度架构深度解读

这是Volcano调度架构参考图，展示了其核心组件如何通过CRD、控制器和调度器协同工作，实现对批量计算作业的统一管理：在这里插入图片描述

Volcano 是专门为高性能计算场景设计的。它的调度架构跟默认调度器最大的不同在于，它支持 Gang Scheduling（帮派调度）。

这是啥意思呢？举个例子，你要跑一个 TensorFlow 的分布式训练，需要 10 个 Pod 同时跑起来才能干活。如果资源只够起 8 个，默认调度器会先把这 8 个起起来，剩下 2 个干等。结果是啥？这 8 个占着茅坑不拉屎，作业跑不起来，资源还被锁死了。

Volcano 的调度架构里，有一个 Cache 机制同步集群状态，然后通过 Session 将调度周期隔离。最核心的是它的 Action（动作）和 Plugin（插件）机制。在调度时，它会看：这 10 个 Pod 能不能凑齐？如果凑不齐，一个都不发；如果能凑齐，就“全员出击”。这就是 Gang Scheduling。此外，它还有 DRF（主导资源公平调度）算法，防止某个大作业把集群资源全吞了。

3.2 Volcano 的应用场景

这是Volcano的应用场景参考图，展示了它如何作为统一调度平台，支撑AI训练、大数据及科学计算等多种分布式工作负载：在这里插入图片描述

这玩意儿主要用在哪？

AI/机器学习训练：像我刚才说的，TFJob、PyTorchJob，这种需要多节点协同的，Volcano 是标配。
大数据处理：Spark、Flink 这种任务，Volcano 能更好地管理它们的资源队列。
高密度的科学计算：比如基因测序、气象模拟，这些任务对资源利用率要求极高，Volcano 的装箱策略能把节点塞得满满当当，不浪费一点 CPU。

来，给你们看个手搓的 Volcano Job 配置，感受下这种“帮派”调度的味道：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: training-job-demo
spec:
  minAvailable: 3 # 划重点：不到3个小弟我就不开工
  schedulerName: volcano
  queue: default
  tasks:
    - replicas: 1
      name: ps # 参数服务器
      template:
        spec:
          containers:
            - image: internal-registry/tensorflow:2.4
              name: ps-container
              command: ["sh", "-c", "python ps.py"]
    - replicas: 2
      name: worker # 干活的工人
      template:
        spec:
          containers:
            - image: internal-registry/tensorflow:2.4
              name: worker-container
              command: ["sh", "-c", "python worker.py"]

第四章：统管全局的大管家，Fleet 与 Kurator 的自动化流程

当你的业务既有云、又有边，还需要跑 AI 任务时，你手里的集群可能已经有十几个了。这时候如果不引入 Fleet，你估计得开十几个终端窗口切换着玩。

4.1 Fleet 核心架构与 Fleet 架构全貌

这是Fleet的核心架构图，展示了其如何基于Bundle定义和集群分组实现多集群应用的分发、同步与状态追踪：在这里插入图片描述

Fleet 是 Kurator 用来做多集群管理的核心组件。它的架构非常有意思，它把“集群”当成“资源”来管。

Fleet 的核心架构基于 GitOps 理念。它由两部分组成：

Fleet Controller：跑在主集群（Host Cluster）里。它负责监听你写的“资源包（Bundle）”。
Fleet Agent：跑在每一个被纳管的子集群（Member Cluster）里。

Fleet 的整体架构是这样的：你在 Git 仓库里定义好你的应用 YAML。Fleet Controller 发现了更新，会生成一个 Bundle。然后，它根据你定义的策略（比如“所有带 env=prod 标签的集群”），将这个 Bundle 映射成 BundleDeployment。各个子集群里的 Agent 就像勤劳的小蜜蜂，主动连上主集群，拉取属于自己的配置，并在本地生效。这种架构的好处是，主集群不需要知道子集群的 API Server 地址，甚至子集群在防火墙后面也没关系，只要 Agent 能连出网就行。

4.2 Kurator CI/CD 的完整流程

有了 Fleet 做分发，Kurator 的 CI/CD 流程就顺滑了。
整个流程是这样的：

代码提交：开发人员把代码推到 GitLab/GitHub。
CI 构建：Tekton（Kurator 常用集成）感知到提交，开始跑单元测试，打 Docker 镜像，推到镜像仓库。
配置更新：CI 流程自动修改 Git 仓库里的 Helm Chart 版本号或者镜像 Tag。
CD 触发：Kurator 的 ArgoCD 或者 Fleet 组件感知到 Git 仓库的变化。
多云分发：根据 Fleet 的策略，新版本被自动同步到北京、上海、甚至美国机房的集群里。

4.3 Kurator Rollout 功能的架构

发布不是一锤子买卖，直接全量上线容易炸。Kurator Rollout 提供了渐进式交付的能力。
它的架构在应用和 K8s 原生 Deployment 之间加了一层。Rollout Controller 会接管流量。当你发布新版本时，它不会直接把旧的杀光。它会先切 5% 的流量给新版本（Canary 金丝雀发布），然后结合监控数据（比如 Prometheus 里的错误率）。如果错误率低，就自动加到 20%，直到 100%。如果中间出事了，秒级回滚。

这里必须要看一段 Fleet 的资源分发配置，这才是多集群管理的灵魂：

apiVersion: placement.fleet.cattle.io/v1alpha1
kind: ClusterResourcePlacement
metadata:
  name: global-app-deploy
spec:
  # 这一段决定了我们要把东西发给谁
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: production-app
      version: v1
  # 策略：发给所有打标 region=asia 的集群
  policy:
    clusterNames: []
    affinity:
      clusterAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: region
                  operator: In
                  values:
                    - asia

第五章：最后一眼，统一监控架构怎么搞

东西都跑起来了，瞎子摸象可不行。你得知道每个集群、每个边缘节点活得好不好。

5.1 Kurator 的统一监控架构

Kurator 采用的是一种 Federated Monitoring（联邦监控） 的架构思路，通常是 Prometheus + Thanos 的组合。

边缘与子集群侧：每个集群里都有一个本地的 Prometheus。它们负责采集本地的 Metrics（比如 CPU、内存、Pod 状态）。对于边缘节点，因为网络弱，这些数据会先在本地存一会儿。
数据传输侧：利用 Thanos Sidecar 或者 Remote Write 机制，将这些分散的数据汇聚或者暴露给中心。
中心侧（Global View）：在 Kurator 的管理集群，部署 Thanos Query 和 Thanos Store。当你查询“所有集群的 CPU 总用量”时，Thanos Query 会像查一个数据库一样，去各个子集群拉数据，然后聚合展示。

这套架构解决了两个痛点：一是数据存不下（Thanos 可以对接对象存储做长期归档），二是看不全（Global View 让你在一个 Grafana 面板看清全球基础设施）。