下面列举下可能原因和解决方法。
节点资源不够
节点资源不够有以下几种情况:
CPU 负载过高 剩余可以被分配的内存不够 剩余可用 GPU 数量不够 (通常在机器学习场景,GPU 集群环境)
如果判断某个
Node
资源是否足够? 通过
kubectl describe node Allocatable : 表示此节点能够申请的资源总和 Allocated resources : 表示此节点已分配的资源 (Allocatable 减去节点上所有 Pod 总的 Request)
如果 Pod 包含 nodeSelector 指定了节点需要包含的 label,调度器将只会考虑将 Pod 调度到包含这些 label 的 Node 上,如果没有 Node 有这些 label 或者有这些 label 的 Node 其它条件不满足也将会无法调度。参考官方文档:https://kubernetes.io/docs/concepts/configuration/assign-pod- node/#nodeselector nodeAffinity: 节点亲和性,可以看成是增强版的 nodeSelector,用于限制 Pod 只允许被调度到某一部分 Node。 podAffinity: Pod 亲和性,用于将一些有关联的 Pod 调度到同一个地方,同一个地方可以是指同一个节点或同一个可用区的节点等。 podAntiAffinity: Pod 反亲和性,用于避免将某一类 Pod 调度到同一个地方避免单点故障,比如将集群 DNS 服务的 Pod 副本都调度到不同节点,避免一个节点挂了造成整个集群DNS 解析失败,使得业务中断。
Capacity:
cpu: 2
ephemeral-storage: 9217Mi
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 2031912Ki
pods: 110
Allocatable:
cpu: 1600m
ephemeral-storage: 9217Mi
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 1452355993
pods: 110
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 350m (21%) 0 (0%)
memory 70Mi (5%) 170Mi (12%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
前者与后者相减,可得出剩余可申请的资源。如果这个值小于
Pod
的
request
,就不满足
Pod
的
资源要求,
Scheduler
在
Predicates (预选) 阶段就会剔除掉这个 Node
,也就不会调度上去。
[root@master ~]# kubectl get pod -n kube-system -o wide
coredns-674d655c65-k8x88 1/1 Running 0 19d 10.233.70.1 master



