为了避免集群中的 Pod 负载加大时节点资源不足，导致某些用户进程被“杀掉”，Kubernetes 需要有一套完备的资源配额限制及对应的 Pod 服务等级机制，解决思路如下： （1）可以全面限制一个应用及其中的 Pod 所能占用的资源配额。具体包括三种方式： <1>定义每个 Pod 上资源配额相关的参数，比如 CPU/Memory Request/Limit； <2>自动为每个没有定义资源配额的 Pod 添加资源配额模板（LimitRange）； <3>从总量上限制一个租户（应用）所能使用的资源配额（ResourceQuota）。 （2）允许集群的资源被超额分配，以提高集群的资源利用率，同时允许用户根据业务的优先级，为不同的 Pod 定义相应的服务保障等级（QoS）。我们可以将 Qos 理解为“活命优先级”，当系统资源不足时，低等级的 Pod 会被操作系统自动清理，以确保高等级的 Pod 稳定运行。
一、计算资源管理
1. Requests 和 Limits 参数简介
Requests 和 Limits 参数只能被设置到容器上，用于表示当前容器的 CPU 或 内存的使用范围，在 Kubernetes 中，可用 Requests 或 Limits 参数设置某个 Pod 中所有容器的 Requests 或 Limits 的总和，对于没有设置 Requests 或 Limits 的容器，该项的值被当作 0 或者按照集群配置的默认值来计算。 CPU 在容器技术中属于可压缩资源，因此对 CPU 的 Limits 配置一般不会因为偶然超标使用而导致容器被操作系统“杀掉”，但对于内存这种不可压缩的资源来说，若容器试图请求超过其 Limits 参数设置的资源，则会被操作系统“杀掉”。2. 基于 Requests 和 Limits 的 Pod 调度机制
Kubernetes 的 kube-scheduler 通过计算 Pod 中所有容器的 Requests 总和来决定对 Pod 的调度。 不管是 CPU 还是内存，Kubemetes 调度器和 kubelet 都会确保节点上所有 Pod 的 Requests 总和不会超过在该节点上可分配给容器使用的资源容量上限（即使实际使用的资源很少）。3. Requests 和 Limits 的背后机制
Kubelet 在启动 Pod 的某个容器时，会将容器的 Requests 和 Limits 值转化为相应的容器启动参数传递给容器执行器（Docker 或 rkt）。（1）spec.container[].resources.requests.cpu
这个参数值会被转化为 core 数（比如配置的 100m 会转化为 0.1），然后乘以 1024，再将这个结果作为 --cpu-shares 参数的值传递给 docker run 命令。在 docker run 命令中，--cpu-share 参数是一个相对权重值，主要用于设置资源分配比例。（2）spec.container[].resources.limits.cpu
这个参数值会被转化为 millicore 数（比如配置的 1 被转化为 1000，而配置的 100m 被转化为 100） ，将此值乘以 100000，再除以 1000，然后将结果值作为 --cpu-quota 参数的值传递给 docker run 命令。 docke run 令中的另一个参数 --cpu-period 默认被设置为 100000，表示 Docker 重新计量和分配 CPU 的使用时间间隔为 100000µs ( 100 ms ) 。两个参数一起配合完成对容器 CPU 的使用限制。（3）spec.container[].resources.requests.memory
这个参数值只提供给 Kubernetes 调度器作为调度和管理的依据，不会作为任何参数传递给 Docker。（4）spec.container[].resources.limits.memory
这个参数值会被转化为单位为 Bytes 整数，值作为 --memory 参数传递给 docker run 命令。4. 计算资源使用情况监控
Pod 资源用量会作为 Pod 状态信息一同上报给 Master。如果在集群中配置了 Heapster 来监控集群的性能数据，那么还可以从 Heapster 查看 Pod 的资源用量信息。二、资源配置范围管理（LimitRange）
在默认情况下，Kubernetes 不会对 Pod 加上 CPU 和内存限制，这意味着 Kubernetes 系统中的任何 Pod 都可以使用其所在节点所有可用的 CPU 和内存。通过配置 Pod 的计算资源 Requests 和 Limits，可以限制 Pod 的资源使用，但配置每一个 Pod 的 Requests 和 Limits 过于烦琐，需要对集群内 Requests 和 Limits 的配置做一个全局限制，这时候 LimitRange 就派上用场了。 LimitRange 各项配置的意义和特点：
三、资源服务质量管理（Resource QoS）
1. Requests 和 Limits 申请资源的可靠性
Requests 是 Kubernetes 调度时能为容器提供的完全、可保障的资源量（最低保璋），而 Limits 是系统允许容器运行时可能使用的资源量的上限（最高上限）。 Kubemetes 中 Pod 的 Requests 和 Limits 资源配置有如下特点： （1）如果 Pod 配置的 Requests 值等于 Limits 值，那么该 Pod 可以获得的资源是完全可靠的。 （2）如果 Pod 的 Requests 值小于 Limits 值，那么该 Pod 获得的资源可分为两部分： <1>完全可靠的资源，资源量的大小等于 Requests 值； <2>不可靠的资源，资源量最大等于 Limits 与 Requests 的差额，这份不可靠的资源能够申请到多少，取决于当时主机上容器可用资源的余量。 通过这种机制， Kubernetes 可以实现节点资源的超售（Over Subscription），如果节点上的容器的资源使用峰值能错开，那么所有容器都可以正常运行。2. 根据 Requests 和 Limits 定义服务质量等级（QoS Classes）
Kubernetes 的资源配置定义了 Pod 的三种 QoS 级别：（1）Guaranteed
如果 Pod 中的所有容器对所有资源类型都定义了 Limits 和 Requests，并且所有容器的 Limits 值都和 Requests 值相等（且都不为 0），那么该 Pod 的 QoS 级别就是 Guaranteed。（2）BestEffort
如果 Pod 所有容器都未定义资源配置（Requests 和 Limits 都未定义），那么该 Pod 的 QoS 级别就是 BestEffort 。（3）Burstable
当一个 Pod 不为 Guaranteed 级别，也不为 BestEffort 级别时，Pod 的 QoS 级别就是 Burstable。Burstable 级别的 Pod 涉及两种情况： <1>Pod 中的一部分容器在一种或多种资源类型的资源配置中定义了 Requests 值和 Limits 值（都不为 0），且 Requests 值小于 Limits 值； <2>Pod 中的一部分容器未定义资源配置（Requests 和 Limits 都未定义）。 QoS 优先级由高到低为：Guaranteed、Burstable、BestEffort。 Kubernetes QoS 的工作特点： 在 Pod 的 CPU Requests 无法得到满足（比如节点的系统级任务占用过多的 CPU 导致无法分配足够的 CPU 给容器使用）时，容器得到的 CPU 会被压缩限流。 由于内存是不可压缩的资源，所以针对内存资源紧缺的情况，会按照以下逻辑处理： （1）BestEffort Pod 的优先级最低，在这类 Pod 中运行的进程会在系统内存紧缺时被第一优先“杀掉＂。当然，从另一个角度来看，BestEffort Pod 由于没有设置资源 Limits，所以在资源充足时，它们可以充分使用所有闲置资源。 （2）Burstable Pod 的优先级居中，这类 Pod 在初始时会被分配较少的可靠资源，但可以按需申请更多的资源。当然，如果整个系统内存紧缺，又没有 BestEffort 容器可以被杀掉以释放资源，那么这类 Pod 中的进程可能被“杀掉"。 （3）Guaranteed Pod 的优先级最高，而且一般情况下这类 Pod 只要不超过其资源 Limits 的限制就不会被“杀掉＂。当然，如果整个系统内存紧缺，又没有其他更低优先级的容器可以被“杀掉“以释放资源，那么这类 Pod 中的进程也可能会被“杀掉＂。四、资源配额管理（Resource Quotas）
通过 ResourceQuota 对象，我们可以定义资源配额，这个资源配额可以为每个命名空间都提供一个总体的资源使用限制：它可以限制命名空间中某种类型的对象的总数量上限，也可以设置命名空间中 Pod 可以使用的计算资源、存储资源的总上限。五、ResourceQuota 和 LimitRange 实践
1. 创建命名空间
2. 创建 ResourceQuota
3. 创建 LimitRange
4. 创建 Pod
5. 再次查看命名空间与 ResourceQuota
只有配置了 Requests 的 Pod 才会受其限制。
六、节点的 CPU 管理策略
kubelet 默认使用 CFS Quota 技术基于 Pod 的 CPU Limit 对 Node 上 CPU 资源的使用进行限制和管理（CFS，Completely Fair Scheduler，即完全公平调度算法）。 当在 Node 上运行了很多 CPU 密集型 Pod 时，容器进程可能会被调度到不同的 CPU 核上进行运算，从而发生 CPU 上下文的切换。许多应用对这种 CPU 的切换不敏感，但也有一些应用的性能会明显受到 CPU 缓存亲和性及调度延迟的影响，针对这类应用，Kubernetes 提供了一个可选的 CPU 管理策略，来确定节点上 CPU 资源调度的优先级，为 Pod 运行达到更好的性能提供支待 。 CPU 管理策略通过 Node 上的 kubelet 启动参数 --cpu-manager-policy 进行指定，目前支持两种策略：（1）None 策略
None 策略使用默认的 CPU 亲和性方案，即操作系统默认的 CPU 调度策略。对于 QoS 级别为 Guaranteed 的 Pod，会强制使用 CFS Quota 机制对 CPU 资源进行限制。（2）Static 策略
Static 策略针对具有特定 CPU 资源需求的 Pod。对于 QoS 级别为 Guaranteed 的 Pod，如果其 Container 设置的 CPU Request 为大于等于 1 的整数， Kubernete 就能允许容器绑定节点上的一个或多个 CPU 核独占运行。这种独占是使用 cpuset cgroup 控制器来实现的。 该策略管理一个共享 CPU 资源池，该资源池最初包含节点上的所有 CPU 资源 。可用的独占性 CPU 资源数最等于节点的 CPU 总量减去通过 --kube-reserved 和 --system-reserved 参数设置保留给系统的 CPU 资源数量。 共享池是 QoS 级别为 BestEffort 和 Burstable 的 Pod 运行所需的 CPU 集合。 QoS 级别为 Guaranteed 的 Pod 中的容器，如果声明了非整数值的 CPU Request，则也将运行在共享池上，只有声明了整数 CPU Request 的容器才会被分配独占的 CPU 资源。 QoS 级别为 Guaranteed 的 Pod 被调度到节点上时，如果容器的 CPU 资源需求设置符合静态分配的要求，则所需的 CPU 核会被从共享池中取出并放到容器的 cpuset 中，供容器独占使用。容器 cpuset 中的 CPU 核数与 Pod 定义中指定的整数个 CPU limit 相等，无须再使用 CFS Quota 机制分配 CPU 资源。这种静态分配机制增强了 CPU 亲和 性，减少了 CPU 上下文切换的次数。七、资源紧缺时的 Pod 驱逐机制
在资源严重不足的情况下，操作系统会触发 OOM Killer 的终极审批。为了避免出现这种严重后果，Kubemetes 设计和实现了一套自动化的 Pod 驱逐机制，该机制会自动从资源紧张的节点上驱逐一定数量的 Pod ，以保证在该节点上有充足的资源。1. 资源监控与驱逐行为
（1）资源监控
每个节点上的 kubelet 都会通过 cAdvisor 提供的资源使用指标来监控自身节点的资源使用量，并根据这些指标的变化做出相应的驱逐决定和操作。（2）驱逐行为
驱逐时机： <1>节点磁盘资源不足时会触发 Pod 的驱逐行为 Kubernetes 包括两种文件系统： nodefs 和 imagefs。nodefs 时 kubelet 用于存储卷系统、服务程序日志等的文件系统；imagefs 是容器运行时使用的可选文件系统，用于存储容器镜像和容器可写层数据。cAdvisor 提供了这两种文件系统的相关统计指标，分别如下： available：表示该文件系统中可用的磁盘空间。 inodesFree：表示该文件系统中可用的 inode 数量（索引节点数量）。 默认情况下，kubelet 检测到下面的任意条件满足时，就会触发 Pod 的驱逐行为。
如果 nodefs 达到驱逐阈值， kubelet 就会删除所有已失效的 Pod 及其容器实例对应的磁盘文件。相应地，如果 imagefs 达到驱逐阔值，则 kubelet 会删除所有未使用的容器镜像。
<2>节点内存不足时会触发 Pod 的驱逐行为
memory.available 代表当前节点的可用内存，默认情况下 memory.available<100Mi 时会触发 Pod 的驱逐行为。驱逐 Pod 的过程：kubelet 从 cAdvisor 中定期获取相关的资源使用量指标数据，通过配置的阈值筛选出满足驱逐条件的 Pod；kubelet 对这些 Pod 进行排序，每次都选择一个 Pod 进行驱逐。
驱逐阈值：
驱逐阈值可以通过软阈值和硬阈值两种方式进行设置。
<1>驱逐软阈值
驱逐软阙值由一个驱逐阈值和一个管理员设定的宽限期共同定义。当系统资源消耗达到软阈值时，在这一状况的持续时间达到宽限期之前，kubelet 不会触发驱逐动作。
<2>驱逐硬阈值
硬阙值没有宽限期，如果达到了硬阈值，则 kubelet 会立即“杀掉 “Pod 并进行资源回收。