记录一次由kubernetes驱逐策略造成的业务故障

故障描述

某年某月某日，监控显示部分业务不正常，线上反馈业务出现偶尔失败现象。

故障分析

登录master查看容器，发现部分pod处于0/1状态，进容器内查看业务进程消失不见了，日志没有啥异常。查看message日志发现大量oom，由于节点内存使用率过高，导致系统杀掉部分进程释放内存。重新启动进程恢复业务，防止再次出现故障赶紧好好学习下k8s的相关驱逐策略。

k8s驱逐策略

可压缩资源和不可压缩资源

可压缩资源：CPU
在压缩资源部分已经提到CPU属于可压缩资源，当pod使用超过设置的limits值，pod中进程使用cpu会被限制，但不会被kill。

不可压缩资源：内存、硬盘
Kubernetes通过cgroup给pod设置QoS级别，当资源不足时先kill优先级低的pod，在实际使用过程中，通过OOM分数值来实现，OOM分数值从0-1000。
可通过/proc/pid/oom_score查看分数

pod优先级

在排查问题发现，并非全部业务进程被杀掉，考虑是否能够设置优先级，让重要的业务不被kill，可以通过下面两种方式实现

pod资源配置

Guaranteed：limits和requests值一样
Burstable：limits和requests值不同
Best-Effort：requests与limits均未设置
优先级Guaranteed > Burstable > Best-Effort

自定义优先级

创建PriorityClasses

apiVersion: scheduling.k8s.io/v1alpha1 
kind: PriorityClass 
metadata: 
name: high-priority 
value: 1000000 
globalDefault: false 
description: "high-priority"

在yaml中添加

priorityClassName: high-priority

通过上述方式当节点资源无法满足调度pod时触发抢占，会尝试删除满足调度的节点上优先级比当前pod低的pod，进行优雅的删除，超过优雅时长则强制删除

主机资源不足

这次出现问题由于内存使用率过高导致，还有哪些资源使用过高也会触发驱逐策略，怎么配置？

定义驱逐策略：

–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

软驱逐：

–eviction-soft:描述驱逐阈值，例如：memory.available<1.5G
–eviction-soft-grace-period:驱逐宽限期，memory.available=1m30s
–eviction-max-pod-grace-period:终止pod最大宽限时间，单位s

硬驱逐：

–eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi
–eviction-minimum-reclaim=“memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi”`
–system-reserved=memory=1.5Gi