Private corporate batches, live online cohorts and 1-on-1 mentoring in container orchestration, scheduling and self-healing workloads at production scale — 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 Kubernetes from the control loop outward — architecture and cluster bootstrap with kubeadm, then workloads, networking, storage, RBAC and observability, finishing with upgrades, backup and restore, and structured troubleshooting across control plane, worker and network layers. Every concept is demonstrated live against a running cluster, and sessions deliberately include breaking the cluster and recovering it, because that is the part most training omits.
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 Kubernetes that means a trainer who has run it in production — container orchestration, scheduling and self-healing workloads at production scale — 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 Kubernetes batchKubernetes, often shortened to K8s, is an open-source platform for orchestrating containerised workloads across a cluster of machines. It takes a declarative description of what should be running — how many replicas, which image, what storage, which network policy — and continuously works to make the cluster match it. When a node dies or a container crashes, the control loop notices the gap and closes it without anyone being paged.
The architecture separates a control plane from worker nodes. The API server is the single front door; etcd stores desired state; the scheduler places pods onto nodes; controllers reconcile actual state against desired state. On each worker, the kubelet runs containers and reports back. Understanding that loop is what separates people who can operate Kubernetes from people who can only apply manifests.
Around that core sits the machinery real workloads need: Deployments and StatefulSets for lifecycle, Services and Ingress for traffic, PersistentVolumes and StorageClasses for state, ConfigMaps and Secrets for configuration, RBAC for authorisation, and network plugins such as Calico, Flannel or Weave Net for pod networking. Kubernetes is less a single tool than a platform for building platforms, which is precisely why teams need training rather than a tutorial.
Kubernetes has become the default substrate for running server-side software. Every major cloud sells a managed control plane, most vendor software now ships as a Helm chart or an operator, and job specifications for platform, SRE and infrastructure roles increasingly assume it as a baseline rather than list it as a bonus.
That ubiquity has shifted where the difficulty lies. Getting a cluster running is close to a solved problem — kubeadm or a managed service handles it. What organisations struggle with is everything after day one: designing namespaces and RBAC that hold up under multiple teams, choosing a network plugin and living with the consequences, running stateful workloads safely, upgrading a cluster without an outage, and debugging a failure that spans application, network and control plane.
Those are the skills teams hire for, and they are the ones that transfer poorly from documentation. They come from working through failure in an environment where breaking things is the point.
The problem Kubernetes solves and the shape of its answer. Control-plane components and what each one is responsible for, node components, and the vocabulary the rest of the course depends on.
Topics: The need for orchestration · Kubernetes architecture · Control plane components · Node components · Core concepts and terminology · Cluster requirements
Standing up a real multi-node cluster by hand, because managed control planes hide exactly the parts worth understanding. Master and worker installation, workstation configuration, and namespaces as the first organisational primitive.
Topics: Cluster planning with kubeadm · Installing and configuring the control plane · Joining worker nodes · Configuring kubectl on a workstation · Namespaces · Verifying cluster health
The workload primitives in the order they evolved, so the reasons behind Deployments are obvious rather than memorised. Pod internals, replication, then rolling updates and rollbacks.
Topics: Defining and inspecting pods · Pod lifecycle in depth · ReplicationControllers · Deployments · Rolling updates and rollbacks · Labels and selectors
Getting traffic to pods. Service types and when each applies, then deploying real multi-tier applications end to end rather than single-container demos.
Topics: Service types and use cases · Service discovery · Deploying a Java application · Deploying a Node.js application · Endpoint behaviour · Debugging service routing
State in a system designed around disposable compute. Volume types, static versus dynamic provisioning, PersistentVolumes and Claims, StorageClasses, and configuration separated from image with ConfigMaps and Secrets.
Topics: Volume types · Static and dynamic provisioning · PersistentVolumes and PersistentVolumeClaims · StorageClasses · ConfigMaps · Secrets
Workload shapes beyond the stateless Deployment. Stable identity with StatefulSets, per-node workloads with DaemonSets, and one-shot and scheduled work with Jobs and CronJobs.
Topics: StatefulSets and stable identity · DaemonSets · Jobs · CronJobs · Ordered deployment and scaling · Stateless vs stateful patterns
The layer that causes the most production confusion. The Kubernetes network model, how pod networking is actually implemented, and a comparison of Flannel, Calico and Weave Net with one implemented properly.
Topics: The Kubernetes network model · Pod networking mechanics · CNI plugins compared · Flannel · Calico · Weave Net · Implementing Calico
Controlling traffic in and between workloads. Ingress controllers and rules, NetworkPolicies for segmentation, and how DNS resolution works for services and pods.
Topics: Ingress and Ingress controllers · Ingress rules and TLS · NetworkPolicies · Default-deny patterns · DNS for services and pods · Debugging resolution failures
Who can do what. Authentication modules, the authorisation pipeline, and RBAC in practice — roles, bindings, service accounts and the least-privilege patterns that hold up when several teams share a cluster.
Topics: Authentication modules · The authorisation pipeline · RBAC roles and bindings · Service accounts · ABAC authorisation · Least-privilege patterns
Where pods land and whether they are healthy. Liveness and readiness probes, static pods, node selectors and affinity, and cluster add-ons including the dashboard.
Topics: Liveness and readiness probes · Static pods · nodeSelector · Node affinity and anti-affinity · Taints and tolerations · Cluster add-ons
The work that starts after go-live. Cluster upgrades, node maintenance and draining, backup and restore of cluster state, then structured troubleshooting across application, control plane, worker and network layers, with monitoring and log management.
Topics: Upgrading a cluster · Node maintenance and draining · Backing up and restoring cluster state · Troubleshooting application failure · Troubleshooting control plane failure · Troubleshooting worker and network failure · Monitoring cluster components · Managing application and component logs
We rebuild the agenda around the tools you actually run.
Request a custom agendaBootstrap a control plane and two workers with kubeadm, configure kubectl, and verify component health — the cluster used for every later lab.
Deploy a stateless front end against a stateful backing store, with correct service topology, probes and rollout strategy.
Implement Calico on a fresh cluster, then segment namespaces with NetworkPolicies and prove isolation by testing what fails.
Run a database with dynamic provisioning and a StorageClass, then delete the pod and prove the data is intact.
Design and implement least-privilege RBAC for three teams sharing one cluster, then audit it by attempting privilege escalation.
Upgrade a live cluster, then work through injected failures across control plane, worker and network layers, restoring from backup and producing a postmortem.
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.
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.
| 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 advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.