云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读本文围绕 Longhorn 的 BackingImage 增强特性展开聚焦三项核心能力通过副本数HA避免 BackingImage 数据丢失、通过nodeSelector与diskSelector将 BackingImage 精准调度到指定节点与磁盘、以及通过驱逐Eviction机制在节点或磁盘下线前主动迁移 BackingImage。读者读完本文后将掌握如何在 Longhorn 中为 BackingImage 配置副本数量与调度约束、如何结合 Kubernetes 标签实施节点/磁盘定向存储、以及如何在节点排空drain前安全触发驱逐以保障数据可用性。该特性源自 Longhorn 社区增强提案 enhancements/20240426-backing-image-enhancement.md对应的功能设计目标源自 longhorn/longhorn#2856 与 longhorn/longhorn#6526此处仅作为背景说明不展开外部链接。特性总览BackingImage 是 Longhorn 中用于预置磁盘镜像如虚拟机镜像、操作系统镜像的机制Volume 创建时可直接以该镜像为模板无需重复下载。原实现中 BackingImage 仅有一个副本副本所在节点宕机或节点被排空时唯一的 BackingImage 副本会丢失用户需要重新准备镜像。本增强特性在 Longhorn 中引入三项能力高可用HA通过numOfCopies/minNumberOfCopies维护集群内 BackingImage 副本数量副本数不足时自动补足副本多余且长期未被使用时自动清理。节点/磁盘选择器nodeSelector / diskSelector将 BackingImage 副本精准调度到具备指定标签tag的节点与磁盘与 Volume Replica 的调度保持一致提升空间利用率。驱逐处理Eviction用户对节点或磁盘手动设置驱逐请求后Longhorn 将 BackingImage 副本迁移到其他节点或磁盘。以下各节分别深入这三项能力的设计、CRD 变化、控制器实现与测试方案。高可用HA维护 BackingImage 副本数设计目标用户可设置全局的高可用因子对所有 BackingImage 生效也可为单个 BackingImage 单独指定副本数。Longhorn 在集群内持续维护 BackingImage 的副本数量。当副本数超过因子、且多余副本一段时间内未被使用时Longhorn 自动删除多余的副本。CRD 变更在 BackingImage CRD 中新增minNumberOfCopies字段。从当前仓库的 CRD 定义deploy/longhorn.yaml可以看到 BackingImage 的spec结构# deploy/longhorn.yaml 中 BackingImage CRD 的 spec 片段 spec: properties: checksum: type: string dataEngine: default: v1 enum: - v1 - v2 diskFileSpecMap: additionalProperties: properties: dataEngine: enum: [v1, v2] evictionRequested: type: boolean diskSelector: items: {type: string} type: array minNumberOfCopies: type: integer nodeSelector: items: {type: string} type: array sourceType: enum: [download, upload, export-from-volume, restore, clone]可见minNumberOfCopies与nodeSelector、diskSelector、evictionRequested均已在 CRD 中落地disks字段被标注为 Deprecated已由diskFileSpecMap取代。BackingImage Controller 的副本维护逻辑当第一个 BackingImage 副本就绪后控制器开始维护集群中的副本数量。若副本数低于设定值控制器挑选一个合法的节点与磁盘每次增加一个副本直至副本数达到或超过设定值。若副本数高于设定值且多余副本一段时间内未被使用受Backing Image Cleanup Wait Interval控制Longhorn 删除这些未使用的副本。该清理逻辑在原提案中已有实现参考对应 longhorn-manager v1.6.1 的 node_controller.go#L1152 的backingImageCleanupWaitInterval设置项。相关全局设置在 Helm Chart 的 values.yaml 中BackingImage 相关的 StorageClass 设置如下backingImage: # -- 在 Longhorn StorageClass 中使用 backing image enable: false # -- 用于创建和恢复 Volume 的 backing image 名称 name: ~ # -- backing image 的数据源类型如 download dataSourceType: ~ # -- 数据源参数JSON 字符串形式的 map # 示例: {url:https://backing-image-example.s3-region.amazonaws.com/test-backing-image} dataSourceParameters: ~ # -- backing image 的预期 SHA-512 checksum expectedChecksum: ~清理间隔设置位于 values.yaml# -- 当磁盘上没有 replica 使用 backing image 文件时Longhorn 等待多少分钟后清理该文件 backingImageCleanupWaitInterval: ~ # -- 当所有镜像磁盘文件状态变为 failed 或 unknown 时Longhorn 等待多少秒后重新下载 backingImageRecoveryWaitInterval: ~nodeSelector 与 diskSelector定向调度 BackingImage设计目标用户创建 BackingImage 时可通过nodeSelector和diskSelector指定目标节点与磁盘。BackingImage 副本只放置在带有对应标签tag的节点和磁盘上。当节点或磁盘被禁用调度时BackingImage 副本无法被放置在该节点或磁盘上。Replica 无法被调度到无法存储对应 BackingImage 的节点和磁盘上。与 Volume Replica 调度的一致性原实现中Longhorn 将 BackingImage 副本随机放置在节点和磁盘上当某个 Replica 需要该 BackingImage 时Longhorn 必须把 BackingImage 复制到 Replica 所在的磁盘。引入选择器后只要 Replica 与 BackingImage 使用相同的nodeSelector和diskSelectorBackingImage 与 Replica 将存储在相同的节点和磁盘集合中从而避免跨磁盘复制显著提升空间利用效率。调度逻辑BackingImage Controller 选择节点/磁盘时遵循diskSelector与nodeSelector设置。Replica Scheduler 在评估节点候选与磁盘候选时会额外检查该节点/磁盘是否可用于 Replica 所使用的 BackingImage。若 BackingImage 无法存储在该节点或磁盘上则 Replica 也不会被调度到该节点。驱逐处理Eviction主动迁移 BackingImage设计目标当用户对节点或磁盘设置驱逐请求evictionRequested true时Longhorn 将 BackingImage 副本迁移到其他节点或磁盘。该能力仅在用户手动设置驱逐请求时生效节点 cordon 或 drain 时 Longhorn 不会自动驱逐 BackingImage与 Replica 的自动驱逐行为不同。原因是自动驱逐需要为 BackingImageManager 配置 PodDisruptionBudgetPDB会增加流程复杂度并引入卡住风险。因此用户应在 drain 节点前先手动设置驱逐请求。CRD 变更BackingImage Spec 由原来的Disks map[string]string扩展为Disks map[string]*BackingImageDiskFileSpec其中新增EvictionRequested字段// 变更前 type BackingImageSpec struct { Disks map[string]string json:disks Checksum string json:checksum SourceType BackingImageDataSourceType json:sourceType SourceParameters map[string]string json:sourceParameters } // 变更后 type BackingImageSpec struct { Disks map[string]*BackingImageDiskFileSpec json:disks Checksum string json:checksum SourceType BackingImageDataSourceType json:sourceType SourceParameters map[string]string json:sourceParameters } type BackingImageDiskFileSpec struct { EvictionRequested bool json:evictionRequested }在 deploy/longhorn.yaml 中diskFileSpecMap的 schema 已体现evictionRequested布尔字段节点 CRD 中同样包含节点级evictionRequesteddeploy/longhorn.yaml以及磁盘级evictionRequesteddeploy/longhorn.yaml。控制器实现Node Controller当节点或磁盘被设置为evictionRequested true时Node Controller 会将该节点上所有 BackingImage 副本的EvictionRequested更新为 true。BackingImage Controller核心方法为replenishBackingImageCopies()与cleanupEvictionRequestedBackingImageCopies()replenishBackingImageCopies()若nonFailedCopies MinNumberOfCopies检查是否需要为驱逐补充副本当NonEvictingCount MinNumberOfCopies时补充一个副本。若nonFailedCopies MinNumberOfCopies补充一个副本以满足MinNumberOfCopies要求。cleanupEvictionRequestedBackingImageCopies()若没有非驱逐的健康副本则不删除被驱逐的副本避免唯一副本被删除。否则删除被驱逐的副本。测试方案原提案给出了 5 组测试用例以下结合预期行为整理为可复现的验证清单HA 副本数维护创建minNumberOfCopies 2的 BackingImage → 创建后立即同步文件到另一个节点/磁盘 → 将Backing Image Cleanup Wait Interval更新为 1 分钟 → 将minNumberOfCopies更新为 1 → 多余的 BackingImage 副本被清理。nodeSelector/diskSelector 定向放置为 node1 设置nodeTag: [node1], diskTag: [disk1]→ 创建minNumberOfCopies 2、nodeSelector [node1]、diskSelector [disk1]的 BackingImage → 第一个副本落在 node1/disk1 → 第二个副本始终不出现日志显示unable to get a ready node disk。与 Replica 选择器不一致负向测试node1/disk1 设置nodeTag: [node1], diskTag: [disk1]node2/disk2 设置nodeTag: [node2], diskTag: [disk2]→ 创建minNumberOfCopies 1、nodeSelector [node1]、diskSelector [disk1]的 BackingImage → 创建numberOfReplicas 1、nodeSelector [node2]、diskSelector [disk2]的 Volume 并附加到 node2 → Volume 的Scheduled条件为false因为 Replica 无法被调度。驱逐 - 1创建只有 1 个副本的 BackingImage → 驱逐副本所在节点 → 先在另一个节点创建副本 → 被驱逐的副本被删除。驱逐 - 2设置minNumberOfCopies 1→ 创建 2 个副本的 BackingImage → 驱逐其中一个副本所在节点 → 被驱逐的副本被删除不补充新副本。驱逐 - 3负向测试设置nodeTag: [node1], diskTag: [disk1]→ 创建minNumberOfCopies 1、nodeSelector [node1]、diskSelector [disk1]的 BackingImage副本在 node1→ 驱逐 node1 → 由于它是唯一副本且受选择器限制无法复制到其他节点该副本不会被删除。升级策略原提案指出本特性的升级策略为None无需额外的数据迁移或版本升级步骤特性随 Longhorn Manager 升级自动生效。新增字段minNumberOfCopies、nodeSelector、diskSelector、diskFileSpecMap均由控制器以默认值/空值兼容旧对象不破坏既有 BackingImage。实践要点与注意事项驱逐与节点维护的配合Longhorn 不会在节点 cordon/drain 时自动驱逐 BackingImage因此节点维护前需先在 Longhorn UI 或 API 中对目标节点/磁盘设置evictionRequested等待 BackingImage 迁移完成后再执行 drain。选择器与副本数的相互约束当选择器限制可放置节点/磁盘集合小于副本数需求时如测试用例 2Longhorn 无法补足副本日志会出现unable to get a ready node disk此时需要放宽选择器或扩充符合条件的节点/磁盘集合。唯一副本保护驱逐逻辑保证不会删除最后一个健康的非驱逐副本测试用例 6避免因驱逐导致 BackingImage 数据彻底丢失。副本清理时机副本清理依赖backingImageCleanupWaitInterval且仅清理未被 Replica 使用的多余副本避免影响运行中的 Volume。延伸阅读增强提案原文enhancements/20240426-backing-image-enhancement.md相关增强提案V2 数据引擎下的 BackingImage 支持见 enhancements/20241203-v2-backing-image-support.md磁盘/节点驱逐机制的更早期设计见 enhancements/20200727-add-replica-eviction-support-for-disks-and-nodes.mdCRD 定义deploy/longhorn.yaml 与 chart/templates/crds.yamlHelm Chart 设置chart/values.yaml含backingImageCleanupWaitInterval、backingImageRecoveryWaitInterval等全局参数说明本文基于当前仓库中的增强提案文档、CRD 定义与 Helm Chart 配置编写提案中引用的 longhorn-manager v1.6.1 node_controller.go 行号属于提案撰写时的外部参考本仓库为纯文档/部署清单仓库不含 Go 源码实现相关控制器行为以提案描述与 Longhorn 官方行为为准。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Longhorn 副本驱逐Replica Eviction机制深度解析磁盘与节点级驱逐的设计、实现与运维实战Longhorn 副本驱逐Replica Eviction机制深度解析磁盘与节点级驱逐的设计、实现与运维实战 本篇技术指南围绕 Longhorn 增强提案云原生存储高可用容器编排Longhorn 磁盘级副本软反亲和Disk Anti-Affinity单节点多磁盘场景下的副本分散调度指南Longhorn 磁盘级副本软反亲和Disk Anti Affinity单节点多磁盘场景下的副本分散调度指南 导读 Longhorn 允许每个节点挂载多块云原生存储高可用容器编排如何构建智能票务自动化系统深度解析大麦抢票框架的技术哲学如何构建智能票务自动化系统深度解析大麦抢票框架的技术哲学 在当今数字化票务生态中效率已成为决定成败的关键因素。大麦智能票务自动化系统正是基于这一理念构建的技云原生存储高可用容器编排上一篇Citra模拟器终极指南5分钟在电脑畅玩任天堂3DS游戏下一篇Quasar CLI 工程quasar/app-viteTypeScript 支持完整指南从 JS 迁移、配置到类型增强创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考