更新时间:2024-10-14 GMT+08:00

设置容器规格

操作场景

CCE支持在创建工作负载时为添加的容器设置资源的需求量和限制,最常见的可设定资源是 CPU 和内存(RAM)大小。此外Kubernetes还支持其他类型的资源,可通过YAML设置。

申请与限制

CPU配额内存配额设置中,申请限制的含义如下:
  • 申请(Request):根据申请值调度该实例到满足条件的节点去部署工作负载。
  • 限制(Limit):根据限制值限制工作负载使用的资源。

如果实例运行所在的节点具有足够的可用资源,实例可以使用超出申请的资源量,但不能超过限制的资源量。

例如,如果您将实例的内存申请值为1GiB、限制值为2GiB,而该实例被调度到一个具有8GiB CPU的节点上,且该节点上没有其他实例运行,那么该实例在负载压力较大的情况下可使用超过1GiB的内存,但内存使用量不得超过2GiB。若容器中的进程尝试使用超过2GiB的资源时,系统内核将会尝试将进程终止,出现内存不足(OOM)错误。

创建工作负载时,建议设置CPU和内存的资源上下限。同一个节点上部署的工作负载,对于未设置资源上下限的工作负载,如果其异常资源泄露会导致其它工作负载分配不到资源而异常。未设置资源上下限的工作负载,工作负载监控信息也会不准确。

配置说明

在实际生产业务中,建议申请和限制比例为1:1.5左右,对于一些敏感业务建议设置成1:1。如果申请值过小而限制值过大,容易导致节点超分严重。如果遇到业务高峰或流量高峰,容易把节点内存或者CPU耗尽,导致节点不可用的情况发生。

  • CPU配额:CPU资源单位为核,可以通过数量或带单位后缀(m)的整数表达,例如数量表达式0.1核等价于表达式100m,但Kubernetes不允许设置精度小于1m的CPU资源。
    表1 CPU配额说明

    参数

    说明

    CPU申请

    容器使用的最小CPU需求,作为容器调度时资源分配的判断依赖。只有当节点上可分配CPU总量 ≥ 容器CPU申请数时,才允许将容器调度到该节点。

    CPU限制

    容器能使用的CPU最大值。

    建议配置方法

    节点的实际可用分配CPU量 ≥ 当前实例所有容器CPU限制值之和 ≥ 当前实例所有容器CPU申请值之和,节点的实际可用分配CPU量请在资源管理 > 节点管理中对应节点的“可分配资源”列下查看“CPU: ** Core”

  • 内存配额:内存资源默认单位为字节,或者也可以使用带单位后缀的整数来表达,例如100Mi。但需要注意单位大小写。
    表2 内存配额说明

    参数

    说明

    内存申请

    容器使用的最小内存需求,作为容器调度时资源分配的判断依赖。只有当节点上可分配内存总量 ≥ 容器内存申请数时,才允许将容器调度到该节点。

    内存限制

    容器能使用的内存最大值。当内存使用率超出设置的内存限制值时,该实例可能会被重启进而影响工作负载的正常使用。

    建议配置方法

    节点的实际可用分配内存量 ≥ 当前节点所有容器内存限制值之和 ≥ 当前节点所有容器内存申请值之和,节点的实际可用分配内存量请在资源管理 > 节点管理中对应节点的“可分配资源”列下查看“内存: ** GiB”

可分配资源:可分配量按照实例申请值(Request)计算,表示实例在该节点上可请求的资源上限,不代表节点实际可用资源(请参见CPU和内存配额使用示例)。 计算公式为:

  • 可分配CPU = CPU总量 - 所有实例的CPU申请值 - 其他资源CPU预留值
  • 可分配内存 = 内存总量 - 所有实例的内存申请值 - 其他资源内存预留值

CPU和内存配额使用示例

假设集群中可调度的节点资源总量为4Core 8GiB,且已经在集群中部署了两个实例,其中实例1存在CPU和内存资源超分(即限制值>申请值),而实例2不存在资源超分。两个实例的规格设置如下:

实例

CPU申请

CPU限制

内存申请

内存限制

实例1

1Core

2Core

1GiB

4GiB

实例2

2Core

2Core

2GiB

2GiB

那么节点上CPU和内存的资源使用情况如下:

  • CPU可分配资源=4Core-(实例1申请的1Core+实例2申请的2Core)=1Core
  • 内存可分配资源=8GiB-(实例1申请的1GiB+实例2申请的2GiB)=5GiB

此时节点还剩余1Core 5GiB的资源可供下一个新增的实例调度。

如果实例1处于业务高峰、负载压力较大时,会尝试在限制值范围内使用更多的CPU和内存,因此实际可用的资源将会小于1Core 5GiB。

其他资源配额

节点通常还可以具有本地的临时性存储Ephemeral Storage),由本地挂载的可写入设备或者有时也用RAM来提供支持。临时性存储所存储的数据不提供长期可用性的保证,Pod通常可以使用本地临时性存储来实现缓冲区、保存日志等功能,也可以使用emptyDir类型的存储卷挂载到容器中。更多详情请参见本地临时存储

Kubernetes支持在容器的定义中指定ephemeral-storage的申请值和限制值来管理本地临时性存储。 Pod中的每个容器可以设置以下属性:

  • spec.containers[].resources.limits.ephemeral-storage
  • spec.containers[].resources.requests.ephemeral-storage

以下示例中,Pod包含两个容器,每个容器的本地临时性存储申请值为2GiB,限制值为4GiB。 因此,整个Pod的本地临时性存储申请值是4GiB,限制值为8GiB,且emptyDir卷使用了500Mi的本地临时性存储。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: container-1
    image: <example_app_image>
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: container-2
    image: <example_log_aggregator_image>
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir:
        sizeLimit: 500Mi