故障描述
某年某月某日，监控显示部分业务不正常，线上反馈业务出现偶尔失败现象。
故障分析
登录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
