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的注释，重启配置文件，问题点又消失了，连模拟都没模拟出来。
先将这个问题给记录下来，等待再出现了，好好搞一番。
这也算是一种解决办法吧