Private corporate batches, live online cohorts and 1-on-1 mentoring in operating Ceph on Kubernetes — block, shared filesystem and S3 object storage — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Rook and Ceph as one subject — RADOS, monitors, managers, OSDs and the CRUSH map first, then the operator and the custom resources that drive them — so attendees can read ceph status before they are asked to trust a StorageClass. The syllabus covers all three consumption paths (RBD block, CephFS shared filesystem and RGW object with bucket claims), then the operational work that decides whether a cluster survives: failure domains, OSD replacement, capacity and near-full handling, and the ordered operator-then-Ceph upgrade. Sessions run against a real multi-node cluster with disks that get deliberately failed.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Rook that means a trainer who has run it in production — operating Ceph on Kubernetes — block, shared filesystem and S3 object storage — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Rook batchRook is a CNCF storage operator for Kubernetes, and in practice that means Rook-Ceph: it deploys, configures and manages a full Ceph cluster inside Kubernetes and exposes it through standard CSI drivers. One storage system then serves all three shapes at once — RBD block volumes for ReadWriteOnce claims, CephFS for ReadWriteMany shared filesystems, and RADOS Gateway for S3-compatible object storage.
The operator pattern is the whole idea. Rook watches custom resources — CephCluster, CephBlockPool, CephFilesystem, CephObjectStore, CephObjectStoreUser, CephNFS, CephClient and the mirroring resources — and reconciles the Ceph daemons to match. Monitors, managers, OSDs, metadata servers and gateways all run as pods. Adding capacity is editing a storageClassDeviceSet or a device filter rather than running ceph-deploy by hand, and replacing a failed OSD becomes a purge job rather than a long manual procedure.
What Rook does not do is remove Ceph. The CRUSH map still decides data placement, failure domains still determine what a rack loss costs you, replicated and erasure-coded pools still have very different economics, placement group counts still matter, and when something is wrong the answer still starts with ceph status from the toolbox pod. Learning Rook without learning Ceph produces a cluster that works until the first OSD fails. This training deliberately teaches both layers together.
The storage question has come back to on-premises Kubernetes. Bare-metal clusters, colocation, sovereign-cloud requirements and repatriated workloads all need persistent storage without a cloud block service underneath, and the demands have widened: databases want low-latency block, machine learning and media pipelines want a shared filesystem, and applications increasingly want an S3 endpoint that is not a public bucket.
Ceph answers all three from one system, which is exactly why it keeps being chosen and exactly why it has a reputation for being hard. Historically it needed a dedicated storage team. Rook narrows that gap by expressing cluster operations as Kubernetes resources, and it is the foundation of vendor storage products, so the skills transfer beyond the upstream project.
The gap is that Rook makes deployment easy and does not make Ceph simple. Teams get a healthy cluster on the first day and then meet placement group warnings, near-full OSDs, a stuck rebalance, an erasure-coded pool that cannot recover with the failure domain they chose, or a version upgrade sequence that must be done in a specific order. Those are Ceph problems reached through a Kubernetes interface, and they are what this training is built around.
Ceph before Rook, because Rook is an interface to it. RADOS as the object store everything else sits on, the daemon roles, how CRUSH decides placement without a lookup table, and then what an operator adds — and what it deliberately does not abstract away.
Topics: RADOS and the object store beneath block, file and object · MON, MGR, OSD, MDS and RGW daemon roles · Pools, placement groups and the CRUSH map · Replicated vs erasure-coded pools and their economics · The operator pattern and Rook's custom resource set · Rook-Ceph vs Longhorn vs NFS vs cloud block storage · Hardware expectations: disks, network, node count and memory
Standing up a real cluster and understanding every choice made along the way. Operator installation, the CephCluster resource, host-based versus PVC-backed OSDs, monitor count and placement, and resource requests that keep OSDs from being evicted under pressure.
Topics: Installing the Rook operator and its CRDs · The CephCluster resource in detail · Host-based OSDs: useAllDevices, deviceFilter and per-node device lists · PVC-backed OSDs with storageClassDeviceSets · Monitor count, placement and the mon failover process · Placement rules, node affinity and tolerations for storage nodes · Resource requests and limits for OSDs and MONs · The toolbox pod and first ceph status
The most common consumption path. CephBlockPool configuration, the RBD CSI driver, StorageClasses and their parameters, then the volume features workloads actually ask for: online expansion, snapshots, clones and the RWO access semantics.
Topics: CephBlockPool: replica size, min_size and failure domain · The rbd.csi.ceph.com driver and its components · StorageClass parameters: pool, imageFormat, imageFeatures, fstype · Provisioning, attaching and the RWO and ReadWriteOncePod distinction · Online volume expansion · VolumeSnapshotClass, snapshots and restore · Volume cloning and its cost · Diagnosing a PVC stuck in Pending or a volume that will not attach
The two capabilities that justify Ceph over a simpler block system. CephFS with metadata servers for genuine ReadWriteMany volumes, then CephObjectStore with RADOS Gateway providing an S3 endpoint, users and dynamic bucket provisioning through ObjectBucketClaims.
Topics: CephFilesystem, data and metadata pools · MDS deployment, active and standby counts, and metadata performance · The cephfs.csi.ceph.com driver and RWX StorageClasses · Subvolume groups and quota · CephObjectStore and RADOS Gateway deployment · CephObjectStoreUser and S3 credentials · ObjectBucketClaims and dynamic bucket provisioning · Exposing the S3 endpoint, TLS and ingress · CephNFS for clients that need NFS
The design decisions that determine what survives. CRUSH failure domains from OSD to host to rack to zone, replica size and min_size and what happens between them, erasure coding trade-offs, placement group autoscaling, and what a node loss actually costs in recovery traffic.
Topics: CRUSH hierarchy and failure domains: osd, host, rack, zone · Replica size vs min_size and the read-only threshold · Erasure-coded pools: k and m, and the recovery cost · Placement groups and the PG autoscaler · Rebalancing, backfill and recovery throttles · Node and rack loss scenarios and expected behaviour · Capacity planning with replication overhead and near-full ratios · Full, near-full and backfill-full behaviour and how to get out of it
Day-two work, which is where Ceph knowledge becomes non-negotiable. Reading ceph status and PG states properly, replacing a failed OSD, recovering monitor quorum, handling a stuck rebalance, and knowing when the operator will fix something and when it will not.
Topics: Toolbox workflows: ceph status, ceph health detail, ceph osd tree, ceph df · PG states and what each one means for availability · Diagnosing a HEALTH_WARN versus a HEALTH_ERR cluster · Failed OSD identification, removal and the purge job · Adding, resizing and draining OSDs · Monitor failure and quorum recovery · Disaster recovery for a cluster whose monitors are lost · When the operator reconciles and when it waits for you · Support data: operator logs, Ceph logs and what to collect
Keeping the cluster running for years. The ordered operator-then-Ceph upgrade path, Prometheus metrics and the Ceph dashboard, encryption at rest, network separation with Multus, and RBD mirroring for cross-cluster disaster recovery.
Topics: Upgrading the Rook operator and then the Ceph version, in order · Version compatibility and pre-upgrade health requirements · Ceph MGR Prometheus module, metrics and Grafana dashboards · Alerts worth having: PG degraded, OSD down, near-full, slow ops · The Ceph dashboard and safe exposure · Encrypted OSDs and key management · Multus for separating public and cluster networks · RBD mirroring and CephFS mirroring for cross-cluster DR · Benchmarking honestly and interpreting the numbers
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy the operator and a CephCluster with OSDs on dedicated devices, then verify health from the toolbox and add a node to watch rebalance.
Build two block pools with different replica settings, run a database on one, then snapshot, restore and expand the volume in place.
Serve an RWX CephFS volume to concurrent writers and provision an S3 bucket through an ObjectBucketClaim, all from the same Ceph cluster.
Design a rack-level CRUSH failure domain, simulate losing a whole rack, and account for availability, degraded PGs and recovery traffic.
Fail a device under load, identify and purge the OSD, bring a replacement into service and return the cluster to HEALTH_OK.
Upgrade operator and Ceph in order on a live cluster, configure RBD mirroring to a second cluster, fail a volume over and write the runbook.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.