一、背景及措施
虽然最近Kubernetes测试群集的Pod状态出现了Evicted现象，但项目仍然可以正常提供服务。 最初的解决方案是手动删除Evicted状态的Pod。
查看已激活状态的pod [ ops @ dev-gate~] # kubectlgetpods-n staging-services|grepevictedeureka-server-02-7f 658 c4dfc-] 1查看evicted 0176 d search-engine-79c 875 CB c8-q4hfx0/1evicted 06 D3 h # describe pod中的一个详细信息[ops@dev-gate ~]# ubectldescribepodeureka-server-02-7f 658 c4dfc-zwt qk-n staging-services name 3360 eureka-server-02-7f 658 c4dfc-4558 . 80.25 /开始时间： tue， 0 jul 2019153360:3360380800 labels : app=eureka-server-02 pod-template-hash=7f 658 C4 DFC annotations 3360 nestatus ce : ephemeral-storage.containereureka-server-02 wasusing 961720 ki， whichexceedsitsrequestof0. IP : IPS : nonecontrolledby : replicaset/eureka-server-02-7f 658 C4 DFC containers : eureka-server-023360 image : registry-VPC.AP-southeast-5.aliy us rt : none requests 3360 CPU :250 m memory :512 mi environment 3360 lang 3360 en age : en _ us : enlc _ all 3: en _ u u u u u u us.utut JDK1.8.0_ 152 a liyun _ logs _ eureka-server/eureka-server-error * a liyun _ logs _ eureka-server-info : eureka-server/from volumn-SLS-15644718371690 (rw )/var/run/secrets/kubernetes.io/serviceacccooor volumes 3360 medium :大小限制： unset default-token-t8 rfx : type : secret (avolumepopulatedbyasecret ) secretname3360default
seQoS Class: BurstableNode-Selectors: <none>Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300sEvents: <none>注意观察 Message 信息: The node was low on resource: ephemeral-storage. Container eureka-server-02 was using 961720Ki, which exceeds its request of 0。
由此可见是 Node 节点资源过低造成的 Pod 驱逐 , 先去 Node 节点查看 Disk / Memory / CPU 的使用情况 , 然后做相应的处理。
[ops@gddxnk1aj2xznytv5w52w8r7kZ ~]# df -ThFilesystem Type Size Used Avail Use% Mounted on/dev/vda1 ext4 50G 42G 5.0G 90% /此次的故障原因是磁盘使用率过高 , 处理好 Node 节点后 , 再去 Master 节点删除 Evicted 状态的Pod。
[ops@dev-gate ~]# kubectl get pods -n staging-services | grep 'Evicted' | awk '{print $1}' | xargs kubectl delete pod -n stagingpod "eureka-server-02-7f658c4dfc-zwtqk" deletedpod "fica-service-5fcd4d777d-k2bsp" deletedpod "search-engine-79c875cbc8-q4hfx" deleted二、为什么 Pod 会被驱逐
Kubernetes 节点上的资源会被 Pod 以及系统进程所使用 , 如果没有做任何限制的话 , 节点上的资源会被耗尽 , 相应的后果也可想而知:
1、集群问题: 如果节点上调度了很多的 Pod , 而且没有做 limit(限制容器使用资源) 限制 , 节点资源肯定被耗尽 , 系统进程也会发生OOM , 因为 Pod 是 Deployment 在控制 , 它会重新调度到其它 Node 节点运行 , 这就造成了一个恶性循环 , 引起集群的雪崩。
2、系统进程问题: 如果在设置了 limit 限制 , 那如果 Node 节点资源不足 , 容器也会出现问题。
因此 , Kubernetes 要做资源的预留和 Pod 的驱逐 , 以保证节点的正常运行。
三、Kubernetes 的做法
经过翻阅资料得知 , 此限制是通过Node组件 kubelet 进行配置
[ops@gddxn8vb409m8717rqugzuqylZ kubernetes]# vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf[Service]Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests"Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-迷人的吐司-dir=/opt/cni/迷人的吐司"Environment="KUBELET_DNS_ARGS=--enable-controller-attach-detach=false --cluster-dns=1.2.3.4 --pod-infra-container-image=registry-vpc.cn-zhangjiakou.aliyuncs.com/acs/pause-amd64:3.0 --enable-load-reader --cluster-domain=cluster.local --cloud-provider=external --hostname-override=cn-zhangjiakou.1.2.3.4 --provider-id=cn-zhangjiakou.i-8vb409m8717rqugzuqyl"Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"Environment="KUBELET_CGROUP_ARGS=--system-reserved=memory=300Mi --kube-reserved=memory=400Mi --eviction-hard=imagefs.available<15%,memory.available<300Mi,nodefs.available<10%,nodefs.inodesFree<5% --cgroup-driver=systemd"Environment="KUBELET_CERTIFICATE_ARGS=--tls-cert-file=/var/lib/kubelet/pki/kubelet.crt --tls-private-key-file=/var/lib/kubelet/pki/kubelet.key --anonymous-auth=false --rotate-certificates=true --cert-dir=/var/lib/kubelet/pki"ExecStart=ExecStart=/usr/迷人的吐司/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CGROUP_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS主要参数说明:
--system-reserved=memory=300Mi # 为system进程预留内存300M --kube-reserved=memory=400Mi # 为kube组件预留内存 400M imagefs.available<15% # 指docker daemon用于存储image和容器可写层(writable layer)的磁盘memory.available<300Mi # 内存小于300M时 , 驱逐Podnodefs.available<10% # 指node自身的存储，存储daemon的运行日志等，一般指root分区 /nodefs.inodesFree<5% # inode小于%5 , 驱逐Pod既然知道了配置文件的配置方法 , 我们就可以根据自己的需求去修改这些阈值。
四、Kubernetes以什么标准去驱逐Pod
答案是QoS(服务质量等级) , 是作用在 Pod 上的一个配置 , Qos等级包括:
Guaranteed: limits 和 request 相等Burstable: limit 和 request 不相等BestEffort: 没有限制由此可见 , Kubernetes是通过配置 limits 和 requests 的值大小来评定 QoS。
三种等级示例:
# Guaranteed 等级 spec: containers: - name: nginx-demo image: nginx resources: limits: cpu: 200m memory: 200Mi requests: cpu: 200m memory: 200Mi ports: - containerPort: 80 # Burstable 等级 spec: containers: - name: nginx-demo image: nginx resources: limits: cpu: 200m memory: 200Mi requests: cpu: 20m memory: 20Mi ports: - containerPort: 80 # BestEffort 等级 spec: containers: - name: nginx-demo image: nginx ports: - containerPort: 80对于CPU而言: 当 Pod 使用 CPU 超过设置的 limits 限制 , Pod不会被 Kill 但是会被限制
对于内存而言: 当 Pod 使用 Memory 超过了 limits 限制 ，Pod 中的 容器中进程会被 Kill , Kubernetes会尝试重启或调度到其它Node节点
当集群监控到 Node 节点的内存或者CPU资源到达阈值时 , 就会触发资源回收策略 , 通过驱逐节点上的Pod来减少资源占用。
QoS驱逐优先级:
BestEffort --> Burstable --> Guaranteed
五、配置建议
将不是很关键的服务 Qos 等级设置为 Burstable 或者 BestEffort。
资源充足的话 , Pod 等级可以设置为 Guaranteed。