3. Kubernetes 环境准备:集群版本要求、节点资源规划、网络与存储后端选型

在生产环境中部署 Rook Ceph 之前,Kubernetes 集群的版本、节点资源、网络配置以及存储后端选型是决定存储系统稳定性与性能的四大基石。本章将逐一拆解这些前置条件,并提供可落地的规划建议。

3.1 集群版本要求

Rook 与 Ceph 的版本组合必须严格匹配。下表列出了当前主流生产环境的推荐版本组合:

组件 最低版本 推荐版本 说明
Kubernetes v1.21 v1.27 ~ v1.29 需启用 CSIDriver 与 VolumeSnapshot 特性门控
Rook Operator v1.10 v1.14+ 建议跟随 Ceph 大版本同步升级
Ceph Quincy (v17) Reef (v18) / Squid (v19) Reef 为当前长期稳定版
Linux Kernel 5.4 6.1+ 低版本内核可能缺少 rbd 与 ceph 文件系统关键修复
版本兼容性警告: 切勿将 Rook v1.14 与 Ceph Pacific (v16) 混用,Rook 自 v1.12 起已移除对 Pacific 的支持。升级前务必查阅 Rook 官方升级矩阵。

3.2 节点资源规划

Ceph 是资源敏感型系统,节点规格直接影响 OSD 性能与集群自愈速度。以下为三种典型规模的资源分配建议:

节点角色 CPU (核) 内存 (GB) 系统盘 (GB) 数据盘 适用场景
Monitor + Manager 2 ~ 4 8 ~ 16 100 (SSD) — 控制面节点,3 节点奇数部署
OSD (HDD) 8 ~ 16 32 ~ 64 200 (SSD) 4 ~ 12 × HDD 容量型,归档/冷数据
OSD (NVMe) 16 ~ 32 64 ~ 128 400 (NVMe) 4 ~ 8 × NVMe 性能型,数据库/实时分析
内存计算经验公式: 每个 OSD 守护进程至少预留 4 GB 内存,每 TB 数据额外增加 1 GB 用于 Page Cache。例如:一台节点承载 8 个 2TB HDD OSD,建议内存 = 8 × 4 + 8 × 2 × 1 = 48 GB。

3.3 网络规划与拓扑

Ceph 集群内部流量分为 客户端流量(前端)与 数据复制/恢复流量(后端)。生产环境必须做网络隔离。

Ceph 生产网络拓扑(双平面隔离) 客户端网络 (Client Network) — 10.10.0.0/24 应用 Pod 应用 Pod 应用 Pod MON / MGR MON / MGR MON / MGR 存储后端网络 (Cluster Network) — 10.20.0.0/24 OSD Node 1 NVMe × 4 OSD Node 2 NVMe × 4 OSD Node 3 NVMe × 4 网络隔离 前端: 10Gbps 后端: 25Gbps
网络配置要点:
  • MTU 9000 (巨型帧):所有存储节点与交换机端口必须开启 jumbo frame,降低 CPU 开销。
  • bond 模式:推荐使用 LACP (802.3ad) 或 active-backup,避免单链路故障。
  • 延迟要求:OSD 节点间 RTT 应 < 1ms,跨 AZ 部署时需启用 CRUSH 故障域。

3.4 存储后端选型

Rook Ceph 支持多种存储后端,选型需综合性能、成本与运维复杂度。以下为三种主流方案的对比:

后端类型 性能 成本 运维复杂度 典型场景
PVC (云盘) 中 (受网络延迟影响) 高 (按量付费) 低 (自动挂载) 云原生环境、快速原型
本地盘 (HDD/SATA SSD) 中高 (直通) 低 (一次性硬件) 中 (需管理磁盘故障) 容量型、冷数据归档
NVMe 极高 (低延迟、高 IOPS) 高 (硬件昂贵) 中高 (需散热与固件管理) 数据库、实时分析、高频交易

3.5 本地盘与 NVMe 的 Rook 配置示例

当使用裸盘(本地盘或 NVMe)时,Rook 通过 storage.nodes.devices 字段发现磁盘。以下为生产级配置片段:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  mon:
    count: 3
    allowMultiplePerNode: false
  storage:
    useAllNodes: false
    useAllDevices: false
    nodes:
      - name: "node-1"
        devices:
          - name: "nvme0n1"
            config:
              osdsPerDevice: "1"
              deviceClass: "nvme-ssd"
          - name: "nvme1n1"
            config:
              osdsPerDevice: "1"
              deviceClass: "nvme-ssd"
      - name: "node-2"
        devices:
          - name: "nvme0n1"
            config:
              osdsPerDevice: "1"
              deviceClass: "nvme-ssd"
          - name: "nvme1n1"
            config:
              osdsPerDevice: "1"
              deviceClass: "nvme-ssd"
    config:
      crushRoot: "default"
      crushDeviceClass: "nvme-ssd"
设备类 (Device Class) 最佳实践: 为 NVMe 与 HDD 分别设置不同的 deviceClass(如 nvme-ssd 与 hdd),CRUSH 规则可据此将高性能池映射到 NVMe OSD,容量池映射到 HDD OSD,实现分层存储。

3.6 存储后端选型决策树

以下决策树可帮助团队快速确定适合自身场景的存储后端:

存储后端选型决策树 选择存储后端 是否在公有云? 是 → PVC 云盘 EBS / 云硬盘 否 → 本地裸盘 物理机/私有云 是否需要高 IOPS? 否 → HDD / SATA SSD 容量优先,成本敏感 是 → NVMe 性能优先,低延迟 决策依据:IOPS 需求 > 延迟敏感度 > 容量成本 > 运维能力 NVMe 推荐用于 4K 随机读写 > 500K IOPS 的场景

3.7 关键检查清单

在进入 Rook 部署前,请逐项确认以下环境条件:

  • Kubernetes 版本:kubectl version --short 确认 server 版本 ≥ v1.21,推荐 v1.27+。
  • 节点标签:为 OSD 节点打上 role=storage 标签,便于 Rook 通过 nodeSelector 调度。
  • 内核参数:sysctl -w net.core.rmem_max=134217728 等网络缓冲区调优。
  • 磁盘清理:所有数据盘必须无分区表、无文件系统,使用 wipefs -a /dev/sdX 彻底清理。
  • 时间同步:所有节点运行 chronyd 或 ntpd,时间偏差 < 50ms。
快速验证命令:
# 检查内核版本
uname -r

# 检查磁盘是否可用(无分区)
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT | grep -E "disk|nvme"

# 检查网络延迟(OSD 节点间)
ping -c 5 -M do -s 8972 <peer-ip>  # 巨型帧测试

# 确认 Rook 兼容的 Kubernetes 版本
kubectl version --short | grep Server