版權聲明：本文為博主原創文章，支持原創，轉載請附上原文出處鏈接和本聲明。
本文地址：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時會被終止