Azure AKS中kube-scheduler节点亲和性配置引发的调度崩溃问题分析

Azure AKS中kube-scheduler节点亲和性配置引发的调度崩溃问题分析

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS

问题背景

在Azure Kubernetes Service(AKS)的某些版本中，用户发现当集群中存在配置了特定类型节点亲和性规则的Pod时，会导致kube-scheduler组件崩溃。这一问题影响了AKS的v1.27.14、v1.28.10和v1.29.5等多个Kubernetes版本。

问题现象

当集群中存在以下配置的Pod时，kube-scheduler会出现panic异常：

apiVersion: v1
kind: Pod
metadata:
  name: break-kube-scheduler
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - invalid-node # 指定了一个不存在的节点名称

这种情况下，kube-scheduler会完全停止工作，导致集群中所有新Pod都无法被调度。

技术分析

这个问题本质上是一个Kubernetes调度器的缺陷，具体表现为：

1. 节点亲和性验证不足：当Pod配置了matchFields类型的节点选择器，并且指定了不存在的节点名称时，调度器没有正确处理这种异常情况。

2. 错误处理机制缺失：调度器在处理这种无效配置时，没有实现适当的错误捕获和处理机制，导致直接panic。

3. 级联影响：由于kube-scheduler是控制平面的核心组件，它的崩溃会直接影响整个集群的调度功能，所有新创建的Pod都会处于Pending状态。

影响范围

该问题主要影响以下AKS版本：

• Kubernetes v1.27.14
• Kubernetes v1.28.10
• Kubernetes v1.29.5

解决方案

AKS团队已经采取了以下措施：

1. 紧急修复：AKS工程师已经为所有受影响的集群部署了修复补丁。

2. 自动更新：修复程序会通过AKS的常规更新机制自动推送到所有区域。

3. 版本更新：建议用户升级到更高版本的AKS，这些版本已经包含了针对此问题的修复。

最佳实践建议

为避免类似问题，建议用户：

1. 谨慎配置节点亲和性：特别是使用matchFields选择器时，确保指定的节点名称确实存在。

2. 测试环境验证：在生产环境部署前，先在测试环境中验证Pod配置的正确性。

3. 版本升级策略：保持AKS集群版本更新，及时应用安全补丁和错误修复。

4. 监控调度状态：设置监控告警，及时发现调度器异常情况。

总结

这次事件凸显了Kubernetes调度器在处理边缘情况时的重要性。AKS团队快速响应并修复问题的做法值得肯定，同时也提醒我们在使用高级调度功能时需要格外谨慎。通过遵循最佳实践和保持系统更新，可以最大限度地减少此类问题对业务的影响。

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS