Pod 和容器的资源管理

当您指定一个 Pod 时，您可以选择性地指定每个 容器 需要多少资源。最常见的资源是 CPU 和内存 (RAM)；还有其他资源。

当您指定 Pod 中容器的资源 *请求* 时，kube-scheduler 会使用此信息来决定将 Pod 放置在哪个节点上。当您为容器指定资源 *限制* 时，kubelet 会强制执行这些限制，以确保正在运行的容器不允许使用超过您设置的限制的资源。kubelet 还为该容器专门保留至少 *请求* 数量的系统资源以供使用。

请求和限制

如果 Pod 运行的节点有足够的资源可用，则容器可以使用超过其为该资源指定的 请求 的资源（这是可能的，也是允许的）。但是，容器不允许使用超过其资源 限制 的资源。

例如，如果您为容器设置了 256 MiB 的 memory 请求，并且该容器位于调度到具有 8GiB 内存且没有其他 Pod 的节点的 Pod 中，那么该容器可以尝试使用更多 RAM。

如果您为该容器设置了 4GiB 的 memory 限制，那么 kubelet（和 容器运行时）会强制执行该限制。运行时会阻止容器使用超过配置的资源限制。例如：当容器中的进程尝试消耗超过允许的内存量时，系统内核会终止尝试分配的进程，并出现内存不足 (OOM) 错误。

限制可以通过两种方式实现：反应式（系统在看到违规时进行干预）或强制式（系统阻止容器永远超过限制）。不同的运行时可以有不同的方式来实现相同的限制。

资源类型

CPU 和 memory 都是 *资源类型*。资源类型有一个基本单位。CPU 代表计算处理，以 Kubernetes CPU 单位指定。内存以字节为单位指定。对于 Linux 工作负载，您可以指定 *大页* 资源。大页是 Linux 特定的功能，其中节点内核分配的内存块远大于默认页面大小。

例如，在默认页面大小为 4KiB 的系统上，您可以指定限制 hugepages-2Mi: 80Mi。如果容器尝试分配超过 40 个 2MiB 大页（总计 80 MiB），则该分配失败。

CPU 和内存统称为 *计算资源* 或 *资源*。计算资源是可以请求、分配和消耗的可衡量数量。它们与 API 资源 不同。API 资源（如 Pod 和 服务）是可以通过 Kubernetes API 服务器读取和修改的对象。

Pod 和容器的资源请求和限制

对于每个容器，您可以指定资源限制和请求，包括以下内容

  • spec.containers[].resources.limits.cpu
  • spec.containers[].resources.limits.memory
  • spec.containers[].resources.limits.hugepages-<size>
  • spec.containers[].resources.requests.cpu
  • spec.containers[].resources.requests.memory
  • spec.containers[].resources.requests.hugepages-<size>

虽然您只能为单个容器指定请求和限制，但考虑 Pod 的整体资源请求和限制也很有用。对于特定资源，*Pod 资源请求/限制* 是 Pod 中每个容器的该类型资源请求/限制的总和。

Kubernetes 中的资源单位

CPU 资源单位

CPU 资源的限制和请求以 *cpu* 单位衡量。在 Kubernetes 中，1 个 CPU 单位相当于 **1 个物理 CPU 内核** 或 **1 个虚拟内核**，具体取决于节点是物理主机还是在物理机中运行的虚拟机。

允许使用小数请求。当您定义一个 spec.containers[].resources.requests.cpu 设置为 0.5 的容器时，您请求的 CPU 时间是请求 1.0 CPU 的一半。对于 CPU 资源单位，数量 表达式 0.1 等效于表达式 100m，可以理解为“一百毫芯”。有些人说“一百毫核”，这被理解为具有相同的含义。

CPU 资源始终以绝对资源量指定，而不是相对资源量。例如，500m CPU 代表的计算能力大致相同，无论该容器是在单核、双核还是 48 核机器上运行。

内存资源单位

memory 的限制和请求以字节为单位衡量。您可以使用以下 数量 后缀之一，将内存表示为纯整数或定点数：E、P、T、G、M、k。您也可以使用 2 的幂等效项：Ei、Pi、Ti、Gi、Mi、Ki。例如，以下表示大致相同的值

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

请注意后缀的大小写。如果您请求 400m 内存，则这是对 0.4 字节的请求。可能有人在输入时本意是请求 400 兆字节 (400Mi) 或 400 兆字节 (400M)。

容器资源示例

以下 Pod 有两个容器。这两个容器都定义了对 0.25 CPU 和 64MiB (226 字节) 内存的请求。每个容器的限制为 0.5 CPU 和 128MiB 内存。您可以说 Pod 的请求为 0.5 CPU 和 128 MiB 内存，限制为 1 CPU 和 256MiB 内存。

---
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"

具有资源请求的 Pod 如何调度

当您创建 Pod 时，Kubernetes 调度器会选择一个节点来运行 Pod。每个节点都具有每种资源类型的最大容量：它可以为 Pod 提供的 CPU 和内存量。调度器确保，对于每种资源类型，已调度容器的资源请求总和都小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用率非常低，但如果容量检查失败，调度器仍然会拒绝将 Pod 放置在节点上。这可以防止在资源使用率后来增加时（例如，在请求速率的每日峰值期间）节点上出现资源短缺。

Kubernetes 如何应用资源请求和限制

当 kubelet 启动 Pod 中的容器时，kubelet 会将该容器的内存和 CPU 请求和限制传递给容器运行时。

在 Linux 上，容器运行时通常会配置内核 cgroups，这些 cgroups 会应用和执行您定义的限制。

  • CPU 限制定义了容器可以使用多少 CPU 时间的硬性上限。在每个调度间隔（时间片）期间，Linux 内核会检查是否超过了此限制；如果是，则内核会在允许该 cgroup 恢复执行之前等待。
  • CPU 请求通常定义一个权重。如果多个不同的容器（cgroups）想要在竞争系统上运行，具有较大 CPU 请求的工作负载分配的 CPU 时间比具有较小请求的工作负载多。
  • 内存请求主要在（Kubernetes）Pod 调度期间使用。在使用 cgroups v2 的节点上，容器运行时可能会使用内存请求作为提示来设置 memory.min 和 memory.low。
  • 内存限制定义了该 cgroup 的内存限制。如果容器尝试分配的内存超过此限制，则 Linux 内核内存不足子系统会激活，并且通常会通过停止尝试分配内存的容器中的一个进程来进行干预。如果该进程是容器的 PID 1，并且容器被标记为可重启，则 Kubernetes 会重启容器。
  • Pod 或容器的内存限制也可以应用于内存支持卷中的页面，例如 emptyDir。kubelet 会将 tmpfs emptyDir 卷跟踪为容器内存使用情况，而不是作为本地临时存储。使用内存支持的 emptyDir 时，请务必查看 下面的 说明。

如果容器超过其内存请求，并且其运行所在的节点总体上内存不足，则该容器所属的 Pod 很可能会被 驱逐。

容器可能被允许或不被允许长时间超过其 CPU 限制。但是，容器运行时不会因过度使用 CPU 而终止 Pod 或容器。

要确定容器是否无法调度或因资源限制而被杀死，请参阅 故障排除 部分。

监控计算和内存资源使用情况

kubelet 会将 Pod 的资源使用情况报告为 Pod status 的一部分。

如果您的集群中提供了可选的 监控工具，则可以从 Metrics API 直接或从您的监控工具中检索 Pod 资源使用情况。

内存支持的 emptyDir 卷的注意事项

从内存管理的角度来看，进程使用内存作为工作区和使用内存支持的 emptyDir 时存在一些相似之处。但是，当使用内存作为卷（如内存支持的 emptyDir）时，您应该注意以下几点。

  • 存储在内存支持卷上的文件几乎完全由用户应用程序管理。与用作进程工作区时不同，您不能依赖诸如语言级垃圾回收之类的功能。
  • 将文件写入卷的目的是保存数据或在应用程序之间传递数据。Kubernetes 或操作系统都不会自动删除卷中的文件，因此当系统或 Pod 处于内存压力下时，这些文件使用的内存无法回收。
  • 内存支持的 emptyDir 由于其性能而非常有用，但内存通常比其他存储介质（如磁盘或 SSD）小得多，成本也高得多。将大量内存用于 emptyDir 卷可能会影响 Pod 或整个节点的正常运行，因此应谨慎使用。

如果您正在管理集群或命名空间，您还可以设置 ResourceQuota 来限制内存使用；您可能还想定义 LimitRange 以进行额外的强制执行。如果您为每个 Pod 指定了 spec.containers[].resources.limits.memory，则 emptyDir 卷的最大大小将是 Pod 的内存限制。

作为替代方案，集群管理员可以使用策略机制（例如 ValidationAdmissionPolicy）对新 Pod 中的 emptyDir 卷强制执行大小限制。

本地临时存储

功能状态： Kubernetes v1.25 [稳定]

节点具有本地临时存储，由本地连接的可写设备或有时由 RAM 支持。“临时”意味着对持久性没有长期保证。

Pod 使用本地临时存储作为临时空间、缓存和日志。kubelet 可以使用本地临时存储为 Pod 提供临时空间，以将 emptyDir 卷 装载到容器中。

kubelet 还使用这种存储来保存 节点级容器日志、容器镜像和正在运行的容器的可写层。

Kubernetes 允许您跟踪、保留和限制 Pod 可以消耗的本地临时存储量。

本地临时存储的配置

Kubernetes 支持两种在节点上配置本地临时存储的方法

在此配置中，您将所有不同类型的本地临时数据（emptyDir 卷、可写层、容器镜像、日志）放入一个文件系统中。配置 kubelet 的最有效方法是将此文件系统专门用于 Kubernetes (kubelet) 数据。

kubelet 还写入 节点级容器日志，并将这些日志视为与本地临时存储类似。

kubelet 将日志写入其配置的日志目录（默认情况下为 /var/log）中的文件；并且具有其他本地存储数据的基目录（默认情况下为 /var/lib/kubelet）。

通常，/var/lib/kubelet 和 /var/log 都位于系统根文件系统上，并且 kubelet 是针对这种布局设计的。

您的节点可以拥有任意数量的其他文件系统，这些文件系统不用于 Kubernetes。

您在节点上有一个文件系统，用于存储来自运行的 Pod 的临时数据：日志和 emptyDir 卷。您可以将此文件系统用于其他数据（例如：与 Kubernetes 无关的系统日志）；它甚至可以是根文件系统。

kubelet 还将 节点级容器日志 写入第一个文件系统，并将这些日志视为与本地临时存储类似。

您还使用一个单独的文件系统，该文件系统由不同的逻辑存储设备支持。在此配置中，您告诉 kubelet 将容器镜像层和可写层放置在的目录位于此第二个文件系统上。

第一个文件系统不保存任何镜像层或可写层。

您的节点可以拥有任意数量的其他文件系统，这些文件系统不用于 Kubernetes。

kubelet 可以衡量它正在使用多少本地存储。前提是您已使用支持的本地临时存储配置之一设置了节点。

如果您有不同的配置，则 kubelet 不会对本地临时存储应用资源限制。

设置本地临时存储的请求和限制

您可以指定 ephemeral-storage 来管理本地临时存储。Pod 的每个容器都可以指定以下任一项或两项

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

ephemeral-storage 的限制和请求以字节量度。您可以使用以下后缀之一将存储表示为普通整数或定点数字：E、P、T、G、M、k。您也可以使用二的幂等效项：Ei、Pi、Ti、Gi、Mi、Ki。例如，以下数量都表示大致相同的值

  • 128974848
  • 129e6
  • 129M
  • 123Mi

请注意后缀的大小写。如果您请求 400m 的临时存储，则这是对 0.4 字节的请求。可能有人在输入时可能想请求 400 兆字节 (400Mi) 或 400 兆字节 (400M)。

在以下示例中，Pod 有两个容器。每个容器都请求 2GiB 的本地临时存储。每个容器的本地临时存储限制为 4GiB。因此，Pod 的本地临时存储请求为 4GiB，限制为 8GiB。该限制中的 500Mi 可以由 emptyDir 卷消耗。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir:
        sizeLimit: 500Mi

具有临时存储请求的 Pod 如何调度

当您创建 Pod 时，Kubernetes 调度器会选择一个节点来运行 Pod。每个节点都具有可以为 Pod 提供的本地临时存储的最大量。有关更多信息，请参阅 节点可分配。

调度器确保已调度容器的资源请求总和小于节点的容量。

临时存储消耗管理

如果 kubelet 将本地临时存储作为资源进行管理，则 kubelet 会在以下方面衡量存储使用情况

  • emptyDir 卷，除了 tmpfs emptyDir 卷
  • 保存节点级日志的目录
  • 可写容器层

如果 Pod 使用的临时存储量超过了您允许的量，则 kubelet 会设置一个驱逐信号，该信号会触发 Pod 驱逐。

对于容器级别的隔离，如果容器的可写层和日志使用量超过其存储限制，kubelet 会将 Pod 标记为需要驱逐。

对于 Pod 级别的隔离，kubelet 会通过将 Pod 中所有容器的限制相加来计算出 Pod 的总存储限制。在这种情况下，如果所有容器的本地临时存储使用量以及 Pod 的 emptyDir 卷的总和超过 Pod 的总存储限制，kubelet 也会将 Pod 标记为需要驱逐。

kubelet 支持不同的方法来测量 Pod 存储使用情况

kubelet 会定期执行计划的检查，扫描每个 emptyDir 卷、容器日志目录和可写容器层。

扫描会测量使用了多少空间。

功能状态： Kubernetes v1.15 [alpha]

项目配额是操作系统级别的功能，用于管理文件系统上的存储使用情况。在 Kubernetes 中，您可以启用项目配额来监控存储使用情况。确保节点上支持 emptyDir 卷的文件系统提供项目配额支持。例如，XFS 和 ext4fs 提供项目配额。

Kubernetes 使用从 1048576 开始的项目 ID。正在使用的 ID 在 /etc/projects 和 /etc/projid 中注册。如果系统上将此范围内的项目 ID 用于其他目的，则必须在 /etc/projects 和 /etc/projid 中注册这些项目 ID，以使 Kubernetes 不使用它们。

配额比目录扫描更快、更准确。当目录被分配给一个项目时，在目录下创建的所有文件都在该项目中创建，内核只需跟踪该项目中的文件使用了多少块。如果一个文件被创建和删除，但有一个打开的文件描述符，它会继续占用空间。配额跟踪会准确地记录该空间，而目录扫描会忽略已删除文件使用的存储空间。

如果您想使用项目配额，您应该

  • 使用 kubelet 配置 中的 featureGates 字段或 --feature-gates 命令行标志启用 LocalStorageCapacityIsolationFSQuotaMonitoring=true 功能门控。

  • 确保根文件系统（或可选的运行时文件系统）启用了项目配额。所有 XFS 文件系统都支持项目配额。对于 ext4 文件系统，您需要在文件系统未挂载时启用项目配额跟踪功能。

    # For ext4, with /dev/block-device not mounted
sudo tune2fs -O project -Q prjquota /dev/block-device

  • 确保根文件系统（或可选的运行时文件系统）已挂载并启用了项目配额。对于 XFS 和 ext4fs，挂载选项名为 prjquota。

扩展资源

扩展资源是 kubernetes.io 域之外的完全限定资源名称。它们允许集群管理员发布和用户使用非 Kubernetes 内置资源。

使用扩展资源需要两个步骤。首先，集群管理员必须发布扩展资源。其次，用户必须在 Pod 中请求扩展资源。

管理扩展资源

节点级扩展资源

节点级扩展资源与节点绑定。

设备插件管理的资源

请参阅设备插件，了解如何在每个节点上发布设备插件管理的资源。

其他资源

要发布新的节点级扩展资源，集群管理员可以向 API 服务器提交一个 PATCH HTTP 请求，以指定集群中节点的 status.capacity 中的可用数量。此操作完成后，节点的 status.capacity 将包含一个新的资源。status.allocatable 字段会由 kubelet 异步更新，自动包含新的资源。

由于调度器在评估 Pod 适应性时使用节点的 status.allocatable 值，因此调度器只会在异步更新后才考虑新值。在用新资源修补节点容量与第一个请求该资源的 Pod 可以调度到该节点的时间之间可能会有短暂的延迟。

示例

以下示例展示了如何使用 curl 形成一个 HTTP 请求，该请求在主节点为 k8s-master 的节点 k8s-node-1 上发布五个“example.com/foo”资源。

curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status

集群级扩展资源

集群级扩展资源不与节点绑定。它们通常由调度器扩展器管理，调度器扩展器处理资源消耗和资源配额。

您可以在调度器配置中指定由调度器扩展器处理的扩展资源。

示例

以下调度器策略配置表明集群级扩展资源“example.com/foo”由调度器扩展器处理。

  • 调度器仅在 Pod 请求“example.com/foo”时才将 Pod 发送到调度器扩展器。
  • ignoredByScheduler 字段指定调度器在其 PodFitsResources 谓词中不检查“example.com/foo”资源。
{
  "kind": "Policy",
  "apiVersion": "v1",
  "extenders": [
    {
      "urlPrefix":"<extender-endpoint>",
      "bindVerb": "bind",
      "managedResources": [
        {
          "name": "example.com/foo",
          "ignoredByScheduler": true
        }
      ]
    }
  ]
}

使用扩展资源

用户可以在 Pod 规范中使用扩展资源，就像使用 CPU 和内存一样。调度器负责资源记账，以确保同时分配给 Pod 的资源不超过可用资源。

API 服务器将扩展资源的数量限制为整数。有效数量的示例包括 3、3000m 和 3Ki。无效数量的示例包括 0.5 和 1500m（因为 1500m 会导致 1.5）。

要在 Pod 中使用扩展资源，请将资源名称作为键包含在容器规范中的 spec.containers[].resources.limits 映射中。

只有在满足所有资源请求（包括 CPU、内存和任何扩展资源）的情况下，Pod 才会被调度。只要无法满足资源请求，Pod 就会一直处于 PENDING 状态。

示例

下面的 Pod 请求 2 个 CPU 和 1 个“example.com/foo”（一个扩展资源）。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        example.com/foo: 1
      limits:
        example.com/foo: 1

PID 限制

进程 ID (PID) 限制允许配置 kubelet 以限制给定 Pod 可以使用的 PID 数量。有关信息，请参阅PID 限制。

故障排除

我的 Pod 处于挂起状态，事件消息为 FailedScheduling

如果调度器无法找到任何可以容纳 Pod 的节点，Pod 将保持未调度状态，直到找到一个位置。每次调度器无法为 Pod 找到位置时，都会生成一个事件。您可以使用 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

在前面的示例中，名为“frontend”的 Pod 由于任何节点上的 CPU 资源不足而无法调度。类似的错误消息也可能表明由于内存不足而导致失败 (PodExceedsFreeMemory)。一般来说，如果 Pod 处于挂起状态，并且消息类型为这种类型，您可以尝试以下几种方法

  • 向集群添加更多节点。
  • 终止不需要的 Pod，为挂起的 Pod腾出空间。
  • 检查 Pod 是否大于所有节点。例如，如果所有节点的容量都为 cpu: 1，那么请求为 cpu: 1.1 的 Pod 将永远不会被调度。
  • 检查节点污点。如果大多数节点都被污点标记，而新 Pod 不容忍该污点，调度器只考虑放置到没有该污点的剩余节点上。

您可以使用 kubectl describe nodes 命令检查节点容量和已分配的容量。例如

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

Name:            e2e-test-node-pool-4lw4
[ ... lines removed for clarity ...]
Capacity:
 cpu:                               2
 memory:                            7679792Ki
 pods:                              110
Allocatable:
 cpu:                               1800m
 memory:                            7474992Ki
 pods:                              110
[ ... lines removed for clarity ...]
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 请求的 CPU 超过 1.120 个，或内存超过 6.23Gi，那么该 Pod 将无法容纳在该节点上。

通过查看“Pods”部分，您可以看到哪些 Pod 正在占用节点上的空间。

可用于 Pod 的资源量小于节点容量，因为系统守护进程使用了一部分可用资源。在 Kubernetes API 中，每个节点都有一个 .status.allocatable 字段（有关详细信息，请参阅NodeStatus）。

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

您可以配置资源配额以限制命名空间可以使用的资源总量。当命名空间中存在 ResourceQuota 时，Kubernetes 会对该命名空间中的对象执行配额。例如，如果您将特定命名空间分配给不同的团队，您可以在这些命名空间中添加 ResourceQuotas。设置资源配额有助于防止一个团队使用过多的任何资源，从而影响其他团队。

您还应该考虑您授予该命名空间的访问权限：对命名空间的完全写入访问权限允许具有该访问权限的人员删除任何资源，包括已配置的 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 原因表明容器试图使用的内存超过了其限制。

您下一步可能是检查应用程序代码是否存在内存泄漏。如果您发现应用程序的行为符合预期，请考虑为该容器设置更高的内存限制（以及可能的请求）。

下一步

上次修改时间：2024 年 7 月 13 日，太平洋标准时间上午 8:36：Add caution for using memory-backed emptydir (#44949) (2c45e1ae28)