深入Kubernetes内存指标

健康生活 2025年08月15日 20:25 1 admin

对于一个系统而言，若要实现可靠运行，监控至关重要。深入理解Kubernetes平台上的内存指标，能够实施有效的监控策略和问题分析，有助于提升系统的性能和稳定性。

容器内存requests and limits

在Kubernetes中，可以为容器设置CPU和内存资源限制，其中内存使用memory requests和memroy limits分别代表请求内存和限制内存。

requests是调度期间为容器分配的最小内存量。当调度Pod时，kube-scheduler会检查Kubernetes的资源请求，以分配一个满足Pod中容器所需最小内存量的节点。如果没有满足条件的节点，Pod将不会被调度，并保持 Pending 状态。

limits 是容器被允许消耗的最大内存量。容器使用的内存不允许超过设定的内存限制。在运行时，Kubernetes会检查Pod中的容器是否超过指定的内存限制。当容器试图消耗的内存超过允许的内存量时，系统内核将终止该进程（OOM）。

对于Kubernetes集群，以下指标通常用于衡量容器内存使用情况：

容器运行于节点之上，可以使用node-exporter服务来收集节点指标：

node_memory_MemTotal_bytes 节点内存总量
node_memory_MemFree_bytes 节点空闲内存，未被使用
node_memory_Cached_bytes 节点缓存使用的内存
node_memory_Buffers_bytes 节点缓冲使用的内存
node_memory_MemAvailable_bytes 节点可用内存，可供分配给新进程或现有进程的内存量，通常available包括free全部和大部分buff/cache内存

可以使用以下方法计算节点内存指标node_memory_MemUsed，通过该指标可以测量应用程序和系统在节点上使用的内存。

node_memory_MemUsed=node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes

节点内存使用量减去不包含缓存的容器内存使用量，可精确衡量节点在Kubernetes之外使用的、不易回收的内存量。

node_memory_MemUsed - sum(container_memory_usage_bytes - container_memory_cache)

容器的所有内存详细信息在路径 /sys/fs/cgroup/memory 下，可以找到诸如使用量、限制、缓存等内存指标。memory.stat文件包含容器内存公式所需的指标值。

RSS是主内存中的物理内存，它与磁盘上的任何内容都不对应。RSS包括堆栈、堆和匿名内存映射。在Kubernetes中，RSS被定义为匿名和交换缓存内存（包括透明大页）的数量。

WSS是进程在一段时间内工作所需的内存。在Kubernetes中，WSS被定义为工作集内存的大小，其中包括最近访问的内存、脏内存和内核内存，该值等于使用量减去total_inactive_file，如果WSS内存超过limit限制就会触发OOM。

从上述可以推断出：

一个没有设置内存限制的容器可能会消耗过多且不受控制的页面缓存。这个过程会增加工作集大小（WSS），并可能触发不必要的清除操作。你可以设置一个合适的内存限制，以限制容器的内存使用。当容器达到其内存阈值时，内核会开始从活动列表中回收可重用的页面。

在大多数情况下，很难决定应该监控哪个内存指标（RSS 还是 WSS）以确保系统可靠性。如果在 Pod 上设置了资源限制，则需要同时监控这两个指标，以防止它们出现内存不足（OOM）的情况。

当观察到内存使用接近其限制时，有关容器可能因内存不足而被 OOMKilled（内存耗尽）的担忧可能会产生。具体取决了程序的特性，在实践中通常会遇到如下场景：

RSS低、WSS高：通常是批量文件处理场景，有时候登录容器，执行一些grep log的操作，也会导致文件缓存升高从而引起WSS升高，这种建议使用RSS作为告警。

RSS高、WSS高：这种需要非常警惕，有可能存在内存泄露或者内存需要扩容。

在容器化系统中，准确监控内存是至关重要的。通过仔细分析这些指标，我们可以更好的理解程序的运行情况，确保性能并增强韧性。

发表评论