惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Last Week in AI
Last Week in AI
GbyAI
GbyAI
Apple Machine Learning Research
Apple Machine Learning Research
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
N
Netflix TechBlog - Medium
量子位
aimingoo的专栏
aimingoo的专栏
D
Docker
F
Fortinet All Blogs
T
Tailwind CSS Blog
V
V2EX
D
DataBreaches.Net
Google DeepMind News
Google DeepMind News
MyScale Blog
MyScale Blog
G
Google Developers Blog
罗磊的独立博客
MongoDB | Blog
MongoDB | Blog
Microsoft Security Blog
Microsoft Security Blog
Microsoft Azure Blog
Microsoft Azure Blog
WordPress大学
WordPress大学
博客园 - 三生石上(FineUI控件)
小众软件
小众软件
A
About on SuperTechFans
IT之家
IT之家

OneUptime Blog

How to Monitor Azure App Services (PaaS) with OpenTelemetry Grafana Stack vs OneUptime: DIY Observability or Unified Platform? Your AI Workloads Are About to Blow Up Your Observability Bill The Great Observability Consolidation Is Here How to Write Custom Object Classes for Ceph How to Write Custom Ceph Manager Modules How to Write a ceph.conf Configuration File How to Use Rook-Ceph with OpenShift How to Use Rook-Ceph with Longhorn for Comparison How to Configure Volume Snapshot Class for RBD in Rook How to Configure VolumeReplicationClass Scheduling Intervals in Rook How to Set Up Volume Replication with Rook-Ceph How to Create Volume Group Snapshots with Rook CSI How to Visualize Ceph Network Performance in Grafana How to Enable Virtual Host-Style Bucket Access in Rook How to View Runtime Configuration via Admin Socket How to View Quota Settings and Update Stats in Ceph RGW How to View PG Scaling Recommendations with autoscale-status How to View PG Distribution via Admin Socket How to View Performance Metrics in the Ceph Dashboard How to View OSD Performance Counters in Ceph How to View Connection Status via Admin Socket How to View Ceph Cluster Summary Dashboard via CLI How to Version Control Rook-Ceph Configuration How to Version Control Ceph Infrastructure with Terraform How to Verify Health Before and After Rook Upgrades How to Verify Data Integrity with Deep Scrubbing How to Verify Complete Rook-Ceph Cleanup How to Verify Backup Integrity from Ceph Snapshots How to Use Rook-Ceph with Velero for Kubernetes Backup
How to Verify Kubernetes Node Requirements for Rook-Ceph ...
Nawaz Dhandala · 2026-03-31 · via OneUptime Blog

Why Node Verification Is Critical

Rook-Ceph operates differently from typical Kubernetes applications. OSDs communicate directly with block devices, CSI drivers mount filesystems using kernel modules, and monitors require stable hostnames and persistent storage. A node that appears healthy to Kubernetes may still cause Rook-Ceph failures if it lacks the right kernel version, modules, or disk configuration.

graph LR
    A[Node Verification] --> B[Kernel Check]
    A --> C[Disk Check]
    A --> D[Memory Check]
    A --> E[CPU Check]
    A --> F[Network Check]
    A --> G[Package Check]
    B --> H{All Pass?}
    C --> H
    D --> H
    E --> H
    F --> H
    G --> H
    H -- Yes --> I[Safe to Deploy]
    H -- No --> J[Fix Issues First]

Minimum Hardware Requirements

Check that each storage node meets the minimum resource thresholds before deploying Rook-Ceph:

ComponentMinimumRecommended
CPU (per OSD)1 core2 cores
RAM (per OSD)2 GB4 GB
RAM (per Mon)1 GB2 GB
RAM (per Mgr)512 MB1 GB
Disk (OSD)10 GB raw100+ GB raw
Network1 Gbps10 Gbps

Check available memory on a node:

kubectl get node node1 -o jsonpath='{.status.capacity.memory}'

List allocatable CPU and memory across all nodes:

kubectl get nodes -o custom-columns=\
NAME:.metadata.name,\
CPU:.status.allocatable.cpu,\
MEMORY:.status.allocatable.memory

Kernel Version Verification

Ceph kernel support improves with newer kernels. Check the kernel version on each node:

kubectl get nodes -o custom-columns=\
NAME:.metadata.name,\
KERNEL:.status.nodeInfo.kernelVersion

You can also run this directly on a node:

uname -r

Rook-Ceph recommends kernel 4.17 or later. For CephFS with quotas, kernel 4.17+ is required. For RBD fast-diff, kernel 4.10+ is needed.

Kernel Module Verification

Check that the required kernel modules are loadable on each node. The easiest way is to run a DaemonSet that probes the modules:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: rook-prereq-check
  namespace: default
spec:
  selector:
    matchLabels:
      app: rook-prereq-check
  template:
    metadata:
      labels:
        app: rook-prereq-check
    spec:
      hostPID: true
      containers:
        - name: checker
          image: busybox
          command:
            - /bin/sh
            - -c
            - |
              echo "Node: $(hostname)"
              lsmod | grep rbd && echo "rbd: OK" || echo "rbd: MISSING"
              lsmod | grep ceph && echo "ceph: OK" || echo "ceph: MISSING"
              sleep 3600
          securityContext:
            privileged: true
      tolerations:
        - operator: Exists

Apply and read the logs:

kubectl apply -f prereq-check.yaml
kubectl logs -l app=rook-prereq-check --prefix=true

Block Device Availability Check

Verify that each node has clean block devices available for Rook-Ceph. Run this command on each storage node:

lsblk --output NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,LABEL

Identify devices that are unpartitioned, have no filesystem, and are not mounted - these are eligible:

NAME    SIZE TYPE FSTYPE MOUNTPOINT LABEL
sda     100G disk
sdb     100G disk
nvme0n1 500G disk

Confirm no LVM signatures remain on the target devices:

sudo pvs /dev/sdc 2>/dev/null && echo "Has LVM" || echo "Clean"

Hostname Resolution Check

Ceph monitors use hostnames for quorum. Each node's hostname must be resolvable from all other nodes:

# On each node, verify self-resolution
hostname -f
nslookup $(hostname -f)

# Test cross-node resolution
nslookup node2.example.com

If DNS is not available, add entries to /etc/hosts on all nodes:

echo "192.168.1.11 node1.example.com node1" | sudo tee -a /etc/hosts
echo "192.168.1.12 node2.example.com node2" | sudo tee -a /etc/hosts
echo "192.168.1.13 node3.example.com node3" | sudo tee -a /etc/hosts

CSI Driver Node Requirements

The Rook CSI driver (ceph-csi) runs on every node that needs to mount Ceph volumes. Check that the CSI requirements are met:

# Check if iscsiadm is available (needed for some configurations)
which iscsiadm

# Check if cryptsetup is available (needed for encrypted volumes)
which cryptsetup

# Check if multipath is properly configured
cat /etc/multipath.conf 2>/dev/null || echo "No multipath config found"

Pod Security Verification

Verify the namespace allows privileged pods, which Rook-Ceph requires:

kubectl get namespace rook-ceph -o yaml | grep pod-security

If Pod Security Admission is enforced, check the labels:

kubectl get namespace rook-ceph --show-labels

The namespace should have pod-security.kubernetes.io/enforce=privileged.

Consolidated Verification Script

Use this script to check all requirements from your local machine using kubectl:

#!/bin/bash
echo "=== Rook-Ceph Node Requirements Check ==="

echo ""
echo "--- Kubernetes Version ---"
kubectl version 2>/dev/null | head -2

echo ""
echo "--- Node Status ---"
kubectl get nodes -o wide

echo ""
echo "--- Node Resources ---"
kubectl get nodes -o custom-columns=\
NAME:.metadata.name,\
STATUS:.status.conditions[-1].type,\
CPU:.status.allocatable.cpu,\
MEMORY:.status.allocatable.memory,\
KERNEL:.status.nodeInfo.kernelVersion

echo ""
echo "--- Storage Capacity Check ---"
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.capacity.ephemeral-storage}{"\n"}{end}'

echo "=== Check complete ==="

Summary

Verifying node requirements before deploying Rook-Ceph prevents the most common class of deployment failures. The key checks are: sufficient CPU and RAM per daemon type, kernel version 4.17 or later with rbd and ceph modules loadable, clean block devices with no filesystem signatures or LVM metadata, reliable hostname resolution between nodes, and a namespace configured to allow privileged pods. Running a pre-deployment DaemonSet to automate these checks across all nodes catches problems before they surface as cryptic Ceph health warnings.