GKE自动扩缩容新节点时工作负载身份DaemonSet与应用Pod调度冲突问题

问题分析 #

生产集群启用GKE工作负载身份后，依赖的gke-metadata-server DaemonSet在节点自动扩缩容时，调度晚于业务应用Pod，导致应用初始化BigQuery Client时调用元数据服务器失败重启。即便给DaemonSet配置了优先级类仍未生效，核心原因通常是优先级类配置不匹配或调度器的系统关键Pod处理逻辑未被触发。

具体解决方案 #

1. 确保DaemonSet使用最高优先级类 #

GKE的gke-metadata-server属于节点关键组件，必须配置Kubernetes内置的system-node-critical优先级类（这是系统级最高优先级，会被调度器优先处理）：

• 检查当前DaemonSet的优先级配置：

  kubectl get daemonset gke-metadata-server -n kube-system -o yaml | grep -A 3 priorityClassName
  

• 若配置的不是system-node-critical，编辑DaemonSet更新：

  kubectl edit daemonset gke-metadata-server -n kube-system
  

  在spec.template.spec下添加/修改：

  priorityClassName: system-node-critical
  

2. 降低业务应用Pod的优先级 #

给业务应用配置低优先级类，确保调度器优先处理关键DaemonSet：

• 创建低优先级类：

  apiVersion: scheduling.k8s.io/v1
  kind: PriorityClass
  metadata:
    name: app-low-priority
  value: 100
  globalDefault: false
  description: "低优先级，用于等待节点关键组件就绪的业务Pod"
  

• 在应用的Deployment/StatefulSet的Pod模板中指定该优先级类：

  spec:
    template:
      spec:
        priorityClassName: app-low-priority
        # 其他配置...
  

3. 给应用Pod添加启动等待逻辑（兜底方案） #

如果优先级调整仍无法解决，通过Init容器强制等待元数据服务器就绪后再启动应用：

spec:
  template:
    spec:
      initContainers:
      - name: wait-for-metadata-server
        image: busybox:1.36
        command: ['sh', '-c', 'until wget -qO- http://localhost:8080/healthz > /dev/null; do echo "等待元数据服务器就绪..."; sleep 2; done']
      containers:
      # 业务容器配置...

（注：gke-metadata-server默认监听8080端口，/healthz为健康检查端点）

4. 排查DaemonSet调度阻塞点 #

如果以上操作无效，检查DaemonSet是否存在调度障碍：

• 检查节点污点容忍配置：确保gke-metadata-server能容忍新节点的所有污点
• 查看调度事件：kubectl describe node <新节点名称>，检查是否有调度失败的事件日志

内容的提问来源于stack exchange，提问作者sarath s kumar