作者：龙蜥系统运维SIG
背景
容器化现阶段已经是构建企业 IT 架构的最佳实践。云原生容器化的部署架构，相较于传统 IDC 部署架构的 IT 架构方案，已经成为兼具高效运维及成本控制的业界事实标准。
但容器化带来的都是好处么？容器化屏蔽了 IDC 基础设施和云资源的同时，也带来了容器引擎层的不透明，现有的云原生可观测体系还无法覆盖。据我们统计，大量超过千节点规模的生产级 JAVA on K8s 的用户都遇到过内存“黑洞”导致的 OOM 问题，以及大规模集群使用上的容器引擎层 CGroup 问题也会使得用户对容器化望而却步。
阿里云容器服务 ACK 团队与阿里云操作系统团队进行合作，通过对多个头部行业客户的千万核规模的 Kubernetes 集群沉淀了丰富的容器化迁移专业经验，以及结合 Alinux 对操作系统 kernel 层的专业增强，通过与云原生容器服务结合，使容器引擎层不再“黑盒”，让用户放心容器化。
常见容器化内存“黑洞问题”
容器内存组成剖析
Kubernetes 采用内存工作集(workingset)来监控和管理容器的内存使用，当容器内存使用量超过了设置的内存限制或者节点出现内存压力时，Kubernetes 会根据 workingset 来决定是否驱逐或者杀死容器。
内存工作集计算公式：
Workingset = inactive_anon + active_anon + active_file。其中 inactive_anon 和 active_anon 是程序匿名内存总大小。active_file 是活跃文件缓存大小。
匿名内存
匿名内存是指没有关联到文件的内存，例如进程的堆、栈、数据段等，有以下几种部分组成：
匿名映射： 程序通过 mmap 系统调用创建的没有关联文件的内存映射。
堆： 程序通过 malloc/new 或 brk 系统调用分配的动态内存。
栈： 用于存储函数参数和局部变量的内存。
数据段： 用于存储已初始化和未初始化的全局变量和静态变量的内存。
活跃文件缓存
程序读写文件会产生文件缓存(file cache)，其中最近多次使用的缓存称为 active file cache，通常不 容易被系统回收。
（图/Kernel Level Memory Distribution）
下面介绍通过 SysOM 监控来排查 Pod workingset 高的问题。
定位步骤一：定位哪些内存导致 workingSet 高
根据 workingset 计算公式：workingset = inactive_anon + active_anon + active_file 查看 PodMonitor 监控大盘中的 woringkset 监控，找到内存最大的类型，这里发现是 active file cache 占比较大。
（图/SysOM 监控提供 Pod 维度的操作系统内核层内存各组成成分监控）
发现问题步骤中，SysOM 提供通过 Top 分析快速定位集群中 active file cache 内存消耗最大的 Pod。
通过 Pod Cache (缓存内存)、InactiveFile（非活跃文件内存占用）、InactiveAnon（非活跃匿名内存占用）、Dirty Memory（系统脏内存占用）等不同内存成分的问题的监控展示，发现常见的 Pod 内存黑洞问题。
（图/通过 Top 分析找出集群中 active file cache 内存消耗最大的 Pod）
（图/SysOM 提供 Pod 维度的详细内存各组成成分监控统计）
定位步骤二：定位具体哪些文件导致 active file cache 高
查看 PodMonitor 监控大盘中的 file cache 监控，发现主要是 ack-ai-dashboard-admin-ui-77564df84c-z6bs2 容器在对 /workspace/ai-dashboard.jar 文件进行 IO 读写时，产生了较大的内存 Cache 缓存。
若 Pod 内存缓存较大，严重会导致 Pod 工作内存占用升高，这部分 Cache 内存会成为 Pod 工作内存的“黑洞”部分难以定为，产生线上常见的 Pod 内存黑洞导致的 OOM 驱逐问题，最终影响 Pod 所在的业务体验。
ACK 提供容器化内核层问题的完整解决方案
发现问题 - SysOM 系统容器监控
基于阿里云 SysOM，阿里云容器服务 ACK 拥有独有的操作系统 kernel 层的容器监控可观测能力。在客户容器化迁移中，社区、其他云厂商的容器服务没有很好地解决的内存黑洞、存储黑洞等问题，基于阿里云 SysOM 可以很好的观测、预警、诊断出问题。
SysOM 提供操作系统内核层 Pod、Node 维度监控大盘，实时监控内存、网络、存储的系统层指标。
（图/SysOM Pod 维度监控大盘）
（图/SysOM Node 维度监控大盘）
SysOM 功能、指标详细请参考文档：help.aliyun.com/document_de…
解决问题 - Koordinator QoS精细化调度功能
内存黑洞问题如何修复，阿里云容器服务通过精细化调度功能，依托 Koordinator 阿里云开源项目，ack-koordinator 为容器提供内存服务质量 QoS（Quality of Service）保障能力，在确保内存资源公平性的前提下，改善应用在运行时的内存性能。本文简介容器内存 QoS 功能，具体说明请参见容器内存 QoS [ 1] 。
容器在使用内存时主要有以下两个方面的约束：
- 自身内存限制：当容器自身的内存（含Page Cache）接近容器上限时，会触发容器维度的内存回收，这个过程会影响容器内应用的内存申请和释放的性能。若内存申请得不到满足则会触发容器 OOM。
- 节点内存限制：当容器内存超卖（Memory Limit>Request）导致整机内存不足，会触发节点维度的全局内存回收，这个过程对性能影响较大，极端情况甚至导致整机异常。若回收不足则会挑选容器 OOM Kill。
针对上述典型的容器内存问题，ack-koordinator 提供了以下增强特性：
- 容器内存后台回收水位：当 Pod 内存使用接近 Limit 限制时，优先在后台异步回收一部分内存，缓解直接内存回收带来的性能影响。
- 容器内存锁定回收/限流水位：Pod 之间实施更公平的内存回收，整机内存资源不足时，优先从内存超用（Memory Usage>Request）的 Pod 中回收内存，避免个别Pod造成整机内存资源质量下降。
- 整体内存回收的差异化保障：在 BestEffort 内存超卖场景下，优先保障 Guaranteed/Burstable Pod 的内存运行质量。
关于 ACK 容器内存 QoS 启用的内核能力，详见 Alibaba Cloud Linux 的内核功能与接口概述 [ 2] 。
(图/ack-koordinator 为容器提供内存服务质量 QoS（Quality of Service）保障能力)
在通过第一步观测发现容器内存黑洞问题之后，可以结合通过 ACK 精细化调度功能针对性挑选内存敏感的 Pod 启用容器内存 QoS 功能，完成闭环修复。
相关链接：
[1] 容器内存链接
help.aliyun.com/zh/ack/ack-…
[2] Alibaba Cloud Linux的内核功能与接口概述
help.aliyun.com/zh/ecs/user…
