Karmada v1.10发布，新增多集群声明式负载重平衡

本文分享自华为云社区《Karmada v1.10 - 多集群声明式负载重平衡》，作者：云容器大未来。
Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云情况下部署和运维业务应用。依附兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。
在最新发布的v1.10版本中，Karmada新增了工作负载重平衡功能：在某些场景下，资源副本的当前分布状态大概不是最优，但调度器为了减少对体系的打击会尽大概保持调度效果的惰性，不会轻易改变调度效果；此时，用户可以通过新引入的 WorkloadRebalancer API 针对指定的资源手动触发全新的重调度，以在集群间建立最优的副本状态分布。

本版本其他新增特性：

• 排除资源模板名称长度不能凌驾 63 个字符的限制
  
• 生产情况中的可用性和可靠性增强
  

新特性概览

Workload Rebalance

一般情况下，工作负载类资源一旦被调度，其调度效果通常会保持惰性，不会轻易改变副本分布状态。即使通过修改资源模板中的副本数或 PropagationPolicy 的 Placement 来触发重新调度，体系也只会在须要时进行最小化的调解，以最大程度地减少对体系的影响。
然而，在某些情况下，用户大概盼望能够主动触发全新的重调度，完全忽略过去的分配效果，并在集群之间建立全新的副本分布状态，比方：

• 在主备集群模式下，由于主集群故障，应用被迁移至备集群，主集群规复后，应用盼望重新迁移至主集群。
  
• 在应用级别故障迁移场景下，由于集群资源不足，应用从多个集群缩减到单个集群，相应集群资源富足后，应用盼望重新分发到多集群以确保高可用性。
  
• 对于聚合调度策略，由于资源限制，副本最初分布在多个集群中，当单个集群足以容纳所有副本后，应用盼望重新聚合到单集群。
  

因此，本版本引入了工作负载重平衡功能，假如当前副本分布状态不是最优，用户可以按需触发全新的重调度。
比方，用户想触发 Deployment/foo 的重调度，只需声明下述 WorkloadRebalancer 资源：

1. apiVersion: apps.karmada.io/v1alpha1
2. kind: WorkloadRebalancer
3. metadata:
4.   name: foo-rebalancer
5. spec:
6.   workloads:
7.     - apiVersion: apps/v1
8.       kind: Deployment
9.       name: foo
10.       namespace: default

复制代码

然后，调度器将对该 Deployment 进行重调度。
1）假如成功，您将看到以下效果:

1. apiVersion: apps.karmada.io/v1alpha1
2. kind: WorkloadRebalancer
3. metadata:
4.   name: foo-rebalancer
5.   generation: 1
6.   creationTimestamp: "2024-05-22T11:16:10Z"
7. spec:
8.   ...
9. status:
10.   finishTime: "2024-05-22T11:16:10Z"
11.   observedGeneration: 1
12.   observedWorkloads:
13.     - result: Successful
14.       workload:
15.         apiVersion: apps/v1
16.         kind: Deployment
17.         name: foo
18.         namespace: default

复制代码

2）假如失败，比方 Deployment/foo 的 ResourceBinding 不存在，您将得到以下效果：

1. apiVersion: apps.karmada.io/v1alpha1
2. kind: WorkloadRebalancer
3. metadata:
4.   name: foo-rebalancer
5.   generation: 1
6.   creationTimestamp: "2024-05-22T11:16:10Z"
7. spec:
8.   ...
9. status:
10.   finishTime: "2024-05-22T11:16:10Z"
11.   observedGeneration: 1
12.   observedWorkloads:
13.     - reason: ReferencedBindingNotFound
14.       result: Failed
15.       workload:
16.         apiVersion: apps/v1
17.         kind: Deployment
18.         name: foo
19.         namespace: default

复制代码

有关此功能的详细描述，请拜见用户指南：https://karmada.io/zh/docs/next/userguide/scheduling/workload-rebalancer排除资源模板命名长度的限制

由于历史筹划原因，资源模板的名称被用作 label 的值，从而加速资源的检索。由于 Kubernetes 限制标签 value 值不能凌驾 63 个字符，导致用户无法将名称长度凌驾 63 个字符的资源分发至成员集群中去，间接限制了资源模板名称的长度，严重阻碍了用户将工作负载从旧集群迁移到Karmada。
Karmada社区从 v1.8 版本起动手消除这一限制，并在 v1.8 和 v1.9 版本中做了富足的准备工作，以确保利用旧版本 Karmada 的用户可以平滑升级到当前新版本，而不用感知这一变化。
更多详情请拜见 [Umbrella] 在资源中利用 permanent-id 替换 namespace/name
标签：https://github.com/karmada-io/karmada/issues/4711
生产情况中的可用性和可靠性增强

本版本融合了大量生产级用户的反馈，进行了大量功能性增强以及安全性提升，包括：
1）功能增强：

• 支持分发 kubernetes.io/service-account-token type的 Secret 资源
  
• 优化 PropagationPolicy 降低优先级时的优先级抢占逻辑
  
• 显著减少 karmada-metrics-adapter 组件的内存利用
  
• 优化了 karmada-webhook 的启动逻辑，消除了偶现的异常报错
  

2）安全增强：

• 将 google.golang.org/protobuf 从 1.31.0 升级到 1.33.0，以办理 CVE-2024-24786 漏洞问题
  
• 将 Karmada 证书的 RSA 密钥长度从 2048 升级到 3072，提高秘钥安全性
  
• 将 text/template 库替换为 html/template，增加 HTML 编码等安全掩护功能
  
• 创建文件时由默认授予 0666 权限改为指定授予 0640 权限，提高文件安全性
  
• 采取须要步调以消除安全扫描工具的误报，如在利用 karmadactl 删除 token 时调解日记打印内容和消除 gosec 警告 G107 等
  

3）生态集成：

• 为 OpenKruise 中的 CloneSet 资源展示 status.labelSelector，以支持该资源的HPA扩缩容特性
  
• 在 karmadactl 添加成员集群时，新增支持 OIDC 认证模式
  

相信这些积极将使 Karmada 为用户带来更好的体验！致谢贡献者

Karmada v1.10 版本包含了来自32位贡献者的356次代码提交，在此对各位贡献者表现由衷的感谢：
贡献者GitHub ID:

参考链接

[1]Release Notes:https://github.com/karmada-io/karmada/releases/tag/v1.10.0
[2]WorkloadRebalancer 指南:https://karmada.io/zh/docs/userguide/scheduling/workload-rebalancer
[3]WorkloadRebalancer 示例教程:https://karmada.io/zh/docs/tutorials/workload-rebalancer
[4]Karmada 1.10升级文档:https://karmada.io/docs/administrator/upgrading/v1.9-v1.10
 
点击关注，第一时间了解华为云奇怪技能~
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。