背景

某天突然发现自己的测试环境中有Evicted状态的pod，于是需要排查原因。先来看看大致情况：

[root@k8s-m1 ~]# kubectl get pod -A -o wide|grep k8s-m1
kube-system   calico-kube-controllers-bcc6f659f-575mr   1/1     Running   3          177d   10.244.42.148   k8s-m1   <none>           <none>
kube-system   calico-node-79p6j                         1/1     Running   2          153d   192.168.2.140   k8s-m1   <none>           <none>
kube-system   coredns-6d56c8448f-l9xmz                  1/1     Running   58         178d   10.244.42.144   k8s-m1   <none>           <none>
kube-system   fluentd-elasticsearch-wk8xc               0/1     Evicted   0          14m    <none>          k8s-m1   <none>           <none>
kube-system   kube-apiserver-k8s-m1                     1/1     Running   304        328d   192.168.2.140   k8s-m1   <none>           <none>
kube-system   kube-controller-manager-k8s-m1            1/1     Running   364        131d   192.168.2.140   k8s-m1   <none>           <none>
kube-system   kube-proxy-dlw8r                          1/1     Running   23         262d   192.168.2.140   k8s-m1   <none>           <none>
kube-system   kube-scheduler-k8s-m1                     1/1     Running   312        188d   192.168.2.140   k8s-m1   <none>           <none>[root@k8s-m1 ~]# for i  in `kubectl get po -A -o wide|grep k8s-m1|awk '{print $2}'`; do echo $i ;kubectl describe po -n kube-system $i |grep QoS; done
calico-kube-controllers-bcc6f659f-575mr
QoS Class:       BestEffort
calico-node-79p6j
QoS Class:       Burstable
coredns-6d56c8448f-l9xmz
QoS Class:       Burstable
fluentd-elasticsearch-589ml
QoS Class:       Burstable
kube-apiserver-k8s-m1vim
QoS Class:         Burstable
kube-controller-manager-k8s-m1
QoS Class:         Burstable
kube-proxy-dlw8r
QoS Class:       BestEffort
kube-scheduler-k8s-m1
QoS Class:         Burstable[root@k8s-m1 ~]# kubectl describe po -n kube-system fluentd-elasticsearch-l2f4s 
.......
Events:Type     Reason     Age    From               Message----     ------     ----   ----               -------Normal   Scheduled  7m50s  default-scheduler  Successfully assigned kube-system/fluentd-elasticsearch-l2f4s to k8s-m1Warning  Evicted    7m51s  kubelet            The node had condition: [DiskPressure].[root@k8s-m1 ~]# grep usage /var/log/messages|tail -5 
Jan 29 09:16:07 k8s-m1 kubelet: I0129 09:16:07.491385   24420 image_gc_manager.go:304] [imageGCManager]: Disk usage on image filesystem is at 97% which is over the high threshold (85%). Trying to free 6582996172 bytes down to the low threshold (80%).
Jan 29 09:21:07 k8s-m1 kubelet: I0129 09:21:07.519727   24420 image_gc_manager.go:304] [imageGCManager]: Disk usage on image filesystem is at 97% which is over the high threshold (85%). Trying to free 6583295180 bytes down to the low threshold (80%).
Jan 29 09:26:07 k8s-m1 kubelet: I0129 09:26:07.544852   24420 image_gc_manager.go:304] [imageGCManager]: Disk usage on image filesystem is at 97% which is over the high threshold (85%). Trying to free 6575201484 bytes down to the low threshold (80%).
Jan 29 09:31:07 k8s-m1 kubelet: I0129 09:31:07.570142   24420 image_gc_manager.go:304] [imageGCManager]: Disk usage on image filesystem is at 97% which is over the high threshold (85%). Trying to free 6576725196 bytes down to the low threshold (80%).
Jan 29 09:36:07 k8s-m1 kubelet: I0129 09:36:07.595313   24420 image_gc_manager.go:304] [imageGCManager]: Disk usage on image filesystem is at 97% which is over the high threshold (85%). Trying to free 6575897804 bytes down to the low threshold (80%).[root@k8s-m1 ~]# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   38G   36G  1.3G  97% /
devtmpfs                 3.9G     0  3.9G   0% /dev
tmpfs                    3.9G     0  3.9G   0% /dev/shm
tmpfs                    3.9G  3.2M  3.9G   1% /run
tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1               1014M  185M  830M  19% /boot
/dev/mapper/centos-home   19G  353M   18G   2% /home

从上面可以看到当前节点上有一个处于Evicted状态的Pod，名为fluentd-elasticsearch-wk8xc，其对应的QoS Classs 为Burstable，而此时节点上pod的QoS Classs 还有BestEffort。同时通过describe发现该Evicted状态的pod是由于DiskPressure造成的。查看/var/log/messages日志中kubelet的相关日志发现是由于磁盘使用量达到97%（超过默认驱逐阈值85%）导致pod被驱逐。而事实上也如此，通过df查看系统根磁盘使用率已经达到97%。

节点压力驱逐

节点压力驱逐是 kubelet 主动终止 Pod 以回收节点上资源的过程。kubelet 监控集群节点的内存、磁盘空间和文件系统的 inode 等资源。 当这些资源中的一个或者多个达到特定的消耗水平， kubelet 可以主动地使节点上一个或者多个 Pod 失效，以回收资源防止饥饿。在节点压力驱逐期间，kubelet 将所选 Pod 的阶段设置为 Failed（Status） 并终止 Pod。

节点压力驱逐不同于 API 发起的驱逐。API 发起的驱逐是一个先调用 Eviction API 创建 Eviction 对象，再由该对象体面地中止 Pod 的过程。我们可以通过直接调用 Eviction API 发起驱逐，也可以通过编程的方式使用 API 服务器的客户端来发起驱逐， 比如常用的 kubectl drain 命令。 此操作创建一个 Eviction 对象，该对象再驱动 API 服务器终止选定的 Pod。

kubelet 并不理会配置的 PodDisruptionBudget 或者是 Pod 的 terminationGracePeriodSeconds。 如果使用了软驱逐条件，kubelet 会考虑所配置的 eviction-max-pod-grace-period。 而如果使用了硬驱逐条件，kubelet 使用 0s 宽限期（立即关闭）来终止 Pod。

自我修复行为

动态Pod的自我修复

kubelet 在终止最终用户 Pod 之前会尝试回收节点级资源。 例如，它会在磁盘资源不足时删除未使用的容器镜像。如果 Pod 是由替换失败 Pod 的工作负载资源 （例如 StatefulSet 或者 Deployment）管理， 则控制平面或 kube-controller-manager 会创建新的 Pod 来代替被驱逐的 Pod。

静态 Pod 的自我修复

如果是在面临资源压力的节点上运行静态 Pod，则 kubelet 可能会驱逐该静态 Pod。 由于静态 Pod 始终表示在该节点上运行 Pod 的意图，kubelet 会尝试创建替代 Pod。创建替代 Pod 时，kubelet 会考虑静态 Pod 的优先级。如果静态 Pod 清单指定了低优先级， 并且集群的控制平面内定义了优先级更高的 Pod，并且节点面临资源压力，则 kubelet 可能无法为该静态 Pod 腾出空间。 即使节点上存在资源压力，kubelet 也会继续尝试运行所有静态 pod。（可以理解为静态pod的优先级高）

驱逐信号和阈值

kubelet 使用各种参数来做出驱逐决定，如下所示：

• 驱逐信号
• 驱逐条件
• 监控间隔

驱逐信号

驱逐信号是特定资源在特定时间点的当前状态。 kubelet 使用驱逐信号，通过将信号与驱逐条件进行比较来做出驱逐决定， 驱逐条件是节点上应该可用资源的最小量。

Linux 系统中，kubelet 使用以下驱逐信号：

驱逐信号	描述
memory.available	memory.available := node.status.capacity[memory] - node.stats.memory.workingSet
nodefs.available	nodefs.available := node.stats.fs.available
nodefs.inodesFree	nodefs.inodesFree := node.stats.fs.inodesFree
imagefs.available	imagefs.available := node.stats.runtime.imagefs.available
imagefs.inodesFree	imagefs.inodesFree := node.stats.runtime.imagefs.inodesFree
pid.available	pid.available := node.stats.rlimit.maxpid - node.stats.rlimit.curproc

在上表中，描述列显示了 kubelet 如何获取信号的值。每个信号支持百分比值或者是字面值。 kubelet 计算相对于与信号有关的总量的百分比值。

注意：memory.available 的值来自 cgroupfs，而不是像 free -m 这样的工具。 这很重要，因为 free -m 在容器中不起作用，如果用户使用节点可分配资源 这一功能特性，资源不足的判定是基于 cgroup 层次结构中的用户 Pod 所处的局部及 cgroup 根节点作出的。 这个脚本https://kubernetes.io/zh-cn/examples/admin/resource/memory-available.sh或者 cgroupv2 脚本https://kubernetes.io/zh-cn/examples/admin/resource/memory-available-cgroupv2.sh 重现了 kubelet 为计算 memory.available 而执行的相同步骤。 kubelet 在其计算中排除了 inactive_file（非活动 LRU 列表上基于文件来虚拟的内存的字节数）， 因为它假定在压力下内存是可回收的。

kubelet 可识别以下两个特定的文件系统标识符：

• nodefs：节点的主要文件系统，用于本地磁盘卷、不受内存支持的 emptyDir 卷、日志存储等。 例如，nodefs 包含 /var/lib/kubelet/。
• imagefs：可选文件系统，供容器运行时存储容器镜像和容器可写层。
  kubelet 会自动发现这些文件系统并忽略节点本地的其它文件系统。kubelet 不支持其他配置。

一些 kubelet 垃圾收集功能已被弃用，以鼓励使用驱逐机制。

现有标志	原因
–maximum-dead-containers	一旦旧的日志存储在容器的上下文之外就会被弃用
–maximum-dead-containers-per-container	一旦旧的日志存储在容器的上下文之外就会被弃用
–minimum-container-ttl-duration	一旦旧的日志存储在容器的上下文之外就会被弃用

驱逐条件

我们可以为 kubelet 指定自定义驱逐条件，以便在作出驱逐决定时使用。 常用的设置有软性的和硬性的驱逐阈值区分。
驱逐条件的形式为 [eviction-signal][operator][quantity]，其中：

• eviction-signal 是要使用的驱逐信号。
• operator 是你想要的关系运算符， 比如 <（小于）。
• quantity 是驱逐条件数量，例如 1Gi。 quantity 的值必须与 Kubernetes 使用的数量表示相匹配。 可以使用文字值或百分比（%）。

例如，如果一个节点的总内存为 10GiB 并且你希望在可用内存低于 1GiB 时触发驱逐， 则可以将驱逐条件定义为 memory.available<10% 或 memory.available< 1G（二者任选其一）。

软驱逐条件

软驱逐条件将驱逐条件与管理员所必须指定的宽限期配对。 在超过宽限期之前，kubelet 不会驱逐 Pod。 如果没有指定的宽限期，kubelet 会在启动时返回错误。

可以既指定软驱逐条件宽限期，又指定 Pod 终止宽限期的上限，给 kubelet 在驱逐期间使用。 如果指定了宽限期的上限并且 Pod 满足软驱逐阈条件，则 kubelet 将使用两个宽限期中的较小者。 如果你没有指定宽限期上限，kubelet 会立即杀死被驱逐的 Pod，不允许其体面终止。

可以使用以下标志来配置软驱逐条件：

• eviction-soft：一组驱逐条件，如 memory.available<1.5Gi， 如果驱逐条件持续时长超过指定的宽限期，可以触发 Pod 驱逐。
• eviction-soft-grace-period：一组驱逐宽限期， 如 memory.available=1m30s，定义软驱逐条件在触发 Pod 驱逐之前必须保持多长时间。
• eviction-max-pod-grace-period：在满足软驱逐条件而终止 Pod 时使用的最大允许宽限期（以秒为单位）。

硬驱逐条件

硬驱逐条件没有宽限期。当达到硬驱逐条件时， kubelet 会立即杀死 pod，而不会正常终止以回收紧缺的资源。可以使用 eviction-hard 标志来配置一组硬驱逐条件， 例如 memory.available<1Gi。

kubelet 具有以下默认硬驱逐条件：

• memory.available<100Mi
• nodefs.available<10%
• imagefs.available<15%
• nodefs.inodesFree<5%（Linux 节点）

只有在没有更改任何参数的情况下，硬驱逐阈值才会被设置成这些默认值。 如果你更改了任何参数的值，则其他参数的取值不会继承其默认值设置，而将被设置为零。 为了使用自定义值，我们需要分别设置所有阈值。

驱逐监测间隔

kubelet 根据其配置的 housekeeping-interval（默认为 10s）评估驱逐条件。

节点状况

kubelet 报告节点状况以反映节点处于压力之下， 原因是满足硬性的或软性的驱逐条件，与配置的宽限期无关。

kubelet 将驱逐信号映射为节点状况如下表：

节点条件	驱逐信号	描述
MemoryPressure	memory.available	节点上的可用内存已满足驱逐条件
DiskPressure	nodefs.available、nodefs.inodesFree、imagefs.available 或 imagefs.inodesFree	节点的根文件系统或镜像文件系统上的可用磁盘空间和 inode 已满足驱逐条件
PIDPressure	pid.available	(Linux) 节点上的可用进程标识符已低于驱逐条件

控制平面还将这些节点状况映射为其污点。kubelet 根据配置的 --node-status-update-frequency 更新节点条件，默认为 10s。

节点状况波动

在某些情况下，节点在软驱逐条件上下振荡，而没有保持定义的宽限期。 这会导致报告的节点条件在 true 和 false 之间不断切换，从而导致错误的驱逐决策。为了防止振荡，可以使用 eviction-pressure-transition-period 标志， 该标志控制 kubelet 在将节点条件转换为不同状态之前必须等待的时间。 过渡期的默认值为 5m。

回收节点级资源

kubelet 在驱逐最终用户 Pod 之前会先尝试回收节点级资源。
当报告 DiskPressure 节点状况时，kubelet 会根据节点上的文件系统回收节点级资源。

有 imagefs

如果节点有一个专用的 imagefs 文件系统供容器运行时使用，kubelet 会执行以下操作：

• 如果 nodefs 文件系统满足驱逐条件，kubelet 垃圾收集死亡 Pod 和容器。
• 如果 imagefs 文件系统满足驱逐条件，kubelet 将删除所有未使用的镜像。

没有 imagefs

如果节点只有一个满足驱逐条件的 nodefs 文件系统， kubelet 按以下顺序释放磁盘空间：

• 对死亡的 Pod 和容器进行垃圾收集
• 删除未使用的镜像

kubelet 驱逐时 Pod 的选择

如果通过kubelet 回收节点级资源的尝试 没有使驱逐信号低于条件， 则 kubelet 开始驱逐最终用户 Pod。
kubelet 使用以下参数来确定 Pod 驱逐顺序：

• Pod 的资源使用是否超过其请求（包括cpu，内存）
• Pod 优先级
• Pod 相对于请求的资源使用情况（包括cpu，内存）

因此，kubelet 按以下顺序排列和驱逐 Pod：

• 首先考虑资源使用量超过其请求的 BestEffort 或 Burstable Pod。 这些 Pod 会根据它们的优先级以及它们的资源使用级别超过其请求的程度被逐出。
• 资源使用量少于请求量的 Guaranteed Pod 和 Burstable Pod 根据其优先级被最后驱逐。

说明：kubelet 不使用 Pod 的 QoS 类来确定驱逐顺序。 在回收内存等资源时，可以使用 QoS 类来估计最可能的 Pod 驱逐顺序。 QoS 分类不适用于临时存储（EphemeralStorage）请求， 因此如果节点在 DiskPressure 下，则上述场景将不适用。

当 Pod 中所有容器都被指定了请求和限制并且二者相等时那么该pod的Qos为Guaranteed ，可以保证 Pod 不被驱逐。 这些 Pod 永远不会因为另一个 Pod 的资源消耗而被驱逐。 如果系统守护进程（例如 kubelet 和 journald） 消耗的资源比通过 system-reserved 或 kube-reserved 分配保留的资源多， 并且该节点只有 Guaranteed 或 Burstable Pod 使用的资源少于其上剩余的请求， 那么 kubelet 必须选择驱逐这些 Pod 中的一个以保持节点稳定性并减少资源匮乏对其他 Pod 的影响。 在这种情况下，它会选择首先驱逐最低优先级的 Pod。

如果正在运行静态 Pod 并且希望避免其在资源压力下被驱逐，请直接为该 Pod 设置 priorityClassName 字段。

当 kubelet 因 inode 或 进程 ID 不足而驱逐 Pod 时， 它使用 Pod 的相对优先级来确定驱逐顺序，因为 inode 和 PID 没有对应的请求字段。

kubelet 根据节点是否具有专用的 imagefs 文件系统对 Pod 进行不同的排序：

有 imagefs

• 如果 nodefs 触发驱逐， kubelet 会根据 nodefs 使用情况（本地卷 + 所有容器的日志）对 Pod 进行排序。
• 如果 imagefs 触发驱逐，kubelet 会根据所有容器的可写层使用情况对 Pod 进行排序。

没有 imagefs

• 如果 nodefs 触发驱逐， kubelet 会根据磁盘总用量（本地卷 + 日志和所有容器的可写层）对 Pod 进行排序。

最小驱逐回收

在某些情况下，驱逐 Pod 只会回收少量的紧俏资源。 这可能导致 kubelet 反复达到配置的驱逐条件并触发多次驱逐。
你可以使用 --eviction-minimum-reclaim 标志或 kubelet 配置文件 为每个资源配置最小回收量。 当 kubelet 注意到某个资源耗尽时，它会继续回收该资源，直到回收到你所指定的数量为止。

例如，以下配置设置最小回收量：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:memory.available: "500Mi"nodefs.available: "1Gi"imagefs.available: "100Gi"
evictionMinimumReclaim:memory.available: "0Mi"nodefs.available: "500Mi"imagefs.available: "2Gi"

在这个例子中，如果 nodefs.available 信号满足驱逐条件， kubelet 会回收资源，直到信号达到 1GiB 的条件， 然后继续回收至少 500MiB 直到信号达到 1.5GiB。

类似地，kubelet 尝试回收 imagefs 资源，直到 imagefs.available 值达到 102Gi， 即 102 GiB 的可用容器镜像存储。如果 kubelet 可以回收的存储量小于 2GiB， 则 kubelet 不会回收任何内容。对于所有资源，默认的 eviction-minimum-reclaim 为 0。

节点内存不足行为

如果节点在 kubelet 能够回收内存之前遇到内存不足（OOM）事件， 则节点依赖 oom_killer 来响应。
kubelet 根据 Pod 的服务质量（QoS）为每个容器设置一个 oom_score_adj 值。

服务质量	oom_score_adj
Guaranteed	-997
BestEffort	1000
Burstable	min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
说明：kubelet 还将具有 system-node-critical （priorityClassName）优先级 的任何 Pod 中的容器 oom_score_adj 值设为 -997。

如果 kubelet 在节点遇到 OOM 之前无法回收内存， 则 oom_killer 根据它在节点上使用的内存百分比计算 oom_score， 然后加上 oom_score_adj 得到每个容器有效的 oom_score。 然后它会杀死得分最高的容器。

这意味着低 QoS Pod 中相对于其调度请求消耗内存较多的容器，将首先被杀死。与 Pod 驱逐不同，如果容器被 OOM 杀死， kubelet 可以根据其 restartPolicy 重新启动它。

实际应用

以下结合实际说明一下驱逐配置的好的做法。

可调度的资源和驱逐策略

当为 kubelet 配置驱逐策略时， 应该确保调度程序不会在 Pod 触发驱逐时对其进行调度，因为这类 Pod 会立即引起内存压力。
考虑以下场景：

节点内存容量：10GiB
我们希望为系统守护进程（内核、kubelet 等）保留 10% 的内存容量
操作员希望在节点内存利用率达到 95% 以上时驱逐 Pod，以减少系统 OOM 的概率。
为此，kubelet 启动设置如下：

--eviction-hard=memory.available<500Mi
--system-reserved=memory=1.5Gi

在此配置中，–system-reserved 标志为系统预留了 1GiB 的内存， 即 总内存的 10% + 驱逐条件量。

如果 Pod 使用的内存超过其请求值或者系统使用的内存超过 1Gi， 则节点可以达到驱逐条件，这使得 memory.available 信号低于 500MiB 并触发条件。

DaemonSets 和节点压力驱逐

Pod 优先级是做出驱逐决定的主要因素。 如果不希望 kubelet 驱逐属于 DaemonSet 的 Pod， 请在 Pod 规约中通过指定合适的 priorityClassName 为这些 Pod 提供足够高的 priorityClass。 你还可以使用较低优先级或默认优先级，以便仅在有足够资源时才运行 DaemonSet Pod。

已知问题

以下部分描述了与资源不足处理相关的已知问题。

kubelet 可能不会立即观察到内存压力

默认情况下，kubelet 轮询 cAdvisor 以定期收集内存使用情况统计信息。 如果该轮询时间窗口内内存使用量迅速增加，kubelet 可能无法足够快地观察到 MemoryPressure， 但是 OOM killer 仍将被调用。

可以使用 --kernel-memcg-notification 标志在 kubelet 上启用 memcg 通知 API，以便在超过条件时立即收到通知。

如果不是追求极端利用率，而是要采取合理的过量使用措施， 则解决此问题的可行方法是使用 --kube-reserved 和 --system-reserved 标志为系统分配内存。

active_file 内存未被视为可用内存

在 Linux 上，内核跟踪活动最近最少使用（LRU）列表上的基于文件所虚拟的内存字节数作为 active_file 统计信息。 kubelet 将 active_file 内存区域视为不可回收。 对于大量使用块设备形式的本地存储（包括临时本地存储）的工作负载， 文件和块数据的内核级缓存意味着许多最近访问的缓存页面可能被计为 active_file。 如果这些内核块缓冲区中在活动 LRU 列表上有足够多， kubelet 很容易将其视为资源用量过量并为节点设置内存压力污点，从而触发 Pod 驱逐。

更多关于kubernets的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出