Private corporate batches, live online cohorts and 1-on-1 mentoring in the CRI runtime beneath Kubernetes — snapshotters, shims, namespaces and the ctr/crictl/nerdctl toolchain — 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 containerd as the layer beneath the engine — the plugin architecture and gRPC service split, namespaces and why k8s.io containers are invisible to a default-namespace client, the content store and snapshotter mechanics that decide pull and unpack behaviour, and the shim model that lets the daemon restart without killing workloads. Sessions cover the configuration engineers actually need to change: config.toml versions, registry mirrors and hosts.toml, the systemd cgroup driver, sandbox image and runtime handlers for gVisor or Kata via RuntimeClass, plus garbage collection, leases and node-level debugging with ctr, crictl and nerdctl.
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 containerd that means a trainer who has run it in production — the CRI runtime beneath Kubernetes — snapshotters, shims, namespaces and the ctr/crictl/nerdctl toolchain — 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 containerd batchcontainerd is a container runtime daemon: a long-running service that manages the complete lifecycle of containers on one machine — pulling and storing images, unpacking them into filesystems, handing execution to an OCI runtime, and supervising the result. It is not a developer tool and has no build system, no Compose and no opinion about workflow. It exposes a gRPC API and expects a client above it, which is exactly why Kubernetes uses it directly through the CRI plugin instead of going through a higher-level engine.
Internally containerd is a set of plugins behind that API, and the separation between them is what makes its behaviour predictable. The content store holds immutable, content-addressed blobs. The image service records manifests and tags pointing at that content. Snapshotters — overlayfs by default, with native, btrfs, zfs, devmapper and lazy-pulling options such as stargz and nydus — turn those layers into a mountable root filesystem. The task service starts processes by launching a shim, and every client operation happens inside a namespace, so the containers Kubernetes creates in the k8s.io namespace are invisible to a client working in the default one.
The shim is the design detail with the largest operational consequence. containerd does not parent container processes itself; containerd-shim-runc-v2 does, one per pod sandbox, and it calls runc to create the container and then stays alive holding the process. Because of that, containerd can be restarted or upgraded while workloads keep running. RuntimeClass and runtime handlers extend the same mechanism to alternative runtimes — gVisor, Kata Containers, crun — by pointing at a different shim.
Kubernetes talks to containerd, not to a container engine. Since dockershim was removed from the kubelet, the runtime under almost every managed and self-managed cluster is containerd, and the tooling engineers reach for by habit no longer sees those containers at all. That gap turns routine node debugging into guesswork for teams who never learned the layer below the engine they started with.
The practical consequences show up constantly. Image pull failures and registry mirror configuration are resolved in containerd's config.toml and hosts.toml, not anywhere in Kubernetes. Cgroup driver mismatches between the kubelet and the runtime produce pods that fail in ways that look like scheduling problems. Disk pressure on a node is usually the content store and snapshots, and it is cleared by understanding leases and garbage collection rather than by deleting directories. Sandboxed runtimes for untrusted workloads are configured as runtime handlers with a RuntimeClass, one layer below anything Kubernetes documents in detail.
There is a performance dimension too. Image pull and unpack time is dominated by the snapshotter, and lazy-pulling snapshotters change node startup characteristics substantially for large images. Those are runtime decisions, made and diagnosed at the containerd layer.
The layering, stated exactly. Kubelet, CRI, containerd, shim, runc and the kernel — who calls whom, what each layer owns, and which of the industry's runtime alternatives replace which layer.
Topics: The OCI runtime, image and distribution specifications · kubelet, CRI, containerd, shim, runc · containerd against CRI-O and other CRI implementations · runc, crun, youki and sandboxed runtimes · What dockershim removal actually changed · Where a container engine still adds value
How the daemon is put together. The plugin model, the service split across content, images, containers, snapshots, tasks, events and leases, and the client libraries that drive them.
Topics: The plugin architecture and plugin types · Content, images, containers, snapshots, tasks and diff services · Events and the subscription API · Leases and reference counting · ctr as a low-level debugging client · The Go client library · Inspecting loaded plugins and their state · Daemon installation and systemd unit
Two concepts that explain most confusion. containerd namespaces as complete isolation between clients, then the content-addressed store: blobs, manifests, digests, and what pulling an image actually writes to disk.
Topics: containerd namespaces: default, moby and k8s.io · Why containers can be invisible to a client · Content-addressed blobs and digests · Image manifests, indexes and multi-architecture · Pull, unpack and the separation between them · Image labels and metadata · ctr and crictl across namespaces · Content store layout on disk
How layers become a root filesystem. The snapshotter interface, overlayfs as the default and its constraints, the alternatives, and the lazy-pulling snapshotters that change node startup time for large images.
Topics: The snapshotter interface: active and committed snapshots · overlayfs mechanics, lowerdir, upperdir and workdir · native, btrfs, zfs and devmapper snapshotters · Lazy pulling with stargz and nydus · Snapshot layout on disk and space accounting · Choosing a snapshotter for a workload profile · Diagnosing mount and permission failures · Measuring pull and unpack time
How a process actually starts. The task service, containerd-shim-runc-v2, the OCI runtime specification bundle handed to runc, and the process supervision model that keeps containers alive across a daemon restart.
Topics: Tasks versus containers · containerd-shim-runc-v2 and the shim API · One shim per pod sandbox · The OCI bundle: config.json and rootfs · runc create, start, exec and delete · Restarting containerd without killing workloads · Signals, exit status and process reaping · Shim logs and failure diagnosis
The Kubernetes-facing interface. The CRI plugin, sandboxes and containers, the pause container's role, image service versus runtime service, and how kubelet configuration and containerd configuration must agree.
Topics: The CRI plugin and its socket · RunPodSandbox, CreateContainer and the CRI call sequence · The pause container and shared namespaces · sandbox_image configuration · Image service versus runtime service · crictl: pods, ps, images, logs, inspect, exec · kubelet flags that must match containerd settings · Reading CRI errors that surface as pod events
The file that decides node behaviour. Configuration versions and their differences, the systemd cgroup driver, registry mirrors and authentication through hosts.toml, and registering additional runtime handlers for sandboxed workloads.
Topics: config.toml versions and migration between them · SystemdCgroup and cgroup v2 · Registry mirrors and the hosts.toml directory layout · Registry authentication and insecure registries · Private and air-gapped registry configuration · Runtime handlers and runtime options · gVisor and Kata Containers as handlers · Exposing handlers through Kubernetes RuntimeClass
Keeping nodes healthy. Leases and the garbage collector, safe image and snapshot pruning, upgrade behaviour, metrics, and the debugging workflow that resolves runtime incidents without restarting nodes at random.
Topics: Leases, reference counting and the garbage collector · Reclaiming disk: images, snapshots and content · kubelet image garbage collection versus containerd's · Upgrading containerd on a live node · Migrating a node from dockershim to CRI · Metrics endpoint and Prometheus scraping · Debugging with ctr, crictl, nerdctl and journalctl · Common failures: disk pressure, cgroup mismatch, mirror misconfiguration, shim leaks
We rebuild the agenda around the tools you actually run.
Request a custom agendaLocate a Kubernetes-created container from the command line, inspect its task and bundle, and explain why the default namespace showed nothing.
Pull a multi-gigabyte image under overlayfs and under a lazy-pulling snapshotter, and measure pull time, unpack time and disk consumed.
Restart and then upgrade containerd while containers serve traffic, and trace the shim processes that made the survival possible.
Create a sandbox and containers with crictl by hand, then diagnose a pod stuck in ContainerCreating entirely from the runtime side.
Configure registry mirrors and credentials with hosts.toml, then prove an air-gapped node pulls only from the internal mirror.
Fill a node until pods are evicted, then reclaim space through leases, garbage collection and pruning without disturbing running workloads.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
| 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.