Why this course teaches Ceph directly

Why this matters in production

Orchestrators change; Ceph does not. Knowing which is which determines how much of what you learn remains useful.

What transfers completely

# identical in both
ceph -s
ceph osd tree
ceph pg dump
ceph df
rbd -p pool ls

Every diagnostic and every concept in this course applies unchanged.

What is orchestrator-specific

The orchestrator layer is roughly 10% of what operating Ceph involves,
and it is the part that changes between deployments.

Applying the material in Rook

# the toolbox pod is the entry point
kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

From there, every command in this course works. The differences appear only where the orchestrator owns the configuration:

Learning an orchestrator on top

With Ceph understood, learning Rook is:
  the custom resource definitions
  the operator's reconciliation behaviour
  the mapping from CR fields to Ceph configuration
  the Kubernetes-specific failure modes

Without Ceph understood, learning Rook is:
  all of that, plus Ceph itself, without a foundation

The order matters: a Rook problem is almost always a Ceph problem that must be diagnosed with Ceph knowledge and then resolved through the orchestrator’s interface.

Quiz

Production discipline

Diagnose Rook cluster problems with Ceph knowledge through the toolbox pod — degraded PGs and capacity thresholds are Ceph conditions regardless of how the daemons were placed. Remediate through whichever interface owns the setting, which is the only part that differs.

Cross-course references

• Kubernetes: understanding the workload beats understanding only the controller managing it
• Linux: knowing the service matters more than knowing the init system