版权声明：本文为博主原创文章，支持原创，转载请附上原文出处链接和本声明。
本文地址：https://www.cnblogs.com/wannengachao/p/13821469.html
1、执行 kubectl get pod --all-namespaces|grep -Ev '1/1|2/2|3/3|Com
查看到Pod长时处于ContainerCreating状态，见下图：
2、kubectl describe pod $Pod名
输出结果见下：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 15m (x33 over 66m) kubelet MountVolume.SetUp failed for volume "volumn-eds-certs" : mount failed: fork/exec /usr/bin/systemd-run: cannot allocate memory
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/fee6bf33-0a03-11eb-95b5-00163e0115c9/volumes/kubernetes.io~secret/volumn-eds-certs --scope -- mount -t tmpfs tmpfs /var/lib/kubelet/pods/fee6bf33-0a03-11eb-95b5-00163e0115c9/volumes/kubernetes.io~secret/volumn-eds-certs
Output:
Warning FailedMount 11m (x35 over 66m) kubelet MountVolume.SetUp failed for volume "default-token-bdxkl" : mount failed: fork/exec /usr/bin/systemd-run: cannot allocate memory
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/fee6bf33-0a03-11eb-95b5-00163e0115c9/volumes/kubernetes.io~secret/default-token-bdxkl --scope -- mount -t tmpfs tmpfs /var/lib/kubelet/pods/fee6bf33-0a03-11eb-95b5-00163e0115c9/volumes/kubernetes.io~secret/default-token-bdxkl
Output:
Warning FailedMount 5m41s (x27 over 64m) kubelet Unable to mount volumes for pod "test-trade-3-pre-b9471abd-4318-4210-9334-d01c5b2d01a3-7c7569pls8_default(fee6bf33-0a03-11eb-95b5-00163e0115c9)": timeout expired waiting for volumes to attach or mount for pod "default"/"test-trade-3-pre-b9471abd-4318-4210-9334-d01c5b2d01a3-7c7569pls8". list of unmounted volumes=[volumn-eds-certs default-token-bdxkl]. list of unattached volumes=[volumn-eds-certs default-token-bdxkl]
3、查看每个node的CPU与内存资源情况，结果查看到node的资源规格是32C、64g并且使用率才50％左右，于是想是否Pod的requests设置的超过了node资源，通过kubectl get rs $异常Pod的rs名 -oyaml 发现设置的limits与requests值是4c、8g没有超过node的自身资源，因为每个Pod的limits与requests不是我本人设置的，怀疑是否有其它的Pod设置的requests过大，导致node被Pod请求资源时没有富余的内存给此Pod。排查发现所有Pod的limits与requests都是4c、8g，最后导致如我猜测的一样node被Pod请求资源时没有富余的内存给此Pod。
4、解决方案：将Pod的limits与requests调小即可。为Pod设置limits与requests谨记设成实际够用的资源即可，如果确实Pod会使用到过大的资源，那就将node扩容下，避免出现Pod向node请求资源时出现资源不足的情况。
5、下面内容是在网上看到的讲解reques、limits比较不错的，在此贴出来分享下：
requests
requests用于schedule阶段，在调度pod保证所有pod的requests总和小于node能提供的计算能力
requests.cpu被转成docker的--cpu-shares参数，与cgroup cpu.shares功能相同
设置容器的cpu的相对权重
该参数在CPU资源不足时生效，根据容器requests.cpu的比例来分配cpu资源
CPU资源充足时，requests.cpu不会限制container占用的最大值，container可以独占CPU
requests.memory没有对应的docker参数，作为k8s调度依据
使用requests来设置各容器需要的最小资源
limits
limits限制运行时容器占用的资源
limits.cpu会被转换成docker的–cpu-quota参数。与cgroup cpu.cfs_quota_us功能相同
限制容器的最大CPU使用率。
cpu.cfs_quota_us参数与cpu.cfs_period_us结合使用，后者设置时间周期
k8s将docker的–cpu-period参数设置100毫秒。对应着cgroup的cpu.cfs_period_us
limits.cpu的单位使用m，千分之一核
limits.memory会被转换成docker的–memory参数。用来限制容器使用的最大内存
当容器申请内存超过limits时会被终止