标签：容器 scale container kubernetes 扩缩内存 Pod CPU 资源

https://imroc.cc/kubernetes/best-practices/autoscaling/hpa-velocity.html

原理与误区

HPA 在进行扩缩容时，先是由固定的算法计算出期望副本数:

期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]

其中 当前指标 / 期望指标 的比例如果接近 1 (在容忍度范围内，默认为 0.1，即比例在 0.9~1.1 之间)，则不进行伸缩，避免抖动导致频繁扩缩容。

容忍度是由 kube-controller-manager 参数 --horizontal-pod-autoscaler-tolerance 决定，默认是 0.1，即 10%。

本文要介绍的扩缩容速率调节，不是指要调整期望副本数的算法，它并不会加大或缩小扩缩容比例或数量，仅仅是控制扩缩容的速率，实现的效果是: 控制 HPA 在 XX 时间内最大允许扩容/缩容 XX 比例/数量的 Pod。

=》想快速trigger新pod；需要将request降低

pod的实际的cpu消耗/request*utilization

比值是0.9-1.1之间不会trigger；必须大于1.1，才trigger

=》

request可以小一点，然后limit放大可以保证pod的cpu使用量，limit不会影响 scale up 和scale down的速度

=》how

确认 pod起task后1分钟左右的cpu消耗，确保那个时候(cpu使用的量/ request*70%) > 1.1

metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: {{ default 70 .Values.hpaCpuAverageUtilization }}

会要求这个比值大于1.1持续足够的窗口时间，才trigger

=》

等pod变成多个后，再trigger新的pod

判断方法是：多个pod的cpu使用量的平均值/request*70%> 1.1

check metric获取cpu使用量的周期是15s目前，无法设置，是内置的

=》

将request加大减小，scale up， down 效果就是最明显的

配置快速扩容，为什么快不起来?

比如这个配置:

behavior:
  scaleUp:
    policies:
    - type: Percent
      value: 900
      periodSeconds: 10

含义是允许每 10 秒最大允许扩出 9 倍于当前数量的 Pod，实测中可能发现压力已经很大了，但扩容却并不快。

通常原因是计算周期与指标延时:

期望副本数的计算有个计算周期，默认是 15 秒 (由 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 参数决定)。
每次计算时，都会通过相应的 metrics API 去获取当前监控指标的值，这个返回的值通常不是实时的，对于腾讯云容器服务而言，监控数据是每分钟上报一次；对于自建的 prometheus + prometheus-adapter 而言，监控数据的更新取决于监控数据抓取间隔，prometheus-adapter 的 --metrics-relist-interval 参数决定监控指标刷新周期(从 prometheus 中查询)，这两部分时长之和为监控数据更新的最长时间。

通常都不需要 HPA 极度的灵敏，有一定的延时一般都是可以接受的。如果实在有对灵敏度特别敏感的场景，可以考虑使用 prometheus，缩小监控指标抓取间隔和 prometheus-adapter 的 --metrics-relist-interval。

https://imroc.cc/kubernetes/best-practices/autoscaling/hpa-with-custom-metrics.html

Kubernetes 默认提供 CPU 和内存作为 HPA 弹性伸缩的指标，如果有更复杂的场景需求，比如基于业务单副本 QPS 大小来进行自动扩缩容，可以考虑自行安装 prometheus-adapter 来实现基于自定义指标的 Pod 弹性伸缩。

https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/

Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 参数设置（默认间隔为 15 秒）。

在每个时间段内，控制器管理器都会根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。控制器管理器找到由 scaleTargetRef 定义的目标资源，然后根据目标资源的 .spec.selector 标签选择 Pod，并从资源指标 API（针对每个 Pod 的资源指标）或自定义指标获取指标 API（适用于所有其他指标）。

 metrics:
  - type: Resource
    resource:
      name: cpu

对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，控制器获取每个 Pod 中的容器资源使用情况，并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。

需要注意的是，如果 Pod 某些容器不支持资源采集，那么控制器将不会使用该 Pod 的 CPU 使用率。下面的算法细节章节将会介绍详细的算法。

metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: {{ default 70 .Values.hpaCpuAverageUtilization }}

如果 Pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用原始值，而不是使用率。

如果 Pod 使用对象指标和外部指标（每个指标描述一个对象信息）。这个指标将直接根据目标设定值相比较，并生成一个上面提到的扩缩比例。在 autoscaling/v2 版本 API 中，这个指标也可以根据 Pod 数量平分后再计算。

HorizontalPodAutoscaler 的常见用途是将其配置为从聚合 API （metrics.k8s.io、custom.metrics.k8s.io 或 external.metrics.k8s.io）获取指标。 metrics.k8s.io API 通常由名为 Metrics Server 的插件提供，需要单独启动。有关资源指标的更多信息，请参阅 Metrics Server。

算法细节

从最基本的角度来看，Pod 水平自动扩缩控制器根据当前指标和期望指标来计算扩缩比例。

期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]

例如，如果当前指标值为 200m，而期望值为 100m，则副本数将加倍，因为 200.0 / 100.0 == 2.0 如果当前值为 50m，则副本数将减半，因为 50.0 / 100.0 == 0.5。如果比率足够接近 1.0（在全局可配置的容差范围内，默认为 0.1），则控制平面会跳过扩缩操作。

如果 HorizontalPodAutoscaler 指定的是 targetAverageValue 或 targetAverageUtilization，那么将会把指定 Pod 度量值的平均值做为 currentMetricValue。

在检查容差并决定最终值之前，控制平面还会考虑是否缺少任何指标，以及有多少 Pod Ready。

所有设置了删除时间戳的 Pod（带有删除时间戳的对象正在关闭/移除的过程中）都会被忽略，所有失败的 Pod 都会被丢弃。

如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。

当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod 或最近的指标度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。

由于技术限制，HorizontalPodAutoscaler 控制器在确定是否保留某些 CPU 指标时无法准确确定 Pod 首次就绪的时间。相反，如果 Pod 未准备好并在其启动后的一个可配置的短时间窗口内转换为准备好，它会认为 Pod “尚未准备好”。该值使用 --horizontal-pod-autoscaler-initial-readiness-delay 标志配置，默认值为 30 秒。一旦 Pod 准备就绪，如果它发生在自启动后较长的、可配置的时间内，它就会认为任何向准备就绪的转换都是第一个。该值由 -horizontal-pod-autoscaler-cpu-initialization-period 标志配置，默认为 5 分钟。

在排除掉被搁置的 Pod 后，扩缩比例就会根据 currentMetricValue/desiredMetricValue 计算出来。

如果缺失某些度量值，控制平面会更保守地重新计算平均值，在需要缩小时假设这些 Pod 消耗了目标值的 100%，在需要放大时假设这些 Pod 消耗了 0% 目标值。这可以在一定程度上抑制扩缩的幅度。

此外，如果存在任何尚未就绪的 Pod，工作负载会在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，控制器保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。

考虑到尚未准备好的 Pod 和缺失的指标后，控制器会重新计算使用率。如果新的比率与扩缩方向相反，或者在容差范围内，则控制器不会执行任何扩缩操作。在其他情况下，新比率用于决定对 Pod 数量的任何更改。

注意，平均利用率的原始值是通过 HorizontalPodAutoscaler 状态体现的，而不考虑尚未准备好的 Pod 或缺少的指标，即使使用新的使用率也是如此。

如果创建 HorizontalPodAutoscaler 时指定了多个指标，那么会按照每个指标分别计算扩缩副本数，取最大值进行扩缩。如果任何一个指标无法顺利地计算出扩缩副本数（比如，通过 API 获取指标时出错），并且可获取的指标建议缩容，那么本次扩缩会被跳过。这表示，如果一个或多个指标给出的 desiredReplicas 值大于当前值，HPA 仍然能实现扩容。

最后，在 HPA 控制器执行扩缩操作之前，会记录扩缩建议信息。控制器会在操作时间窗口中考虑所有的建议信息，并从中选择得分最高的建议。这个值可通过 kube-controller-manager 服务的启动参数 --horizontal-pod-autoscaler-downscale-stabilization 进行配置，默认值为 5 分钟。这个配置可以让系统更为平滑地进行缩容操作，从而消除短时间内指标值快速波动产生的影响。

工作量规模的稳定性

在使用 HorizontalPodAutoscaler 管理一组副本的规模时，由于评估的指标的动态特性，副本的数量可能会经常波动。这有时被称为抖动（thrashing）或波动（flapping）。它类似于控制论中的滞后（hysteresis）概念。

对资源指标的支持

HPA 的任何目标资源都可以基于其中的 Pods 的资源用量来实现扩缩。在定义 Pod 规约时，类似 cpu 和 memory 这类资源请求必须被设定。这些设定值被用来确定资源利用量并被 HPA 控制器用来对目标资源完成扩缩操作。要使用基于资源利用率的扩缩，可以像下面这样指定一个指标源：

type: Resource
resource:
  name: cpu
  target:
    type: Utilization
    averageUtilization: 60

基于这一指标设定，HPA 控制器会维持扩缩目标中的 Pods 的平均资源利用率在 60%。 利用率是 Pod 的当前资源用量与其请求值之间的比值。关于如何计算利用率以及如何计算平均值的细节可参考算法小节。

说明：

由于所有的容器的资源用量都会被累加起来，Pod 的总体资源用量值可能不会精确体现各个容器的资源用量。这一现象也会导致一些问题，例如某个容器运行时的资源用量非常高，但因为 Pod 层面的资源用量总值让人在可接受的约束范围内，HPA 不会执行扩大目标对象规模的操作

可配置的扩缩行为

特性状态： Kubernetes v1.23 [stable]

（之前的 autoscaling/v2beta2 API 版本将此功能作为 beta 功能提供）

如果你使用 v2 HorizontalPodAutoscaler API，你可以使用 behavior 字段（请参阅 API 参考）来配置单独的放大和缩小行为。你可以通过在行为字段下设置 scaleUp 和/或 scaleDown 来指定这些行为。

你可以指定一个 “稳定窗口”，以防止扩缩目标的副本计数发生波动。扩缩策略还允许你在扩缩时控制副本的变化率。

扩缩策略

可以在规约的 behavior 部分中指定一个或多个扩缩策略。当指定多个策略时，允许最大更改量的策略是默认选择的策略。以下示例显示了缩小时的这种行为：

behavior:
  scaleDown:
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
    - type: Percent
      value: 10
      periodSeconds: 60

periodSeconds 表示在过去的多长时间内要求策略值为真。第一个策略（Pods）允许在一分钟内最多缩容 4 个副本。第二个策略（Percent）允许在一分钟内最多缩容当前副本个数的百分之十。

由于默认情况下会选择容许更大程度作出变更的策略，只有 Pod 副本数大于 40 时，第二个策略才会被采用。如果副本数为 40 或者更少，则应用第一个策略。例如，如果有 80 个副本，并且目标必须缩小到 10 个副本，那么在第一步中将减少 8 个副本。在下一轮迭代中，当副本的数量为 72 时，10% 的 Pod 数为 7.2，但是这个数字向上取整为 8。在 autoscaler 控制器的每个循环中，将根据当前副本的数量重新计算要更改的 Pod 数量。当副本数量低于 40 时，应用第一个策略（Pods），一次减少 4 个副本。

可以指定扩缩方向的 selectPolicy 字段来更改策略选择。通过设置 Min 的值，它将选择副本数变化最小的策略。将该值设置为 Disabled 将完全禁用该方向的扩缩。

稳定窗口

当用于扩缩的指标不断波动时，稳定窗口用于限制副本计数的波动。自动扩缩算法使用此窗口来推断先前的期望状态并避免对工作负载规模进行不必要的更改。

例如，在以下示例代码段中，为 scaleDown 指定了稳定窗口。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

当指标显示目标应该缩容时，自动扩缩算法查看之前计算的期望状态，并使用指定时间间隔内的最大值。在上面的例子中，过去 5 分钟的所有期望状态都会被考虑。

这近似于滚动最大值，并避免了扩缩算法频繁删除 Pod 而又触发重新创建等效 Pod。

默认行为

要使用自定义扩缩，不必指定所有字段。只有需要自定义的字段才需要指定。这些自定义值与默认值合并。默认值与 HPA 算法中的现有行为匹配。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max

用于缩小稳定窗口的时间为 300 秒（或是 --horizontal-pod-autoscaler-downscale-stabilization 参数设定值）。只有一种缩容的策略，允许 100% 删除当前运行的副本，这意味着扩缩目标可以缩小到允许的最小副本数。对于扩容，没有稳定窗口。当指标显示目标应该扩容时，目标会立即扩容。这里有两种策略，每 15 秒添加 4 个 Pod 或 100% 当前运行的副本数，直到 HPA 达到稳定状态。

kubectl 对 HorizontalPodAutoscaler 的支持

与每个 API 资源一样，HorizontalPodAutoscaler 都被 kubectl 以标准方式支持。你可以使用 kubectl create 命令创建一个新的自动扩缩器。你可以通过 kubectl get hpa 列出自动扩缩器或通过 kubectl describe hpa 获取详细描述。最后，你可以使用 kubectl delete hpa 删除自动扩缩器。

此外，还有一个特殊的 kubectl autoscale 命令用于创建 HorizontalPodAutoscaler 对象。例如，执行 kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80 将为 ReplicaSet foo 创建一个自动扩缩器，目标 CPU 利用率设置为 80%，副本数在 2 到 5 之间。

https://kubernetes.io/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server

资源指标管道

对于 Kubernetes，Metrics API 提供了一组基本的指标，以支持自动伸缩和类似的用例。该 API 提供有关节点和 Pod 的资源使用情况的信息，包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中，那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。

图中从右到左的架构组件包括以下内容：

cAdvisor: 用于收集、聚合和公开 Kubelet 中包含的容器指标的守护程序。
kubelet: 用于管理容器资源的节点代理。可以使用 /metrics/resource 和 /stats kubelet API 端点访问资源指标。
Summary API: kubelet 提供的 API，用于发现和检索可通过 /stats 端点获得的每个节点的汇总统计信息。
metrics-server: 集群插件组件，用于收集和聚合从每个 kubelet 中提取的资源指标。 API 服务器提供 Metrics API 以供 HPA、VPA 和 kubectl top 命令使用。Metrics Server 是 Metrics API 的参考实现。
Metrics API: Kubernetes API 支持访问用于工作负载自动缩放的 CPU 和内存。要在你的集群中进行这项工作，你需要一个提供 Metrics API 的 API 扩展服务器。
说明： cAdvisor 支持从 cgroups 读取指标，它适用于 Linux 上的典型容器运行时。如果你使用基于其他资源隔离机制的容器运行时，例如虚拟化，那么该容器运行时必须支持 CRI 容器指标以便 kubelet 可以使用指标。

https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu

Kubernetes 中的资源单位

CPU 资源单位

CPU 资源的限制和请求以 “cpu” 为单位。在 Kubernetes 中，一个 CPU 等于 1 个物理 CPU 核或者 1 个虚拟核，取决于节点是一台物理主机还是运行在某物理主机上的虚拟机。

你也可以表达带小数 CPU 的请求。当你定义一个容器，将其 spec.containers[].resources.requests.cpu 设置为 0.5 时，你所请求的 CPU 是你请求 1.0 CPU 时的一半。对于 CPU 资源单位，数量表达式 0.1 等价于表达式 100m，可以看作 “100 millicpu”。有些人说成是“一百毫核”，其实说的是同样的事情。

CPU 资源总是设置为资源的绝对数量而非相对数量值。例如，无论容器运行在单核、双核或者 48-核的机器上，500m CPU 表示的是大约相同的计算能力。

说明：

Kubernetes 不允许设置精度小于 1m 的 CPU 资源。因此，当 CPU 单位小于 1 或 1000m 时，使用毫核的形式是有用的；例如 5m 而不是 0.005。

内存资源单位

memory 的限制和请求以字节为单位。你可以使用普通的整数，或者带有以下数量后缀的定点数字来表示内存：E、P、T、G、M、k。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。例如，以下表达式所代表的是大致相同的值：

128974848、129e6、129M、128974848000m、123Mi

请注意后缀的大小写。如果你请求 400m 临时存储，实际上所请求的是 0.4 字节。如果有人这样设定资源请求或限制，可能他的实际想法是申请 400Mi 字节（400Mi）或者 400M 字节。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Kubernetes 应用资源请求与限制的方式

当 kubelet 将容器作为 Pod 的一部分启动时，它会将容器的 CPU 和内存请求与限制信息传递给容器运行时。

在 Linux 系统上，容器运行时通常会配置内核 CGroups，负责应用并实施所定义的请求。

CPU 限制定义的是容器可使用的 CPU 时间的硬性上限。在每个调度周期（时间片）期间，Linux 内核检查是否已经超出该限制；内核会在允许该 cgroup 恢复执行之前会等待。

CPU 请求值定义的是一个权重值。如果若干不同的容器（CGroups）需要在一个共享的系统上竞争运行， CPU 请求值大的负载会获得比请求值小的负载更多的 CPU 时间。

内存请求值主要用于（Kubernetes）Pod 调度期间。在一个启用了 CGroup v2 的节点上，容器运行时可能会使用内存请求值作为设置 memory.min 和 memory.low 的提示值。

内存限制定义的是 cgroup 的内存限制。如果容器尝试分配的内存量超出限制，则 Linux 内核的内存不足处理子系统会被激活，并停止尝试分配内存的容器中的某个进程。如果该进程在容器中 PID 为 1，而容器被标记为可重新启动，则 Kubernetes 会重新启动该容器。

Pod 或容器的内存限制也适用于通过内存供应的卷，例如 emptyDir 卷。 kubelet 会跟踪 tmpfs 形式的 emptyDir 卷用量，将其作为容器的内存用量，而不是临时存储用量。

如果某容器内存用量超过其内存请求值并且所在节点内存不足时，容器所处的 Pod 可能被逐出。

每个容器可能被允许也可能不被允许使用超过其 CPU 限制的处理时间。但是，容器运行时不会由于 CPU 使用率过高而杀死 Pod 或容器。

要确定某容器是否会由于资源限制而无法调度或被杀死，请参阅疑难解答节。

https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/#troubleshooting

疑难解答

我的 Pod 处于悬决状态且事件信息显示 `FailedScheduling`

如果调度器找不到该 Pod 可以匹配的任何节点，则该 Pod 将保持未被调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个 Event。你可以使用 kubectl 来查看 Pod 的事件；例如：

kubectl describe pod frontend | grep -A 9999999999 Events

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  23s   default-scheduler  0/42 nodes available: insufficient cpu

在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 无法被调度。由于内存不足（PodExceedsFreeMemory）而导致失败时，也有类似的错误消息。一般来说，如果 Pod 处于悬决状态且有这种类型的消息时，你可以尝试如下几件事情：

向集群添加更多节点。
终止不需要的 Pod，为悬决的 Pod 腾出空间。
检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是cpu：1，那么一个请求为 cpu: 1.1 的 Pod 永远不会被调度。
检查节点上的污点设置。如果集群中节点上存在污点，而新的 Pod 不能容忍污点，调度器只会考虑将 Pod 调度到不带有该污点的节点上。

你可以使用 kubectl describe nodes 命令检查节点容量和已分配的资源数量。例如：

kubectl describe nodes e2e-test-node-pool-4lw4

Name:            e2e-test-node-pool-4lw4
[ ... 这里忽略了若干行以便阅读 ...]
Capacity:
 cpu:                               2
 memory:                            7679792Ki
 pods:                              110
Allocatable:
 cpu:                               1800m
 memory:                            7474992Ki
 pods:                              110
[ ... 这里忽略了若干行以便阅读 ...]
Non-terminated Pods:        (5 in total)
  Namespace    Name                                  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------    ----                                  ------------  ----------  ---------------  -------------
  kube-system  fluentd-gcp-v1.38-28bv1               100m (5%)     0 (0%)      200Mi (2%)       200Mi (2%)
  kube-system  kube-dns-3297075139-61lj3             260m (13%)    0 (0%)      100Mi (1%)       170Mi (2%)
  kube-system  kube-proxy-e2e-test-...               100m (5%)     0 (0%)      0 (0%)           0 (0%)
  kube-system  monitoring-influxdb-grafana-v4-z1m12  200m (10%)    200m (10%)  600Mi (8%)       600Mi (8%)
  kube-system  node-problem-detector-v0.1-fj7m3      20m (1%)      200m (10%)  20Mi (0%)        100Mi (1%)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  CPU Requests    CPU Limits    Memory Requests    Memory Limits
  ------------    ----------    ---------------    -------------
  680m (34%)      400m (20%)    920Mi (11%)        1070Mi (13%)

在上面的输出中，你可以看到如果 Pod 请求超过 1.120 CPU 或者 6.23Gi 内存，节点将无法满足。

通过查看 "Pods" 部分，你将看到哪些 Pod 占用了节点上的资源。

Pods 可用的资源量低于节点的资源总量，因为系统守护进程也会使用一部分可用资源。在 Kubernetes API 中，每个 Node 都有一个 .status.allocatable 字段（详情参见 NodeStatus）。

字段 .status.allocatable 描述节点上可以用于 Pod 的资源总量（例如：15 个虚拟 CPU、7538 MiB 内存）。关于 Kubernetes 中节点可分配资源的信息，可参阅为系统守护进程预留计算资源。

你可以配置资源配额功能特性以限制每个名字空间可以使用的资源总量。当某名字空间中存在 ResourceQuota 时，Kubernetes 会在该名字空间中的对象强制实施配额。例如，如果你为不同的团队分配名字空间，你可以为这些名字空间添加 ResourceQuota。设置资源配额有助于防止一个团队占用太多资源，以至于这种占用会影响其他团队。

你还需要考虑为这些名字空间设置授权访问：为名字空间提供全部的写权限时，具有合适权限的人可能删除所有资源，包括所配置的 ResourceQuota。

我的容器被终止了

你的容器可能因为资源紧张而被终止。要查看容器是否因为遇到资源限制而被杀死，请针对相关的 Pod 执行 kubectl describe pod：

kubectl describe pod simmemleak-hra99

输出类似于：

Name:                           simmemleak-hra99
Namespace:                      default
Image(s):                       saadali/simmemleak
Node:                           kubernetes-node-tf0f/10.240.216.66
Labels:                         name=simmemleak
Status:                         Running
Reason:
Message:
IP:                             10.244.2.75
Containers:
  simmemleak:
    Image:  saadali/simmemleak:latest
    Limits:
      cpu:          100m
      memory:       50Mi
    State:          Running
      Started:      Tue, 07 Jul 2019 12:54:41 -0700
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Fri, 07 Jul 2019 12:54:30 -0700
      Finished:     Fri, 07 Jul 2019 12:54:33 -0700
    Ready:          False
    Restart Count:  5
Conditions:
  Type      Status
  Ready     False
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  42s   default-scheduler  Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
  Normal  Pulled     41s   kubelet            Container image "saadali/simmemleak:latest" already present on machine
  Normal  Created    41s   kubelet            Created container simmemleak
  Normal  Started    40s   kubelet            Started container simmemleak
  Normal  Killing    32s   kubelet            Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod

在上面的例子中，Restart Count: 5 意味着 Pod 中的 simmemleak 容器被终止并且（到目前为止）重启了五次。原因 OOMKilled 显示容器尝试使用超出其限制的内存量。

你接下来要做的或许是检查应用代码，看看是否存在内存泄露。如果你发现应用的行为与你所预期的相同，则可以考虑为该容器设置一个更高的内存限制（也可能需要设置请求值）。

接下来

获取分配内存资源给容器和 Pod 的实践经验
获取分配 CPU 资源给容器和 Pod 的实践经验

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/

超过容器限制的内存

当节点拥有足够的可用内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。如果容器分配的内存（request）超过其限制，该容器会成为被终止的候选容器。 如果容器继续消耗超出其限制的内存（limit），则终止容器。 如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-2
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-2-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"

超过整个节点容量的内存

内存请求和限制是与容器关联的，但将 Pod 视为具有内存请求和限制，也是很有用的。 Pod 的内存请求是 Pod 中所有容器的内存请求之和。同理，Pod 的内存限制是 Pod 中所有容器的内存限制之和。

Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求（request）的内存时，才会将 Pod 调度至节点上运行。

内存单位

内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。例如，下面是一些近似相同的值：

128974848, 129e6, 129M, 123Mi

如果你没有指定内存限制

如果你没有为一个容器指定内存限制（limit、），则自动遵循以下情况之一：

容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，进而可能导致该节点调用 OOM Killer。此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。 集群管理员可用使用 LimitRange 来指定默认的内存限制。

内存请求和限制的目的

通过为集群中运行的容器配置内存请求（request）和限制（limit），你可以有效利用集群节点上可用的内存资源。通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。通过让内存限制（limit）大于（request）内存请求，你可以完成两件事：

Pod 可以进行一些突发活动，从而更好的利用可用内存。
Pod 在突发活动期间，可使用的内存被限制为合理的数量

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/

如何为容器设置 CPU request（请求）和 CPU limit（限制）。容器使用的 CPU 不能超过所配置的限制。如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求（request）数量的 CPU 资源。

指定 CPU 请求和 CPU 限制

要为容器指定 CPU 请求，请在容器资源清单中包含 resources: requests 字段。要指定 CPU 限制，请包含 resources:limits。

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"

说明：

CPU 使用率低于 1.0 的另一种可能的解释是，节点可能没有足够的 CPU 资源可用。回想一下，此练习的先决条件需要你的集群至少具有 1 个 CPU 可用。如果你的容器在只有 1 个 CPU 的节点上运行，则容器无论为容器指定的 CPU 限制如何，都不能使用超过 1 个 CPU。

CPU 单位

CPU 资源以 CPU 单位度量。Kubernetes 中的一个 CPU 等同于：

1 个 AWS vCPU
1 个 GCP核心
1 个 Azure vCore
裸机上具有超线程能力的英特尔处理器上的 1 个超线程

小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。精度不能超过 1m。

CPU 请求只能使用绝对数量，而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。

设置超过节点能力的 CPU 请求

CPU 请求和限制与都与容器相关，但是我们可以考虑一下 Pod 具有对应的 CPU 请求和限制这样的场景。 Pod 对 CPU 用量的请求等于 Pod 中所有容器的请求数量之和。同样，Pod 的 CPU 资源限制等于 Pod 中所有容器 CPU 资源限制数之和。

Pod 调度是基于资源请求值（request）来进行的。仅在某节点具有足够的 CPU 资源来满足 Pod CPU 请求时，Pod 将会在对应节点上运行：

如果不指定 CPU 限制

如果你没有为容器指定 CPU 限制，则会发生以下情况之一：

容器在可以使用的 CPU 资源上没有上限。因而可以使用所在节点上所有的可用 CPU 资源。
容器在具有默认 CPU 限制的名字空间中运行，系统会自动为容器设置默认限制。集群管理员可以使用 LimitRange 指定 CPU 限制的默认值。

如果你设置了 CPU 限制但未设置 CPU 请求

如果你为容器指定了 CPU 限制值（limit）但未为其设置 CPU 请求（request），Kubernetes 会自动为其设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。

CPU 请求和限制的初衷

通过配置你的集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。通过使 CPU 限制大于 CPU 请求，你可以完成两件事：

Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。
Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。

标签：容器,scale,container,kubernetes,扩缩,内存,Pod,CPU,资源
From： https://www.cnblogs.com/panpanwelcome/p/17482494.html

container scale up/ down 原理 in kubernetes

原理与误区

配置快速扩容，为什么快不起来?

算法细节

工作量规模的稳定性

对资源指标的支持

可配置的扩缩行为

扩缩策略

稳定窗口

默认行为

kubectl 对 HorizontalPodAutoscaler 的支持

资源指标管道

Kubernetes 中的资源单位

CPU 资源单位

内存资源单位

Kubernetes 应用资源请求与限制的方式

疑难解答

我的 Pod 处于悬决状态且事件信息显示 `FailedScheduling`

我的容器被终止了

接下来

超过容器限制的内存

超过整个节点容量的内存

内存单位

如果你没有指定内存限制

内存请求和限制的目的

指定 CPU 请求和 CPU 限制

CPU 单位

设置超过节点能力的 CPU 请求

如果不指定 CPU 限制

如果你设置了 CPU 限制但未设置 CPU 请求

CPU 请求和限制的初衷

相关文章

赞助商

阅读排行

container scale up/ down 原理 in kubernetes

原理与误区

配置快速扩容，为什么快不起来?

算法细节

工作量规模的稳定性

对资源指标的支持

可配置的扩缩行为

扩缩策略

稳定窗口

默认行为

kubectl 对 HorizontalPodAutoscaler 的支持

资源指标管道

Kubernetes 中的资源单位

CPU 资源单位

内存资源单位

Kubernetes 应用资源请求与限制的方式

疑难解答

我的 Pod 处于悬决状态且事件信息显示 FailedScheduling

我的容器被终止了

接下来

超过容器限制的内存

超过整个节点容量的内存

内存单位

如果你没有指定内存限制

内存请求和限制的目的

指定 CPU 请求和 CPU 限制

CPU 单位

设置超过节点能力的 CPU 请求

如果不指定 CPU 限制

如果你设置了 CPU 限制但未设置 CPU 请求

CPU 请求和限制的初衷

相关文章

赞助商

阅读排行

我的 Pod 处于悬决状态且事件信息显示 `FailedScheduling`