k8s资源管理（k8s pod资源限制）

总结：容器内的资源分配策略有3种。 顾名思义，这是容器的最低资源需求和最大使用限制。 与直接配置的磁盘使用量不同，磁盘使用量可以被视为用于策略目的的资源。 如果在此期间资源使用率低于阈值，则不会恢复。

QoS

k8s 中容器资源分配有三种策略：

有保证。 使用此策略，CPU 或内存请求和限制驻留在 pod.spec.containers[].resources 中。 顾名思义，这是容器的最低资源需求和最大使用限制。 如果您设置了限制但没有设置请求，则默认情况下该请求将由限制值定义。 具体配置请参见之前的注释。

尽最大努力。 如果pod描述文件中没有resource.limit和resource.request相关的配置，则容器可以运行任意数量的资源，其资源使用限制实际上是容器所在节点的容量。 。

可爆裂。 当以除上述两种方法之外的任何其他方式设置resource.limit和resource.request时，使用此模式。

QoS目前仅通过CPU和内存来描述。 CPU可以进行资源压缩。 如果容器的CPU使用率超过限制，它将被流量控制，如果内存超过限制，它将变成oom_killed。 这里，kubelet 自己计算容器的 oom_score 并检查相应 Linux 进程的 oom_adj。 oom_adj 最高的进程将首先被 oom_killed。
保证模式下容器的最小oom_score为-998，对应的oom_adj为0或1，BestEffort模式为1000。，burstable 模式下的 oom_score 根据内存使用情况而变化，但在 2-1000 之间。

当节点内存消耗严重时，你会注意到采用 BestEffort 策略的 pod 首先被 kubelet 杀死，然后被 Burstable 杀死（如果有多个采用该策略的 pod 的话，它们也会被杀死） ）。 它会根据内存使用情况被杀死，从高到低然后保证。

kubelet 的驱逐机制

完全依赖 oom_kill 并不是一个好的解决方案。 首先，它不会影响对CPU要求较高的容器。 其次，它只是杀死了 pod，并没有从根本上解决困境。 例如，如果某个 pod 占用了节点很大一部分内存，而该 pod 被添加然后被杀死，那么当该 pod 被调度回该节点时，就会再次出现 oom 情况。 所以kubelet增加了驱逐机制。
驱逐机制适用于：
memory.available、nodefs.available、nodefs.inodesFree、imagefs.available、imagefs.inodesFree
分别是节点当前可用内存，kubelet执行对应日志。 用于挂载节点和容器磁盘的文件系统边距和索引节点边距，以及用于在节点上存储容器映像和读/写层的文件系统边距和索引节点边距。

要触发驱逐，您必须在驱逐中设置驱逐阈值。 该阈值配置可以是固定值或百分比。 例如：
memory.available<10%
memory.available<1Gi

软驱逐阈值

软驱逐机制使用节点的内存/磁盘空间时下降，达到一定阈值时应观察一段时间。 如果它有所改善并低于阈值，则不会被删除。 如果在此期间超过阈值，则会被删除。
单击此处获取阈值路径通过参数--eviction-soft设置，如上所示。 观察时间通过参数--eviction-soft-grace-period设置（例如，1分30秒） 。
还有一个参数eviction-max-pod-grace-period。 这会影响被驱逐 Pod 的终止时间或终止。 Pod 容器所花费的时间。

硬驱逐阈值

强制驱逐的机制非常简单。 当达到阈值时，Pod 会立即在本地被杀死，并删除 eviction-hard 参数。 作品。 示例与上面相同。

Pod 驱逐

当资源使用触发驱逐条件时，kubelet 驱逐正在运行的 pod，直到资源使用量低于阈值，然后依次启动停止的任务。 以硬驱逐为例，整体流程如下：

定期从 cadvisor 检索资源使用情况并验证阈值是否被触发。

从正在运行的 Pod 检查 QoS 策略。 最开放的 pod，比如 bestEffort 策略的 pod（即使这个 pod 消耗的内存不多，大部分内存都是另一个 Burstable 策略的 pod，内存占用也很高），kubelet 会停止所有容器并更新pod对应的pod状态为“失败”。 如果一个 pod 长时间没有被优雅地杀死，kubelet 会寻找另一个 pod 来删除。

检查内存使用率是否低于阈值。 如果没有，请重复第二步（现在你需要杀死罪魁祸首）。 这将持续下去，直到内存使用量降至阈值以下。

有几点需要记住：

kubelet 选择驱逐哪些 pod 的策略取决于 QoS 策略的开放性以及具有相同 QoS 的多个 pod 的情况。关于豆荚排序。其中，kubelet首先移除使用触发指标资源最多的那个。

与内存不同，磁盘使用可以通过请求和限制来配置。 磁盘使用可以被视为具有 BestEffort QoS 策略的资源。 当触发磁盘资源不足时，kubelet 会执行额外的工作，例如清理容器日志中的死 pod 和清理未使用的容器映像。 当然，kubelet会增加磁盘使用量（包括挂载本地卷空间+容器日志大小），如果imagefs指标超过配额，那么文件大小最大的pod（容器可以读取的层的文件大小）并写）同时选择。 running) 也被添加到这里用于驱逐。

节点条件

如上所述，当触发软驱逐或硬驱逐时，kubelet 会尝试杀死 pod。 从驱逐指示器信息中删除您自己的状态。 例如，如果内存使用量超过标准并触发驱逐，则节点的状态将被记录为伴随该状态的 kubelet 的调度心跳消息上传到 master。 等等。 调度器进行调度时，将这些条件作为调度条件的参考。 例如，调度程序不会在 diskPressure 中的节点上调度 pod。 节点可能严重崩溃。

但是如果某个节点的内存波动高于或低于某个阈值，并且状态反复更新为压力或正常，则 Pod 可能会被错误地调度到该节点，这也会导致延迟，因此，驱逐。 -压力-transition-period参数指定触发驱逐后一次更新后条件保持变化的最短时间。 如果在此时间范围内资源使用率低于阈值，则情况将不会恢复。

其他

我担心最低驱逐请求节点移除小 Pod 后，该指标仅略低于阈值。 然后，如果另一个 pod 的指标略有上升，节点将不得不再次驱逐它。 因此，请使用以下参数：
--eviction-minimum-reclaim ('memory.available=0Mi,nodefs.available=500Mi,imagefs .available= 2Gi"）是有限制的。当发生驱逐时，节点对某个指标的使用情况（例如该指标阈值-），否则该 pod 将被移除。
简单来说，该参数是在节点之后设置的b>表示效果低于阈值的程度