Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。

本版本包含下列新增特性：

• 支持联邦应用跨集群滚动升级，使用户版本发布流程更加灵活可控；
• karmadactl 新增了多项运维能力，提供独特的多集群运维体验；
• 为联邦工作负载提供标准化 generation 语义，使 CD 执行一步到位；
• Karmada Operator 支持自定义 CRD 下载策略，使离线部署更灵活。

联邦应用跨集群滚动升级​

在最新发布的 v1.11 版本中，Karmada 新增了联邦应用跨集群滚动升级特性。这一特性特别适用于那些部署在多个集群上的应用，使得用户在发布应用新版本时能够采用更加灵活和可控的滚动升级策略。用户可以精细地控制升级流程，确保每个集群在升级过程中都能够平滑过渡，减少对生产环境的影响。这一特性不仅提升了用户体验，也为复杂的多集群管理提供了更多的灵活性和可靠性。

下面通过一个示例来演示如何对联邦应用进行滚动升级：

假定用户已经通过 PropagationPolicy 将 Deployment 应用分发到三个成员集群中：ClusterA、ClusterB、ClusterC：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - ClusterA
        - ClusterB
        - ClusterC

此时 Deployment 版本为v1，为了将 Deployment 资源版本升级至 v2，您可以依次执行下列步骤。

首先，通过配置 PropagationPolicy 策略，暂时停止向 ClusterA 和 ClusterB 分发资源，从而应用的变更将只发生在 ClusterC：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  #...
  suspension:
    dispatchingOnClusters:
      clusterNames:
        - ClusterA
        - ClusterB

然后更新 PropagationPolicy 资源，允许系统向 ClusterB 集群同步新版本资源：

  suspension:
    dispatchingOnClusters:
      clusterNames:
        - ClusterA

最后删除 PropagationPolicy 资源中的 suspension 字段，允许系统向 ClusterA 集群同步新版本资源：

从上述示例中我们可以看到，利用联邦应用跨集群滚动发布能力，新版本应用可以做到按集群粒度滚动升级，并且可以做到精准控制。

此外，该功能还可以应用于其他场景，特别是对于开发者来说，由于 Karmada 控制平面和成员集群之间争夺资源控制权而导致资源频繁更新的情况。在这种情况下，暂停资源与成员集群的同步过程可以方便快速识别问题。

karmadactl 能力增强​

在本版本中，Karmada 社区致力于增强 Karmadactl 的能力，以便提供更好的多集群运维体验，进而摆脱用户对 kubectl 的依赖。

更丰富的命令集​

Karmadactl 支持更丰富的命令集，如 create、patch、delete、label、annotate、edit、attach、top node、api-resources 以及 explain，这些命令允许用户对 Karmada 控制面或成员集群上的资源执行更多操作。

更丰富的功能​

Karmadactl 引入了 --operation-scope 参数来控制命令的操作范围。有了这个新参数，get、describe、exec 和 explain 等命令可以灵活切换集群视角对 Karmada 控制面或成员集群的资源进行操作。

更详细的命令输出信息​

karmadactl get cluster 命令的输出现在增加了 cluster 对象的 Zones、Region、Provider、API-Endpoint 和 Proxy-URL 信息。

通过这些能力增强，karmadactl 的操作和运维体验得到了提升。karmadactl 的新功能和更多详细信息可以通过使用 karmadactl --help 获得。

联邦工作负载标准化 generation 语义​

在本版本中，Karmada 将联邦层面的工作负载 generation 语义进行了标准化。这一更新为发布系统提供了可靠的参考，增强了跨集群部署的精确度。通过标准化 generation 语义，Karmada 简化了发布流程，并确保一致性地跟踪工作负载状态，使得跨多个集群管理和监控应用程序变得更加容易。

标准化细节为，当且仅当工作负载分发至所有成员集群中的资源状态满足 status.observedGeneration >= metadata.generation 时，联邦层面的工作负载状态中的 observedGeneration 值才会被设置为其本身 .metadata.generation 值，这确保了每个成员集群中相应的控制器均已完成了对该工作负载的处理。此举将联邦层面的 generation 语义同kubernetes 集群的 generation 语义进行了统一，使用户能够更便捷的将单集群业务迁移至多集群业务。

本版本已完成下列资源适配：

• GroupVersion: apps/v1 Kind: Deployment, DaemonSet, StatefulSet
• GroupVersion: apps.kruise.io/v1alpha1 Kind: CloneSet, DaemonSet
• GroupVersion: apps.kruise.io/v1beta1 Kind: StatefulSet
• GroupVersion: helm.toolkit.fluxcd.io/v2beta1 Kind: HelmRelease
• GroupVersion: kustomize.toolkit.fluxcd.io/v1 Kind: Kustomization
• GroupVersion: source.toolkit.fluxcd.io/v1 Kind: GitRepository
• GroupVersion: source.toolkit.fluxcd.io/v1beta2 Kind: Bucket, HelmChart, HelmRepository, OCIRepository

如有您有更多资源（包括CRD）需要适配，可以向 Karmada 社区进行反馈，也可以使用 Resource Interpreter 进行扩展。

Karmada Operator 支持自定义 CRD 下载策略​

CRD（Custom Resource Definition，自定义资源定义）资源是 Karmada Operator 用于配置新的 Karmada 实例的关键前提资源。这些 CRD 资源包含了 Karmada 系统的关键 API 定义，例如，PropagationPolicy，ResourceBinding，Work 等。

在 v.1.11 版本中，Karmada Operator 支持用户自定义 CRD 下载策略。利用这个功能，用户可以指定 CRD 资源的下载路径，并定义更多的下载策略，为用户提供了更灵活的离线部署方式。

有关该特性的详细描述，可以参考提案：Custom CRD Download Strategy Support for Karmada Operator。

致谢贡献者

Karmada v1.11 版本包含了来自 36 位贡献者的 223 次代码提交，在此对各位贡献者表示由衷的感谢：

摘要​

随着云原生技术在越来越多的企业和组织中的大规模落地，如何高效、可靠地管理大规模资源池以应对不断增长的业务挑战成为了当下云原生技术的关键挑战。 在过去的很长一段时间内，不同厂商尝试通过定制Kubernetes原生组件的方式扩展单集群的规模，这在扩大规模的同时也引入了复杂的单集群运维、不清晰的集群升级路径等问题。 而多集群技术能在不侵入修改Kubernetes单集群的基础上横向扩展资源池的规模，在扩展资源池的同时降低了企业的运维管理等成本。

在Karmada的大规模落地进程中，Karmada的可扩展性和大规模逐渐成为社区用户的新关注点。 因此，我们对Karmada开展了大规模环境下的测试工作，以获取Karmada管理多个Kubernetes集群的性能基线指标。 对于以Karmada为代表的多集群系统而言，单集群的规模不是制约它的资源池规模的限制因素。 因此，我们参考了Kubernetes的大规模集群的标准配置和用户的生产落地实践，测试了Karmada同时管理100个5k节点和2wPod的Kubernetes集群的用户场景。 受限于测试环境和测试工具，本次测试并未追求测试到Karmada多集群系统的上限，而是希望能覆盖到在生产中大规模使用多集群技术的典型场景。 根据测试结果分析，以Karmada为核心的集群联邦可以稳定支持100个大规模集群，管理超过50万个节点和200万个Pod，可以满足用户在大规模生产落地的需要。

在本文中，我们将介绍用于测试的相关指标，如何进行大规模测试，以及我们如何实现大规模的集群接入。

背景​

随着云原生技术的不断发展和使用场景的不断丰富，多云、分布式云逐渐成为引领云计算发展的趋势。著名分析公司Flexera在2021的调查报告显示，超过93%的企业正同时使用多个云厂商的服务，一方面受限于Kubernetes单集群的业务承载能力和故障恢复能力，单一的集群无法适应现有的企业业务，另一方面，在全球化的当下，企业出于避免被单家厂商垄断的目的，或是出于成本等因素考虑，更倾向于选择混合云或者多公有云的架构。 与此同时，Karmada社区的用户在落地的进程中也提出了多集群下大规模节点和应用管理的诉求。

Karmada是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容Kubernetes原生API的能力，Karmada可以平滑迁移单集群工作负载，并且仍可保持与Kubernetes周边生态工具链协同。

在最新发布的1.3版本中，Karmada重新设计了应用跨集群故障迁移功能，实现了基于污点的故障驱逐机制，并提供平滑的故障迁移过程，可以有效保障服务迁移过程的连续性（不断服）。

本版本新增加的特性：

• 增加了面向多集群的资源代理新特性，通过该代理平台业务方可以在不感知多集群的情况下，以单集群访问姿势直接操纵部署在多集群的工作负载；
• 提供针对集群资源建模能力，通过自定义的集群资源模型，调度器可以更精准地进行资源调度；
• 提供基于Bootstrap令牌来注册Pull模式集群的能力，不仅可以简化集群注册过程，还可以方便地进行权限控制；

此外，基于生产环境的用户反馈，本版本还进行了诸多性能优化，系统运行过程中CPU和内存资源需求大大降低，详细的性能测试报告稍后发布。

与之前版本一样，v1.3与前面的版本仍然保持兼容，前面版本的用户仍可以平滑升级。

In terms of multi-cluster management, Industrial and Commercial Bank of China (ICBC) found a new way to do it efficiently, that is, using Karmada. At KubeCon 2021, Kevin Wang from Huawei Cloud and Shen Yifan from ICBC shared how they managed it.