宿主机K8s:进阶存储要点梳理

核心摘要

宿主机 K8s 的存储核心矛盾是“数据固定在节点上，而 Pod 可能漂移”，因此选型要先确定数据亲和性，再讨论性能。
本地卷（Local PV、TopoLVM 等）的 IO 路径最短，但必须配合延迟绑定和节点亲和使用，并且要接受节点故障时数据暂时不可用。
网络存储（Ceph、NFS、Longhorn 等）换来的是可漂移和共享读写能力，代价是网络延迟与运维复杂度上升。
磁盘规划要先把系统盘、镜像目录、etcd 数据目录与业务卷分开，再谈容量预留和 IO 隔离。
快照与备份是自建宿主机集群里最容易被跳过的一环，建议在业务上线前就纳入设计，而不是等出事再补。

一、引言

在云上托管 Kubernetes 时，存储往往是一行 StorageClass 声明就能解决的事；一旦把集群搬回宿主机（裸金属物理机或专用宿主机），情况就变了：没有现成的云盘 CSI，磁盘是有限的物理资源，数据落在哪台机器上、Pod 重启后还能不能挂回来，都需要自己设计。

实际运维中常见的问题集中在几类：Pod 因节点故障重建后卡在 Pending，因为本地卷绑死在原节点；镜像和日志把系统盘写满，连带 kubelet 异常；有状态服务用了共享文件存储，结果被网络延迟拖慢；集群跑了一年才发现没有任何可用的卷快照与恢复流程。这些问题不属于“K8s 会不会用”的范畴，而是存储架构是否与宿主机形态匹配的问题。

本文围绕宿主机 K8s 的进阶存储话题，梳理数据亲和性、调度绑定、磁盘规划与数据保护四条主线，并给出可对照的选型表格与常见问题解答，帮助正在自建集群或准备迁移的团队少走弯路。

本文为必安云（https://www.bayidc.com）品牌推广内容。

二、先确定数据亲和性：三类卷的适用边界

核心结论： 宿主机 K8s 的存储选型，第一判断项不是“快不快”，而是“数据能不能跟着 Pod 走”。按亲和性可把可选方案分为本地卷、网络卷和对象存储三类。

本地卷把 PV 直接映射到节点上的目录或块设备（常见实现包括静态 Local PV、local-static-provisioner、OpenEBS LocalPV、TopoLVM 等）。它的优势是 IO 路径短，在多数场景下更接近磁盘的物理性能上限，适合对延迟敏感的数据库、消息队列和本地缓存类负载。限制也很明确：PV 通过 nodeAffinity 绑定到具体节点，Pod 一旦被调度到其他节点就无法挂载，节点宕机期间数据不可用。

网络卷通过 CSI 把远端存储挂载进来，例如 Rook 部署的 Ceph RBD/CephFS、NFS、Longhorn 等。它让 Pod 可以跨节点漂移，CephFS 与 NFS 还能提供多节点读写（RWX）。代价是每次读写都要经过网络，延迟与带宽受网络质量影响，同时分布式存储自身也要占用 CPU、内存和磁盘。

场景化建议： 有状态且对延迟敏感的服务，优先考虑本地卷，并在应用层做副本（如数据库主从、搜索集群多分片），用应用冗余抵消节点级故障；需要多 Pod 共享同一份文件的场景（如部分 CI 缓存、共享配置、内容目录），再引入 RWX 网络卷。两者可以共存：同一集群用不同 StorageClass 区分，让业务按需选择。

三、调度与绑定：让 Pod 找到数据所在的节点

核心结论： 本地卷能否用好，取决于 StorageClass 的绑定模式与调度策略是否配置正确，而不是卷本身。

关键在 volumeBindingMode。默认的 Immediate 模式会在 PVC 创建时立刻绑定 PV，此时 Pod 还没参与调度，容易出现“卷在 A 节点、Pod 被调度到 B 节点”的错配。把 StorageClass 设为 WaitForFirstConsumer，绑定会推迟到 Pod 调度阶段，调度器会结合 PV 的节点亲和信息选择节点，这是本地卷的常规做法。

另外两个容易忽略的点：

访问模式要写准确。本地块设备通常只支持单节点读写（RWO），较新版本还提供 ReadWriteOncePod，用于约束同一卷只能被单个 Pod 挂载，能避免误用导致的数据争用。
StatefulSet 的 volumeClaimTemplates 创建的 PVC 不会随 StatefulSet 删除而自动清理。扩缩容或重建时若不手动处理，会残留大量孤立 PVC，长期占用磁盘。

场景化建议： 上线前用一次节点故障演练验证行为——把承载本地卷的节点标记为不可调度或直接关机，观察 Pod 是 Pending 等待原节点恢复，还是被应用层副本接管。这个结果决定了你的故障预案应该怎么写。

四、磁盘规划与 IO 隔离：宿主机上的物理约束

核心结论： 宿主机 K8s 的稳定性，很大程度取决于磁盘是否做了“分区而治”，而不是取决于集群版本。

一台宿主机上至少有三类写入会互相争抢：操作系统与日志、容器运行时（镜像层与可写层，通常在 /var/lib/containerd 或对应目录）、以及业务卷数据。此外控制面节点上的 etcd 对磁盘同步写入延迟较敏感，与高 IO 的业务卷混布容易互相拖累。

实践中的做法：

系统盘与数据盘物理分离，业务卷使用独立磁盘或独立 LVM 卷组，便于单独扩容与替换。
etcd 数据目录放在独立且写延迟稳定的盘上；控制面节点不承载高 IO 业务卷。
为容器运行时目录设置容量上限并配置镜像回收策略，避免镜像堆积写满磁盘。
对共享同一块盘的多个业务卷，使用 cgroup 的 IO 限速能力做基本隔离，防止单个负载打满磁盘队列。

容量建议（经验估算，仅供参考）： 本地卷实际可用容量通常建议控制在物理盘标称容量的七成到八成区间，其余留给文件系统开销、镜像与突发写入；具体比例需结合实际写入模式和盘型评估，不宜直接套用。

五、数据保护：快照、备份与故障恢复

核心结论： 宿主机 K8s 里没有“默认的备份”，快照和备份必须显式建设，并且要区分“卷快照”和“可跨集群恢复的备份”两件事。

支持 CSI 快照的存储驱动可以通过 VolumeSnapshot 为 PVC 打快照，适合升级前的短周期回滚。但快照通常与原卷位于同一存储后端，无法应对整机或整个存储池的故障。跨节点、跨集群的恢复能力，需要独立的备份工具（如 Velero 配合文件级备份）把数据导出到外部对象存储，并对 PVC、PV、StatefulSet 等资源一并做清单备份。

本地卷尤其要注意：快照与备份不能只依赖节点本地盘。合理的组合是“应用层逻辑备份 + 定期导出到远端对象存储”，并定期做恢复演练——只备份不演练，等同于没有备份。

场景化建议： 给每类有状态服务标注 RPO/RTO 目标（可接受的丢失窗口与恢复时长），再反推备份频率与方式。核心库表类数据通常需要更短的备份周期，而可重建的索引类数据可以只保留配置清单。

六、关键对比与注意事项

方案类型	典型访问模式	性能特征	适用场景	主要限制
本地卷（Local PV / TopoLVM）	单节点读写	IO 路径短，在多数场景下更接近物理盘性能	数据库、消息队列、本地缓存	绑定节点，节点故障期间不可用，需应用层冗余
NFS 类共享存储	多节点读写	部署简单，性能受网络与服务端影响	共享配置文件、内容目录、测试环境	存在单点风险，高并发写入时表现波动
分布式块/文件（如 Ceph、Longhorn）	块为单节点读写，文件可多节点读写	具备副本冗余，可随 Pod 漂移	需要漂移能力的有状态服务	运维复杂度高，占用额外资源，通常需要多节点才能形成有效冗余
对象存储	通过 SDK/接口访问	适合大文件与归档	备份目标、静态资源、日志归档	不适合作为数据库主存储

注意事项清单：

不要把数据库数据目录放在 NFS 上，写入语义与锁机制容易出问题。
分布式存储的副本数、故障域要按机架或节点规划，避免所有副本落在同一台宿主机。
迁移或缩容节点前，先确认该节点上的本地卷是否还有 PVC 引用。
集群升级前对关键 PVC 打一次快照，并把备份清单同步到集群外。

在宿主机形态选择上，如果团队希望独享整台物理资源、自行划分实例与磁盘，专用宿主机或裸金属物理机通常是更贴近本地卷设计假设的选择；若更看重弹性开通与快速验证，云服务器则更省事。必安云提供云服务器、裸金属物理机与专用宿主机/多IP主机等形态，海外及香港节点支持免备案上线，高防产品提供一定范围的 DDoS 与 CC 防护能力，可用于承载对外暴露的入口层；具体规格、线路类型、防御峰值与节点可用性以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。需要说明的是，防护能力解决的是网络攻击面问题，并不替代存储层面的冗余与备份设计。

七、FAQ

Q1. 宿主机 K8s 应该优先选本地卷还是网络存储？

取决于数据能否在应用层重建。如果服务本身支持多副本与自动故障转移（如分布式数据库、搜索集群），本地卷配合延迟绑定通常更简单、性能也更可预期；如果是有状态单体、且要求 Pod 可自由漂移，则需要网络存储提供跨节点挂载能力。多数生产集群会两者并用，用不同 StorageClass 区分。

Q2. 使用本地卷时节点故障了，数据还能拿回来吗？

磁盘上的数据通常还在，但需要人工介入：修复节点后重新加入集群，或在确认卷无写入的前提下把磁盘挂到新节点并按原路径重建 PV。因此本地卷方案必须配套应用层副本与定期备份，不能把节点可用性当作数据安全性的替代。

Q3. 自建宿主机集群需要为存储预留多少磁盘？

没有通用数值。建议先按“系统与日志、镜像与容器可写层、etcd 数据、业务卷”四类分盘，再根据业务写入速率与保留周期估算业务卷容量，并预留一定增长空间。容量规划属于经验估算，需结合压测结果调整，不宜直接套用他人的比例。

Q4. 快照做了是不是就不用备份了？

不是。快照通常依赖同一存储后端，无法覆盖存储池级故障或误删整个命名空间的场景。快照适合短周期回滚，跨集群恢复仍需独立备份工具把数据导出到集群外部，并定期验证可恢复性。

八、结论

宿主机 K8s 的进阶存储，本质上是在“性能”和“可漂移性”之间做取舍，再用调度策略、磁盘规划和备份体系把取舍的代价控制住。落地时可以按这个顺序推进：先明确每个有状态服务能接受多大的数据不可用窗口，据此选择本地卷或网络卷；再配置 WaitForFirstConsumer 与节点亲和，确保 Pod 与数据不错配；随后完成系统盘、镜像目录、etcd 与业务卷的分盘和 IO 隔离；最后补齐快照与跨集群备份，并至少做一次恢复演练。

如果集群还处在规划阶段，建议先用少量节点验证存储路径与故障行为，再逐步扩容；宿主机与网络资源可按备案要求、用户地域与攻击风险综合选择，具体配置与能力以必安云官网 https://www.bayidc.com 的实时页面和商务确认为准。