Kubernetes 针对资源紧缺处理方式的配置

如何在资源紧缺的情况下,保证 Node 的稳定性,是 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 支持两种文件系统分区。

  1. nodefs:保存 kubelet 的卷和守护进程日志等。
  2. 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 会按照下面的顺序来清理空间。

  1. 删除死掉的 Pod/容器

如果 imagefs 文件系统到达了驱逐阈值,kubelet 会按照下面的顺序来清理空间。

  1. 删掉所有无用镜像

没有 Imagefs

如果 nodefs 文件系统到达了驱逐阈值,kubelet 会按照下面的顺序来清理空间。

  1. 删除死掉的 Pod/容器
  2. 删掉所有无用镜像

驱逐用户 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。

原文:  http://kubernetes.io/docs/admin/out-of-resource/#eviction-policy

译文:http://blog.fleeto.us/translation/configuring-out-resource-handling