Karmada v0.10 版本新特性解析Resource Interpreter Webhook、动态权重调度与跨集群观测【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada本文基于 Karmada 官方变更记录 CHANGELOG-0.10.md 展开系统讲解 v0.10 版本交付的三大核心能力Resource Interpreter Webhook 框架让自定义资源获得与原生资源同等的传播能力、dynamicWeight与Job分片调度增强以及kubectl karmada get跨集群资源观测命令。读完本文你可以理解自定义资源接入 Karmada 传播体系的完整机制、动态权重复制分摊的计算原理并掌握从控制面统一观测成员集群工作负载的方法。一、Karmada v0.10 交付了哪些能力Karmada v0.10 的版本记录围绕三个主题组织新特性Whats New包括 Resource Interpreter Webhook、调度能力增强、跨集群工作负载观测三大块其他重要变更Other Notable Changes则涵盖 estimator 行为调整、对象标签迁移、Bug 修复与可观测性埋点等内容。从源码结构看这几块能力分别落在以下模块特性仓库中对应的实现位置Resource Interpreter Webhookpkg/resourceinterpreter/、pkg/webhook/interpreter/dynamicWeight / Job 分片调度pkg/apis/policy/v1alpha1/propagation_types.go、pkg/scheduler/core/kubectl karmada getpkg/karmadactl/get/get.go事件/状态埋点pkg/events/events.go、pkg/apis/work/v1alpha2/binding_types.go下面按变更记录的原始脉络逐一展开。二、Resource Interpreter Webhook教会 Karmada 理解你的自定义资源2.1 设计动机在资源即 resource template传播到成员集群的过程中Karmada 会根据资源定义采取行动。例如在构建ResourceBinding阶段karmada-controller-manager会解析Deployment等资源的replicas字段而对没有replicas的资源则不做处理。对于 Kubernetes 原生资源Karmada 内置了解析知识但对于自定义资源类型CRD由于不了解其结构Karmada 只能把它当作普通资源处理。v0.10 引入的Resource Interpreter Webhook框架正是解决这一问题的方案用户可以实现自己的 CRD 插件在传播流程的各个环节被 Karmada 咨询。借助该框架CRD 和 CR 将像 Kubernetes 原生资源一样被传播也就是说所有调度原语scheduling primitives都支持自定义资源。官方提案见 Resource Interpreter Webhook Proposal仓库同时提供了完整的示例工程与工具位于 examples/customresourceinterpreter/。2.2 配置 APIResourceInterpreterWebhookConfiguration框架受 Kubernetes Admission Webhook 的启发由两个 API 构成一个声明启用哪些 webhook 的配置 APIResourceInterpreterWebhookConfiguration定义在config.karmada.io组一个声明 Karmada 与 webhook 之间请求/响应格式的消息 APIResourceInterpreterContext。配置对象的核心结构摘自提案文档type ResourceInterpreterWebhookConfiguration struct { metav1.TypeMeta json:,inline metav1.ObjectMeta json:metadata,omitempty // Webhooks 是需要启用的 webhook 及其作用资源与操作的列表。 Webhooks []ResourceInterpreterWebhook json:webhooks } type ResourceInterpreterWebhook struct { // Name 是 webhook 的完全限定名。 Name string json:name // ClientConfig 定义如何与 webhook 通信。 ClientConfig admissionregistrationv1.WebhookClientConfig json:clientConfig // Rules 描述该 webhook 关注的操作和资源。 Rules []RuleWithOperations json:rules,omitempty // TimeoutSeconds 指定 webhook 超时时间1~30 秒默认 10 秒。 TimeoutSeconds *int32 json:timeoutSeconds,omitempty // InterpreterContextVersions 是 Webhook 期望的 ResourceInterpreterContext // 版本有序列表Karmada 会优先使用列表中它支持的第一个版本。 InterpreterContextVersions []string json:interpreterContextVersions }其中RuleWithOperations是操作Operations与资源APIGroups/APIVersions/Kinds的元组APIGroups、APIVersions、Kinds三个字段都支持*通配出现*时切片长度必须为 1核心组的 group 为空需写成[]。2.3 消息 API 与操作集合InterpreterOperationInterpreterOperation表示 Karmada 在整个传播过程中可能调用 webhook 的请求类型这也是本框架的扩展点所在操作含义*InterpreterOperationAll匹配所有操作InterpretReplica让 webhook 解释资源声明的副本数仅适用于带副本声明的资源类型ReviseReplica请求 webhook 按目标值修改副本数InterpretStatus解释如何获取状态适用于状态不在.status路径的特殊资源Prune解释如何将资源模板打包进 WorkRetain请求 webhook 决定期望资源模板中哪些本地变更需要保留适用于成员集群控制器会回写.spec的资源AggregateStatus解释如何把各集群状态聚合回资源模板InterpretHealth解释如何判断资源的健康状态InterpretDependency解释资源的依赖关系如 Deployment 依赖 ConfigMap/Secret使依赖可随资源一起传播对应的请求/响应消息ResourceInterpreterContext包含Request与Response两部分Request携带UID用于 Karmada 与 webhook 之间关联日志、Kind、Name、Namespace、Operation、资源对象Object以及在特定操作下才填充的ObservedObject仅Retain操作来自成员集群的观测对象、DesiredReplicas仅ReviseReplica操作、AggregatedStatus各集群状态列表等字段Response则按需回填Replicas、ReplicaRequirements、Dependencies、RawStatus、Healthy以及 JSONPatch 格式的Patch当前仅支持 RFC 6902 的JSONPatch。提案中的两条用户故事说明了典型使用场景让自定义工作负载参与副本调度你的自定义资源与Deployment高度相似、带有replica字段希望通过ReplicaScheduling规则把副本分到多个集群。没有该框架时Karmada 因不了解结构而无法读取副本数自定义本地值保留retain策略成员集群中的控制器会修改资源如更新.spec中的字段你希望 Karmada 保留这些变更。没有该框架时Karmada 可能无法正确保留导致资源在 Karmada 与你的控制器之间被反复来回修改。2.4 配置示例与请求/响应示例下面是一个声明了两个 webhook 的配置示例foo.example.com服务于foo.example.com组的Foo实现Retain与InterpretHealthbar.example.com服务于bar.example.com组的Bar实现InterpretDependency与InterpretHealthapiVersion: config.karmada.io/v1alpha1 kind: ResourceInterpreterWebhookConfiguration metadata: name: example webhooks: - name: foo.example.com rules: - operations: [Retain, InterpretHealth] apiGroups: [foo.example.com] apiVersions: [*] kinds: [Foo] clientConfig: url: https://xxx:443/explore-foo caBundle: {{caBundle}} interpreterContextVersions: [v1alpha1] timeoutSeconds: 3 - name: bar.example.com rules: - operations: [InterpretDependency, InterpretHealth] apiGroups: [bar.example.com] apiVersions: [*] kinds: [Bar] clientConfig: url: https://xxx:443/explore-bar caBundle: {{caBundle}} interpreterContextVersions: [v1alpha1] timeoutSeconds: 3以InterpretHealth为例Karmada 发送的请求形如apiVersion: config.karmada.io/v1alpha1 kind: ResourceInterpreterContext request: uid: xxx kind: group: foo.example.com version: v1alpha1 kind: Foo name: foo namespace: default operation: InterpretHealth object: 资源的原始数据webhook 响应形如apiVersion: config.karmada.io/v1alpha1 kind: ResourceInterpreterContext response: uid: xxx # 与请求中的 uid 相同 successful: true healthy: true2.5 仓库中的实现与示例从源码结构看该框架的调用入口在 pkg/resourceinterpreter/interpreter.go其中Webhook 解释器的具体实现位于 pkg/resourceinterpreter/customized/webhook/包含 webhook 配置管理configmanager/、请求属性解析request/与服务端点解析serviceresolvers.goKarmada 对原生资源的默认解释逻辑位于 pkg/resourceinterpreter/default/native/按操作拆分为 replica.go、revisereplica.go、retain.go、aggregatestatus.go、healthy.go、dependencies.go 与 prune/ 等文件可以对照各操作逐一理解默认行为除了 webhook 方式仓库还演进出了基于 Lua 声明式的解释器 pkg/resourceinterpreter/customized/declarative/并对 Argo Workflows、KubeRay、Flux、Volcano 等第三方生态资源内置了定制配置见 pkg/resourceinterpreter/default/thirdparty/resourcecustomizations/。完整的可运行示例见 examples/customresourceinterpreter/包含示例 CRD 定义 workload.example.io_workloads.yaml、webhook 服务端 examples/customresourceinterpreter/webhook/app/、webhook 配置 karmada-interpreter-webhook-example.yaml 以及配套的资源与 PropagationPolicy是上手该框架最直接的参考。三、调度能力显著增强3.1 dynamicWeight按可用副本数动态分配权重v0.10 为PropagationPolicy与ClusterPropagationPolicy引入了dynamicWeight原语对应上游 PR #841。开启后副本可以按一个动态权重列表划分每个集群的权重在调度时基于其可用副本数available replicas实时计算出来从而显著平衡各集群的利用率。在类型定义中dynamicWeight位于ReplicaSchedulingStrategy的WeightPreferenceClusterPreferences下源码见 pkg/apis/policy/v1alpha1/propagation_types.go// ClusterPreferences describes weight for each cluster or for each group of cluster. type ClusterPreferences struct { // StaticWeightList defines the static cluster weight. StaticWeightList []StaticClusterWeight json:staticWeightList,omitempty // DynamicWeight specifies the factor to generates dynamic weight list. // If specified, StaticWeightList will be ignored. DynamicWeight DynamicWeightFactor json:dynamicWeight,omitempty } // DynamicWeightFactor represents the weight factor. // For now only support AvailableReplicas. type DynamicWeightFactor string const ( // DynamicWeightByAvailableReplicas 按可用资源available replicas生成集群权重列表。 DynamicWeightByAvailableReplicas DynamicWeightFactor AvailableReplicas )关键行为约束可直接从源码注释得到当前仅支持AvailableReplicas一种因子后续可按需扩展一旦指定dynamicWeightstaticWeightList将被忽略——动态权重优先于静态权重。类型定义中的注释给出了官方计算示例值得完整保留调度器选出了 A/B/C 三个集群需要分配 12 个副本。集群 A 最多可用 6 个副本、B 最多 12 个、C 最多 18 个则 A:B:C 的权重为 6:12:18即 1:2:3最终分配结果为 A: 2、B: 4、C: 6。结合ReplicaSchedulingStrategy的语义propagation_types.goreplicaSchedulingType为Divided时按有效候选集群划分副本replicaDivisionPreference为Weighted时按WeightPreference中的权重划分若只声明Weighted而未配置任何权重则所有集群等权。一个典型的声明写法为spec: replicaScheduling: replicaSchedulingType: Divided replicaDivisionPreference: Weighted weightPreference: dynamicWeight: AvailableReplicas3.2 Job 分片调度v0.10 引入了对Job的调度分片支持对应上游 PR #898期望多个副本的Job现在可以像Deployment一样被划分到多个集群这使得在若干小集群上运行超大型 Job 成为可能。从 examples/nginx/ 等示例使用的PropagationPolicy可见副本调度原语是策略声明层的一部分Job接入分片调度后同样由这些原语驱动。四、从 Karmada 控制面观测工作负载工作负载如 Deployment被传播到成员集群后用户往往还希望获取跨集群的整体状态尤其是每个Pod的状态。v0.10 为此在kubectl-karmada中引入了get子命令可以直接从 Karmada 控制面获取部署在成员集群中的各类资源。变更记录给出的示例输出$ kubectl karmada get deployment NAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTION nginx member2 1/1 1 1 19m Y nginx member1 1/1 1 1 19m Y $ kubectl karmada get pods NAME CLUSTER READY STATUS RESTARTS AGE nginx-6799fc88d8-vzdvt member1 1/1 Running 0 31m nginx-6799fc88d8-l55kk member2 1/1 Running 0 31m结合源码可以补充两点输出细节。该命令的实现位于 pkg/karmadactl/get/get.go其输出的ADOPTION列有三个取值get.go取值常量含义YmanagedByKarmada该资源由 Karmada 控制面托管NnotManagedByKaramda该资源位于成员集群但未受 Karmada 控制面管理-notApplicableKarmada 控制面自身资源不适用此外代码中还定义了CLUSTER、ADOPTION以及针对事件的EVENT附加列get.go说明该命令对 Pod、Event 等资源有定制化的列渲染逻辑而不仅是简单拼接原生kubectl get输出。五、其他重要变更变更记录的 Other Notable Changes 一节列出了以下值得关注的调整均附带了上游 PR 编号以便追溯karmada-scheduler-estimatorPR #777集群的 Pod 数量成为计算可用副本数时的重要参考因素。从 pkg/estimator/server/ 的 estimator 服务端实现可见可用副本估算会结合节点可分配资源与现有工作负载共同计算Work 对象标签迁移PR #752此前打在Work对象上的标签resourcebinding.karmada.io/namespace、resourcebinding.karmada.io/name、clusterresourcebinding.karmada.io/name已全部迁移为注解annotations。编写基于标签的选择器逻辑时需注意这一兼容性变化Bug 修复PR #817修复了集群 unjoin退出联邦对资源状态聚合的影响避免已退出集群的状态残留污染聚合结果Work 对象事件PR #800引入SyncFailed与SyncSucceed事件。在 pkg/events/events.go 中可确认这两个事件原因常量EventReasonSyncWorkloadFailed SyncFailed、EventReasonSyncWorkloadSucceed SyncSucceed且 pkg/controllers/binding/cluster_resource_binding_controller_test.go 中对事件触发行为有专门的测试断言ResourceBinding / ClusterResourceBinding 条件PR #823、PR #825分别引入Scheduled与FullyApplied条件。FullyApplied在 pkg/apis/work/v1alpha2/binding_types.go 中定义为“资源已被完全应用于所有相关集群”的状态条件且两个 Binding 类型的 printcolumn 中都有对应的FULLYAPPLIED列kubectl get时可直接查看Cluster 对象事件PR #749引入CreateExecutionNamespaceFailed与RemoveExecutionNamespaceFailed事件用于观测为成员集群创建/删除执行命名空间时的失败工作队列指标PR #831为karmada-agent与karmada-controller-manager引入workqueue_adds_total、workqueue_depth、workqueue_longest_running_processor_seconds、workqueue_queue_duration_seconds_bucket等指标便于监控控制器队列健康度karmada-scheduler 特性门控PR #805调度器引入 feature gates 机制从 pkg/scheduler/scheduler.go 的调度器组装逻辑可以看出其特性注册入口karmada-controller-manager 删除行为PR #970成员集群中删除资源时默认采用Background删除选项加快删除速度。六、小结Karmada v0.10 是一次围绕传播能力下沉与可观测性补强的版本Resource Interpreter Webhook通过配置 APIResourceInterpreterWebhookConfiguration与消息 APIResourceInterpreterContext把InterpretReplica、Retain、AggregateStatus、InterpretDependency等操作开放给用户使 CRD 获得与原生资源一致的副本调度、状态聚合与健康判断能力dynamicWeight: AvailableReplicas让副本按集群实时可用容量加权划分配合Weighted划分偏好可显著平衡集群利用率Job 分片则把多副本 Job 纳入了同样的调度原语kubectl karmada get让成员集群中的 Deployment、Pod 等资源的跨集群状态可以在控制面统一查看ADOPTION列明确区分了受管与不受管资源事件SyncSucceed/SyncFailed、条件Scheduled/FullyApplied与工作队列指标共同补齐了传播链路的观测手段。如果需要在实际集群中验证这些能力建议从 examples/customresourceinterpreter/ 的 webhook 示例与 samples/nginx/ 的 PropagationPolicy 示例入手并配合 docs/command-line-flags/karmadactl_get.md 了解get命令的完整参数。【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考