从内核的视角观测容器——SysOM 容器监控
作者:龙蜥系统运维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 功能、指标详细请参考文档:https://help.aliyun.com/document_detail/2560259.html
解决问题 - 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] 容器内存链接
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/memory-qos-for-containers
[2] Alibaba Cloud Linux的内核功能与接口概述
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
解密最受欢迎的开源 Serverless 框架:流量篇
作者:元毅 对于 web 应用来说,通过请求流量的并发数、qps、rt 等指标,可以很好的衡量当前的 web 服务质量。Knative 中提供了基于请求驱动的 Serverless 能力,包括多版本管理流量,流量访问,基于流量的弹性以及监控等。本文从流量角度出发,为您解密 Knative 相关的能力。 Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架,其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布、函数部署以及事件驱动等。 流量管理 如何做蓝绿发布 我们首先看一下,在 K8s 中如果要做基于流量的蓝绿发布需要怎么做? 首先需要创建对应的 K8s Service 与 Deployment,如果需要弹性,则还需要配置 HPA,然后在流量灰度发布时,要创建新的版本。以上图为例,创始版本是 v1,要想实现流量灰度发布,我们需要创建一个新的版本 v2。创建 v2 时,要创建对应的 Service、Deployment、HPA。创建完之后通过 I...
- 下一篇
秒速出图!体验 TensorRT 加速 Stable Diffusion 图像创作
作者:顾静 TensorRT 如何加速 Stable Diffusion? 生成式 AI 图像内容生成技术近年来发展迅速,可以根据人类语言描述生成图片,在时尚、建筑、动漫、广告、游戏等领域有着广泛应用。 Stable Diffusion WebUI 是 Github 上最为热门的利用生成式 AI 进行图像生成的项目。它采用 ClipText 对文字进行编码,然后采用 UNet+Scheduler 在潜在表示空间(latent space)上进行 Diffusion,最后采用 Autoencoder Decoder 将第二步生成的扩散信息再转为图像。 Stable Diffusion PipelineDiffusion 模型最大的痛点是生成图片的速度过慢。Stable Diffusion 采用了多种方式加速图片生成,令实时图像生成成为可能。Stable Diffusion 使用编码器将图片从 3512512 转为 46464,极大地降低了计算量。它在潜在表示空间(latent space)上进行 Diffusion 过程,大大减少计算复杂度,同时也能保证不错的图片生成效果。在 GPU 上...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Red5直播服务器,属于Java语言的直播服务器
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8安装Docker,最新的服务器搭配容器使用