一、背景以及措施
近日 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 以及系统进程所使用 , 如果没有做任何限制的话 , 节点上的资源会被耗尽 , 相应的后果也可想而知:
- 集群问题: 如果节点上调度了很多的 Pod , 而且没有做 limit(限制容器使用资源) 限制 , 节点资源肯定被耗尽 , 系统进程也会发生OOM , 因为 Pod 是 Deployment 在控制 , 它会重新调度到其它 Node 节点运行 , 这就造成了一个恶性循环 , 引起集群的雪崩
- 系统进程问题: 如果在设置了 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。
评论区