Karmada v1.15 版本发布！多模板工作负载资源感知能力增强

本文分享自华为云社区《Karmada v1.15 版本发布！多模板工作负载资源感知能力增强》，作者：云容器大未来。Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada可以平滑迁徙单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。

Karmada v1.15版本现已发布，本版本包罗下列新增特性：● 多模板工作负载的资源精确感知
● 集群级故障迁徙功能增强 
● 结构化日志
● Karmada 控制器和调理器性能显着提升
新特性概览

多模板工作负载的资源精确感知

Karmada 利用资源解释器获取工作负载的副本数和资源请求，并据此盘算工作负载所需资源总量，从而实现资源感知调理，联邦配额管理等高阶能力。这种机制在传统的单模板工作负载中表现精良。然而，许多AI大数据应用的工作负载 CRD（如 FlinkDeployments，PyTorchJob 和 RayJob 等）包罗多个 Pod 模板或组件，每个组件都有独特的资源需求。由于资源解释器仅能处置惩罚单个模板的资源请求，无法正确反映不同模板间的差异，导致多模板工作负载的资源盘算不够精确。在这个版本中，Karmada 强化了对多模板工作负载的资源感知能力，通过扩展资源解释器，Karmada 如今可以获取同一工作负载不同模板的副本数和资源请求，确保数据的精确性。这一改进也为多模板工作负载的联邦配额管理提供了更加可靠和精细的数据支持。
假设你部署了一个 FlinkDeployment，其资源相关配置如下：

1. spec:
2.   jobManager:
3.     replicas: 1
4.     resource:
5.       cpu: 1
6.       memory: 1024m
7.   taskManager:
8.     replicas: 1
9.     resource:
10.       cpu: 2
11.       memory: 2048m

复制代码

通过 ResourceBinding，你可以查看资源解释器解析出的 FlinkDeployment 各个模板的副本数以及资源请求。

1. spec:
2.   components:
3.   - name: jobmanager
4.     replicaRequirements:
5.       resourceRequest:
6.         cpu: "1"
7.         memory: "1.024"
8.     replicas: 1
9.   - name: taskmanager
10.     replicaRequirements:
11.       resourceRequest:
12.         cpu: "2"
13.         memory: "2.048"
14.     replicas: 1

复制代码

此时，FederatedResourceQuota 盘算的 FlinkDeployment 占用的资源量为：

1. status:
2.     overallUsed:
3.       cpu: "3"
4.       memory: 3072m

复制代码

留意：该特性​​目前处于 Alpha 阶段，必要启用 MultiplePodTemplatesScheduling 特性开关​​才能利用。
随着多模板工作负载在云原生环境中的广泛应用，Karmada 致力于对其提供更强有力的支持。在接下来的版本中，我们将基于此功能进一步增强对多模板工作负载的调理支持，提供更加细粒度的资源感知调理——敬请等待更多更新！
更多有关此功能的资料请参考：多 Pod 模板支持。集群级故障迁徙功能增强

在之前的版本中，Karmada 提供了基本的集群级故障迁徙能力，可以大概通过自定义的故障条件触发集群级别的应用迁徙。为了满足有状态应用在集群故障迁徙过程中保留其运行状态的需求，Karmada 在 v1.15 版本支持了集群故障迁徙的应用状态中继机制。对于大数据处置惩罚应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处置惩罚状态，从而避免数据重复处置惩罚。社区在 PropagationPolicy/ClusterPropagationPolicy API 中的 .spec.failover.cluster 下引入了一个新的 StatePreservation 字段， 用于定义有状态应用在故障迁徙期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁徙到另一个集群时，可以大概从原始资源配置中提取关键数据。
状态保留策略 StatePreservation 包罗了一系列 StatePreservationRule 配置，通过 JSONPath 来指定必要保留的状态数据片段，并利用关联的 AliasLabelName 将数据通报到迁徙后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。当集群发生故障时，Flink 应用可以利用 jobID 来恢复故障前作业的状态，从故障点处继续实行。详细的配置和步骤如下：

1. apiVersion: policy.karmada.io/v1alpha1
2. kind: PropagationPolicy
3. metadata:
4.   name: foo
5. spec:
6.   #...
7.   failover:
8.     cluster:
9.       purgeMode: Directly
10.       statePreservation:
11.         rules:
12.           - aliasLabelName: application.karmada.io/cluster-failover-jobid
13.             jsonPath: "{ .jobStatus.jobID }"

复制代码

• 迁徙前，Karmada 控制器将按照用户配置的路径提取 job ID。
  
• 迁徙时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，好比 application.karmada.io/cluster-failover-jobid : 。
  
• 运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据 jobID 获取该 job 的 checkpoint 数据存储路径，好比 ////checkpoints/xxx，然后配置 initialSavepointPath 指示从save point 启动。
  
• Flink 应用根据 initialSavepointPath 下的 checkpoint 数据启动，从而继承迁徙前保存的最终状态。
  

该能力广泛适用于可以大概基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现集群级故障迁徙的状态中继。 留意：该特性​​目前处于 Alpha 阶段，必要启用 StatefulFailoverInjection 特性开关​​才能利用。功能约束：

• 应用必须限定在单个集群中运行；
  
• 迁徙清理策略（PurgeMode）限定为 Directly，即必要确保故障应用在旧集群上删除之后再在新集群中恢复应用，确保数据同等性。
  

结构化日志

日志是体系运行过程中记载事件、状态和行为的关键工具，广泛用于故障排查、性能监控和安全审计。Karmada 组件提供丰富的运行日志，帮助用户快速定位问题并回溯实行场景。在先前版本中，Karmada 仅支持非结构化的文本日志，难以被高效解析与查询，限定了其在现代化观测体系中的集成能力。Karmada 在 1.15 版本引入了结构化日志支持，可通过 --logging-format=json 启动参数配置 JSON 格式输出。结构化日志示例如下：

1. {
2.   "ts":“日志时间戳”,
3.   "logger":"cluster_status_controller",
4.   "level": "info",
5.   "msg":"Syncing cluster status",
6.   "clusterName":"member1"
7. }

复制代码

结构化日志的引入显着提升了日志的可用性与可观测性：
● 高效集成：可无缝对接 Elastic、Loki、Splunk 等主流日志体系，无需依赖复杂的正则表达式或日志解析器。● 高效查询：结构化字段支持快速检索与分析，显着提升故障排查服从。
● 可观察性增强：关键上下文信息（如集群名、日志级别）以结构化字段出现，便于跨组件、跨时间关联事件，实现精准问题定位。
● 可维护性提升：结构化日志使开辟者和运维人员在体系演进过程中更易于维护、解析和调解日志格式，保障日志体系的长期稳固与同等性。
Karmada 控制器和调理器性能显着提升

在本次版本中，Karmada 性能优化团队继续致力于提升 Karmada 关键组件的性能，在控制器和调理器方面取得了显着进展。控制器方面，通过引入优先级队列，控制器可以大概在重启或切主后优先相应用户触发的资源变更，从而显着缩短服务重启和故障切换过程中的停机时间。
测试环境包罗 5,000 个 Deployment、2,500 个 Policy 以及 5,000 个 ResourceBinding。在控制器重启且工作队列中仍有大量待处置惩罚事件的情况下，更新 Deployment 和 Policy。测试结果显示，控制器可以大概立即相应并优先处置惩罚这些更新事件，验证了该优化的有效性。留意：该特性​​目前处于 Alpha 阶段，必要启用 ControllerPriorityQueue 特性开关才能利用。
调理器方面，通过减少调理过程中的冗余盘算，低落长途调用请求次数，Karmada 调理器的调理服从得到了显着提升。测试记载了在开启精确调理组件 karmada-scheduler-estimator 情况下，调理 5,000 个 ResourceBinding 所用的时间，结果如下：
● 调理器吞吐量 QPS 从约 15 提升至约 22，性能提升达 46%；
● gRPC 请求次数从约 10,000 次减少至约 5,000 次，降幅达 50%。
这些测试证明，在 1.15 版本中，Karmada 控制器和调理器的性能得到了极大提升。未来，我们将继续对控制器和调理器举行体系性的性能优化。
相关的详细测试陈诉，请参考 [Performance] Overview of performance improvements for v1.15 。致谢贡献者

Karmada v1.15 版本包罗了来自 39 位贡献者的 269 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：

@abhi0324	@abhinav-1305	@Arhell
@Bhaumik10	@CaesarTY	@cbaenziger
@deefreak	@dekaihu	@devarsh10
@greenmoon55	@iawia002	@jabellard
@jennryaz	@liaolecheng	@linyao22
@LivingCcj	@liwang0513	@mohamedawnallah
@mohit-nagaraj	@mszacillo	@RainbowMango
@ritzdevp	@ryanwuer	@samzong
@seanlaii	@SunsetB612	@tessapham
@wangbowen1401	@warjiang	@wenhuwang
@whitewindmills	@whosefriendA	@XiShanYongYe-Chang
@zach593	@zclyne	@zhangsquared
@zhuyulicfc49	@zhzhuang-zju	@zzklachlan

参考资料

[1] Karmada: Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration | karmada[2] Karmada v1.15: https://github.com/karmada-io/karmada/releases/tag/v1.15.0[3] 多 Pod 模板支持: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/multi-podtemplate-support[4] [Performance] Overview of performance improvements for v1.15: https://github.com/karmada-io/karmada/issues/6516[5] GitHub地点：https://github.com/karmada-io/karmada 点击关注，第一时间了解华为云新鲜技术~ 

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