【前瞻创想】Kurator云原生套件实战指南：从环境搭建到多集群应用分发与智能调度深度解析

摘要

本文深入探讨Kurator云原生套件的技术架构、核心组件及实践应用，通过环境搭建、多集群管理、智能调度、GitOps发布等实战场景，全面解析Kurator如何整合Prometheus、Istio、Karmada、KubeEdge、Volcano等优秀开源项目，构建统一的分布式云原生平台。文章不仅涵盖技术细节，还结合实践经验分析Kurator的创新优势，并对未来分布式云原生技术发展方向提出建设性建议，为云原生技术从业者提供有价值的实践参考。

一、Kurator概述与核心价值

看这张图就知道什么是Kurator啦

1.1 什么是Kurator云原生套件

Kurator是一个面向分布式云原生场景的开源套件，它通过集成多个优秀的开源项目，为用户提供统一的多集群管理、应用分发、智能调度、边缘计算等能力。Kurator的核心价值在于解决了传统云原生技术在多集群、混合云、边缘计算等复杂场景下面临的碎片化问题，通过统一的控制平面和标准化的API，实现了跨集群、跨地域、跨云的应用管理。

Kurator不仅仅是一个工具集合，更是一个完整的云原生解决方案平台。它基于Kubernetes生态，通过深度整合Karmada、KubeEdge、Volcano、Istio等项目，构建了一个端到端的分布式云原生基础设施。这种集成不是简单的拼凑，而是通过统一的架构设计和API抽象，实现了各组件之间的无缝协作。

在实际生产环境中，企业往往面临多云、混合云、边缘计算等复杂场景，传统的单集群Kubernetes解决方案无法满足需求。Kurator通过提供统一的管理界面和标准化的操作流程，大大降低了分布式云原生的使用门槛，让企业能够专注于业务创新而非基础设施复杂性。

1.2 Kurator的架构设计理念

Kurator的架构图：

Kurator的架构设计遵循"分层解耦、统一控制、智能调度"的核心理念。整个架构分为四个主要层次：基础设施层、控制平面层、调度层和应用层。

基础设施层负责管理物理或虚拟的计算资源，包括公有云、私有云、边缘节点等。控制平面层是Kurator的核心，通过Fleet Manager统一管理多个集群，提供集群生命周期管理、资源监控、安全策略等功能。调度层基于Karmada和Volcano，实现跨集群的智能调度和批处理任务管理。应用层则通过GitOps、服务网格等技术，提供应用分发、流量管理、可观测性等能力。

这种分层架构设计使得Kurator具有高度的可扩展性和灵活性。每个层次都可以独立演进，同时通过标准化的接口保持相互协作。例如，当需要支持新的云提供商时，只需在基础设施层进行扩展，而不影响上层的应用逻辑。

Kurator的另一个重要设计理念是"声明式API"。所有资源管理都通过YAML配置文件进行声明，这使得整个系统具有可预测性、可审计性和可回滚性。这种设计与GitOps理念高度契合，为实现持续交付和自动化运维奠定了基础。

1.3 为什么选择Kurator解决分布式云原生挑战

在分布式云原生时代，企业面临诸多挑战：多集群管理复杂、应用分发困难、资源利用率低、边缘计算支持不足等。Kurator正是针对这些挑战而设计的解决方案。

首先，Kurator通过Karmada实现了真正的多集群管理，而不是简单的集群联邦。Karmada支持跨集群的自动故障转移、负载均衡、弹性伸缩等功能，大大提高了应用的可用性和资源利用率。其次，Kurator集成了KubeEdge，为边缘计算场景提供了完整的解决方案，解决了边缘节点离线、网络不稳定等难题。

在调度方面，Kurator通过Volcano提供了企业级的批处理调度能力，支持队列管理、资源预留、任务优先级等高级特性，特别适合AI/ML、大数据分析等工作负载。在网络层面，Istio的集成提供了强大的服务网格能力，实现了细粒度的流量管理、安全策略和可观测性。

选择Kurator的另一个重要原因是其开放性和社区活跃度。作为开源项目，Kurator拥有活跃的开发者社区和完善的文档体系。企业可以根据自身需求进行定制和扩展，而不受单一厂商的限制。这种开放性也保证了技术的持续创新和演进。

二、环境搭建与基础配置

2.1 使用wget命令获取Kurator源码

环境搭建是使用Kurator的第一步。首先，我们需要获取Kurator的源代码。这里使用wget命令从GitHub仓库下载最新的主分支代码：

用wget的方法拉取

# 下载最新源代码zip包
wget https://github.com/kurator-dev/kurator/archive/refs/heads/main.zip

然后解压这个文件就可以得到源码啦

unzip main.zip

拉取下来以后就可以使用啦

这个命令获取的是Kurator的最新开发版本，包含了所有核心功能和最近的改进。对于生产环境，建议使用稳定版本，可以通过指定tag来下载：

wget https://github.com/kurator-dev/kurator/archive/refs/tags/v0.5.0.zip

获取源码后，我们需要检查系统环境是否满足要求。Kurator对环境有以下基本要求：

• Kubernetes集群版本 1.20+
• Helm 3.8+
• Kubectl 1.20+
• Docker 20.10+

通过./scripts/check-env.sh脚本可以自动检查环境依赖，确保所有组件都已正确安装。

2.2 依赖环境准备与安装

在安装Kurator之前，需要准备相应的依赖环境。首先，确保已经有一个可用的Kubernetes集群，可以是本地的Minikube、Kind，也可以是云厂商提供的托管集群。

接下来，安装Helm并添加必要的仓库：

helm repo add kurator https://kurator-dev.github.io/charts
helm repo update

Kurator依赖于多个外部组件，包括Cert-Manager、Prometheus、Istio等。我们可以使用脚本一键安装这些依赖：

./scripts/install-dependencies.sh

这个脚本会自动检测系统环境，并安装所有必要的依赖组件。安装过程中，脚本会输出详细的日志信息，方便排查问题。

对于特定的组件，我们也可以手动安装。例如，安装Cert-Manager：

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.10.0/cert-manager.yaml

安装完成后，需要等待所有Pod都处于Running状态：

kubectl get pods -n cert-manager

三、Kurator核心组件深度解析

3.1 Fleet管理框架架构

Fleet是Kurator的核心组件之一，负责管理多个Kubernetes集群的生命周期和资源调度。Fleet的设计理念是"集群即资源"，将每个Kubernetes集群视为一个可管理的资源对象，通过统一的API进行操作。

Fleet架构包含三个主要组件：Fleet Controller、Cluster Manager和Resource Distributor。Fleet Controller负责监听Fleet资源的变化，根据策略创建和管理集群资源。Cluster Manager负责集群的注册、健康检查、版本升级等生命周期管理任务。Resource Distributor则负责将应用资源分发到目标集群。

Fleet的一个重要特性是支持集群分组。通过标签选择器，可以将多个集群划分为不同的组，每个组可以有不同的管理策略。例如，可以将生产集群和测试集群分组，应用不同的安全策略和资源配额。

Fleet还提供了集群状态的实时监控和告警功能。当集群出现异常时，Fleet会自动触发告警，并根据预设策略进行故障转移。这种自动化的故障处理机制大大提高了系统的可靠性和运维效率。

3.2 Karmada多集群调度集成

Karmada是Kurator集成的核心组件之一，专门用于多集群调度和管理。Karmada的核心价值在于实现了真正的应用级多集群管理，而不是简单的集群联邦。

Karmada的调度架构基于Kubernetes的标准调度器，但扩展了多集群调度的能力。它包含三个主要组件：karmada-scheduler、karmada-controller-manager和karmada-agent。karmada-scheduler负责跨集群的资源调度决策，karmada-controller-manager管理各种控制器，karmada-agent运行在成员集群中，负责与控制平面通信。

Karmada支持多种调度策略，包括：

• 副本调度：将应用副本分散到多个集群
• 主备调度：指定主集群和备集群
• 聚合调度：将应用聚合到特定集群
• 动态调度：根据集群负载动态调整

在Kurator中，Karmada的集成是通过CRD（Custom Resource Definition）实现的。用户可以通过Kurator的API直接操作Karmada资源，无需了解底层细节。例如，创建一个PropagationPolicy资源来定义应用的分发策略：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
meta
  name: nginx-propagation
spec:
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
    name: nginx
  placement:
    clusterAffinity:
      clusterNames:
      - cluster-1
      - cluster-2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightList:
      - targetCluster:
          clusterNames:
          - cluster-1
        weight: 2
      - targetCluster:
          clusterNames:
          - cluster-2
        weight: 1

这个策略将nginx应用的3个副本按照2:1的比例分配到两个集群中。

3.3 KubeEdge边缘计算支持

KubeEdge是Kurator集成的另一个重要组件，专门为边缘计算场景设计。KubeEdge解决了传统Kubernetes在边缘环境中的局限性，如网络不稳定、设备资源有限、离线操作等。

KubeEdge架构包含三个核心组件：CloudCore、EdgeCore和EdgeMesh。CloudCore运行在云端，负责与Kubernetes API Server通信，管理边缘节点的注册和状态。EdgeCore运行在边缘节点上，负责运行容器、管理设备、处理离线场景等。EdgeMesh提供边缘节点间的网络通信能力。

在Kurator中，KubeEdge的集成是通过EdgeCluster资源实现的。用户可以将边缘集群注册到Kurator中，享受统一的管理界面。例如，创建一个EdgeCluster资源：

apiVersion: edge.kurator.io/v1alpha1
kind: EdgeCluster
meta
  name: edge-cluster-1
spec:
  kubeconfigSecret: edge-cluster-1-kubeconfig
  edgeNodeSelector:
    zone: edge
  offlineStrategy:
    maxOfflineDuration: 24h
    autoRecovery: true

这个配置定义了一个边缘集群，指定了边缘节点的选择器和离线策略。当边缘节点离线超过24小时，系统会自动触发恢复流程。

KubeEdge在Kurator中的一个重要应用场景是物联网设备管理。通过KubeEdge的Device CRD，可以将物理设备抽象为Kubernetes资源，实现设备的统一管理和监控。例如，管理一个温度传感器：

apiVersion: devices.kubeedge.io/v1alpha2
kind: Device
meta
  name: temperature-sensor-1
spec:
  deviceModelRef:
    name: temperature-sensor-model
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
      - key: edge-node
        operator: In
        values:
        - edge-node-1
  twins:
  - propertyName: temperature
    desired:
      metadata:
        type: int
      value: "25"
    reported:
      meta
        type: int
      value: "24"

这种设备管理能力使得Kurator在工业物联网、智慧城市等领域具有广阔的应用前景。

四、高级调度与资源管理

4.1 Volcano批处理调度架构

Volcano调度架构如图所示：

Volcano是Kurator集成的批处理调度引擎，专门为AI/ML、大数据分析、科学计算等工作负载设计。与Kubernetes默认调度器相比，Volcano提供了更丰富的调度策略和队列管理能力。

Volcano的架构基于Kubernetes CRD，核心组件包括vc-scheduler、vc-controller-manager和vc-webhook。vc-scheduler是增强版的调度器，支持多种调度算法和策略。vc-controller-manager管理各种控制器，如Queue Controller、PodGroup Controller等。vc-webhook提供准入控制和验证功能。

Volcano的核心概念包括Queue、PodGroup和Job。Queue用于资源配额管理和多租户隔离，PodGroup定义任务的最小可用性要求，Job则是具体的任务定义。这种分层设计使得Volcano能够处理复杂的批处理工作负载。

在Kurator中，Volcano的集成是通过VolcanoJob CRD实现的。用户可以定义复杂的批处理任务，利用Volcano的高级调度能力。例如，创建一个AI训练任务：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
meta
  name: ai-training-job
spec:
  minAvailable: 4
  schedulerName: volcano
  queue: high-priority
  tasks:
  - replicas: 4
    name: worker
    template:
      spec:
        containers:
        - name: tensorflow
          image: tensorflow/tensorflow:latest-gpu
          resources:
            limits:
              nvidia.com/gpu: 1
              memory: 16Gi
            requests:
              cpu: 4
              memory: 8Gi
        nodeSelector:
          node-type: gpu

这个任务定义了一个需要4个GPU节点的AI训练作业，并指定了高优先级队列。Volcano会确保在所有worker Pod都可用的情况下才启动任务，避免部分失败导致的资源浪费。

4.2 Queue与PodGroup资源管理

Queue和PodGroup是Volcano的两个核心概念，在Kurator中发挥着重要作用。Queue用于资源配额管理和多租户隔离，PodGroup则用于定义任务的最小可用性要求。

Queue资源定义了队列的权重、资源配额和调度策略。在多租户环境中，不同的团队或项目可以分配不同的Queue，确保资源使用的公平性。例如，定义一个高优先级队列：

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
meta
  name: high-priority
spec:
  weight: 100
  capability:
    cpu: "100"
    memory: 200Gi
  reclaimable: true
  reservation:
    timeout: 10m

这个队列具有较高的权重（100），可以使用100个CPU和200GB内存，并且支持资源回收和保留。

PodGroup定义了任务的最小可用性要求和调度策略。它确保在满足最小副本数的情况下才启动任务，避免部分成功导致的问题。例如：

apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
meta
  name: data-processing-group
spec:
  minMember: 8
  minTaskMember:
  - name: mapper
    minMember: 4
  - name: reducer
    minMember: 4
  scheduleTimeoutSeconds: 300

这个PodGroup要求至少8个Pod可用，其中mapper和reducer任务各需要4个，调度超时时间为5分钟。

在Kurator中，Queue和PodGroup的结合使用，为复杂的工作负载提供了精细的资源控制能力。企业可以根据业务优先级、资源需求、SLA要求等维度，设计合理的队列策略和任务分组，最大化资源利用率。

4.3 跨集群弹性伸缩实践

Karmada跨集群弹性伸缩如图所示：

跨集群弹性伸缩是Kurator结合Karmada提供的高级能力，能够根据负载情况自动调整应用在不同集群中的副本数，实现资源的最优利用。

Karmada的弹性伸缩基于Horizontal Pod Autoscaler（HPA），但扩展了跨集群的能力。它通过监控各集群的资源使用情况，动态调整应用在不同集群中的副本分布。例如，当某个集群的CPU使用率超过阈值时，Karmada会自动将部分副本迁移到负载较低的集群。

在Kurator中，配置跨集群弹性伸缩需要创建一个ClusterPropagationPolicy和相应的HPA资源。首先，定义传播策略：

apiVersion: policy.karmada.io/v1alpha1
kind: ClusterPropagationPolicy
meta
  name: web-app-policy
spec:
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
    name: web-app
  placement:
    clusterAffinity:
      clusterNames:
      - cluster-east
      - cluster-west
    replicaScheduling:
      replicaSchedulingType: Duplicated

然后，创建HPA资源：

apiVersion: autoscaling.karmada.io/v1alpha1
kind: PropagationHorizontalPodAutoscaler
meta
  name: web-app-hpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  clusterMetrics:
  - clusterName: cluster-east
    weight: 0.6
  - clusterName: cluster-west
    weight: 0.4

这个配置定义了一个跨集群的HPA，总副本数在3-20之间，根据CPU使用率自动调整。其中，cluster-east集群承担60%的负载，cluster-west承担40%。

在实际生产环境中，跨集群弹性伸缩需要考虑网络延迟、数据一致性、成本优化等因素。Kurator提供了丰富的策略选项，如基于地理位置的调度、基于成本的调度、基于延迟的调度等，帮助企业实现最优的资源分配策略。

五、应用分发与发布策略

5.1 GitOps实现方式与FluxCD集成

GitOps实现方式如图所示：

GitOps是Kurator推荐的应用分发方式，通过将Git仓库作为唯一的真实数据源，实现声明式的应用部署和管理。Kurator集成了FluxCD作为GitOps引擎，提供了完整的CI/CD能力。

FluxCD的核心组件包括Source Controller、Kustomize Controller和Helm Controller。Source Controller负责监控Git仓库、Helm仓库等源的变化，Kustomize Controller处理Kustomize配置，Helm Controller管理Helm发布。

在Kurator中，配置GitOps流水线需要创建GitRepository和Kustomization资源。首先，定义Git仓库：

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
meta
  name: app-repo
  namespace: kurator-system
spec:
  url: https://github.com/company/app-repo.git
  ref:
    branch: main
  interval: 1m

然后，创建Kustomization资源，定义如何应用配置：

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
meta
  name: app-kustomization
  namespace: kurator-system
spec:
  targetNamespace: default
  sourceRef:
    kind: GitRepository
    name: app-repo
  path: ./deploy/production
  prune: true
  validation: client
  interval: 5m
  retryInterval: 1m
  timeout: 2m

这个配置每5分钟检查一次Git仓库的变化，自动应用部署配置。当Git仓库中的配置发生变化时，FluxCD会自动同步到集群中，实现持续部署。

Kurator通过集成FluxCD，为GitOps提供了企业级的支持，包括多环境管理、版本回滚、安全策略等。企业可以将不同环境（开发、测试、生产）的配置放在不同的目录中，通过不同的Kustomization资源进行管理，实现环境隔离和权限控制。

5.2 金丝雀发布与蓝绿发布配置

金丝雀发布和蓝绿发布是两种常见的渐进式发布策略，Kurator通过集成Flagger和Istio，提供了完整的支持。

金丝雀发布通过逐步将流量切换到新版本，降低发布风险。在Kurator中，配置金丝雀发布需要创建Canary资源：

apiVersion: flagger.app/v1beta1
kind: Canary
meta
  name: web-app
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  progressDeadlineSeconds: 60
  service:
    port: 80
    targetPort: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
      interval: 1m
    - name: request-duration
      thresholdRange:
        max: 500
      interval: 1m
    webhooks:
    - name: load-test
      url: http://flagger-loadtester.test/
      timeout: 5s
      metadata:
        type: cmd
        cmd: |
          hey -z 1m -q 10 -c 2 http://web-app.test/

这个配置定义了一个金丝雀发布策略，每次增加10%的流量到新版本，最大50%，监控成功率和延迟指标，当指标不达标时自动回滚。

Kurator 配置金丝雀如图所示：

蓝绿发布则通过维护两个独立的环境（蓝色和绿色），在新版本验证通过后，一次性切换流量。在Kurator中，配置蓝绿发布：

apiVersion: flagger.app/v1beta1
kind: Canary
meta
  name: web-app-bluegreen
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  service:
    port: 80
    targetPort: 8080
  analysis:
    interval: 1m
    threshold: 10
    maxWeight: 100
    stepWeight: 100
    promotion:
      strategy: bluegreen
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
      interval: 1m
    - name: request-duration
      thresholdRange:
        max: 500
      interval: 1m
    preRollout:
      webhooks:
      - name: acceptance-test
        url: http://flagger-loadtester.test/
        timeout: 15s
        meta
          type: cmd
          cmd: |
            curl -sd 'test' http://web-app-canary.test/
    postRollout:
      webhooks:
      - name: send-notification
        url: http://notification-service/send
        timeout: 5s

这个配置使用蓝绿发布策略，在预发布阶段运行验收测试，发布成功后发送通知。
Kurator 配置蓝绿发布如图所示：

5.3 A/B测试与流量管理

A/B测试是产品迭代的重要手段，Kurator通过Istio的服务网格能力，提供了强大的流量管理功能。在Kurator中，配置A/B测试需要创建VirtualService和DestinationRule资源。

首先，定义DestinationRule，将不同版本的Pod分组：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
meta
  name: web-app
spec:
  host: web-app
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

然后，创建VirtualService，定义流量分配规则：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: web-app-abtest
spec:
  hosts:
  - web-app
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Chrome.*"
    route:
    - destination:
        host: web-app
        subset: v2
      weight: 100
    - destination:
        host: web-app
        subset: v1
      weight: 0
  - route:
    - destination:
        host: web-app
        subset: v1
      weight: 90
    - destination:
        host: web-app
        subset: v2
      weight: 10

这个配置将Chrome浏览器用户全部导向v2版本，其他用户90%使用v1版本，10%使用v2版本，实现A/B测试。

Kurator还支持基于请求头、Cookie、地理位置等维度的流量分割，为精细化运营提供技术支持。通过Prometheus和Grafana的集成，可以实时监控不同版本的性能指标，为产品决策提供数据支持。

六、未来发展方向与实践建议

6.1 Kurator技术演进路线

Kurator作为新兴的云原生套件，其技术演进路线清晰明确。短期目标是完善核心功能，提高稳定性和性能；中期目标是扩展生态系统，支持更多云原生项目；长期目标是构建完整的分布式云原生平台，成为企业数字化转型的核心基础设施。

在核心功能方面，Kurator将持续优化多集群调度算法，提高资源利用率和应用可用性。特别是在跨云、混合云场景下，需要解决网络延迟、数据同步、成本优化等复杂问题。Kurator计划引入机器学习算法，实现智能的资源预测和调度决策。

在生态系统方面，Kurator将加强与CNCF项目的集成，如ArgoCD、Tekton、Crossplane等，提供更丰富的功能选项。同时，Kurator将开放插件机制，允许社区开发者贡献自定义组件，形成繁荣的生态系统。

在平台化方面，Kurator将提供企业级的管理界面、可观测性工具、安全策略等，降低使用门槛。通过统一的API网关和身份认证，实现多租户隔离和权限管理，满足企业级需求。

6.2 分布式云原生技术趋势

分布式云原生技术正在快速发展，呈现出几个明显的趋势。首先是边缘计算的普及，随着5G和物联网的发展，越来越多的计算需求将转移到边缘，Kurator需要提供更好的边缘支持。其次是多云管理的复杂性增加，企业需要统一的管理平台来协调不同云提供商的资源。第三是安全性的提升，零信任架构和细粒度的访问控制成为必需。

另一个重要趋势是AI/ML工作负载的云原生化。传统的AI训练和推理任务需要专门的基础设施，现在正逐步迁移到Kubernetes平台。Kurator通过Volcano的集成，已经具备了一定的支持能力，但还需要进一步优化，如支持GPU资源共享、模型版本管理、自动超参数调优等。

服务网格技术也在快速发展，从简单的流量管理向全栈可观测性、安全策略、策略执行等方向演进。Kurator需要与Istio、Linkerd等项目深度集成，提供企业级的服务网格能力。

6.3 企业落地最佳实践建议

对于企业来说，落地Kurator需要遵循渐进式策略。首先从非关键业务开始试点，验证技术可行性和团队能力。其次，建立完善的监控告警体系，确保系统稳定性。最后，逐步推广到核心业务，实现全面的云原生转型。

在组织架构方面，建议建立专门的云原生平台团队，负责Kurator的运维和优化。这个团队应该具备Kubernetes、网络、安全等多方面的技能，能够快速响应问题和需求。

在技术选型方面，不要盲目追求新技术，而是根据业务需求选择合适的功能模块。例如，如果企业没有边缘计算需求，可以暂时不启用KubeEdge；如果主要是Web应用，可以优先关注GitOps和发布策略。

在安全方面，必须重视身份认证、权限管理和数据加密。Kurator提供了基础的安全能力，但企业需要根据自身需求进行定制和加强，如集成企业级的身份提供商、实现网络策略的细粒度控制等。

通过合理的规划和执行，Kurator可以帮助企业构建现代化的分布式云原生基础设施，提高业务敏捷性和创新能力，在数字化转型中获得竞争优势。