【探索实战】从混沌到统一：手把手带你用Kurator构建跨云多集群监控告警体系

引言：云原生时代的“甜蜜”与“烦恼”
当我们谈论云原生时，我们在谈论什么？是Kubernetes带来的极致弹性，是Istio实现的精细流量管控，还是Prometheus勾勒出的全栈可观测性？毫无疑问，这些技术栈共同构成了现代应用的基石。然而，当企业业务从“单云单集群”走向“多云多集群”、“云边协同”的分布式架构时，最初的“甜蜜”很快被现实的“烦恼”所取代：每一个集群都是一个孤岛，我们需要在每一个孤岛上重复部署、配置、管理一套几乎相同的组件。运维的复杂度不是线性增长，而是几何级爆炸。

而Kurator，正是为了终结这种混沌而生。

它并非又一个“造轮子”的项目，而是一个“组装引擎”，将Karmada、KubeEdge、Prometheus、Istio等业界顶级的轮子，精巧地组装成一辆能够驰骋在分布式云环境中的超级跑车。本文将聚焦于 “可观测性” 这一核心运维场景，带你从0到1，体验如何使用Kurator一键构建一个跨云跨地域的统一监控告警体系。

一、 场景与挑战：为什么我们需要Kurator？

假设你是一家AI科技公司的运维负责人，公司的业务架构如下：

• AWS集群 (aws-cluster)：部署在美国东部，承载主要的模型训练任务和在线推理服务，资源密集。

• 阿里云集群 (aliyun-cluster)：部署在华北地区，服务中国本土用户，满足数据合规要求。

• 边缘集群 (edge-cluster)：通过KubeEdge管理，部署在多个工厂车间，负责实时数据采集和边缘推理。

在没有Kurator之前，你的监控日常是这样的：

1. 部署三套Prometheus Stack：分别在三个集群中手动部署Prometheus、Grafana、Alertmanager，并确保配置一致。

2. 配置三份抓取任务：为每个Prometheus编写几乎相同的scrape_configs，管理三份配置。

3. 数据孤岛：查看监控数据需要在三个Grafana之间来回切换，无法获得全局视图。

4. 告警混乱：三个Alertmanager各自为战，可能产生重复告警，且难以实现全局的静默或路由策略。

5. 运维地狱：任何一个监控组件的版本升级、配置变更，都需要重复操作三次，极易出错。

我们的目标： 建立一个中心化的监控控制平面，能够一键下发监控配置，汇聚所有集群的指标数据，并实现统一的告警管理。

二、 实战演练：Kurator一键构建统一监控平台

接下来，让我们用Kurator来解决上述所有挑战。

第一步：环境准备与Kurator安装

首先，你需要一个已经存在的Kubernetes集群作为主集群（Host Cluster），它将运行Kurator的控制面。

bash

# 1. 使用helm安装Kurator
helm repo add kurator https://kurator.dev/helm-charts
helm repo update
helm install kurator kurator/kurator --namespace kurator-system --create-namespace

# 2. 验证安装
kubectl get pods -n kurator-system

你应该能看到类似kurator-controller-manager的Pod在运行，这标志着你的Kurator控制平面已经就绪。

第二步：构建“舰队（Fleet）”——统一管理的基石

Fleet是Kurator的核心概念，它是一组Kubernetes集群的逻辑抽象。我们将上述三个集群加入到同一个Fleet中。

首先，创建一个Fleet配置文件 my-global-fleet.yaml：

yaml

# my-global-fleet.yaml
apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: global-fleet
  namespace: default
spec:
  clusters:
    - name: aws-cluster
      kind: AttachedCluster # 表示这是一个已存在的、被接入的集群
      kubeconfig: # 引用访问aws集群的kubeconfig secret
        secretRef:
          name: aws-cluster-kubeconfig
    - name: aliyun-cluster
      kind: AttachedCluster
      kubeconfig:
        secretRef:
          name: aliyun-cluster-kubeconfig
    - name: edge-cluster
      kind: AttachedCluster
      kubeconfig:
        secretRef:
          name: edge-cluster-kubeconfig

在应用此配置前，确保你已提前将三个集群的kubeconfig创建为Secret：
kubectl create secret generic aws-cluster-kubeconfig --from-file=value=./aws-kubeconfig.yaml

应用Fleet配置：

bash

kubectl apply -f my-global-fleet.yaml

执行后，Kurator会利用Karmada的能力，在背后自动将这三个集群纳管起来。你可以通过kubectl get fleet和kubectl get attachedclusters来查看纳管状态。

第三步：声明式部署全局监控栈

这是最具魔力的一步。我们不需要分别去三个集群操作，只需要在主集群声明我们的期望状态。

创建 fleet-monitoring-stack.yaml：

yaml

# fleet-monitoring-stack.yaml
apiVersion: fleet.kurator.dev/v1alpha1
kind-: Application
metadata:
  name: global-monitoring
  namespace: default
spec:
  fleet: global-fleet # 指定部署到哪个舰队
  policy:
    placement:
      clusterTolerations:
        - key: cluster-type # 假设我们给边缘集群打上了污点
          operator: Equal
          value: edge
          effect: NoSchedule
    override:
      - op: add
        path: "/spec/template/spec/values"
        value: |
          prometheus:
            prometheusSpec:
              resources:
                requests:
                  memory: 512Mi
                  cpu: 300m
          grafana:
            resources:
              requests:
                memory: 256Mi
                  cpu: 100m
  template:
    spec:
      source:
        helm:
          repository: https://prometheus-community.github.io/helm-charts
          chart: kube-prometheus-stack
          version: "55.0.0"
      sink:
        extraResources:
          - apiVersion: v1
            kind: ConfigMap
            metadata:
              name: thanos-sidecar-config
            data:
              thanos.yaml: |
                type: SIDECAR
                http:
                  port: 10902
                grpc:
                  port: 10901
                objstore:
                  type: FILESYSTEM
                  config:
                    directory: "/var/thanos"

让我们来解析这个配置的精妙之处：

1. fleet: global-fleet： 指明这个Application要安装到我们刚刚创建的global-fleet中的所有集群。

2. policy.placement： 这是Kurator基于Karmada提供的差异化部署能力。我们通过clusterTolerations告诉调度器，即使edge-cluster有污点，也要将监控栈调度上去，但可以容忍。

3. policy.override： 这是配置覆写能力。我们针对所有集群，统一修改了Prometheus和Grafana的资源请求，确保在资源受限的边缘节点上也能稳定运行。你甚至可以针对不同的集群做不同的覆写，例如为AWS集群分配更多资源。

4. template： 定义了我们要部署的应用。这里我们使用Helm Chart，指定了kube-prometheus-stack。

5. sink.extraResources： 这是Kurator的一个强大特性，允许你在部署主Chart的同时，注入额外的Kubernetes资源。这里我们创建了一个ConfigMap，为后续集成Thanos做准备。

应用这个Application：

bash

kubectl apply -f fleet-monitoring-stack.yaml

此时，Kurator会驱动Karmada，将Prometheus Stack的部署工作流下发到三个成员集群中。你只需一条命令，就完成了过去需要重复三次的复杂部署。

第四步：集成Thanos，实现指标联邦与全局查询

现在，每个集群都有了独立的Prometheus，但数据仍是孤立的。我们需要Thanos来构建中心化的查询层。

我们在主集群部署Thanos Query。Thanos Query可以通过Kurator发现Fleet中所有集群的Prometheus Sidecar。

yaml

# thanos-query.yaml
apiVersion-: apps/v1
kind: Deployment
metadata:
  name: thanos-query
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: thanos-query
  template:
    metadata:
      labels:
        app: thanos-query
    spec:
      containers:
      - name: thanos-query
        image: thanosio/thanos:v0.35.0
        args:
        - query
        - --http-address=0.0.0.0:10902
        - --grpc-address=0.0.0.0:10901
        - --store=dnssrv+_grpc._tcp.prometheus-operated.monitoring.global-fleet-clusters.svc.cluster.local
        ports:
        - containerPort: 10902
        - containerPort: 10901

注意--store参数：Kurator和Karmada会为Fleet内的服务创建对应的DNS记录，Thanos Query可以通过这个DNS SRV记录自动发现所有集群中的Prometheus Thanos Sidecar。

现在，你只需要在主集群的Grafana中，将数据源指向http://thanos-query:10902，就可以在一个Grafana界面中，无缝查询来自AWS、阿里云、边缘任何一个集群的监控指标了！

第五步：统一告警管理

我们可以利用类似的思路，在主集群部署一个中心的Alertmanager。然后通过配置覆写，将所有成员集群中Prometheus的externalUrl指向这个中心的Alertmanager。

yaml

# 在Application的override部分添加
- op: add
  path: "/spec/template/spec/values/prometheus/prometheusSpec/alerting/alertmanagers/0"
  value:
    static_configs:
      - targets:
        - "central-alertmanager.monitoring.svc:9093"

这样，所有告警都将汇聚到一处，便于进行全局的告警去重、静默和路由（例如，根据集群标签，将不同严重程度的告警发送到不同的钉钉/Slack频道）。

三、 深度剖析：Kurator带来的范式转移

通过以上实战，我们不仅仅完成了一个工具的使用，更体验了一种运维范式的转移。

1. 从“操作式”到“声明式”：我们不再关心“如何做”（How），即不再需要手动登录各个集群执行kubectl或helm命令；我们只关心“做什么”（What），即声明“我的全球舰队都需要一个监控栈”。Kurator负责让现实符合期望。

2. 从“碎片化”到“一体化”：Kurator通过Fleet概念，将物理上分散的集群，在逻辑上整合为一个庞大的“超级集群”。运维的粒度从“单个集群”提升到了“业务舰队”。

3. “配置即代码”的终极实践：整个分布式云原生平台的架构状态，包括集群纳管、应用部署、配置差异，都可以用YAML文件描述并纳入Git版本库。这为基础设施带来了可追溯性、可重复性和自动化能力。

4. 生态整合而非替代：Kurator的成功，高度依赖于其底层整合的顶级项目（Karmada for 调度，KubeEdge for 边缘，Prometheus for 监控等）。它的价值在于提供了最佳实践的内聚和抽象，降低了用户直接组合使用这些复杂技术的门槛。

四、 总结与展望

在本实战中，我们以“统一监控”这个具体场景为切入点，深入体验了Kurator在舰队管理、统一应用分发、差异化配置方面的强大能力。你会发现，基于同样的模式，你可以轻松地将这套方法论复制到统一流量治理（Fleet内Istio网格的构建）、统一安全策略等任何场景。

Kurator代表的是一种面向未来的云原生管理理念。在企业数字化转型深入骨髓的今天，业务的分布式形态已成定局。Kurator所提供的这套“一栈统一”的框架，正是帮助企业从云原生技术中获得最大价值，同时将管理复杂度降至最低的关键利器。