`
## Kubernetes 中的资源单位 {#resource-units-in-kubernetes}
### CPU 资源单位 {#meaning-of-cpu}
CPU 资源的限制和请求以 **cpu** 为单位。
在 Kubernetes 中，一个 CPU 等于 **1 个物理 CPU 核**或者 **1 个虚拟核**，
取决于节点是一台物理主机还是运行在某物理主机上的虚拟机。
你也可以表达带小数 CPU 的请求。
当你定义一个容器，将其 `spec.containers[].resources.requests.cpu` 设置为 `0.5` 时，
你所请求的 CPU 是你请求 `1.0` CPU 时的一半。对于 CPU 资源单位，
[数量](/zh-cn/docs/reference/kubernetes-api/common-definitions/quantity/)表达式 `0.1`
等价于表达式 `100m`，可以看作 “100 millicpu”。
有些人说成是“一百毫核”，其实说的是同样的事情。
CPU 资源总是设置为资源的绝对数量而非相对数量值。
例如，无论容器运行在单核、双核或者 48 核的机器上，`500m` CPU 表示的是大约相同的算力。
说明：
Kubernetes 不允许设置精度小于 1m 或 0.001 的 CPU 资源。
为了避免意外使用无效的 CPU 数量，当使用少于 1 个 CPU 单元时，使用
milliCPU 形式而不是十进制形式指定 CPU 单元非常有用。
例如，你有一个使用 5m 或 0.005 核 CPU 的 Pod，并且希望减少其 CPU 资源。
通过使用十进制形式，更难发现 0.0005 CPU 是无效值，而通过使用 milliCPU 形式，
更容易发现 0.5m 是无效值。
特性状态：
Kubernetes v1.34 [beta]（默认启用）
此特性可以通过设置 `PodLevelResources`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates)来启用。
以下 Pod 明确请求了 1 个 CPU 和 100 MiB 的内存，并设置了明确的限制值为 1 个 CPU 和 200 MiB 的内存。
`pod-resources-demo-ctr-1` 容器设置了明确的资源请求和限制值。不过 `pod-resources-demo-ctr-2`
容器没有设置明确的资源请求和限制，因此它将共享 Pod 资源边界内的可用资源。
apiVersion: v1
kind: Pod
metadata:
name: pod-resources-demo
namespace: pod-resources-example
spec:
resources:
limits:
cpu: "1"
memory: "200Mi"
requests:
cpu: "1"
memory: "100Mi"
containers:
- name: pod-resources-demo-ctr-1
image: nginx
resources:
limits:
cpu: "0.5"
memory: "100Mi"
requests:
cpu: "0.5"
memory: "50Mi"
- name: pod-resources-demo-ctr-2
image: fedora
command:
- sleep
- inf
## 带资源请求的 Pod 如何调度 {#how-pods-with-resource-limits-are-run}
当你创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。
每个节点对每种资源类型都有一个容量上限：可为 Pod 提供的 CPU 和内存量。
调度程序确保对于每种资源类型，所调度的容器的资源请求的总和小于节点的容量。
请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，如果容量检查失败，
调度程序仍会拒绝将 Pod 放置在该节点上。
当稍后节点上资源用量增加，例如到达请求率的每日峰值区间时，节点上也不会出现资源不足的问题。
## Kubernetes 处理资源请求与限制的方式 {#how-pods-with-resource-limits-are-run}
当 kubelet 将容器作为 Pod 的一部分启动时，它会将容器的 CPU 和内存请求与限制值信息传递给容器运行时。
在 Linux 系统上，容器运行时通常会配置内核
CGroup，负责应用并实施所定义的请求。
- CPU 限制定义的是容器可使用的 CPU 时间的硬性上限。
在每个调度周期（时间片）期间，Linux 内核检查是否已经超出该限制；
内核在允许该 CGroup 恢复执行之前会等待。
- CPU 请求值定义的是一个权重值。如果若干不同的容器（CGroup）需要在一个共享的系统上竞争运行，
CPU 请求值大的负载会获得比请求值小的负载更多的 CPU 时间。
- 内存请求值主要用于（Kubernetes）Pod 调度期间。在一个启用了 CGroup v2 的节点上，
容器运行时可能会使用内存请求值作为设置 `memory.min` 和 `memory.low` 的提示值。
- 内存限制定义的是 CGroup 的内存限制。如果容器尝试分配的内存量超出限制，
则 Linux 内核的 out-of-memory （内存不足）子系统会被激活，并停止尝试分配内存的容器中的某个进程。
如果该进程在容器中 PID 为 1，而容器被标记为可重新启动，则 Kubernetes
会重新启动该容器。
- Pod 或容器的内存限制也适用于以内存为介质的卷，例如 `emptyDir` 卷。
kubelet 会跟踪 `tmpfs` 形式的 `emptyDir` 卷用量，将其作为容器的内存用量，
而不是[临时存储](/zh-cn/docs/concepts/storage/ephemeral-storage/)用量。
当使用内存作为介质的 `emptyDir` 时，
请务必查看[下面](#memory-backed-emptydir)的注意事项。
如果某容器内存用量超过其内存请求值并且所在节点内存不足时，容器所处的 Pod
可能被逐出。
每个容器可能被允许也可能不被允许使用超过其 CPU 限制值的处理时间。
但是，容器运行时不会由于 CPU 使用率过高而杀死 Pod 或容器。
要确定某容器是否会由于资源限制而无法调度或被杀死，请参阅[问题诊断](#troubleshooting)节。
### 调整容器资源
创建 Pod 后，你可能需要根据实际使用情况调整其 CPU 或内存资源。Kubernetes
提供了两种调整 Pod 资源大小的方法：
#### 就地调整 {#pod-resize-inplace}
特性状态：
Kubernetes v1.35 [stable]（默认启用）
你无需重新创建 Pod 即可修改正在运行的 Pod 中容器的 CPU 和内存请求及限制。
这称为 "Pod 就地垂直扩容"或 "Pod 就地调整大小"。
要执行就地调整大小，请使用 Pod 的 `/resize` 子资源更新容器的资源规约。
你可以通过设置容器规约中的 `resizePolicy` 字段来控制是否需要重启容器。
#### 通过启动替换 Pod 来调整 Pod 的资源
云原生方式更改 Pod 资源的方法是更新工作负载对象（例如 Deployment 或 StatefulSet）中的
Pod 模板，并让工作负载控制器将旧 Pod 替换为具有更新资源的新 Pod。
此方法适用于任何 Kubernetes 版本，并且可以更改任何 Pod 规约。
有关 Pod 调整大小的更多详细信息，
请参阅[调整 Pod 大小](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-resize)。
有关就地调整大小的详细说明，
请参阅[调整分配给容器的 CPU 和内存资源](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/)。
你还可以使用[垂直 Pod 自动扩缩器](/zh-cn/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/)来自动管理
Pod 资源建议。
### 监控计算和内存资源用量 {#monitoring-compute-memory-resource-usage}
kubelet 会将 Pod 的资源使用情况作为 Pod
[`status`](/zh-cn/docs/concepts/overview/working-with-objects/#object-spec-and-status)
的一部分来报告的。
如果为集群配置了可选的[监控工具](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)，
则可以直接从[指标 API](/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)
或者监控工具获得 Pod 的资源使用情况。
### 使用内存作为介质的 `emptyDir` 卷的注意事项 {#memory-backed-emptydir}
注意：
如果你没有为 emptyDir 卷指定 sizeLimit，该卷就会消耗 Pod 的内存，
卷的用量上限为 Pod 的内存限制（Pod.spec.containers[].resources.limits.memory）。
如果你没有设置内存限制，Pod 的内存消耗将没有上限，并且可能会用掉节点上的所有可用内存。
Kubernetes 基于资源请求（Pod.spec.containers[].resources.requests）调度 Pod，
并且在决定另一个 Pod 是否适合调度到某个给定的节点上时，不会考虑超出请求的内存用量。
这可能导致拒绝服务，并使得操作系统需要处理内存不足（OOM）的情况。
用户可以创建任意数量的 emptyDir，可能会消耗节点上的所有可用内存，使得 OOM 更有可能发生。
说明：
在前面的请求中，~1 是在 patch 路径中对字符 / 的编码。
JSON-Patch 中的操作路径的值被视为 JSON-Pointer 类型。
有关更多详细信息，请参见
IETF RFC 6901 第 3 节。
说明：
扩展资源取代了非透明整数资源（Opaque Integer Resources，OIR）。
用户可以使用 kubernetes.io（保留）以外的任何域名前缀。
说明：
扩展资源不能过量使用，因此如果容器规约中同时存在请求和限制，则它们的取值必须相同。
