如何基于节点池/污点为同一Deployment配置不同的资源限制？

这个问题我之前帮团队解决类似需求时太有共鸣了——拆分两个Deployment确实会给KEDA扩缩容添不少麻烦，毕竟目前ScaledObject还不支持同时关联多个Deployment。给你几个亲测可行的方案，都是基于同一Deployment实现动态资源调整的：

方案一：Mutating Admission Webhook 动态修改Pod资源 #

这是最灵活也最推荐的方式，完全不影响原有的Deployment结构和KEDA配置：

• 先给节点打标签/配置污点区分类型：给所有arm节点打上统一标签（比如node-arch=arm64-weak），或者给它们加专属污点（比如node-type=arm:PreferNoSchedule），x86节点对应打上node-arch=x86-strong
• 开发一个简单的Mutating Webhook：当Kubernetes创建Pod的时候，这个Webhook会在准入阶段介入，判断该Pod要调度到的节点类型（可以通过节点标签，或者Pod的容忍度反推目标节点）
• 动态调整资源：如果判断是arm节点，就把Pod spec里容器的CPU request和limit乘以1.5。比如Deployment里原本配置的是requests.cpu: "1"，Webhook会自动改成"1500m"，x86节点的Pod则保持原配置。这里给你个核心逻辑的伪代码示例：

# 伪代码：Webhook核心处理逻辑
def mutate_pod_resource(pod, cluster_nodes):
    # 先获取Pod要调度的目标节点
    target_node = get_scheduled_node(pod, cluster_nodes)
    if not target_node:
        return pod  # 无法确定节点时保持原配置
    
    # 判断节点类型
    if target_node.labels.get("node-arch") == "arm64-weak":
        for container in pod.spec.containers:
            # 处理CPU request
            cpu_req = container.resources.requests.get("cpu", "1000m")
            # 转换为毫核计算
            if cpu_req.endswith("m"):
                cpu_m = int(cpu_req[:-1])
            else:
                cpu_m = int(float(cpu_req) * 1000)
            # 乘以1.5倍
            new_cpu_m = int(cpu_m * 1.5)
            container.resources.requests["cpu"] = f"{new_cpu_m}m"
            # 同步修改limit
            if "cpu" in container.resources.limits:
                container.resources.limits["cpu"] = f"{new_cpu_m}m"
    return pod

• 部署Webhook并配置触发规则：确保这个Webhook只针对你的目标Deployment的Pod，避免影响集群里其他应用

⚠️ 踩坑提醒：Webhook要配置好容错策略，比如failurePolicy=Ignore，防止Webhook挂了导致Pod无法创建；另外要做好高可用，比如多副本部署Webhook服务

方案二：RuntimeClass + 资源策略注入 #

如果你的集群已经在用RuntimeClass管理容器运行时，可以用这个更轻量的方案：

• 创建两个RuntimeClass：分别对应x86和arm节点，比如rc-x86和rc-arm，通过nodeSelector绑定到对应的节点池
• 用集群策略工具配置规则：当Pod使用rc-arm这个RuntimeClass时，自动注入1.5倍的CPU资源限制；使用rc-x86时保持原配置
• 自动匹配RuntimeClass：可以通过Webhook在Pod创建时自动给它匹配对应的RuntimeClass，无需手动修改Deployment的核心配置

方案三：自定义调度器扩展 #

如果你的集群已经在使用自定义调度器，或者愿意替换默认调度器，可以用这个方案：

• 选择支持动态修改Pod资源的自定义调度器，或者给默认调度器添加扩展插件
• 配置调度器规则：当调度Pod到arm节点时，自动将CPU的request和limit乘以1.5
• 这个方案灵活性也很高，但需要改动集群的调度器配置，风险比前两个略高，适合有一定集群定制经验的团队

最后给你个小技巧：Deployment里的CPU配置可以直接写x86节点的标准值，比如1000m，这样Webhook或者调度器只需要针对arm节点做乘法即可，不用做复杂的多分支判断，维护起来更简单

备注：内容来源于stack exchange，提问作者yotamN