K8S 计算资源管理 requests & limits

为pod中的容器申请资源

设置 pod 的容器资源申请量保证每个容器能够获得它所需要资源的最小量。
创建一个 pod 时，可以指定容器对 CPU 和内存的资源请求量（requests）,以及资源限制量（limits）。它们并不是在 pod 里定义，而是针对每个容器单独指定。pod 对资源的请求量和限制量是它所包含的所有容器的请求量和限制量之和。

创建包含资源 requests 的 pod

apiVersion: v1
kind: Pod
metadata:
  name: requests-pod
spec:
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main         
    resources:
      requests:
        cpu: 200m
        memory: 10Mi

在 pod mainfest 中，声明你一个容器需要 1/5 核 （200 毫核）的 CPU 才能正常运行。换句话说，五个同样的 pod（或容器）可以足够快地运行在一个 CPU 核上。
当我们不指定 CPU requests 时，表示我们并不关心系统为容器内的进程分配了多少 CPU 时间。在最坏情况下进程可能根本分不到 CPU 时间（当其他进程对 CPU 需求量很大时会发生）。这对一些时间不敏感、低优先级的 batch jobs 没有问题，但对于处理用户请求的容器这样配置显然不太合适。
在 pod spec 里，同时为容器申请了 10 MB 的内存，说明期望容器内的进程最大消耗 10MB 的 RAM。它们可能实际占用较小，但在正常情况下我们并不希望它们占用超过这个值。

资源 requests 如何影响调度

通过设置资源 requests 我们指定了 pod 对资源需求的最小值。调度器在将 pod调度到节点的过程中会用到该信息。每个节点可分配给 pod 的 CPU 和内存数量都是一定的 。调度器在调度时只考虑那些未分配资源量满足 pod 需求量的节点。如果节点的未分配资源量小于 pod 需求量，这时节点没有能力提供 pod 对资源需求的最小量，因此Kubernetes不会将该 pod 调度到这个节点。

调度器如何判断一个pod是否适合调度到某个节点

调度器在调度时并不关注各类资源在当前时刻的实际使用量，而只关心节点上部署的所有 pod 的资源申请量之和。尽管现有 pods 的资源实际使用量可能小于它的申请量，但如果使用基于实际资源消耗量的调度算法将打破系统为这些已部署成功的 pods 提供足够资源的保证。

上图中，节点上部署了三个pod。它们共申请了节点80%的 CPU 和60%的内存资源。图右下方的 podD 将无法调度到这个节点上，因为它25%的 CPU requests 大于节点未分配的20% CPU。而实际上，这与当前三个 pods 仅使用70%的 CPU 没有什么关系。

更多请看此文章：
k8s 计算资源管理 requests & limits

相关文章：
k8s 计算资源管理 requests & limits
Prometheus监控k8s中Pod使用Shell模拟消耗CPU资源
Prometheus监控K8S各项指标
通过 Prometheus 获取 Kubernetes 中 Pod 资源（CPU/MEM/GPU）消耗信息

为者常成，行者常至