Private corporate batches, live online cohorts and 1-on-1 mentoring in the vendor-neutral container discipline — kernel primitives, OCI standards, the runtime landscape, image supply chain and platform choice — 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 containers from the kernel primitives upward: namespaces, cgroups, capabilities and seccomp built by hand before any tooling appears, then the OCI image, runtime and distribution specifications that make the ecosystem interoperable, the runtime landscape from runc and containerd through CRI-O to Kata and gVisor, daemonless and rootless image building, and a supply chain covering base image ownership, signing, provenance attestation, SBOMs and admission verification. Sessions include unpacking an image by hand, escaping a deliberately misconfigured container, and reproducing CPU throttling and container out-of-memory kills to show why they are so often misdiagnosed.
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 Containers that means a trainer who has run it in production — the vendor-neutral container discipline — kernel primitives, OCI standards, the runtime landscape, image supply chain and platform choice — 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 Containers batchContainers are processes with a restricted view of the machine. There is no container object in the Linux kernel — what exists is a set of primitives that, combined, produce isolation: namespaces give a process its own view of process identifiers, mounts, network interfaces, users and hostnames; control groups cap and account for its CPU, memory and I/O; capabilities and seccomp filters reduce what it may ask the kernel to do; and a union filesystem assembles its root directory from stacked read-only layers with a thin writable layer on top. Everything above that is tooling.
That tooling is standardised, which is the reason container skills transfer between products. The Open Container Initiative defines three specifications — image, runtime and distribution — so an image built by one tool runs under another runtime and is served by any compliant registry. Beneath the familiar commands sit low-level runtimes such as runc and crun, high-level runtimes such as containerd and CRI-O that manage images, storage and lifecycle, and sandboxed alternatives such as Kata Containers, gVisor and Firecracker that trade startup cost for a stronger boundary. Building has similarly diversified beyond one tool: BuildKit, Buildah, Kaniko, Cloud Native Buildpacks and language-native builders all produce the same OCI artefact.
The hard problems with containers in production are rarely about starting one. They are about the image supply chain — what is inside a base image, whether it is signed, whether its provenance is attested, how vulnerabilities are triaged and how quickly a rebuild reaches production. They are about isolation being weaker than a virtual machine's, so a root process inside a container is one misconfiguration away from being root outside it. And they are about resource behaviour, where a CPU quota produces throttling that looks nothing like a busy machine and a memory limit produces a kill rather than a slowdown.
Containers are now the default packaging format for server software, which means the interesting questions have moved past adoption. Organisations that containerised years ago are dealing with the consequences: thousands of images of unknown provenance, base images that nobody owns, build tooling that requires a privileged daemon in CI, registries with no retention policy, and security teams asking questions the platform cannot answer.
Regulation has accelerated that. Software bills of materials, provenance attestation and signed artefacts have moved from good practice to procurement requirement in several sectors, and satisfying them requires understanding the image format and the build path rather than adding a scanner at the end. The engineers who can design a supply chain — reproducible builds, signed images, verified admission, a rebuild path that actually gets patches to production — are in demand well beyond the platform team.
The runtime landscape has also stopped being a single choice. Kubernetes clusters run containerd or CRI-O rather than Docker; CI systems build without a privileged daemon; multi-tenant platforms evaluate sandboxed runtimes; and some workloads belong on a managed service rather than an orchestrator at all. Making those calls needs vendor-neutral understanding rather than familiarity with one product's command set.
The kernel primitives, assembled by hand before any container tool is introduced. Each namespace type and what it hides, cgroup v2 hierarchies and controllers, capabilities and seccomp as the syscall boundary, and union filesystems as the layered root — then building an isolated process from those pieces alone.
Topics: Namespaces: pid, mount, network, user, uts, ipc, cgroup · cgroup v2 hierarchies, controllers and delegation · Capabilities, no-new-privileges and dropping privilege · Seccomp filters and the syscall attack surface · Union filesystems: overlayfs, layers and copy-on-write · Rootless containers and user namespace mapping · Building an isolated process with unshare, clone and pivot_root · Containers compared with virtual machines and chroot
Why the ecosystem interoperates. The image specification with its manifests, configuration and layer digests; the runtime specification with its bundle and config.json lifecycle; the distribution specification behind every registry API; and content addressing as the property that makes all three verifiable.
Topics: The Open Container Initiative and what it standardises · Image spec: manifest, config, layers and content addressing · Manifest lists and multi-architecture images · Runtime spec: filesystem bundle, config.json, lifecycle hooks · Distribution spec: the registry API and how a pull works · Digests versus tags, and why tags are not identity · OCI artefacts beyond container images · Unpacking an image to a runtime bundle by hand
What actually runs containers in production, which is increasingly not what developers use locally. Low-level runtimes, high-level runtimes and the Kubernetes CRI, daemonless and rootless tooling, sandboxed runtimes for hostile multi-tenancy, and Windows containers.
Topics: Low-level runtimes: runc, crun and the runtime spec in practice · High-level runtimes: containerd and CRI-O · The Kubernetes Container Runtime Interface and the kubelet path · Docker Engine and where it sits relative to containerd · Podman, Buildah and the daemonless model · Sandboxed runtimes: Kata Containers, gVisor, Firecracker · Runtime classes and mixing runtimes in one cluster · Windows containers: process versus Hyper-V isolation · Choosing a runtime against isolation, density and startup requirements
Producing artefacts that are small, cacheable, reproducible and safe to build in CI. Layer semantics and cache invalidation, multi-stage builds, distroless and minimal bases, daemonless builders for restricted environments, buildpacks and language-native builders, and multi-architecture output.
Topics: Layer semantics, ordering and cache invalidation · Multi-stage builds and separating build from runtime · Base image choice: distroless, minimal, and owning your own · BuildKit: cache mounts, secrets, parallelism · Daemonless building: Buildah, Kaniko and privilege-free CI · Cloud Native Buildpacks and language-native builders · Multi-architecture builds and emulation cost · Reproducible builds and deterministic output · Image size, layer count and what actually matters
Where images live and how they move. Registry architecture and storage, authentication and pull credentials, tag versus digest deployment, mirroring and pull-through caching, retention and garbage collection, replication across regions, and getting images into an air-gapped environment.
Topics: Registry architecture, storage backends and the API · Authentication, tokens and pull credentials in an orchestrator · Deploying by digest rather than by tag · Tag immutability and mutable-tag incidents · Mirroring, pull-through cache and rate limits · Retention policy and garbage collection · Cross-region replication and promotion between registries · Air-gapped distribution and image bundles · Self-hosted registry options and their trade-offs
The area most estates are weakest in. Vulnerability scanning and triage that is not just noise, software bills of materials, signing and provenance attestation, admission-time verification, and runtime security — least privilege, escape scenarios and detection.
Topics: Scanning images and triaging findings by reachability, not count · Base image ownership, patch cadence and rebuild pipelines · SBOM generation, formats and consumption · Signing images and verifying signatures · Provenance attestation and build integrity · Admission control: verifying signatures and policy before a workload runs · Least privilege at runtime: rootless, dropped capabilities, read-only root, seccomp · Container escape scenarios and the misconfigurations that enable them · Runtime detection and behavioural monitoring · Secrets handling — and the anti-patterns that bake them into layers
How containers behave once they are running. Storage drivers and their performance characteristics, volumes and bind mounts, container networking from bridge and host modes to CNI, then the resource behaviour that causes most misdiagnosis — CPU quota throttling, memory limits and out-of-memory kills.
Topics: Storage drivers: overlay2 and alternatives, and their costs · Volumes, bind mounts, tmpfs and data lifecycle · Network modes: bridge, host, none and container · Port publishing, NAT and the packet path · The Container Network Interface and pluggable networking · Service discovery and DNS inside container networks · CPU requests, limits, shares and quota throttling · Memory limits, page cache accounting and OOM kills · Diagnosing a container that is slow at low reported utilisation
Containers are not a deployment strategy on their own. What an orchestrator provides, an honest comparison across Kubernetes, managed container services, Nomad and single-host compose, and the day-two concerns — image lifecycle, node maintenance, logging, autoscaling and cost — that follow whichever is chosen.
Topics: What orchestration adds: scheduling, healing, service discovery, rollout · Kubernetes, managed container services, Nomad and compose compared · Serverless containers and scale-to-zero models · When an orchestrator is unnecessary complexity · Logging and metrics for ephemeral workloads · Image lifecycle and node maintenance in a running platform · Autoscaling signals and bin-packing efficiency · Cost implications of container density and idle capacity · Migration paths between platforms
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a working isolated process using only namespaces, cgroups, capabilities and pivot_root, then remove one namespace at a time to demonstrate exactly what each was hiding.
Fetch an image through the registry API alone, reassemble it from its layer digests, unpack it into a runtime bundle and start it with a low-level runtime and a hand-written config.json.
Shrink a large image substantially with multi-stage builds and a minimal base, then rebuild it daemonlessly in CI and produce multi-architecture output.
Generate an SBOM, sign an image, attach provenance attestation, and configure admission control so an unsigned or unattested image cannot be deployed.
Escape a deliberately misconfigured container, identify each enabling condition — privileged mode, host mounts, excess capabilities — and remediate them one by one.
Reproduce CPU quota throttling and a container out-of-memory kill, explain why standard utilisation metrics mislead, and produce a limits standard backed by measurement.
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
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
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.
| 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.