4.8.3 容器的可见资源

细心的读者可能已经发现了这一点：于容器中运行的 top 等命令观察资源可用量信息时，即便定义了 requests 和 limits 属性，虽然其可用资源受限于此两个文明属性的定义，但容器中可见的资源量依然是节点级别的可用总量。例如，为前面定义的 stress-pod 添加如下 limits 属性定义：

    limits:
      memory: "512Mi"
      cpu: "400m"

重新创建 stress-pod 对象，并于其容器内分别列出容器可见的内核和CPU资源总量，命令及结果如下所示：

**[terminal]
**[delimiter $ ]**[command kubectl exec stress-pod -- cat /proc/meminfo | grep ^MemTotal]
MemTotal:        8009032 kB
**[delimiter $ ]**[command kubectl exec stress-pod -- cat /proc/cpuinfo | grep -c ^processor]
4

命令结果中显示其可用内存资源总量为80009032KB（8GB），CPU 核心数为8个，这是节点级的资源数量，而非由容器的 limits 所定义的 512Mi 和 400m。其实，这种结果不仅仅使得其查看命令的显示结果看起来有些奇怪，而且对有些容器应用的配置也会带来不小的负面影响。

较为经典的是在 Pod 中运行 Java 应用程序时，若未使用 “-Xmx” 选项指定 JVM 的堆内存可用总量，它默认会设置为主机内存总量的一个空间比例（如30%），这会导致容器中的应用程序申请内存资源时将会达到上限而转为 OOMKilled。另外，即便使用了“-Xmx”选项设置其堆内存上限，但它对于非堆内存的可用空间不会产生任何限制作用，结果是仍然存在达到容器内存资源上限的可能性。

另一个颇具代表性的场景是于 Pod 中运行的 Nginx 应用，在配置参数 worker_processes 的值为 “auto” 时，主进程会创建于 Pod 中能够访问到的 CPU 核心数相同数量的 worker 进程。若 Pod 的实际可用 CPU 核心远低于主机级别的数量时，那么这种设置在较大的并发访问负荷下会导致严重的资源竞争，并将带来更多的内存资源消耗。一个较为妥当的解决方案是使用 Downward API 将 limits 定义的资源量暴露给容器，这一点将在后面的章节中予以介绍。