Labels as the placement mechanism

Intermediate⏱ ~16 minceph

What you'll learn

Apply and manage host labels
Design a label scheme for a cluster
Use labels in placement specifications
Understand the special labels cephadm defines

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

Naming hosts in service specifications means editing them every time the cluster grows. Labels move the decision to the host, so adding capacity is labelling a host rather than editing four specifications — and the labels document what each host is for.

Managing labels

ceph orch host label add ceph-osd-05 osd
ceph orch host label add ceph-osd-05 rgw
ceph orch host label rm ceph-osd-05 rgw

ceph orch host ls
ceph orch host ls --label mon

HOST         ADDR         LABELS              STATUS
ceph-mon-01  10.20.0.10   _admin mon mgr
ceph-osd-01  10.20.0.21   osd
ceph-osd-05  10.20.0.25   osd rgw

Special labels

Label	Meaning
`_admin`	the admin keyring and ceph.conf are distributed here
`_no_schedule`	no daemons are placed here
`_no_conf_keyring`	configuration and keyring are not distributed
`_no_autotune_memory`	memory autotuning is skipped

_admin is the important one: it controls where /etc/ceph/ceph.client.admin.keyring is placed. Adding it to a host grants that host full cluster administrative access.

ceph orch host label add ceph-mon-02 _admin
ceph orch host label rm ceph-osd-01 _admin

_no_schedule is how a host is taken out of service without removing it — existing daemons stay, nothing new is placed.

A label scheme

mon      → monitor hosts
mgr      → manager hosts
osd      → storage hosts
mds      → CephFS metadata hosts
rgw      → gateway hosts
lb       → load balancer hosts
_admin   → administrative access

ceph orch apply mon --placement="5 label:mon"
ceph orch apply mgr --placement="2 label:mgr"
ceph orch apply osd --placement="label:osd"
ceph orch apply rgw default --placement="4 label:rgw"

Adding a labelled storage host now provisions its OSDs automatically, without touching any specification.

Combining with counts

ceph orch apply mon --placement="5 label:mon"

Five daemons chosen from the labelled hosts, so labelling seven hosts gives the orchestrator spare candidates without deploying seven monitors. That is generally what you want for monitors and managers: label generously, deploy a fixed count.

Quiz

Knowledge check · 4 questions

Q1. What does the `_admin` label do?

Grants accounts on that host administrator privileges in the Ceph dashboard interface Marks the host as the one the orchestrator uses to run its maintenance operations from Prevents daemon placement on the host so it can be administered without interference Causes the admin keyring and ceph.conf to be distributed to that host, giving it full cluster authority
Q2. `--placement="5 label:mon"` deploys monitors on every host labelled mon.

True False
Q3. Design a label scheme for a growing cluster.

A cluster will grow from 12 to 40 hosts over two years. Services are currently declared with explicit host lists, so each expansion requires editing four service specifications and is occasionally forgotten.
Q4. When should a placement use a bare label rather than a count with a label?

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

Production discipline

Convert explicit host lists to label-based placement so expansion is a single action on the new host rather than an edit to every service specification. Audit which hosts carry _admin periodically — it grants full cluster authority and is easy to add during troubleshooting and leave behind.

Cross-course references

Kubernetes: node labels with nodeSelector serve exactly this decoupling purpose
Linux: role-based host grouping in configuration management is the same pattern