如何在资源紧缺的情况下，保证 Node 的稳定性，是 Kubelet 需要面对的一个重要的问题。尤其对于内存和磁盘这种不可压缩的资源，紧缺就相当于不稳定。
在kubelet启动作为参数或者在配置文件中配置
驱逐策略
Kubelet 能够监控资源消耗，来防止计算资源被耗尽。一旦出现资源紧缺的迹象，Kubelet 就会主动终止一或多个 Pod 的运行，以回收紧俏资源。当一个 Pod 被终止时，其中的容器会全部停止，Pod 状态会被置为 Failed。
驱逐信号
下文中提到了一些信号，kubelet 能够利用这些信号作为决策依据来触发驱逐行为。描述列中的内容来自于 Kubelet summary API。
| 驱逐信号 | 描述 |
|---|---|
| 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 |
上面的每个信号都支持整数值或者百分比。百分比的分母部分就是各个信号的总量。kubelet 支持两种文件系统分区。
- nodefs：保存 kubelet 的卷和守护进程日志等。
- imagefs：在容器运行时，用于保存镜像以及可写入层。
imagefs 是可选的。Kubelet 能够利用 cAdvisor 自动发现这些文件系统。Kubelet 不关注其他的文件系统。所有其他类型的配置，例如保存在独立文件系统的卷和日志，都不被支持。
因为磁盘压力已经被驱逐策略接管，因此未来将会停止对现有 垃圾收集 方式的支持。
驱逐阈（yù，音同“预”）值：
一旦超出阈值，就会触发 kubelet 进行资源回收的动作。阈值的定义方式如下：
- 上面的表格中列出了可用的 eviction-signal.
- 仅有一个 operator 可用：<
- quantity 需要符合 Kubernetes 中的描述方式。
例如如果一个 Node 有 10Gi 内存，我们希望在可用内存不足 1Gi 时进行驱逐，就可以选取下面的一种方式来定义驱逐阈值：
- memory.available<10%
- memory.available<1Gi
驱逐软阈值
软阈值需要和一个宽限期参数协同工作。当系统资源消耗达到软阈值时，这一状况的持续时间超过了宽限期之前，Kubelet 不会触发任何动作。如果没有定义宽限期，Kubelet 会拒绝启动。
另外还可以定义一个 Pod 结束的宽限期。如果定义了这一宽限期，那么 Kubelet 会使用pod.Spec.TerminationGracePeriodSeconds 和最大宽限期这两个值之间较小的那个（进行宽限），如果没有指定的话，kubelet 会不留宽限立即杀死 Pod。
软阈值的定义包括以下几个参数：
- eviction-soft：描述一套驱逐阈值（例如 memory.available<1.5Gi ），如果满足这一条件的持续时间超过宽限期，就会触发对 Pod 的驱逐动作。
- eviction-soft-grace-period：包含一套驱逐宽限期（例如 memory.available=1m30s），用于定义达到软阈值之后，持续时间超过多久才进行驱逐。
- eviction-max-pod-grace-period：在因为达到软阈值之后，到驱逐一个 Pod 之前的最大宽限时间（单位是秒），
驱逐硬阈值
硬阈值没有宽限期，如果达到了硬阈值，kubelet 会立即杀掉 Pod 并进行资源回收。
硬阈值的定义：
- eviction-hard：描述一系列的驱逐阈值（比如说 memory.available<1Gi），一旦达到这一阈值，就会触发对 Pod 的驱逐，缺省的硬阈值定义是：
–eviction-hard=memory.available<100Mi
驱逐监控频率
Housekeeping interval 参数定义一个时间间隔，Kubelet 每隔这一段就会对驱逐阈值进行评估。
- housekeeping-interval：容器检查的时间间隔。
节点状况
Kubelet 会把驱逐信号跟节点状况对应起来。
如果触发了硬阈值，或者符合软阈值的时间持续了与其对应的宽限期，Kubelet 就会认为当前节点压力太大，下面的节点状态定义描述了这种对应关系。
| 节点状况 | 驱逐信号 | 描述 |
|---|---|---|
| MemoryPressure | memory.available | 节点的可用内存达到了驱逐阈值 |
| DiskPressure | nodefs.available, nodefs.inodesFree, imagefs.available, imagefs.inodesFree | 节点的 root 文件系统或者镜像文件系统的可用空间达到了驱逐阈值 |
Kubelet 会持续报告节点状态的更新过程，这一频率由参数 –node-status-update-frequency 指定，缺省情况下取值为 10s。
节点状况的波动
如果一个节点的状况在软阈值的上下波动，但是又不会超过他的宽限期，将会导致该节点的状态持续的在是否之间徘徊，最终会影响降低调度的决策过程。
要防止这种状况，下面的标志可以用来通知 Kubelet，在脱离压力状态之前，必须等待。
eviction-pressure-transition-period 定义了在跳出压力状态之前要等待的时间。
Kubelet 在把压力状态设置为 False 之前，会确认在周期之内，该节点没有达到逐出阈值。
回收节点级别的资源
如果达到了驱逐阈值，并且超出了宽限期，那么 Kubelet 会开始回收超出限量的资源，直到驱逐信号量回到阈值以内。
Kubelet 在驱逐用户 Pod 之前，会尝试回收节点级别的资源。如果服务器为容器定义了独立的 imagefs，他的回收过程会有所不同。
有 Imagefs
如果 nodefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。
- 删除死掉的 Pod/容器
如果 imagefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。
- 删掉所有无用镜像
没有 Imagefs
如果 nodefs 文件系统到达了驱逐阈值，kubelet 会按照下面的顺序来清理空间。
- 删除死掉的 Pod/容器
- 删掉所有无用镜像
驱逐用户 Pod
如果 Kubelet 无法获取到足够的资源，就会开始驱逐 Pod。
Kubelet 会按照下面的标准对 Pod 的驱逐行为进行评判：
- 根据服务质量
- 根据 Pod 调度请求的被耗尽资源的消耗量
接下来，Pod 按照下面的顺序进行驱逐：
- BestEffort：消耗最多紧缺资源的 Pod 最先失败。
- Burstable：相对请求（request）最多紧缺资源的 Pod 最先被驱逐，如果没有 Pod 超出他们的请求，策略会瞄准紧缺资源消耗量最大的 Pod。
- Guaranteed：相对请求（request）最多紧缺资源的 Pod 最先被驱逐，如果没有 Pod 超出他们的请求，策略会瞄准紧缺资源消耗量最大的 Pod。
Guaranteed Pod 绝不会因为其他 Pod 的资源消费被驱逐。如果系统进程（例如 kubelet、docker、journald 等）消耗了超出 system-reserved 或者 kube-reserved 的资源，而且这一节点上只运行了 Guaranteed Pod，那么为了保证节点的稳定性并降低异常消费对其他 Guaranteed Pod 的影响，必须选择一个 Guaranteed Pod 进行驱逐。
本地磁盘是一个 BestEffort 资源。如有必要，kubelet 会在 DiskPressure 的情况下，kubelet 会按照 QoS 进行评估。如果 Kubelet 判定缺乏 inode 资源，就会通过驱逐最低 QoS 的 Pod 的方式来回收 inodes。如果 kubelet 判定缺乏磁盘空间，就会通过在相同 QoS 的 Pods 中，选择消耗最多磁盘空间的 Pod 进行驱逐。
有 Imagefs
如果 nodefs 触发了驱逐，Kubelet 会用 nodefs 的使用对 Pod 进行排序 – Pod 中所有容器的本地卷和日志。
如果 imagefs 触发了驱逐，Kubelet 会根据 Pod 中所有容器的消耗的可写入层进行排序。
没有 Imagefs
如果 nodefs 触发了驱逐，Kubelet 会对各个 Pod 的所有容器的总体磁盘消耗进行排序 —— 本地卷 + 日志 + 写入层。
在某些场景下，驱逐 Pod 可能只回收了很少的资源。这就导致了 kubelet 反复触发驱逐阈值。另外回收资源例如磁盘资源，是需要消耗时间的。
要缓和这种状况，Kubelet 能够对每种资源定义 minimum-reclaim。kubelet 一旦发现了资源压力，就会试着回收至少 minimum-reclaim 的资源，使得资源消耗量回到期望范围。
例如下面的配置：
--eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi --eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"`
- 如果 memory.available 被触发，Kubelet 会启动回收，让 memory.available 至少有 500Mi。
- 如果是 nodefs.available，Kubelet 就要想法子让 nodefs.available 回到至少 1.5Gi。
- 而对于 imagefs.available， kubelet 就要回收到最少 102Gi。
缺省情况下，所有资源的 eviction-minimum-reclaim 为 0。
调度器
在节点资源紧缺的情况下，节点会报告这一状况。调度器以此为信号，不再继续向此节点部署新的 Pod。
| 节点状况 | 调度行为 |
|---|---|
| MemoryPressure | 不再分配新的 BestEffort Pod 到这个节点 |
| DiskPressure | 不再向这一节点分配 Pod |
节点的 OOM 行为
如果节点在 Kubelet 能够回收内存之前，遭遇到了系统的 OOM (内存不足)，节点就依赖oom_killer 进行响应了。
kubelet 根据 Pod 的 QoS 为每个容器设置了一个 oom_score_adj 值。
| QoS | oom_score_adj |
|---|---|
| Guaranteed | -998 |
| BestEffort | 1000 |
| Burstable | min(max(2, 1000 – (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
如果 kubelet 无法在系统 OOM 之前回收足够的内存，oom_killer 就会根据根据内存使用比率来计算 oom_score，得出结果和 oom_score_adj 相加，最后得分最高的 Pod 会被首先驱逐。
这一行为的思路是，QoS 最低，相对于调度的 Reqeust 来说又消耗最多内存的 Pod 会被首先清除，来保障内存的回收。
跟 Pod 驱逐不同，如果一个 Pod 的容器被 OOM 杀掉，他是可能被 kubelet 根据 RestartPolicy重启的。
最佳时间
可调度的资源和驱逐策略
我们想象如下的场景：
- 节点内存容量：10Gi
- 保留 10% 的内存容量给系统服务（内核，kubelet 等）。
- 在 95% 内存使用率的时候驱逐 Pod，来降低系统 OOM 的发生率。
所以我们用这样的参数启动 Kubelet：
--eviction-hard=memory.available<500Mi --system-reserved=memory=1.5Gi
这个配置中隐含了一个设定就是，系统保留涵盖了驱逐标准。
要达到这一容量，可能是有的 Pod 使用了超出其请求的数量，或者系统占用了超过 500Mi。
这样的配置保证了调度器不会向即将发生内存压力的节点分配 Pod，避免触发驱逐。
DaemonSet
因为 DaemonSet 中的 Pod 会立即重建到同一个节点，所以 Kubelet 不应驱逐 DaemonSet 中的 Pod。
但是目前 Kubelet 无法分辨一个 Pod 是否由 DaemonSet 创建。如果/当 Kubelet 能够识别这一点，那么就可以先从驱逐候选列表中过滤掉 DaemonSet 的 Pod。
一般来说，强烈建议 DaemonSet 不要创建 BestEffort Pod，而是使用 Guaranteed Pod，来避免进入驱逐候选列表。
弃用的现存回收磁盘的选项
为了保证节点的稳定性，Kubelet 已经尝试来释放磁盘空间了。
因为基于磁盘的驱逐方式已经成熟，下列的 Kubelet 参数会被标记为弃用。
| 现有参数 | 新参数 |
|---|---|
| –image-gc-high-threshold | –eviction-hard or eviction-soft |
| –image-gc-low-threshold | –eviction-minimum-reclaim |
| –maximum-dead-containers | 弃用 |
| –maximum-dead-containers-per-container | 弃用 |
| –minimum-container-ttl-duration | 弃用 |
| –low-diskspace-threshold-mb | –eviction-hard or eviction-soft |
| –outofdisk-transition-frequency | –eviction-pressure-transition-period |
已知问题
Kubelet 无法及时观测到内存压力
Kubelet 目前从 cAdvisor 定时获取内存使用状况统计。如果内存使用在这个时间段内发生了快速增长，Kubelet 就无法观察到 MemoryPressure，可能会触发 OOMKiller。我们正在尝试将这一过程集成到 memcg 通知 API 中，来降低这一延迟，而不是让内核首先发现这一情况。
如果用户不是希望获得终极使用率，而是作为一个过量使用的衡量方式，对付这一个问题的较为可靠的方式就是设置驱逐阈值为 75% 容量。这样就提高了避开 OOM 的能力，提高了驱逐的标准，有助于集群状态的平衡。
Kubelet 可能驱逐超出需要的更多 Pod
这也是因为状态搜集的时间差导致的。未来会加入功能，让根容器的统计频率和其他容器分别开来（https://github.com/google/cadvisor/issues/1247）。
Kubelet 如何在 inode 耗尽的时候评价 Pod 的驱逐
目前不可能知道一个容器消耗了多少 inode。如果 Kubelet 觉察到了 inode 耗尽，他会利用 QoS 对 Pod 进行驱逐评估。在 cadvisor 中有一个 issue，来跟踪容器的 inode 消耗，这样我们就能利用 inode 进行评估了。例如如果我们知道一个容器创建了大量的 0 字节文件，就会优先驱逐这一 Pod。