云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读本文深入解析 Longhorn 的Storage Network存储网络特性设计与实现通过引入 Instance Manager gRPC Proxy将 Longhorn Manager 对引擎/副本进程的调用从直接执行引擎二进制改为gRPC 请求经由实例管理器转发并结合 MultusNetworkAttachmentDefinition为数据面 Pod 附加第二网络实现集群内存储数据流量与 Kubernetes 管理网络集群 CNI的物理/逻辑隔离。读完本文你将掌握 Storage Network 全局设置的配置方式、其背后 gRPC Proxy 的接口设计与向后兼容机制、storageIPCRD 字段的语义以及该功能在升级场景下的行为约束。本文对应的原始设计文档为 enhancements/20220428-storage-network-through-grpc-proxy.md文中实现细节同时对照了当前仓库中的 Helm Chart 与部署清单等实际落地证据。背景与动机为什么需要隔离存储网络当前 Longhorn 的引擎Engine与副本Replica进程运行在 Instance Manager Pod 中它们与 Longhorn Manager 之间的通信复用 Kubernetes 集群 CNI 网络与集群内所有其他资源共享同一网络平面。这带来两个问题网络可用性不可控存储数据流量复制、重建、快照、备份与业务流量、管理流量混在同一网络任何网络抖动、带宽争抢都可能直接影响存储 I/O 稳定性缺乏隔离能力无法为存储流量单独规划网段、QoS 或安全策略。设计目标因此非常明确提供一个全局Storage Network设置允许用户输入一个已存在的 MultusNetworkAttachmentDefinitionCR格式为namespace/nameLonghorn 据此将集群内数据流量切换到该存储网络。隔离的关键手段是用 Longhorn Manager 到 Instance Manager 的 gRPC 连接替换原有的引擎二进制调用由 Instance Manager 负责在管理网络与存储网络之间转发请求。关联 Issue该设计主要对应 Longhorn 的 Issue #2285存储网络隔离需求与 #3546gRPC 代理通信相关改进。本文聚焦于方案本身具体 Issue 详情可从 Longhorn 项目仓库检索获取。设计目标与非目标Goals目标新增一个Storage Network全局设置项将 Manager 对引擎的二进制调用替换为指向 Instance Manager 的 gRPC 客户端Manager 与 Instance Manager 之间的管理通信仍然走管理网络存储网络只承载数据面组件到实例进程Instance Manager Pod 中的引擎与副本之间的数据流量升级后新旧版本混跑时保持向后兼容新版 Manager 与旧版 Instance Manager 通信时能回退到引擎二进制调用保证既有引擎/副本不受影响。Non-goals非目标不负责创建和配置 MultusNetworkAttachmentDefinitionCR用户需自行完成网络插件部署与 CR 定义不监控NetworkAttachmentDefinitionCR 的变更如果 CR 更新Longhorn 不会收到通知因此用户应当新建一个NetworkAttachmentDefinitionCR 并更新storage-network设置而不是修改已有 CR不覆盖集群外数据流量例如 backing image 的上传与下载等场景不在本设计范围内。备选方案对比设计文档明确评估过两种替代路径并予以否决方案思路否决原因Manager 加入存储网络让 Longhorn Manager 自身接入存储网络Manager 需要重启自身才能获得第二存储网络 IP且无法将存储网络隔离到 Longhorn 数据面引擎与副本层面为 Engine/Replica 提供双 IP让每个引擎/副本进程同时拥有管理 IP 与存储 IP相关代码改动混乱容易显著增加维护复杂度最终采用Manager 通过 gRPC 连接 Instance Manager 代理转发的架构Manager 本身只需要管理网络地址而引擎/副本进程对外暴露存储网络地址由 Instance Manager 作为桥梁在两个网络之间转发数据面请求。总体方案两层设计的组合整个特性由两个相互配合的层面构成通信层gRPC Proxy在 Instance Manager 中新增 gRPC 服务端Manager 通过可复用的 gRPC 连接向 Instance Manager 发起对引擎/副本的调用替代原先直接执行引擎二进制的做法网络层Storage Network为涉及数据传输的 Pod 打上k8s.v1.cni.cncf.io/networks注解由 Multus 为其附加第二网络接口并在Engine、Replica、BackingImageManager的 CR 状态中记录存储网络 IPstorageIP。第一层Instance Manager gRPC Proxy 详细设计Instance Manager 侧新增 gRPC Proxy 服务端在进程服务process server的基础上以下一个端口启动 gRPC Proxy 服务端默认监听地址为localhost:8501Proxy 服务与进程服务共享同一个imrpc包名暴露的 RPC 方法完整覆盖引擎管理与数据操作Ping ServerVersionGet VolumeGet VolumeExpand VolumeFrontendStart VolumeFrontendShutdown VolumeSnapshot SnapshotList SnapshotRevert SnapshotPurge SnapshotPurgeStatus SnapshotClone SnapshotCloneStatus SnapshotRemove SnapshotBackup SnapshotBackupStatus BackupRestore BackupRestoreStatus BackupVolumeList BackupVolumeGet BackupGet BackupConfigMetaGet BackupRemove ReplicaAdd ReplicaList ReplicaRebuildingStatus ReplicaVerifyRebuild ReplicaRemove可以看出Proxy 层完整镜像了引擎/副本进程的能力面卷生命周期VolumeGet/VolumeExpand/VolumeFrontendStart/VolumeFrontendShutdown、快照管理Snapshot 系列、备份管理Backup/SnapshotBackup 系列以及副本管理Replica 系列。Manager 对这些能力的调用路径从本机 fork 引擎二进制并执行演变为通过网络向 Instance Manager 的 gRPC Proxy 发请求。Manager 侧proxyHandler 与 gRPC 客户端生命周期Manager 侧的核心设计是一个proxyHandler 对象它维护控制器 ID → EngineClient 接口实现的映射并在所有控制器之间共享Instance Manager Controller 负责 Proxy gRPC 客户端的生命周期。每次入队处理时检查 proxyHandler 中是否已存在对应 gRPC 客户端并通过Ping请求验证连接存活若连接已失效则停止该 proxy gRPC 客户端并返回错误触发重新入队若 proxyHandler 中不存在对应客户端则新建 gRPC 连接并映射到当前控制器 ID当 Instance Manager 版本低于当前版本时不建立 Proxy gRPC 连接此时获取客户端时使用外部传入的回退调用器fallback interface caller。gRPC 客户端统一实现EngineClient接口。在从 proxyHandler 获取客户端时允许传入回退调用器回退对象包括既有的Engine客户端用于二进制调用BackupTargetClient备份目标客户端。关键接口定义回退接口BackupTargetBinaryClient用于旧版 Instance Manager 的备份目标二进制调用type BackupTargetBinaryClient interface { BackupGet(destURL string, credential map[string]string) (*Backup, error) BackupVolumeGet(destURL string, credential map[string]string) (volume *BackupVolume, err error) BackupNameList(destURL, volumeName string, credential map[string]string) (names []string, err error) BackupVolumeNameList(destURL string, credential map[string]string) (names []string, err error) BackupDelete(destURL string, credential map[string]string) (err error) BackupVolumeDelete(destURL, volumeName string, credential map[string]string) (err error) BackupConfigMetaGet(destURL string, credential map[string]string) (*ConfigMetadata, error) }代理接口EngineClientProxy组合了EngineClient、BackupTargetBinaryClient及代理专属方法使调用方无论走 Proxy 还是非 Proxy/回退路径都使用同一套EngineClient接口做到自适应切换type EngineClientProxy interface { EngineClient BackupTargetBinaryClient IsGRPC() bool Start(*longhorn.InstanceManager, logrus.FieldLogger, *datastore.DataStore) error Stop(*longhorn.InstanceManager) error Ping() error }其中IsGRPC()用于标识当前客户端是否为 gRPC 代理连接Start/Stop管理代理生命周期Ping用于连接健康检查。这套抽象使得 Manager 对引擎的调用在新 Instance ManagergRPC与旧 Instance Manager二进制回退之间透明切换。第二层Storage Network 详细设计设置项Setting新增全局设置Storage Network内部键名为storage-network类型string默认值空字符串表示不启用归属分类danger zone危险区与删除确认、系统托管等高风险设置同列校验时机在 Admission Webhook 的设置校验器中执行两点约束取值必须是NAMESPACE/NETWORK-ATTACHMENT-DEFINITION-NAME格式有卷处于 attached 状态时不允许更新。CRD 变更CRD变更Engine状态中新增storageIPreplicaAddressMap改用副本的status.storageIP而非status.IPReplica状态中新增storageIPBackingImageManager状态中新增storageIPstorageIP的语义是用于与实例进程通信的存储网络 IP。当storage-network设置为空时storageIP即回落到 Pod IP。各控制器如何接入存储网络所有涉及数据传输的 Pod 创建时都会携带 Multus 注解k8s.v1.cni.cncf.io/networks接口名统一为lhnet1命名空间与网络名取自storage-network设置值k8s.v1.cni.cncf.io/networks: [ { namespace: kube-system, name: demo-10-30-0-0, interface: lhnet1 } ] 覆盖范围与各自处理逻辑如下Instance Manager Controller创建引擎/副本 Instance Manager Pod 时添加上述注解Instance Handler随后从 Pod 的k8s.v1.cni.cncf.io/network-status注解中解析出lhnet1接口对应的 IP写入 Engine 与 Replica 的 Storage IPstorage-network为空时取 Pod IP。Backing Image Manager Controller创建 backing image manager Pod 时添加上述注解并从 Pod 的network-status注解解析 IP 写入BackingImageManager的 Storage IP为空时回落 Pod IP。Backing Image Manager 之间的数据流量走存储网络。Backing Image Data Source Controller创建 backing image data source Pod 时添加上述注解副本与 backing image data source 之间的数据流量走存储网络。Backing Image Manager 从卷导出Export From Volume取lhnet1接口的 IPv4 地址作为接收方地址若接口不存在则使用 Pod IP。Setting Controller监控storage-network设置变更时——若有卷处于 attached 状态拒绝更新并返回错误删除所有 backing image manager Pod删除所有 instance manager Pod。由于 Proxy 连接按 Instance Manager 建立、存储网络 IP 由 Pod 注解解析而来Pod 重建是让新网络配置生效的必需动作这也是文档用户故事中更新设置后看到引擎/副本 Instance Manager Pod 与 backing image manager Pod 重启的原因。用户故事配置与升级的完整操作流Story 1设置存储网络系统管理员视角集群已安装 Multus创建NetworkAttachmentDefinitionCR 并确认配置正确将namespace/NetworkAttachmentDefinition name填入 LonghornStorage Network设置若当前有卷 attached会看到设置更新失败detach 全部卷更新设置观察到引擎/副本 Instance Manager Pod 与 backing image manager Pod 重启attach 卷查看 Engine、Replica、BackingImageManager 的 CR statusstorageIP落在NetworkAttachmentDefinition的 subnet/CIDR 范围内且与 CR status 中的ip不同查看 EnginereplicaAddressMapspec 与 status使用的是存储 IP查看 Pod 日志可确认网络方向。Story 2升级兼容性验证视角集群运行 Longhorn v1.2.4卷健康 attached升级 Longhorn 后卷保持 attached 且健康可用的引擎镜像升级提示存在卷 attached 时无法升级卷的引擎镜像detach 卷后即可升级引擎镜像重新 attach 卷卷恢复健康。这个场景验证了核心的向后兼容承诺升级后旧引擎/副本在旧 Instance Manager 中继续工作用户自主决定引擎镜像升级时机。API 变更与设置下发链路新的Storage Network全局设置沿用既有/v1/settingsAPI不引入新的 API 端点设置值通过 Helm Chart 注入默认设置chart/templates/default-setting.yaml中对应条目为storage-network: {{ .Values.defaultSettings.storageNetwork | quote }}而 chart/values.yaml 中默认值storageNetwork: ~即空/未启用与设计文档默认值为空字符串一致用户也可在 Helm 安装时通过defaultSettings.storageNetwork预置该设置。测试计划CI 流水线当集群配置了存储网络时所有既有测试都应通过并考虑为存储网络新增专门的测试流水线。基础设施前置条件Infra Prerequisites每个集群实例节点添加第二网络接口secondary network interface部署 Multus创建 network-attachment-definition在所有集群节点配置路由确保实例之间网络可达使用 AWS 时需为每个云实例关闭网络源/目的检查disable network source/destination checks。核心测试场景Engine、Replica与BackingImageManager在设置更新后其 IP 应处于storage-network所指向NetworkAttachmentDefinition的 subnet/CIDR 范围内。升级策略与向后兼容升级期间会有部分旧 Instance Manager Pod 仍在运行Longhorn 官方 KB 中描述过upgrade 后仍有一些旧 instance manager pod 在运行的已知现象。旧引擎 Instance Manager 没有可供 Manager 通信的 gRPC Proxy 服务端因此必须支持向后兼容Manager 通信升级 Instance Manager API 版本Manager 检测到不兼容版本时回退为通过引擎二进制发起请求卷/引擎在线升级live upgrade保留在线升级能力。设计文档明确说明1.3 版本不强制任何变更引擎升级的强制化将在 1.4 落地。也就是说存储网络特性在引入早期以软提示方式演进避免破坏存量用户。仓库中的实现证据与后续演进当前仓库中的部署与清单文件可以印证上述设计已经落地CRD 定义deploy/longhorn.yaml 中可找到backingimagemanagers.longhorn.io、engines.longhorn.io、instancemanagers.longhorn.io、replicas.longhorn.io四个 CRD其中Engine、Replica、BackingImageManager的 status schema 均声明了storageIP字段type: string默认设置chart/templates/default-setting.yaml 与 chart/values.yaml 中的storage-network/storageNetwork条目与设计文档的设置语义完全对应后续演进CHANGELOG/CHANGELOG-1.7.0.md 记录表明Storage Network 在后续版本已扩展支持 RWX 卷的网络隔离Issue #8184体现该架构的可扩展性仓库中另有 enhancements/20240522-storage-network-for-rwx-volumes.md 与 enhancements/20251017-rwx-volume-endpoint-network.md 两篇后续设计文档读者可继续追踪该主题的演进脉络。总结Longhorn 的 Storage Network 特性用一套清晰的双层设计解决了存储流量隔离问题底层以 Instance Manager gRPC Proxy 取代 Manager 对引擎二进制的直接调用使 Manager 只暴露管理网络地址数据面请求由 Instance Manager 在网络间转发上层以 Multus 注解 storageIPCRD 状态字段承载第二网络的接入与寻址。整个方案同时内置了版本探测与二进制回退机制保障了新旧 Instance Manager 混跑时的升级兼容性danger zone分类与卷 attached 时禁止更新的 Webhook 校验则把误操作风险降到最低。对于需要为存储流量单独规划网段、保障存储 I/O 网络可用性的生产环境可以按照部署 Multus → 创建 NetworkAttachmentDefinition → 配置Storage Network设置 → detach 卷后让 Pod 重建生效的路径落地本特性。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐基于 SPDK 重写 Longhorn 存储引擎V2 Data Engine 架构设计与实现解析基于 SPDK 重写 Longhorn 存储引擎V2 Data Engine 架构设计与实现解析 导读 本文以 Longhorn 设计文档《Reimpleme云原生存储高可用容器编排零基础高效数据采集工具3步搞定TikTok评论导出与分析想轻松获取TikTok视频下的用户评论数据进行市场调研这款零代码数据爬取工具将帮你在10分钟内完成从评论抓取到Excel导出的全过程。无需编程基础只需简单复嵌入式网络物联网上一篇WinApps五分钟把 Windows 应用搬进 Linux 桌面下一篇GitHub中文化插件5分钟实现GitHub界面全面汉化的终极方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考