在GKE Autopilot集群部署Azure Arc时诊断作业调度失败求助
2026-7-21
GKE Autopilot+Azure Arc诊断Job失败的排查方向
核对节点污点与Pod容忍度
GKE Autopilot节点自带专属污点，比如node.kubernetes.io/unschedulable:NoSchedule这类。Azure Arc的诊断Pod如果没配置对应容忍度，根本无法被调度。- 执行
kubectl describe node <节点名>查看节点的污点列表 - 检查诊断Job的Pod模板，确认是否包含匹配的容忍度。若没有，可修改Helm部署参数添加容忍度，或手动给Job补充容忍度配置
- 执行
检查Pod资源请求是否超出Autopilot限制
Autopilot对单Pod的CPU/内存请求管控严格，即便GCP全局配额充足，Pod请求若超出节点可用资源或Autopilot阈值，就会处于Pending状态。- 执行
kubectl describe pod <Pending状态的Pod名>查看Requests字段的资源要求 - 对照Autopilot节点的默认规格（通常为固定CPU/内存配置），调整Pod的资源请求至合理范围，修改Helm部署参数即可
- 执行
验证Arc服务账号的权限
诊断Job需要访问集群节点、配额等信息，Autopilot对Pod权限限制严格，权限不足会导致Job执行失败。- 执行
kubectl describe sa <Arc服务账号名> -n <Arc命名空间>查看绑定的权限，确认是否具备足够的API访问权限
- 执行
排查网络策略限制
Autopilot默认可能启用网络策略，阻止诊断Pod与K8s API Server通信，进而导致Pod初始化失败。- 查看Arc命名空间下的网络策略：
kubectl get networkpolicy -n <Arc命名空间> - 若存在拦截策略，添加一条允许诊断Pod访问API Server的规则
- 查看Arc命名空间下的网络策略：
手动测试简化版Pod
自动部署的Job可能存在参数问题，可手动创建临时Pod测试：- 使用与诊断Job相同的镜像，配置相同的资源请求和容忍度，编写yaml文件创建Pod
- 执行
kubectl describe pod <临时Pod名>查看详细事件，获取更具体的调度失败原因
内容的提问来源于stack exchange，提问作者williamohara
相关产品推荐
相关产品推荐
