17 K8S 之容器资源需求与资源限制

初始化容器的典型应用需求有如下：

1. 用于运行需要管理权限的工具程序，例如 iptables 命令等，出于安全等方面的原因，应用容器不适合拥有运行这类程序的权限。

2. 提供主容器镜像中不具备的工具程序或自定义代码。

3. 为容器镜像的构建和部署人员提供了分离、独立工作的途径，部署人员使用专用的初始化容器完成特殊的部署逻辑，从而使得他们不必协同起来制作单个镜像文件。

4. 初始化容器和应用容器处于不同的文件系统视图中，因此可分别安全地使用敏感数据，例如 Secrets 资源等。

5. 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得以满足。

Pod 对象中的所有初始化容器必须按定义的顺序串行运行，直到它们全部成功结束才能启动应用容器，因而初始化容器通常很小，以便它们能够以轻量的方式快速运行。

Sidecar 容器是 Pod 中与主容器松散耦合的实用程序容器，遵循容器设计模式，并以单独容器进程运行，负责运行应用的非核心功能，以扩展、增强主容器。Sidecar 模式最著名的用例是充当服务网格中的微服务的代理应用（例如 Istio 中的数据控制平面 Envoy），其他典型使用场景包括日志传送器、监视代理和数据加载器等。

在 Kubernetes 上，可由容器或 Pod 请求与消费的“资源”主要是指 CPU 和内存（RAM），它可统称为计算资源，另一种资源是事关可用存储卷空间的存储资源。

CPU 属于可压缩型资源，即资源额度可按需弹性变化，而内存（当前）则是不可压缩型资源，对其执行压缩操作可能会导致某种程度的问题，例如进程崩溃等。目前，资源隔离仍属于容器级别，CPU 和内存资源的配置主要在 Pod 对象中的容器上进行。

资源需求：定义需要系统预留给该容器使用的资源最小可用值，容器运行时可能用不到这些额度的资源，但用到时必须确保有相应数量的资源可用。

资源限制：定义该容器可以申请使用的资源最大可用值，超出该额度的资源使用请求将被拒绝；显然，该限制需要大于等于 requests 的值，但系统在某项资源紧张时，会从容器回收超出 request 值的那部分。

在 Kubernetes 系统上，1 个单位的 CPU 相当于虚拟机上的 1 颗虚拟 CPU（vCPU）或物理机上的一个超线程（Hyperthread，或称为一个逻辑 CPU），它支持分数计量方式，一个核心（1core）相当于 1000 个微核心（millicores，以下简称为 m），因此 500m 相当于是 0.5 个核心，即 1/2 个核心。内存的计量方式与日常使用方式相同，默认单位是字节，也可以使用 E、P、T、G、M 和 K 为单位后缀，或 Ei、Pi、Ti、Gi、Mi 和 Ki 形式的单位后缀。

stress-ng 是一个多功能系统压力测试工具，master/worker 模型，master 为主进程，负载生成和控制子进程，worker 是负责执行各类特定测试的子进程，例如测试 CPU 的子进程，以及测试 RAM 的子进程等。

与资源需求不同的是，资源限制并不影响 Pod 对象的调度结果，即一个节点上的所有 Pod 对象的资源限制数量之和可以大于节点拥有的资源量，即支持资源的过载使用（overcommitted）。不过，这么一来，一旦内存资源耗尽，几乎必然地会有容器因 OOMKilled 而终止。

在容器中运行 top 等命令观察资源可用量信息时，容器可用资源受限于 requests 和 limits 属性中的定义，但容器中可见的资源量依然是节点级别的可用总量。

根据 Pod 对象的 requests 和 limits 属性，Kubernetes 把 Pod 对象归类到 BestEffort、Burstable 和 Guaranteed 这 3 个服务质量类别（Quality of Service，QoS）类别下。

Guaranteed：Pod 对象为其每个容器都设置了 CPU 资源需求和资源限制，且二者具有相同值；同时为每个容器都设置了内存资需求和内存限制，且二者具有相同值。这类 Pod 对象具有最高级别服务质量。

Burstable：至少有一个容器设置了 CPU 或内存资源的 requests 属性，但不满足 Guaranteed 类别的设定要求，这类 Pod 对象具有中等级别服务质量。

BestEffort：不为任何一个容器设置 requests 或 limits 属性，这类 Pod 对象可获得的服务质量为最低级别。