Kubernetes Pod Evicted

一、背景以及措施

近日 Kubernetes 测试集群 Pod 状态出现 Evicted 现象 , 但是项目还是能正常提供服务 , 最先的解决办法是手动将 Evicted 状态的 Pod 删除。

# 查看 Evicted 状态的 Pod
[ops@dev-gate ~]# kubectl get pods  -n staging-services | grep Evicted 
eureka-server-02-7f658c4dfc-zwtqk             0/1     Evicted            0          288d
fica-service-5fcd4d777d-k2bsp                 0/1     Evicted            0          176d
search-engine-79c875cbc8-q4hfx                0/1     Evicted            0          6d3h

# describe 查看其中一个 Pod 的详细信息
[ops@dev-gate ~]# kubectl describe pod eureka-server-02-7f658c4dfc-zwtqk -n staging-services
Name:           eureka-server-02-7f658c4dfc-zwtqk
Namespace:      staging-services
Priority:       0
Node:           ap-southeast-5.192.168.80.25/
Start Time:     Tue, 30 Jul 2019 15:30:38 +0800
Labels:         app=eureka-server-02
                pod-template-hash=7f658c4dfc
Annotations:    <none>
Status:         Failed
Reason:         Evicted
Message:        The node was low on resource: ephemeral-storage. Container eureka-server-02 was using 961720Ki, which exceeds its request of 0. 
IP:             
IPs:            <none>
Controlled By:  ReplicaSet/eureka-server-02-7f658c4dfc
Containers:
  eureka-server-02:
    Image:      registry-vpc.ap-southeast-5.aliyuncs.com/jakarta-services/eureka-server:staging
    Port:       <none>
    Host Port:  <none>
    Requests:
      cpu:     250m
      memory:  512Mi
    Environment:
      LANG:                             en_US.UTF-8
      LANGUAGE:                         en_US:en
      LC_ALL:                           en_US.UTF-8
      JAVA_HOME:                        /usr/local/jdk1.8.0_152
      aliyun_logs_eureka-server-error:  /data/serviceLogs/eureka-server/eureka-server-error*
      aliyun_logs_eureka-server-info:   /data/serviceLogs/eureka-server/eureka-server-info*
    Mounts:
      /data/serviceLogs/eureka-server/ from volumn-sls-15644718371690 (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-t8rfx (ro)
Volumes:
  volumn-sls-15644718371690:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  default-token-t8rfx:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-t8rfx
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <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@iZk1aj2xznytv5w52w8r7kZ ~]# df -Th
Filesystem                                                              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 staging
pod "eureka-server-02-7f658c4dfc-zwtqk" deleted
pod "fica-service-5fcd4d777d-k2bsp" deleted
pod "search-engine-79c875cbc8-q4hfx" deleted

二、为什么 Pod 会被驱逐

Kubernetes 节点上的资源会被 Pod 以及系统进程所使用 , 如果没有做任何限制的话 , 节点上的资源会被耗尽 , 相应的后果也可想而知:

1、集群问题: 如果节点上调度了很多的 Pod , 而且没有做 limit(限制容器使用资源) 限制 , 节点资源肯定被耗尽 , 系统进程也会发生OOM , 因为 Pod 是 Deployment 在控制 , 它会重新调度到其它 Node 节点运行 , 这就造成了一个恶性循环 , 引起集群的雪崩。

2、系统进程问题: 如果在设置了 limit 限制 , 那如果 Node 节点资源不足 , 容器也会出现问题。

因此 , Kubernetes 要做资源的预留和 Pod 的驱逐 , 以保证节点的正常运行。

三、Kubernetes 的做法

经过翻阅资料得知 , 此限制是通过Node组件 kubelet 进行配置

[ops@iZ8vb409m8717rqugzuqylZ 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-bin-dir=/opt/cni/bin"
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/bin/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时 , 驱逐Pod
nodefs.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。