一、企业云原生面临的挑战：从单集群到多云多集群的基础设施重构

随着云原生技术的广泛应用，企业在追求业务数字化转型的过程中，逐步从传统的 IT 基础设施向云原生架构迁移，尤其是在 DevOps 和平台工程的推动下。我们面临的主要挑战包括：

• 集群管理的复杂性
  传统的 Kubernetes 集群管理通常局限于单集群场景，但在现实中，越来越多的企业面临跨云、多集群的管理需求，包括多个公有云平台（如 AWS、Azure、GCP），以及企业自建数据中心的混合部署。

• DevOps 敏捷性与运维治理的平衡
  DevOps 强调快速迭代和持续交付，但同时，企业的运维团队需要确保应用交付的质量、安全性以及合规性。如何在保证敏捷性的同时，实现稳定的集群治理、监控和策略管理，是 DevOps 实践中的关键问题。

• 跨环境应用的管理与部署
  在云原生架构中，跨环境部署（开发、测试、生产）与跨区域部署（全球多区域）成为常态。如何保证跨环境、跨集群的一致性、可扩展性以及可靠性，变成了企业在应用交付过程中不可忽视的难题。

在这样的背景下，我们开始探索如何借助 Kurator 提供的一套分布式云原生平台解决方案，来应对上述挑战，提升企业的运维能力和交付效率。

二、技术选型与架构设计：为什么选择 Kurator 作为平台建设的底座？

在寻找合适的解决方案时，我们对比了多个开源项目和商业平台，最后决定选择 Kurator，主要考虑到以下几个方面：

2.1 Kurator 核心优势：面向分布式云原生控制平面的高效抽象

1. Fleet 作为多集群管理的核心抽象
   Kurator 的最大优势之一是其 Fleet 设计，能够将多个 Kubernetes 集群抽象为一个统一的管理域，这对于跨云、跨地域、多集群场景尤为重要。在这种架构下，所有集群都可以被视为一个大规模的云原生平台，从而简化了集群管理的复杂性，支持统一的监控、日志、流量治理、应用发布等操作 。

2. GitOps 与 DevOps 的完美结合
   Kurator 的集成非常友好地支持 GitOps，通过 Application 和 Rollout 对象来管理应用的生命周期，结合 Git 仓库作为唯一真理源，支持自动化的配置同步和版本控制。这与 DevOps 的敏捷交付理念高度契合，能够提供跨云、跨集群的部署与回滚能力 。

3. 开源与标准化的生态整合
   Kurator 本身依赖于 Kubernetes 和其他成熟的开源项目（如 Istio、Prometheus、Kyverno、FluxCD 等），确保了高可定制性与可靠性，同时又避免了“重造轮子”的问题。在保证业务快速迭代的同时，Kurator 也能确保企业的运维能力不被牺牲 。

2.2 针对企业需求定制的多云架构

在多云环境下，Kurator 提供的 Fleet 和 AttachedCluster 功能，能够帮助我们将多个云环境中的 Kubernetes 集群统一纳管，并通过声明式的 CRD 对集群、应用、流量、策略等进行全局管理和控制。

我们为企业平台设计的基础架构大致如下：

• 控制平面（Control Plane）：一个主控集群，负责管理和调度下游集群。
• 多个子集群（Member Clusters）：分布在公有云（AWS、Azure、GCP）和私有云/本地数据中心中的 Kubernetes 集群。
• Fleet：将同类集群归类到一个逻辑分组（如生产、开发、测试），并统一应用部署与流量治理。

三、企业平台构建的关键技术实践

通过使用 Kurator，我们实现了以下几个关键技术实践：

3.1 统一集群管理：Fleet + AttachedCluster 的全局视图

在实际使用中，Kurator 的 Fleet 和 AttachedCluster 提供了强大的多集群管理能力。我们通过以下步骤将多个集群纳入统一控制面：

1. 创建集群的 CRD
   每个集群（无论是公有云还是私有云）都通过 AttachedCluster CRD 纳入管理。下面是一个示例配置：

   apiVersion: cluster.kurator.dev/v1alpha1
   kind: AttachedCluster
   metadata:
     name: aws-prod-cluster
     namespace: kurator-fleet
   spec:
     kubeconfig:
       name: aws-prod-kubeconfig
       key: config
   

2. 创建 Fleet
   我们定义了多个 Fleet，每个 Fleet 对应一个业务域或集群组。以下示例配置了一个包含多个公有云集群的 Fleet：

   apiVersion: fleet.kurator.dev/v1alpha1
   kind: Fleet
   metadata:
     name: fleet-prod
     namespace: kurator-fleet
   spec:
     clusters:
       - name: aws-prod-cluster
         kind: AttachedCluster
       - name: azure-prod-cluster
         kind: AttachedCluster
     plugin:
       metric:
         thanos:
           objectStoreConfig:
             secretName: thanos-config
       policy:
         kyverno:
           podSecurity:
             standard: restricted
             validationFailureAction: Enforce
   

   在这个配置中，Fleet-prod 将 aws-prod-cluster 和 azure-prod-cluster 这两个公有云集群纳入统一管理，并启用了监控与安全策略。

3.2 应用交付与 CI/CD：GitOps + Rollout 实现持续交付

在应用交付方面，Kurator 使用 GitOps 模型，通过 Application 对象将 Git 仓库和 Kubernetes 集群之间建立桥梁，确保所有变更都可以被追踪和管理。以下是我们为一个服务（如 payment-gateway）定义的 GitOps 配置：

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: payment-gateway
  namespace: kurator-fleet
spec:
  source:
    gitRepository:
      url: https://git.example.com/payment-gateway.git
      ref:
        branch: main
      interval: 5m
  syncPolicies:
    - name: prod-aws
      destination:
        fleet: fleet-prod
      kustomization:
        path: ./deploy/overlays/aws-prod
        targetNamespace: payment
        prune: true
    - name: prod-azure
      destination:
        fleet: fleet-prod
      kustomization:
        path: ./deploy/overlays/azure-prod
        targetNamespace: payment
        prune: true

通过上述配置，payment-gateway 应用会自动从 Git 仓库同步到 prod-aws 和 prod-azure 两个集群，而整个流程实现了自动化、审计和回滚的功能。

具体可参考如下架构图：

3.3 实现渐进式发布与自动回滚

为了确保在多个环境和集群之间发布应用时能够确保安全性和质量，我们使用了 Rollout 配置来实现渐进式发布（如金丝雀发布）。以下是 payment-gateway 的 Rollout 示例：

apiVersion: rollout.kurator.dev/v1alpha1
kind: Rollout
metadata:
  name: payment-gateway-rollout
  namespace: payment
spec:
  workload:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-gateway
  traffic:
    provider: istio
    host: payment.api.example.com
    port: 443
  strategy:
    canary:
      steps:
        - weight: 5
        - weight: 15
        - weight: 30
        - weight: 50
      analysis:
        interval: 2m
        metrics:
          - name: error-rate
            type: prometheus
            query: |
              sum(rate(http_requests_total{app="payment-gateway",code=~"5.."}[5m])) /
              sum(rate(http_requests_total{app="payment-gateway"}[5m]))
            threshold:
              max: 0.02
      autoPromotionEnabled: true
      autoRollbackEnabled: true

通过这个 Rollout 配置，payment-gateway 在逐步发布时会根据错误率等指标进行动态调整，一旦出现异常，系统将自动回滚。

3.4 多集群监控：统一 Prometheus + Thanos 集中管理

为了提供跨集群的统一监控，我们使用 Prometheus + Thanos 进行多集群监控指标的聚合。在 Kurator 中，我们可以通过插件配置 Thanos 和 Grafana 来实现这一目标：

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: fleet-monitoring
  namespace: kurator-fleet
spec:
  clusters:
    - name: aws-prod-cluster
      kind: AttachedCluster
    - name: azure-prod-cluster
      kind: AttachedCluster
  plugin:
    metric:
      thanos:
        objectStoreConfig:
          secretName: thanos-config
      grafana:
        enabled: true

通过这个配置，所有在 fleet-monitoring 中的集群都将自动启用 Thanos 来聚合和存储 Prometheus 指标，并在 Grafana 中进行统一展示。

当然，感兴趣的同学可前往直接克隆代码，体验一波。

四、总结：Kurator 为企业云原生平台的演进提供了强大支撑

通过在企业平台中的实际落地实践，Kurator 展现了它在多云、多集群、GitOps、DevOps、以及安全策略治理等方面的强大能力。我们通过 Fleet、AttachedCluster、Application、Rollout 等核心组件的灵活使用，实现了：

1. 统一管理和高效编排：将多个集群视为一个 Fleet，简化了跨云、跨集群的运维管理；
2. 敏捷与合规并行：通过 GitOps 和 Rollout 模型，实现了敏捷交付的同时，确保了合规性与回滚能力；
3. 跨集群的可观测性：利用 Thanos 和 Grafana 统一监控全局指标，增强了系统的可观测性与可维护性；
4. 安全策略的一致性：通过 Kyverno 实现跨集群统一的安全策略，并能快速响应合规需求。

对企业平台工程的启示

Kurator 不仅仅是一个工具，它代表了一种面向数字化转型、DevOps、平台工程的思维方式。在未来的多云环境中，Kurator 有潜力成为我们平台工程的基石，提供高效、可扩展、安全的分布式云原生平台。

…

(未完待续)