When cephadm is the right choice

Intermediate⏱ ~17 mincephadmceph

What you'll learn

Identify the situations favouring cephadm
Describe what cephadm provides operationally
Recognise its assumptions and requirements
Plan a cephadm deployment

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

cephadm makes Ceph a system in its own right, which is the correct model whenever storage has consumers beyond a single Kubernetes cluster.

Situations favouring cephadm

Situation	Why
Storage serves several consumers	independence from any one of them
Storage availability must exceed a consumer’s	no shared failure domain
Bare metal or dedicated VMs	the natural deployment target
A dedicated storage team	operating Ceph directly is their job
Regulatory or organisational separation	storage is a separate system
Very large clusters	operational model scales
Mixed consumers — Proxmox, Kubernetes, applications	none is privileged

What cephadm provides

ceph orch host add ceph-04 10.0.2.24 --labels osd
ceph orch apply osd --all-available-devices
ceph orch ls
ceph orch ps
ceph orch upgrade start --ceph-version 20.2.1

Capability	Mechanism
Host management	`ceph orch host`
Daemon placement	placement specifications and labels
Service definitions	declarative service specs
Rolling upgrades	`ceph orch upgrade` with health gating
Device discovery	`ceph orch device ls`
Monitoring stack deployment	Prometheus, Grafana, Alertmanager
Maintenance mode	`ceph orch host maintenance`

# a declarative service spec
service_type: osd
service_id: hdd-drives
placement:
  label: osd
spec:
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

ceph orch apply -i osd-spec.yaml

The service spec model gives cephadm much of the declarative behaviour that Rook provides, applied to hosts rather than to Kubernetes nodes.

Assumptions and requirements

cephadm requires:
  a container runtime on every host
  SSH access from the manager to every host
  Python 3
  systemd
  time synchronisation

HOSTNAME=stor-04
cephadm check-host
ceph cephadm check-host ${HOSTNAME}

Requirement	Why
Container runtime	daemons run as containers
SSH key distributed	cephadm manages hosts over SSH
Consistent time	monitors depend on it
Raw devices	OSDs need unpartitioned devices
Firewall permitting Ceph ports	daemons must communicate

Planning a deployment

1. Prepare hosts: container runtime, SSH, time sync, firewall
2. Bootstrap on the first monitor host
3. Add hosts with labels reflecting their roles
4. Define the CRUSH hierarchy to match the physical layout
5. Apply service specs for monitors, managers, and OSDs
6. Create pools with rules matching the failure domain
7. Deploy the monitoring stack
8. Establish the operational practices before production

cephadm bootstrap --mon-ip 10.0.2.11 --cluster-network 10.0.3.0/24
ceph orch host add ceph-02 10.0.2.12 --labels mon,mgr

Quiz

Knowledge check · 4 questions

Q1. Why does cephadm manage hosts over SSH rather than running an agent?

SSH is faster than an agent's polling loop, so a daemon change reaches every host within a second rather than at the next poll interval An agent would need deploying, upgrading, and monitoring — a bootstrapping problem — while SSH is already present and authenticated Agents are not supported by systemd on all the distributions cephadm targets, so the SSH path is the only portable one It provides better security, since an agent needs a listening port on every host while SSH is already firewalled and audited
Q2. With a cephadm service spec applied, adding a host with the matching label deploys its daemons without a further command.

True False
Q3. Choose an orchestrator for a shared storage cluster.

A storage cluster will serve a Proxmox environment, two Kubernetes clusters, and several application servers. A dedicated storage team will operate it.
Q4. What are cephadm's host prerequisites?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Apply declarative service specs with ceph orch apply -i rather than adding daemons individually — the spec is reviewable, and adding a labelled host then deploys the right daemons automatically. Verify the host prerequisites with cephadm check-host before bootstrapping.

Cross-course references

Kubernetes: declarative manifests provide the same reviewability as service specs
Linux: agentless management avoids the agent bootstrapping problem