Kurator v0.4.0版本更新4大内容，满足多云环境的复杂需求

摘要：在最新发布的 v0.4.0 版本中，Kurator 进一步丰富了分布式云原生场景下的应用统一管理能力，以便更好地满足多云环境的复杂需求。

本文分享自华为云社区《Kurator v0.4.0：引领分布式云原生管理的全新篇章》，作者：华为云云原生团队。

Kurator 是一款开源的分布式云原生平台，融合了众多主流的云原生软件栈，如Kubernetes、Istio、Prometheus 等，旨在帮助用户构建和管理自己的分布式云原生基础设施，以推动企业的数字化转型。Kurator 体现了“基础设施即代码”的理念，允许用户以声明方式管理云、边缘或本地环境的基础设施。同时，其“开箱即用”的特性，使用户可以一键安装云原生软件栈。而借助Fleet，Kurator更提供了多云、多集群的统一管理，极大提升了管理效率。

在最新发布的 v0.4.0 版本中，Kurator 进一步丰富了分布式云原生场景下的应用统一管理能力，以便更好地满足多云环境的复杂需求。此次更新主要包括以下四个方面：

⦁ 采用了GitOps方式并利用Fleet来实现多云环境下的统一应用分发。这种新的方法将降低多云异构环境配置的复杂性，简化了分布式部署的管理过程。

⦁ 为用户提供了一种基于Fleet、Prometheus和Thanos的统一集群指标监控方案。这种方案旨在提高在复杂的多云、多集群环境中的指标监控的全面性、准确性和实时性，从而提高运维效率并降低运维复杂性。

⦁ 通过利用Kyverno和Fleet，为多云、多集群环境下的策略管理提供了统一的解决方案。这一功能的加入将提高策略管理的效率，保证了在所有集群中的策略一致性和安全性。

⦁ 新增了一种名为"Attached Cluster"的集群类型。这种集群类型使得Kurator能够纳管任何地点、由任何工具搭建的Kubernetes集群，进一步加强了Kurator对分布式云环境的管理。

统一应用分发

随着多云、多集群的普及，如何有效在分布式云原生环境中部署和分发应用成为日益重要的话题。为此，Kurator 推出了统一应用分发功能，目标是解决以下问题：

多云、多集群配置繁琐：在传统的多云环境中，部署同一应用需要在每个环境中进行复杂的配置，这无疑增加了部署的难度，同时消耗了不必要的时间和人力资源。
维护版本一致性的挑战：在分布式的多云环境中，由于各个集群可能运行在不同的环境、拥有不同的配置，因此保持应用在所有集群中版本一致，并能及时进行更新，是一项挑战。
分布式部署管理困难：应用在各个集群中部署后，需要分别进入每个集群，以检查部署是否成功以及查看部署的状态。

Kurator 的统一应用分发功能采用 GitOps 方式，使得一键将应用部署到多个云环境成为可能，同时简化了配置流程。这种方法确保了各集群中的应用版本保持一致，也能及时进行版本更新。在 Kurator 宿主集群上，用户可以对所有集群的应用部署情况进行统一的查看和管理，从而提高运维效率。

Kurator应用管理架构图

Kurator 基于 FluxCD，通过自动化的应用同步和部署流程，优化了部署效率和准确性。借助于 Fleet 的优势，它还能灵活地适应各种不同的业务和集群需求，满足用户对于应用分发的多样化需求。

Kurator 的统一应用分发功能提供了丰富而灵活的配置选项，用户可以通过 YAML 配置文件定义应用的源、同步策略等关键参数。同时，Kurator 还支持多种类型的源（包括 gitRepository，helmRelease等）和同步策略的组合。

以下是一个统一应用分发的例子：

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: gitrepo-kustomization-demo
  namespace: default
spec:
  source:
    gitRepository:
      interval: 3m0s
      ref:
        branch: master
      timeout: 1m0s
      url: https://github.com/stefanprodan/podinfo
  syncPolicies:
    - destination:
        fleet: quickstart
      kustomization:
        interval: 5m0s
        path: ./deploy/webapp
        prune: true
        timeout: 2m0s
    - destination:
        fleet: quickstart
      kustomization:
        targetNamespace: default
        interval: 5m0s
        path: ./kustomize
        prune: true
        timeout: 2m0s

此示例配置表达了如何借助 Kurator 实现多集群统一应用分发：从 Git 源中获取应用配置，然后通过 Fleet 进行同步和部署。用户只需简单的配置，即可迅速将应用部署到多个集群中。

关于更多例以及其他相关信息，请参考：https://kurator.dev/docs/fleet-manager/application/

统一集群指标监控

在复杂的多云、多集群环境中，统一的集群指标监控可以提升工作效率并且降低运维复杂性。对于许多企业来说，他们面临的挑战是如何在各个集群间进行有效的监控和管理，以确保服务的稳定性和优化资源使用率。

单一的监控工具常常无法满足全面、及时和准确的监控需求。这就需要运维人员分别进入每个集群进行检查，不仅增加了工作量，也可能导致关键指标信息的遗漏或延误。而且，由于不同的集群可能有不同的需求，管理工作变得更加复杂。

为解决上述问题，Kurator 提供了一种基于 Prometheus、Thanos、Grafana 以及 Fleet 的多集群指标监控方案，使用户能够轻松实现多集群的统一指标监控。

统一监控架构图

通常，集群权限和远程存储配置完成后，我们可以将在多集群环境中实现统一指标监控的过程概括如下：

每个集群运行一个 Prometheus 实例，负责收集本地的监控数据；
每个Prometheus 实例都附带一个 Thanos Sidecar，这个 Sidecar 将 Prometheus 收集到的数据推送到远程存储；
Thanos Query 从所有的 Thanos Sidecar 和远程存储中聚合数据，并提供一个统一的查询接口；
Grafana 连接到 Thanos Query，从而能够展示所有集群的统一监控视图。

借助于 Kurator 的 Fleet 的能力，用户无需亲自处理上述复杂流程。用户只需在 Fleet 中定义相关配置，Fleet Manager 就能自动完成上述流程。

下面是一个可以完成上述流程的 Fleet 配置示例：

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1
      kind: AttachedCluster
    - name: kurator-member2
      kind: AttachedCluster
  plugin:
    metric:
      thanos:
        objectStoreConfig:
          secretName: thanos-objstore
grafana: {}

在执行上述配置后，Fleet Manager 将会在 kurator-member1 与 kurator-member2 这两个集群上分别安装 Prometheus 和 Thanos Sidecar。然后，用户便可以在 Kurator 主机上通过 Grafana 仪表板查看所有集群的统一监控视图。

关于使用统一集群指标监控的更多细节，请参考：https://kurator.dev/docs/fleet-manager/metric-plugin/

统一策略管理

在分布式云环境中，为了满足多云、多集群的统一安全保护需求，Kurator 引入了统一策略管理功能，以解决以下问题：

无法统筹多个集群的策略管理，跨集群应用同一策略
多个子集群策略分散管理，冗余且复杂度较高，无法统一高效配置和管理
无法统一限制多个集群资源使用情况，以保证所有集群遵循相同的操作规则和业务需求

Kurator 的策略管理能力基于 Kyverno，并利用 Fleet 实现应用策略的跨集群分发和应用。这种机制允许策略在整个集群群组中被统一和高效地管理，避免了在每个子集群单独管理策略的复杂性。

统一策略管理架构图

Kurator 提供的策略管理能力与在单一 Kubernetes 集群中的策略管理几乎无异，用户可以快速熟悉和上手。下面是一个使用 Kurator 在 Fleet 中实现统一策略管理的示例：

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1
      kind: AttachedCluster
    - name: kurator-member2
      kind: Cluster
    - name: kurator-member3
      kind: CustomCluster
  plugin:
    policy:
      kyverno:
        podSecurity:
          standard: baseline
          severity: high
          validationFailureAction: Audit

在上述配置文件中，我们为 Fleet 中的集群统一应用了 podSecurityStandard 为 baseline，podSecuritySeverity 为 high 的 Pod 安全策略。当Pod配置违背安全策略时，在其创建过程将会在PolicyReport中记录相应事件；而当 validationFailureAction 设置为Enforce时，非法资源的创建或者更新就会被拦截。Fleet 中的所有集群都将运用此策略，应用运维和开发人员将在遵循该 Pod 安全性规定的前提下调整和配置应用。借助 Kurator 的统一策略管理能力，可以有效提高策略管理的效率，同时保证所有集群中策略的一致性和安全性。

关于 Kurator 统一策略管理的更多信息，请参考：https://kurator.dev/docs/fleet-manager/policy/

AttachedCluster

在云原生的世界里，基础设施的复杂性和多样性是无法避免的问题。对于大型组织或公司来说，他们可能已经在不同的环境下部署了多个 Kubernetes 集群，而这些集群可能是由各种不同的工具创建的，并分布在世界各地。为了更好地解决这个问题，Kurator 在最新的版本中引入了一种新的集群类型，即 AttachedCluster。

AttachedCluster 的主要目的是为了管理那些并非由Kurator创建，却又需要被纳入到Kurator舰队管理范围的 Kubernetes 集群。这些集群可以由任何工具创建，并位于任何地方。引入这种新的集群类型，使得Kurator的管理能力得以延伸，实现对真正的分布式云环境的高效管理。在实际使用中，用户需要为预计要接入 Kurator 管理的 Kubernetes 集群创建 AttachedCluster 资源。这些资源中包含了集群的连接和身份验证信息，这些信息通过 Secret 进行安全存储和管理。有了这些信息，Kurator 就能够与这些集群进行有效的交互和管理。]

下面是一个示例：

apiVersion: cluster.kurator.dev/v1alpha1
kind: AttachedCluster
metadata:
  name: kurator-member1
  namespace: default
spec:
  kubeconfig:
    name: kurator-member1
    key: kurator-member1.config

资源创建完成后，用户还需要将这些 AttachedCluster 资源加入到 Kurator Fleet 中，从而将这些集群纳入 Kurator 的管理范围。这样一来，无论这些集群在何处，由何种工具创建，都能够在 Kurator 中进行统一的管理和监控。

下面是一个将上述 AttachedCluster 加入 Fleet 的例子：

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet 
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    # 在此处添加 AttachedCluster 或者其他类型的集群
    - name: kurator-member1 
      kind: AttachedCluster

对于用户来说，Kurator 通过引入 AttachedCluster，在统一平台上实现了对所有 Kubernetes 集群的便捷管理，避免了在各种工具之间的频繁切换，有效地监控与管理了分布式云环境中各个集群。这个改进，不仅强化了 Kurator 在云原生领域中的管理能力，也扩展了其管理范围，使得 Kurator 在处理复杂多样的云计算环境中的适应力和管理效率得到了显著提升。