CrashLoopBackOff的解決辦法之一

問題來源

# kubectl get pods -n assembly
NAME                              READY   STATUS             RESTARTS   AGE
alertmanager-858b7749c5-6jsfh     0/1     CrashLoopBackOff   3          82s

昨天晚上還好好的，今天在做jenkins和gitlab集成時，啟動了jenkins pod ，而jenkiins pod又與prometheus pod 運行與一台虛機。而jenkins pod 啟動成功后，這個問題出現。

解決思路

1. 先看了 kubectl logs pods alertmanager-858b7749c5-6jsfh -n assembly，沒啥發現
2. 再 describe pods alertmanager-858b7749c5-6jsfh -n assembly 又所發現

failed to write 10000 to cpu.cfs_quota_us: write /sys/fs/cgroup/cpu,cpuacct/kubepods/poddb4dcb1c-efe9-477a-af6b-a9cdd1aa6d72/xxxxxxx/cpu.cfs_quota_us: invalid argument\\\"\"": unknown

cpu emmm --> 資源限制出問題了？

解決方案

既然懷疑到cpu限制這塊了 就像resources部分給注釋掉

# cat alertmanager-deployment.yaml 
		 resources:
       requests:
         cpu: 100m
         memory: 256Mi
       limits:
         cpu: 100m
         memory: 256Mi
         
重啟 alertmanager-deployment.yaml 
# kubectl get pods -n assembly
NAME                              READY   STATUS    RESTARTS   AGE
alertmanager-76fd475999-t7cln     1/1     Running   0          6m42s

問題解決了

疑問

不對啊 因為的bs-k8s-node01節點分配了7.7個G。資源是夠的

# kubectl top nodes
NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%     
20.0.0.204  711m         18%    1552Mi          21%    

顯然問題點沒找的不對。google了半天 ，沒發現啥有價值的思路。
再次模擬問題，取消resources的注釋，重啟配置文件，問題點又消失了，連模擬都沒模擬出來。
先將這個問題給記錄下來，等待再出現了，好好搞一番。
這也算是一種解決辦法吧