Kurator 云边协同与多集群治理实操指南
近年来，云原生领域'多云'与'边缘计算'概念普及迅速，但实际落地案例较少。实施难度较大，光是一个 K8s 就够复杂，再涉及多集群编排、边缘设备接入及批量计算，挑战更多。Kurator 项目整合了业界最强的开源组件，提供统一 API 操作，无论是数据中心服务器还是边缘设备，均可通过一套逻辑管理。
本文从环境搭建到流量治理、算力调度，详细介绍 Kurator 的实操应用。
第一部分：环境搭建
源码安装与环境准备
建议直接使用源码安装，便于理解配置和修改。机器上需准备 Go 环境和 Docker。将 Kurator 代码克隆到本地。
git clone https://github.com/kurator-dev/kurator.git
资源文件下载后，确认版本信息（如 0.6.0）。环境拉取后，准备一个主集群（Host Cluster），通常使用 Kind 或 Minikube 启动，然后将 Kurator 的 Operator 部署上去。这一步完成后，即拥有控制平面。
GitOps 落地方案
Kurator 原生支持 GitOps，核心是'一切皆代码'。底层集成 FluxCD 能力并做封装，无需编写复杂 Flux CRD。在 Kurator 配置文件中指定应用配置所在的 Git 仓库分支即可。
Kurator Controller 周期性扫描 Git 仓库。一旦提交新代码或配置，自动同步到目标集群。在多集群环境下，只需修改 Git 仓库，多个集群即可自动同步更新。
CI/CD 流水线构建
Jenkins 或 GitLab CI 负责前半段——代码构建、单元测试、打 Docker 镜像推送到仓库，同时更新 Git 仓库中的 Manifest 文件（如修改 Deployment 的 image tag）。
后半段交给 Kurator。Kurator 监控到 Manifest 变化，自动触发同步。Kurator 还支持 Tekton 等云原生流水线工具，可定义 Pipeline 对象，将源码拉取、镜像构建、部署上线定义为 K8s 资源对象，由 Kurator 统一调度。
第二部分：云边协同架构与网络排查
KubeEdge 核心组件
KubeEdge 在 Kurator 中主要分两头：云端（CloudCore）和边端（EdgeCore）。
- CloudCore：运行在中心机房，监听 K8s API Server，检测是否有新 Pod 调度到边缘节点。如有，通过 WebSocket 通道发送指令。
- EdgeCore：运行在树莓派或工控机上，轻量级 Kubelet，去除 Docker 不常用功能，内存占用低。负责接收云端指令，拉起容器，并将边缘设备状态汇报给云端。
两者配合关键在于容忍'弱网'。断网时，EdgeCore 将数据存于本地数据库，待网络恢复后重发。
隧道机制与网络连通性
边缘节点通常在防火墙后或仅有内网 IP，云端访问需借助隧道机制。Kurator 利用 KubeEdge 隧道技术（基于 WebSocket 或 QUIC 协议），建立从边缘主动连接云端的长连接。运维人员查看边缘容器日志或进入容器时，数据流走反向隧道。
网络连通性排查步骤：
- 检查边缘节点
edgecore日志，搜索connection refused等报错。 - 验证边缘节点能否解析云端域名。
- 确认云端端口（默认 10000 和 10002）未被安全组封锁。
- 若隧道建立但数据不通，检查 MTU 问题，特别是经过 VPN 或专线时。
云边协同计算场景
常见应用场景包括：
- AI 推理下沉：模型训练在云端，训练完成后通过 Kurator 推送至边缘摄像头进行人脸识别，实现低延迟。
- 数据预处理：工厂传感器产生海量数据，直接在边缘部署 Flink 或 Python 脚本清洗聚合，仅将结果上传云端，节省带宽。
第三部分：Fleet 舰队与多集群管理
身份映射机制
多集群访问外部资源（如 AWS S3 或阿里 OSS）时，避免在每个集群埋入 Access Key。Kurator 提供身份映射机制，利用 Workload Identity 概念。在管理平面统一配置身份策略，指定 Fleet 中特定命名空间的 Pod 自动映射为云服务商 IAM 角色。Pod 启动时，Kurator 注入临时 Token，应用无需硬编码密钥，符合企业级安全合规要求。
命名空间相同性
多集群追求命名空间相同性（Namespace Sameness）。集群 A 的 prod 命名空间与集群 B 的 prod 命名空间被视为同一逻辑隔离域。Kurator 通过抽象，使网络策略或服务发现规则跨集群生效。例如，配置规则允许 prod 命名空间下的服务互相访问，无论物理集群位置，Kurator 底层自动下发跨集群防火墙规则。
FluxCD Helm 应用工作流程
多集群下 Helm 应用流程：
- Source Controller：从 Git 仓库拉取 Helm Chart 定义。
- Kustomize Controller（可选）：对 Chart 进行 Overlay 修改（如不同区域使用不同 values.yaml）。
- Helm Controller：生成
HelmRelease对象。 - Kurator 将
HelmRelease分发到目标集群。支持推模式（管理面推送）和拉模式（子集群 Agent 拉取），大规模场景推荐拉模式以减轻控制面压力。
第四部分：流量路由与 Volcano 算力调度
金丝雀发布配置
Kurator 集成 Istio 等服务网格能力，定义复杂的流量路由规则。例如金丝雀发布，新版本仅允许特定用户访问。
以下 YAML 示例展示基于权重的流量切分配置：
apiVersion: networking.kurator.dev/v1alpha1
kind: TrafficRoute
metadata:
name: canary-demo
namespace: default
spec:
hosts:
- "myapp.example.com"
gateways:
- my-gateway
http:
- route:
- destination:
host: myapp
subset: v1
weight: 90 # 90% 的流量走老版本
- destination:
host: myapp
subset: v2
weight: 10 # 10% 的流量给金丝雀
headers:
request:
set:
x-canary-version: "v2" # 标记方便追踪日志
Kurator 控制器自动调整网关和 Sidecar 配置，监控大盘可见流量分流效果。
Volcano Job 与 PodGroup
大数据处理、基因测序或 AI 训练需依赖 Volcano。K8s 原生调度器对批处理任务支持有限，Volcano 引入三个核心概念：
- Job（作业）：任务本体，如 TensorFlow 训练任务。
- PodGroup（Pod 组）：Job 包含多个 Pod（如 1 个 PS，4 个 Worker）。这 5 个 Pod 必须同时运行。若资源不足，原生 K8s 可能先起部分导致死锁。PodGroup 告诉调度器：'要么一起上，要么都别上（All-or-Nothing）'。
- Queue（队列）：资源分配桶。可将集群资源切分为多个 Queue（如'研发部'30%，'生产部'70%），Job 提交到对应 Queue。
Volcano Job 配置示例：
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
name: tensorflow-training-job
spec:
minAvailable: 3 # 凑够 3 个 Pod 资源才调度
schedulerName: volcano
queue: research-queue # 提交到研发队列
tasks:
- replicas: 1
name: ps
template:
spec:
containers:
- command: ["python", "ps.py"]
image: tensorflow/tensorflow:1.15.2
name: ps
- replicas: 2
name: worker
template:
spec:
containers:
- command: ["python", "worker.py"]
image: tensorflow/tensorflow:1.15.2
name: worker
配置中 minAvailable: 3 隐含创建 PodGroup。若资源紧张，Volcano 挂起 Job 直到资源充足，避免碎片化。
总结
Kurator 解决了云原生运维中边缘网络、多集群一致性、批量计算调度等难题。它贴近实操，从源码安装到 Volcano 调度原理均有覆盖。建议在掌握理论后动手搭建测试环境，通过解决实际问题巩固知识。
