Harvester 节点 KSM 内存合并支持:Ksmtuned 控制器设计全解析

发布时间:2026/10/14 15:40:58
Harvester 节点 KSM 内存合并支持:Ksmtuned 控制器设计全解析 云原生虚拟化存储后端高可用【免费下载链接】harvesterOpen source hyperconverged infrastructure (HCI) software项目地址https://gitcode.com/gh_mirrors/ha/harvester点击查看免费下载导读本文以 Harvester 开源仓库中的增强设计文档 enhancements/20220823-node-manager-support-ksm.md 为核心系统讲解 Harvester 如何在节点上启用内核同页合并Kernel Samepage MergingKSM以降低集群内存占用并给出完整的 Ksmtuned 控制器设计方案——包括三种运行模式stop/run/prune、三种配置模式standard/high/customized、Ksmtuned 自定义资源CR的完整 YAML 示例、各参数语义、控制器行为与可落地的测试计划。读完本文你将掌握KSM 在 Harvester 中的整体架构、如何通过 UI/API 替代逐节点命令行配置、thresCoef等关键参数如何影响 ksmd 的扫描与合并行为以及如何验证 KSM 是否按预期运行。一、背景与动机为什么 Harvester 需要 KSMKSMKernel Samepage Merging是 Linux 内核提供的内存去重机制它允许内核将内容相同的物理内存页合并为共享页从而显著降低运行大量相似工作负载例如多个运行相同操作系统镜像的虚拟机时的内存消耗。在 Harvester 这类超融合基础设施HCI中节点上往往同时运行多个 KVM 虚拟机内存是稀缺资源启用 KSM 可以有效提升内存使用效率。该增强方案的核心目标Goals包括配置方式现代化从 UI 或 API 配置 Ksmtuned替代登录每台节点使用命令行手工配置的运维方式降低操作复杂度和安全风险可观测性监控节点 ksmd 进程的 CPU 利用率暴露给 Prometheus 抓取工程化落地将 Ksmtuned 脚本转换为 Go 程序并补充单元测试计划直接集成进 Harvester 的 ISO 发布物中。方案原计划在 GA 版本 1.1.0 中首次交付API 层面不引入额外变更。当前仓库中与 KSM 相关的 KubeVirt 侧能力也已存在在 pkg/apis/harvesterhci.io/v1beta1/openapi_generated.go 中可以看到 KubeVirt 的KSMConfiguration定义其nodeLabelSelector字段用于按节点标签过滤启用 KSM 的节点同时 pkg/controller/master/node/condition_annotations_test.go 中出现了kubevirt.io/ksm-enabled、kubevirt.io/ksm-handler-managed注解说明节点侧 KSM 状态会通过节点注解暴露。本方案则是在此基础上把节点 KSM 参数的调优与管理能力以 Ksmtuned 控制器的形式沉淀为声明式配置。二、总体设计DaemonSet Ksmtuned CR 的双层架构2.1 实现总览方案的核心是部署一个Ksmtuned controller控制器来管理 Harvester 各节点的 KSM 配置。其实现要点使用DaemonSet在每个节点上运行每个节点只获取与自身相关的配置信息天然实现一节点一配置的隔离控制器按配置写入 KSM 的 sysfs 接口文件/sys/kernel/mm/ksm/下的run、pages_to_scan等并定时读取节点的内存使用情况根据阈值计算结果启动或停止 ksmd 程序实现内存充足时让出 CPU、内存紧张时才合并的自适应行为。这种设计把原先需要运维人员逐台登录节点执行的脚本化操作抽象为 Kubernetes 原生的声明式资源管理与 Harvester 的以 API/UI 管理集群理念一致。2.2 Ksmtuned 自定义资源CRKsmtuned CR 的 API 分组为node.harvesterhci.io/v1beta1kind 为Ksmtuned一个 CR 对应一个节点的 KSM 管理配置CR 与 Node 通过ownerReferences建立归属关系。当spec.mode为standard标准或high高性能模式时spec.ksmtunedParameters展示对应的配置参数。一个典型的 CR 如下apiVersion: node.harvesterhci.io/v1beta1 kind: Ksmtuned metadata: name: node1 ownerReferences: - apiVersion: v1 kind: Node name: node1 spec: ksmtunedParameters: boost: 0 decay: 0 maxPages: 100 minPages: 100 sleepMsec: 20 mergeAcrossNodes: 0 mode: standard/high/customized run: stop/run/prune thresCoef: 20 status: fullScans: 17 ksmdPhase: Stopped/Running/Pruned shared: 171264 sharing: 1368772 stableNodeChains: 12 stableNodeDups: 538 unshared: 545943 volatile: 10909其中status字段直接反映内核 KSM 的运行状态与统计信息fullScans、shared、sharing、stableNodeChains、stableNodeDups、unshared、volatile以及当前 ksmd 的阶段ksmdPhaseStopped/Running/Pruned让管理员无需进入节点即可掌握 KSM 的实时合并效果。三、三种运行模式与三种配置模式3.1 运行模式spec.run用户故事中明确了三种运行选项覆盖 KSM 生命周期的管理运行模式行为适用场景stop停止 Ksmtuned 与 KSM但已存在的共享内存页继续保留临时关闭合并避免影响 VM 内存访问性能run运行 Ksmtuned按配置驱动 KSM 工作日常默认运行态prune停止 Ksmtuned 并清理pruneKSM 共享内存页需要彻底回收共享页、恢复独立内存布局时需要特别说明当spec.run为stop时只是挂起ksmtuned虚拟机仍可继续使用已有的共享内存页因此不会引发 VM 内存内容丢失只有prune才会真正清理共享页见下文示例中的 status 归零。3.2 配置模式spec.mode方案提供三种配置模式决定 ksmd 对 CPU 资源的占用策略与扫描合并效率Standard标准模式默认控制节点的 ksmd 大约占用单个 CPU 的 20%参数如下boost: 0 decay: 0 minPages: 100 maxPages: 100 sleepMsec: 20由于boost与decay均为 0每次扫描的页数恒定在 100 页CPU 占用平稳可控适合默认部署场景。High Performance高性能模式节点 ksmd 占用单个 CPU 的 20%100%扫描与合并效率更高参数如下boost: 200 decay: 50 minPages: 100 maxPages: 10000 sleepMsec: 20该模式下boost与decay非零扫描页数会随内存压力动态在 10010000 页之间调整内存越紧张扫描越激进从而更快完成合并。Customized自定义模式完全由用户自定义参数以达成期望的性能与 CPU 占用平衡。当spec.mode为customized时必须自行配置spec.ksmtunedParameters。四、Ksmtuned 参数语义详解Ksmtuned.spec中的每个参数都直接影响内核 KSM 的行为理解其语义是调优的关键runstop/run/prune停止/运行 Ksmtuned 或清理共享页modestandard/high/customized三种配置模式thresCoef空闲内存阈值百分比。当可用内存低于设定百分比时 KSM 启动否则停止。这是 KSM 自适应的核心开关mergeAcrossNodes指定是否允许合并来自不同 NUMA 节点的内存页0 为不允许1 为允许对多路服务器上的跨 NUMA 合并行为有直接影响ksmtunedParameters.boost当可用内存低于阈值时每次扫描页数的增量用于增压加速合并ksmtunedParameters.decay当可用内存高于阈值时每次扫描页数的减量用于减压让出 CPUksmtunedParameters.maxPages每次扫描的最大页数上限ksmtunedParameters.minPages每次扫描的最小页数即首次运行的初始配置值ksmtunedParameters.sleepMsec每次调整配置的时间间隔基准两次扫描的实际间隔由公式sleepMsec * 16 * 1024 * 1024 / total memory计算得出单位毫秒即根据节点总内存动态换算扫描间隔。设计文档中特别指出由于 KSM 运行在单一模式下大内存设备可能长时间占用 CPU。为解决此问题ksmtuned 脚本通过阈值机制thresCoef让 KSM 仅在空闲内存低于一定百分比时运行从而在内存充裕时避免无谓的 CPU 消耗——这正是thresCoef与boost/decay配合实现的自适应调节链路。五、各运行状态的 CR 配置实例5.1 自动创建的标准模式 CRKsmtuned 控制器会检查节点的 Ksmtuned CR 是否存在若不存在则自动为该节点创建一个mode 为 standard、thresCoef 为 20、状态为 stop的 CR默认配置避免新节点因启用 KSM 引入意外开销。对应 CR 形态spec: run: run mode: customized thresCoef: 20 ksmtuneddParameters: boost: 300 decay: 50 maxPages: 2000 minPages: 100 sleepMsec: 20注上面展示的是自定义模式示例即mode: customized时需要显式给出全部ksmtunedParameters此处boost: 300、maxPages: 2000演示了比标准模式更激进的合并策略。5.2 runstop挂起 KSM、保留共享页apiVersion: harvesterhci.io/v1beta1 kind: Ksmtuned metadata: name: harvester-master spec: ksmtunedParameters: boost: 0 decay: 0 maxPages: 100 minPages: 100 sleepMsec: 20 mergeAcrossNodes: 0 mode: standard run: stop thresCoef: 20 status: sharing: 17299179 shared: 312514 unshared: 2334736 volatile: 65571 fullScans: 14102 stableNodeChains: 30 stableNodeDups: 56249 ksmdPhase: Stopped可以看到run: stop后ksmdPhase变为Stopped但sharing共享节省的内存仍保留在 17299179证明已合并的页面未被破坏。5.3 runprune停止并清理共享页apiVersion: harvesterhci.io/v1beta1 kind: Ksmtuned metadata: name: harvester-master spec: ksmtunedParameters: boost: 0 decay: 0 maxPages: 100 minPages: 100 sleepMsec: 20 mergeAcrossNodes: 0 mode: standard run: prune thresCoef: 20 status: sharing: 0 shared: 0 unshared: 0 volatile: 0 fullScans: 0 stableNodeChains: 0 stableNodeDups: 0 ksmdPhase: Prunedrun: prune后所有合并统计全部归零ksmdPhase为Pruned表明共享内存页已被彻底清理系统回到未合并的初始状态。5.4 通过 status 观测 KSM 内核指标Ksmtuned CR 的status用于展示内核 KSM daemon 的 sysfs 指标与 ksmd 阶段。控制器会持续将以下内核统计同步进 CRapiVersion: harvesterhci.io/v1beta1 kind: Ksmtuned metadata: name: harvester-master spec: ... status: sharing: 17299179 shared: 312514 unshared: 2334736 volatile: 65571 fullScans: 14102 stableNodeChains: 30 stableNodeDups: 56249 ksmdPhase: Stopped/Running/Pruned这些字段与/sys/kernel/mm/ksm/下同名指标一一对应sharing为共享页节省的字节数、shared为共享页数、fullScans为完成的扫描次数、stableNodeDups/stableNodeChains为稳定树的去重计数、volatile为易变页数、unshared为取消共享的页数。将内核状态提升为 CR 的 status使得 Grafana/Prometheus 与 UI 可以统一从 API 读取无需再进入节点查看/sys文件。六、控制器行为设计6.1 Node Controller节点控制器自动创建同步 Node 时若该节点的 Ksmtuned CR 不存在则自动为其创建默认mode 为 standard、thresCoef 为 20、run 状态为 stop随节点清理Node 被删除时同步删除该节点的 Ksmtuned CR避免残留配置造成状态漂移。6.2 Ksmtuned ControllerKsmtuned 控制器配置驱动运行Ksmtuned CR 被创建/更新时运行状态适配预定义standard/high或自定义customized配置否则停止运行程序删除即终止Ksmtuned CR 被删除时终止对应的 ksmtuned 程序确保声明式配置与实际进程状态一致。6.3 监控指标Metrics暴露ksmd 程序的 CPU 利用率指标供 Prometheus 抓取对应设计文档中的目标Monitor node ksmd CPU utilization并关联到 Harvester 的监控看板见下节 UI 体验。七、用户体验UI 展示与配置入口在 UI 层面方案规划了两处入口节点级配置KSM 配置将在Hosts → info/edit → KSM页面展示与配置。管理员无需登录节点执行命令行即可针对每个节点选择运行模式stop/run/prune与配置模式standard/high/customized并直接编辑thresCoef、boost、decay等参数集群级观测在 Dashboard 页面的Cluster Metrics集群指标中增加ksmd 利用率 Top10图表直观展示各节点 ksmd 的 CPU 占用排名配合第 6.3 节的 Prometheus 指标形成配置—运行—观测闭环。八、测试计划如何验证 KSM 按预期运行设计文档给出了可直接落地的验证方法核心思路是利用/sys/kernel/mm/ksm/run与pages_to_scan两个内核接口观察 KSM 行为验证 thresCoef 阈值逻辑设置thresCoef: 20后当可用内存总量低于 总内存 × 0.2 时执行cat /sys/kernel/mm/ksm/run应输出1KSM 开启反之内存充足应输出0KSM 关闭观察扫描页数动态变化使用watch -n1 grep . /sys/kernel/mm/ksm/*持续观察pages_to_scan的变化即可验证boost、decay、maxPages、minPages配置是否生效——内存紧张时pages_to_scan应随 boost 递增内存充裕时应随 decay 递减且不超出[minPages, maxPages]区间。完整的测试步骤如下准备一台内存充足的节点并预先创建大量虚拟机制造可合并的内存页检查自动为该节点创建的 Ksmtuned CR应默认 standard/thresCoef20/stop按测试预期调整该节点 Ksmtuned 中thresCoef的百分比按测试预期调整boost/decay/maxPages/minPages的值检查 Ksmtuned CR 的status或登录系统读取/sys/kernel/mm/ksm/*观察实际运行情况两者应相互印证。九、升级策略与工程落地设计文档明确该功能无独立的升级策略Upgrade strategy: No即它作为节点管理能力随 ISO 发行版整体交付不需要额外的数据迁移或版本兼容处理。工程层面方案要求把原本的 Ksmtuned 脚本改写成 Go 程序并补充单元测试使其作为守护进程随 DaemonSet 在每节点运行——这既提升了程序健壮性也使其能够复用 Harvester 现有的 clientset、controller-runtime 等基础设施。值得说明的是截至当前仓库快照Ksmtuned CR 的 Go 类型尚未出现在 pkg/apis/harvesterhci.io/v1beta1 中该目录目前包含 addon、backup、image、upgrade 等类型也未见其 OpenAPI 定义进入 api/openapi-spec/swagger.json与之相邻的 KubeVirt 侧 KSM 能力KSMConfiguration.nodeLabelSelector已存在于 openapi_generated.go。可以推断本方案当前以设计文档形态沉淀在 enhancements/20220823-node-manager-support-ksm.md 中具体 CRD 与控制器代码的落库位置可能位于配套的 node-manager 实现中。读者若要在自己的 Harvester 环境评估该能力应以上述设计文档描述的 CR 结构与参数语义为准。十、小结Harvester 的 KSM 支持方案通过DaemonSet 逐节点守护 Ksmtuned CR 声明式配置 控制器自动编排 Prometheus 可观测四层设计将 Linux 内核的 KSM 能力转化为 HCI 集群中可配置、可观测、可验证的运维资产三种运行模式覆盖 KSM 的启停与清理三种配置模式覆盖从保守到激进的 CPU/内存权衡thresCoef阈值机制则确保 KSM 只在内存压力下才消耗 CPU。对大规模部署 Harvester 并希望压榨内存利用率的团队而言这套方案是降低节点内存成本、提升虚拟机密度的一条现实路径。赞分享云原生虚拟化存储后端高可用【免费下载链接】harvesterOpen source hyperconverged infrastructure (HCI) software项目地址https://gitcode.com/gh_mirrors/ha/harvester点击查看免费下载相关推荐终极指南深入理解os-tutorial内存去重与KSM合并机制终极指南深入理解os tutorial内存去重与KSM合并机制 内存管理是操作系统开发中的核心技术而 内存去重 和 KSM合并机制 更是提升系统性能的关键。示例工程Velero node-agent 并发控制设计VGDP 并发实例的全局与按节点配额机制Velero node agent 并发控制设计VGDP 并发实例的全局与按节点配额机制 导读 本文围绕 Velero 仓库中 node agent 并发能力云原生灾备存储后端Slicer 参数节点包装器支持类型全解析从内置类型到 parameterPack 自定义聚合Slicer 参数节点包装器支持类型全解析从内置类型到 parameterPack 自定义聚合 导读 Slicer 的 parameterNodeWrappe医疗健康图像处理数据可视化桌面应用3D渲染创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询