Karmada v1.5发布：多调度组助力成本优化
摘要：在最新发布的1.5版本中，Karmada 提供了多调度组的能力，利用该能力，用户可以实现将业务优先调度到成本更低的集群，或者在主集群故障时，优先迁移业务到指定的备份集群。
本文分享自华为云社区《Karmada v1.5发布！多调度组助力成本优化》，作者：华为云云原生团队。
Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。在最新发布的1.5版本中，Karmada 提供了多调度组的能力，利用该能力，用户可以实现将业务优先调度到成本更低的集群，或者在主集群故障时，优先迁移业务到指定的备份集群。
本版本其他新增特性：
- 提供了多调度器支持能力，默认调度器可以与第三方自定义调度器协同工作，提供更强的定制能力。
- 集群差异化配置策略（OverridePolicy/ClusterOverridePolicy）将按照隐式的优先级进行应用。
- 内置资源解释器支持聚合StatefulSet/CronJob 状态。
新特性概览
多调度组
根据 Flexera 发布的《2023 年云现状调查报告》，云成本的管理取代了安全性话题，成为当下云使用者面临的首要问题。
Karmada 秉承这一趋势，同样关注云成本管理。从v1.5版本开始，用户可以在 PropagationPolicy/ClusterPropagationPolicy 中设置多个集群组，实现将业务优先调度到成本更低的集群组。下面我们给出一个针对成本优化进行调度的例子：
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: local-clusters clusterNames: - local-member1 - local-member2 - affinityName: cloud-clusters clusterNames: - huawei-member1 - huawei-member2
上面的例子配置有本地集群组（local-clusters）和云上集群组（cloud-clusters），Karmada 在选择集群组进行资源分发时， 将按顺序对集群组逐一进行评估，直到找到满足调度约束的集群组。所以在调度Deployment/nginx时，会优先尝试调度到本地集群组的local-member1和local-member2，如果失败（如资源不足），则选择云上集群组，从而实现在本地集群资源足够时，优先选择成本更低的本地集群。基于此，系统管理员也可以定义主集群组和备份集群组，在主集群组故障时，将业务往备份集群组的集群迁移。下面我们给出一个针对容灾迁移的例子：
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: primary-cluster clusterNames: - member1 - affinityName: backup-cluster clusterNames: - member2
上面的例子通过配置主群组（primary-cluster）和备份集群组（backup-cluster），在调度 Deployment/nginx 时，如果主集群组满足要求，会调度到主集群组的member1。在主集群组的集群故障时，调度器按顺序匹配新集群组，将业务迁移到备份集群组的member2。
关于多调度组更多信息，请参考：https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/multi-scheduling-group
自定义调度器
Karmada 默认调度器内置多款可灵活配置的插件，可以满足大部分使用场景，用户还可以使用插件扩展机制来实现个性化调度诉求。Karmada 1.5版本提供了多调度器支持能力，Karmada 默认调度器可以与第三方自定义调度器协同工作，以提供更强的定制能力。用户可以参考默认调度器实现自定义调度器，当多个调度器共存时，需通过命令行启动参数指定调度器名称，如 --scheduler-name=my-scheduler 。如果自定义调度器与默认调度器部署在同一namespace中，建议同时配置 --leader-elect-resource-name 参数，以避免副本选主冲突。关键命令行启动参数如下所示：
command: - /bin/karmada-scheduler - --kubeconfig=/etc/kubeconfig - --bind-address=0.0.0.0 - --secure-port=10351 - --enable-scheduler-estimator=true - --leader-elect-resource-name=my-scheduler 你的自定义调度器名称 - --scheduler-name=my-scheduler 你的自定义调度器
通过参数 --scheduler-name 将多个调度器进行区分，每个调度器将只负责调度特定的工作负载。通过 Karmada 分发工作负载时，可以在 PropagationPolicy/ClusterPropagationPolicy 的 schedulerName 字段指定调度器名字，如下所示：
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: schedulerName: my-scheduler resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1 - member2
上例通过 schedulerName 指定此Deployment必须由名为 my-scheduler 的调度器进行调度，此时默认调度器将自动忽略该工作负载。schedulerName 如果没有指定，则默认值为 default-scheduler ，意味着由默认调度器进行调度，前面版本的用户升级到新版本时无需额外配置。关于如何扩展调度器插件和实现自定义调度器，请查看官方文档：https://karmada.io/docs/developers/customize-karmada-scheduler/
版本升级
Karmada v1.5版本API兼容v1.4版本API，v1.4版本的用户仍然可以平滑升级到v1.5版本。可参考升级文档：https://karmada.io/docs/administrator/upgrading/v1.4-v1.5
致谢贡献者
Karmada v1.5版本包含了来自25位贡献者的数百次代码提交，在此对各位贡献者表示由衷的感谢：
贡献者GitHub ID:
@a7i@calvin0327@carlory@chaunceyjiang@fengshunli@Fish-pro@Garrybest@helen-frank@ikaven1024@jwcesign@lonelyCZ@maoyangLiu@my-git9@Poor12@qingwave@RainbowMango@VedRatan@Wang-Kai@whitewindmills@wlp1153468871@wongearl@XiShanYongYe-Chang@yanfeng1992@yanggangtony@Zhuzhenghao
参考链接
-
Release Notes：https://github.com/karmada-io/karmada/releases/tag/v1.5.0
-
多调度组：https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/multi-scheduling-group
-
2023 年云现状调查报告：https://info.flexera.com/CM-REPORT-State-of-the-Cloud
-
扩展调度器插件和实现自定义调度器：https://karmada.io/docs/developers/customize-karmada-scheduler/
附：Karmada社区技术交流地址
- 项目地址：https://github.com/karmada-io/karmada
- Slack地址：https://slack.cncf.io/(karmada)