CrashLoopBackOff的解決辦法之一

2020-03-21 18:01:00

問題來源

# 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 啟動成功後，這個問題出現。

解決思路

先看了 kubectl logs pods alertmanager-858b7749c5-6jsfh -n assembly，沒啥發現
再 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的注釋，重新開機配置檔案，問題點又消失了，連模拟都沒模拟出來。

先将這個問題給記錄下來，等待再出現了，好好搞一番。

這也算是一種解決辦法吧

過手如登山，一步一重天