Karmada 多集群调度污点容忍度Taint TolerationE2E 测试覆盖分析【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada导读本文基于 Karmada 仓库中 test/e2e/suites/base/coverage_docs/tainttoleration_test.md 这份 E2E 测试覆盖分析文档深入解读基于污点与容忍度的调度Schedule Based on Taints and Tolerations这一多集群调度特性。文章将串联该文档对应的端到端测试用例源码、调度器底层 TaintToleration 插件实现以及 API 定义帮助读者理解如何在成员集群上设置污点Taint、如何在 PropagationPolicy 的 Placement 中声明容忍度Toleration、调度器如何据此过滤候选集群以及该特性在仓库中的测试验证闭环。读完本文你将能够复现该 E2E 用例、读懂覆盖文档的追踪逻辑并掌握在实际多集群场景下使用污点容忍度做调度管控的完整方法。覆盖文档解读一条测试用例如何对应一项调度能力tainttoleration_test.md是 Karmada 测试套件中用于追踪 E2E 用例与用户功能文档对应关系的覆盖分析文档。其正文只有一张表格却精确描述了一项核心调度能力的测试状态Test CaseE2E Describe TextCommentsTest Deployment propagate with taint and tolerationdeployment with cluster tolerations testingSchedule Based on Taint Toleration三个字段分别对应Test Case面向用户的测试场景名称即携带污点与容忍度配置的 Deployment 传播E2E Describe TextGinkgo 测试框架中实际注册的It用例文本用于在测试日志中快速定位Comments该用例所验证的功能在官方用户指南中的主题——基于污点与容忍度的调度即调度器在选集群时会参考成员集群的污点与调度策略中声明的容忍度。这类覆盖文档的作用是防止测试与文档脱节开发者通过它核对文档宣称的能力是否有对应测试守护。它本身不是完整教程而是追踪表要完整理解该特性需要结合仓库中对应的测试源码、调度插件与 API 定义这正是本文接下来要展开的内容。对应的 E2E 测试tainttoleration_test.go全流程拆解覆盖文档中的 deployment with cluster tolerations testing 用例实现在 test/e2e/suites/base/tainttoleration_test.go 中。测试以 Ginkgo 框架编写外层使用framework.SerialDescribe(propagation with taint and toleration testing, ...)声明为串行执行——因为该用例会向所有成员集群添加污点影响其他并发用例的调度结果必须独占执行环境。前置为每个成员集群构造唯一的污点在BeforeEach中测试会为所有成员集群打上NoSchedule污点污点 key 固定为cluster-toleration.karmada.iovalue 为各集群自身的名字taints : constructAddedTaints(tolerationKey, clusterName) // constructAddedTaints 生成 // corev1.Taint{Key: tolerationKey, Value: clusterName, Effect: corev1.TaintEffectNoSchedule} clusterObj.Spec.Taints append(clusterObj.Spec.Taints, taints...) err controlPlaneClient.Update(context.TODO(), clusterObj)即每个集群最终携带形如cluster-toleration.karmada.iomember1:NoSchedule的污点。写入操作通过gomega.Eventually轮询完成保证控制面更新成功后再继续。核心在 PropagationPolicy 中声明 ClusterTolerations测试同时构造了一个指向所有成员集群的 PropagationPolicy并在Placement.ClusterTolerations中声明一条只容忍第一个成员集群的容忍度tolerationKey cluster-toleration.karmada.io tolerationValue framework.ClusterNames()[0] clusterTolerations []corev1.Toleration{ { Key: tolerationKey, Operator: corev1.TolerationOpEqual, Value: tolerationValue, Effect: corev1.TaintEffectNoSchedule, }, } policy helper.NewPropagationPolicy(policyNamespace, policyName, []policyv1alpha1.ResourceSelector{...}, policyv1alpha1.Placement{ ClusterAffinity: policyv1alpha1.ClusterAffinity{ ClusterNames: framework.ClusterNames(), }, ClusterTolerations: clusterTolerations, })这里的容忍度语义与 Kubernetes Pod 的 Toleration 完全一致OperatorEqual、Key/Value精确匹配、EffectNoSchedule表示容忍 key 为cluster-toleration.karmada.io、value 为首个集群名、效果为 NoSchedule 的污点。断言Deployment 只会被调度到被容忍的集群调度器同步集群污点变更后测试预留了 1 秒等待窗口用例通过framework.ExtractTargetClustersFromRB从 ResourceBinding 中提取实际调度目标集群并断言gomega.Eventually(func(g gomega.Gomega) { targetClusterNames : framework.ExtractTargetClustersFromRB( controlPlaneClient, deployment.Kind, deployment.Namespace, deployment.Name) g.Expect(len(targetClusterNames)).Should(gomega.Equal(1)) g.Expect(targetClusterNames[0]).Should(gomega.Equal(tolerationValue)) }, pollTimeout, pollInterval).Should(gomega.Succeed())验证结论尽管 ClusterAffinity 将全部成员集群都列为候选但只有被容忍的那个集群进入最终调度结果其余携带不可容忍污点的集群全部被过滤。这正对应覆盖文档中 Test Deployment propagate with taint and toleration 的语义。清理恢复集群原始状态AfterEach中通过removeTargetFromSource将测试添加的污点从集群Spec.Taints中剔除避免污染后续用例clusterObj.Spec.Taints removeTargetFromSource(clusterObj.Spec.Taints, constructAddedTaints(tolerationKey, clusterName))其中removeTargetFromSource使用corev1.Taint.MatchTaint做匹配逐个移除与目标污点等价的条目。底层原理TaintToleration 调度插件如何过滤集群E2E 用例验证的调度行为在源码层面由调度器的TaintToleration插件实现位于 pkg/scheduler/framework/plugins/tainttoleration/taint_toleration.go。该插件实现了framework.FilterPlugin接口是调度框架的过滤环节之一并注册在插件注册表中见 pkg/scheduler/framework/plugins/registry.go 中的tainttoleration.Name: tainttoleration.New。其核心过滤逻辑Filter分三步已调度集群豁免如果集群已经出现在 ResourceBinding 的调度结果bindingSpec.TargetContains(cluster.Name)中直接返回 Success。源码注释说明原因此时若工作负载无法容忍该污点将由 taint-manager 在宽限期后驱逐而非由调度器干预。只关注两类 effectfilterPredicate仅匹配TaintEffectNoSchedule与TaintEffectNoExecute两种效果的污点PreferNoSchedule不参与硬性过滤。匹配不可容忍污点调用v1helper.FindMatchingUntoleratedTaint用bindingSpec.Placement.ClusterTolerations逐一匹配集群的污点。存在不可容忍污点则返回framework.Unschedulable附带原因字符串cluster(s) had untolerated taint {%s}否则放行。需要特别留意的是源码中还注释了一个版本相关的实现细节Kubernetes v1.35 为容忍度引入了Lt、Gt比较运算符但 Karmada 当前通过enableComparisonOperatorsfalse显式关闭该能力以维持向后兼容行为。也就是说当前版本的 Karmada 集群级容忍度只支持 Kubernetes 原有的运算符语义Equal/Exists。该插件的单元测试位于 pkg/scheduler/framework/plugins/tainttoleration/taint_toleration_test.go覆盖四种典型场景可作为理解插件行为的快速参考测试场景输入要点期望结果cluster already in target clusters集群已在调度结果中Success豁免no taints集群无污点Successtolerated taint容忍度与污点 Key/Value/Effect 完全匹配Successuntolerated taint集群有污点但无对应容忍度Unschedulable原因包含cluster(s) had untolerated taint {key1value1:NoSchedule}API 定义污点写在哪里容忍度声明在哪里该特性涉及两处 API 字段均可从仓库源码确认1. 集群污点Cluster.Spec.Taints成员集群的污点定义在 Cluster API 中见 pkg/apis/cluster/v1alpha1/types.go// Taints are attached to the member cluster. // Taints on the cluster have the effect on // any resource that does not tolerate the Taint. // optional Taints []corev1.Taint json:taints,omitempty字段直接复用 Kubernetes 标准corev1.Taint类型可通过kubectl edit cluster name或直接 patch 该字段的方式为成员集群打污点。E2E 测试正是通过控制面客户端修改此字段来模拟真实污点。2. 策略容忍度Placement.ClusterTolerations调度策略侧在PropagationPolicy/ClusterPropagationPolicy共用的Placement结构中声明容忍度见 pkg/apis/policy/v1alpha1/propagation_types.go// ClusterTolerations represents the tolerations. // optional ClusterTolerations []corev1.Toleration json:clusterTolerations,omitempty一个可复制的完整 PropagationPolicy 示例等价于 E2E 用例的声明式写法apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-taint-toleration spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1 - member2 clusterTolerations: - key: cluster-toleration.karmada.io operator: Equal value: member1 effect: NoSchedule调度时Placement.ClusterTolerations会被携带进 ResourceBinding 的Placement字段供 TaintToleration 插件在过滤阶段读取使用。关联能力ClusterTaintPolicy 自动打污点污点不仅支持手工维护Karmada 还提供ClusterTaintPolicy根据集群条件自动增删污点。虽然覆盖文档tainttoleration_test.md本身未提及但其姊妹用例 test/e2e/suites/base/clustertaintpolicy_test.go 与之形成完整闭环当集群的NetworkReady、StorageReady等条件变为False/Unknown时自动添加NoSchedule/NoExecute污点条件恢复True后自动移除并产生TaintClusterSucceed事件。两者配合的典型运维场景是先由 ClusterTaintPolicy 根据集群健康状态自动打污点再由调度策略中的 ClusterTolerations 决定哪些工作负载可以容忍异常集群从而在多集群环境中实现精细化、声明式的调度准入控制。如何在本地运行该 E2E 测试该用例属于基础套件base suites随 Karmada E2E 测试框架整体运行。仓库提供了完整的本地拉起环境脚本通过 hack/local-up-karmada.sh 搭建包含控制面与若干成员集群的测试环境运行基础套件 E2E含本用例或以 Ginkgo focus 方式只运行污点容忍度用例# 运行全部 base 套件其中包含本用例串行执行 go test ./test/e2e/suites/base/... # 只运行污点容忍度相关用例 go test ./test/e2e/suites/base/... -ginkgo.focuspropagation with taint and toleration测试日志中可通过deployment with cluster tolerations testing定位本用例与覆盖文档的 E2E Describe Text 字段一致并通过日志中的update taints(...) of cluster(...)观察污点的添加与清理过程。小结tainttoleration_test.md虽然只有一行表格却是一条连接用户文档、E2E 用例、调度实现三者的索引。通过本文的展开可以看到完整链路E2E 用例 tainttoleration_test.go 验证声明容忍度后Deployment 只调度到被容忍的集群调度器侧 TaintToleration 插件 taint_toleration.go 是过滤逻辑的真正执行者而 propagation_types.go 与 types.go 分别定义了容忍度与污点的 API 承载。三者对照阅读即可完整掌握 Karmada 基于污点与容忍度的多集群调度机制。【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考