Kubernetes节点资源耗尽状态的处理

发表于 | 分类于 | 浏览 次

最近发现测试环境的k8s集群，总有node利用不上，pod漂移过去之后，启动不了，故仔细排查了一下缘由！

问题现象

1
2
3
4
5
6
7
8
[root@master35 scripts]# ./list_pod.sh | grep imis
imis-866d46c464-nvz4b                       0/1       ContainerCreating   0          3m        <none>          node149

发现有的pod无法启动，刚开始describe查了下原因，看到，一直在拉镜像状态中，但是3分钟了，也不至于镜像拉不下来啊！

查看了下node149的状态，发现
Warning: “EvictionThresholdMet Attempting to reclaim nodefs”
发现大概应该是由于磁盘原因造成的，也可以看下kubelet日志，也会报这个类似的错误

原因分析

1
2
3
4
5
6
7
8
[root@node149 ~]# df -h
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/cl-root        36G  30G   6G  86% /
devtmpfs                  7.8G     0  7.8G   0% /dev
tmpfs                     7.8G     0  7.8G   0% /dev/shm
tmpfs                     7.8G  9.3M  7.8G   1% /run
tmpfs                     7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda1                1014M  186M  829M  19% /boot
1
由于这是测试环境，所以docker的目录，默认在/var/lib/docker，没有单独挂载别的目录，这样的话，也没加定时任务清理磁盘，/ 磁盘就会越来越满，现在看是用了86%

由于某些原因，我们的那个portal pod必须运行于该node上（通过nodeSelector选定node的方式）。在无法扩充根分区size的情况下，为了临时恢复pod运行，我们只能进一步“压榨”node了。于是我们的思路是：通过调整node的eviction threshold值来让node恢复healthy。

解决方案

每个node上的kubelet都负责定期采集资源占用数据，并与预设的 threshold值进行比对，如果超过 threshold值，kubelet就会尝试杀掉一些Pod以回收相关资源，对Node进行保护。kubelet关注的资源指标threshold大约有如下几种： 

1
2
3
4
5
- memory.available
- nodefs.available
- nodefs.inodesFree
- imagefs.available
- imagefs.inodesFree

每种threshold又分为eviction-soft和eviction-hard两组值。soft和hard的区别在于前者在到达threshold值时会给pod一段时间优雅退出，而后者则崇尚“暴力”，直接杀掉pod，没有任何优雅退出的机会。这里还要提一下nodefs和imagefs的区别： 

1
2
nodefs: 指node自身的存储，存储daemon的运行日志等，一般指root分区/；
imagefs: 指docker daemon用于存储image和容器可写层(writable layer)的磁盘；

解决步骤

我们需要为kubelet重新设定nodefs.available的threshold值。怎么做呢？

kubelet是运行于每个kubernetes node上的daemon，它在system boot时由systemd拉起:

1
2
3
root@master35 ~# ps -ef|grep kubelet
root      5718  5695  0 16:38 pts/3    00:00:00 grep --color=auto kubelet
root     13640     1  4 10:25 ?        00:17:25 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cadvisor-port=0

查看一下kubelet service的状态： 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@master35 scripts]# systemctl status kubelet               
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Thu 2018-07-19 21:04:35 CST; 8 months 29 days ago
     Docs: http://kubernetes.io/docs/
 Main PID: 1921 (kubelet)
    Tasks: 19
   Memory: 54.9M
   CGroup: /system.slice/kubelet.service
           └─1921 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=...

Apr 14 09:26:16 master35 kubelet[1921]: W0414 09:26:16.673359    1921 reflector.go:341] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: watch o...(56737582)
Apr 15 06:36:48 master35 kubelet[1921]: W0415 06:36:48.938194    1921 reflector.go:341] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: watch o...(56940044)

我们定义一个新的Environment var，比如就叫：KUBELET_EVICTION_POLICY_ARGS 在/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

1
2
3
Environment="KUBELET_EVICTION_POLICY_ARGS=--eviction-hard=nodefs.available<5%"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_EXTRA_ARGS $KUBELET_EVICTION_POLICY_ARGS

这样控制，node的磁盘策略为<5%的硬盘就可以用，不像之前默认的15%就用不了了！

Donate