配置KEDA的Azure Function无法调度至Virtual Kubelet节点运行

核心排查点 #

• KEDA扩容Pod未继承调度规则：这是最高发的问题。你在Deployment YAML里写的toleration、节点选择规则，仅对手动创建的初始Pod生效，KEDA根据队列积压自动扩容出的新Pod，默认不会自动携带这些配置，必须把调度规则写到对应ScaledObject资源的配置中，否则扩容出的Pod永远用默认调度逻辑，只会跑到普通节点。
• 污点容忍规则不匹配：不要凭记忆写Virtual Kubelet的污点，先执行kubectl describe node <你的虚拟节点名称> | grep Taints拿到节点实际的污点配置，确认toleration的key、value、effect三个字段和实际污点完全一致，Azure Virtual Node默认污点是virtual-kubelet.io/provider=azure:NoSchedule，任意字段拼写错误都会导致容忍失效。
• 仅配置容忍未配置调度强制规则：toleration的作用只是让Pod“可以被调度到”带对应污点的节点，不是“必须调度到”该类节点。如果普通节点有剩余资源，K8s调度器默认会优先把Pod分配到普通节点。要实现固定调度到虚拟节点，需要给虚拟节点打专属标签，配置nodeAffinity或nodeSelector强制约束Pod调度目标，也可以给普通节点加对应污点，阻止Function Pod落地。
• 集群准入Webhook篡改调度配置：你提到Pod始终调度到普通节点的node-agent上，大概率是集群部署的node-agent对应的Mutating Webhook自动给Pod注入了节点亲和性规则，强制绑定到部署了node-agent的普通节点。需要给Function Pod配置对应豁免标签，跳过该Webhook的修改逻辑。

正确配置参考 #

在KEDA的ScaledObject资源中通过advanced.podTemplate字段指定扩容Pod的调度规则，示例配置如下：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: queue-function-scaler
spec:
  scaleTargetRef:
    name: your-azure-function-app-deployment
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: azure-queue
      metadata:
        queueName: your-function-trigger-queue
        connection: StorageConnectionString
  # 关键：给KEDA扩容出的所有Pod注入调度规则
  advanced:
    podTemplate:
      spec:
        tolerations:
          - key: "virtual-kubelet.io/provider"
            operator: "Equal"
            value: "azure"
            effect: "NoSchedule"
        nodeSelector:
          type: virtual-node # 替换为你的虚拟节点实际绑定的标签

验证步骤 #

1. 应用更新后的ScaledObject配置，删除当前跑在普通节点上的所有Function旧Pod
2. 往触发队列里塞消息触发KEDA扩容，等新Pod创建完成后执行kubectl describe pod <新Pod名称>
3. 检查Pod的spec中是否正确携带了配置的toleration和nodeSelector规则，同时查看Events栏的调度日志，确认是否有调度报错
4. 确认新Pod的spec中没有被Webhook注入额外的节点亲和性规则

内容的提问来源于stack exchange，提问作者Karthikeyan VK