Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Kubernetes 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 as an estate you have to operate rather than an API you have to memorise: a kubeadm bootstrap so the certificates, static pod manifests and kubeconfigs are visible objects, a CNI plugin installed by hand, ingress and TLS on bare metal where no cloud controller exists, storage on local persistent volumes, and RBAC and Pod Security Admission written so a reviewer can follow them. The back half of the syllabus is the part regulated and plant-side teams book it for — mirroring images into a private registry and installing with no outbound route, a minor version upgrade executed against a timer with PodDisruptionBudgets in force, etcd snapshot and restore proven by destroying a control plane and bringing it back, and a structured diagnosis path across application, node, network and control-plane layers. The teaching comes out of twenty years of production work spanning DevOps, SRE and security, and a count of engineers taught that is now well past 10,000.
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 — Kubernetes platform operations for Pune's regulated data centres, cloud teams and plant edge — 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.
Onsite delivery covers Kharadi, Magarpatta, Hinjewadi, Baner, Balewadi, Yerwada and Viman Nagar, and we travel to the Pimpri-Chinchwad and Chakan belt for plant-edge teams; you provide the room, a screen and network, we bring trainer, agenda, manifests, assessments and certificates. Hours are 09:30 to 17:30 IST, and for manufacturing clients we schedule the upgrade and disaster-recovery labs so they mirror a real changeover window rather than a quiet afternoon. Labs run on clusters the attendees build themselves — three small nodes each on free-tier cloud, or kubeadm on local VMs — because a managed cluster hides exactly the control-plane behaviour the operations modules are about; where your estate is air-gapped we mirror the lab images into your internal registry in advance so no exercise needs an outbound pull. Invoicing is in INR with GST against your purchase order from the Indian entity, and travel beyond the city is quoted separately.
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 is a cluster-level control system. You hand it a declarative description of what should be running — how many replicas of which image, which storage claim, which network rules, which limits — and a set of controllers works continuously to make the machines match that description. The API is identical everywhere. What is not identical is who owns the parts underneath it, and in Pune that question splits three ways: a vendor distribution running inside a bank's own racks with no route out to the public internet, a managed control plane in the cloud region next door, and a three-node cluster wired into a plant network with an intermittent link back to head office.
The control plane is where that difference bites. The API server is the only front door, etcd holds the entire declared and observed state, the scheduler decides placement, and controllers close the gap between what was asked for and what exists; on each node the kubelet runs containers and reports back. A managed provider owns all of that and hands you an upgrade button. Run it yourself and every one of those becomes a written procedure: certificate rotation before expiry, an etcd snapshot somebody has actually restored from, a version skew policy between control plane and kubelets, and an image path that does not assume a public registry is reachable.
Around that core sits the machinery real workloads need — Deployments, StatefulSets, DaemonSets and Jobs; Services, CoreDNS and a CNI plugin; Ingress, NetworkPolicy, PersistentVolumes and StorageClasses; ConfigMaps, Secrets and RBAC. On an estate with no cloud controller behind it several of those defaults simply do nothing: a LoadBalancer service stays pending forever, dynamic provisioning needs a driver you install and operate yourself, and every image has to already exist in a registry you run. Kubernetes is a platform for building platforms, and the platform you end up building is shaped by the constraints of the site it runs on.
Kubernetes demand in Pune no longer comes from teams deciding whether to adopt it. It comes from teams that adopted it two or three years ago and are now carrying the consequences. The banking, insurance and payments captives running clusters on their own infrastructure have reached the point where a version is approaching end of support, certificates are approaching expiry, and nobody in the group has performed a restore. That is a very different request from "teach us containers", and it is the one that arrives most often.
The product and platform teams whose clusters sit in the cloud region next door have the opposite pressure: multi-tenancy, autoscaling behaviour, spot interruptions and a cost line that finance can now see. The manufacturing groups pushing small clusters toward plant sites have a third problem entirely — hardware that cannot be scaled out, a link that drops, and a maintenance window measured in minutes at a shift changeover.
Hiring has moved with all of that. Local platform-engineering roles now expect a packaging story, a working ingress and certificate story, and evidence that the candidate has taken a live cluster through a minor version upgrade without an outage. Reading manifests is assumed. Operating the thing is what gets paid for, which is why this syllabus spends its back half on upgrades, recovery and diagnosis rather than on deploying a first pod.
The reconciliation model first: declared state in etcd, controllers closing the gap, the kubelet reporting back. Then the three estate shapes this batch covers — a self-managed cluster with no outbound route, a managed control plane in a nearby cloud region, and a small cluster at a plant site — and which components your team is actually responsible for patching, backing up and restoring in each.
Topics: The reconciliation loop and declarative state · API server, etcd, scheduler and controller manager · kubelet, kube-proxy and the container runtime on a node · Self-managed versus managed control plane: what you own in each · Version skew policy between control plane and kubelets · Sizing for a regulated estate, a cloud region and a constrained plant site
A cluster built by hand, because the upgrade and recovery modules later depend on knowing where the certificates, static pod manifests and kubeconfigs actually live. Control-plane initialisation, joining workers, kubeconfig contexts, and then the part an air-gapped estate needs on day one: mirroring images into an internal registry, pointing containerd at it, and completing an install with no outbound pull.
Topics: Host prerequisites: swap, cgroups, kernel modules, sysctl settings · containerd configuration and the container runtime interface · kubeadm init, the generated certificates and the static pod manifests · Joining workers, join tokens and rotating them · kubeconfig, contexts and driving two clusters from one workstation · Mirroring control-plane and workload images into a private registry · containerd registry mirrors, imagePullSecrets and pulling with no internet route · Single-node and three-node topologies for a constrained site
Pod internals, then the controllers that manage them. Deployments and ReplicaSets with their rolling-update parameters, DaemonSets for per-node agents, StatefulSets for identity-bearing workloads, and Jobs and CronJobs for batch. Particular attention to the surge and unavailable numbers, because they behave very differently on a three-node cluster than on one that can absorb an extra replica.
Topics: Pod specification, init containers and multi-container patterns · Pod lifecycle, restart policy and termination grace period · Deployments, ReplicaSets, labels and selectors · maxSurge and maxUnavailable on small clusters · Rollout history, pause, resume and rollback · DaemonSets for node-level agents · StatefulSets, stable identity and ordered scaling · Jobs and CronJobs with backoff limits and deadlines
How a packet actually reaches a pod. The Kubernetes network model and its flat-address assumption, installing and living with a CNI plugin, kube-proxy modes, the service types and what each does without a cloud provider underneath, endpoints and readiness gating, and CoreDNS resolution — the layer responsible for the largest share of misdiagnosed outages.
Topics: The Kubernetes network model and the CNI contract · Calico, Flannel and Weave Net compared, and installing one properly · kube-proxy in iptables and IPVS modes · ClusterIP, NodePort, headless and ExternalName services · Endpoints, EndpointSlices and readiness gating · CoreDNS: service and pod records, search paths and ndots · Why a LoadBalancer service stays pending with no cloud controller
Publishing services on an estate that has no cloud load balancer to call. Ingress controllers run as a DaemonSet behind existing load balancing, host and path rules, TLS terminated with certificates issued by an internal authority, and NetworkPolicy written as a default-deny baseline plus explicit allows that map onto a written control rather than onto a whiteboard diagram.
Topics: Ingress resources, ingress classes and controllers · Running an ingress controller on-premises: DaemonSet, hostNetwork, NodePort · TLS termination with certificates from an internal authority · MetalLB and bare-metal service exposure · NetworkPolicy: default deny, namespace and pod selectors, egress rules · Writing policy that maps to a stated control an auditor can follow · Proving isolation by testing what is supposed to fail
Separating configuration from image, and controlling where images are allowed to come from. ConfigMaps and Secrets as environment variables and as mounted volumes, what Secret encoding does and does not protect, encryption at rest for etcd, pull credentials for a private registry, and admission control that refuses an image sourced from anywhere you do not operate.
Topics: ConfigMaps as environment variables and as mounted volumes · Secrets, base64, and what is genuinely protected · etcd encryption at rest for secret data · External secret sources and rotation without a restart · imagePullSecrets and private registry credentials · Tags versus digests, and why digests matter on an offline estate · Admission control to restrict the registries a cluster will accept
State on machines that are meant to be disposable. PersistentVolumes and Claims, access modes and reclaim policies, StorageClasses and dynamic provisioning, CSI drivers for on-premises back ends, and the answers a plant site actually has available: local persistent volumes, hostPath and its risks, and what happens to a claim when the node holding it does not come back.
Topics: PersistentVolume, PersistentVolumeClaim and the binding process · Access modes, reclaim policies and volume expansion · StorageClasses and dynamic provisioning · CSI drivers and on-premises storage back ends · Local persistent volumes and node affinity · hostPath: where it is acceptable and where it is not · StatefulSet volumeClaimTemplates and recovery after node loss
Where pods land, and what stops one workload starving another. Requests and limits and the quality-of-service classes they produce, quotas and limit ranges per namespace, node selectors, affinity and anti-affinity, taints and tolerations, topology spread, and priority and preemption — all of which matter far more where adding another node is not an option.
Topics: Requests, limits and quality-of-service classes · ResourceQuota and LimitRange per namespace · nodeSelector, node affinity and pod anti-affinity · Taints, tolerations and dedicated node groups · Topology spread constraints · Priority classes, preemption and eviction order · Horizontal Pod Autoscaler and metrics-server · Capacity planning when the cluster cannot grow
Who may do what, expressed so it can be reviewed by somebody who is not a Kubernetes engineer. Authentication modules and certificate-based users, service accounts and projected tokens, Roles and ClusterRoles with their bindings, aggregation, and Pod Security Admission in place of the removed PodSecurityPolicy — plus how to produce the evidence a review will ask for.
Topics: Authentication modules: client certificates, tokens and OIDC · Service accounts, projected tokens and disabling automount · Roles, ClusterRoles, RoleBindings and ClusterRoleBindings · Aggregated ClusterRoles and least privilege in practice · kubectl auth can-i and auditing effective permissions · Pod Security Admission: privileged, baseline and restricted · API audit logging and what a reviewer will want to see · Namespace separation for multiple teams and external vendors
The same application delivered to several clusters that are not identical. Helm chart anatomy, values and templating, releases with upgrade and rollback, chart repositories hosted internally with mirrored dependencies, and Kustomize bases and overlays — plus what a chart does when the dependency it wants cannot be fetched from a public repository.
Topics: Helm chart anatomy: templates, values, helpers and dependencies · Releases, upgrade, rollback and release history · Hosting a chart repository internally and mirroring chart dependencies · helm template and diffing a release before applying it · Kustomize bases and overlays for per-site differences · Choosing between a chart and an overlay, honestly · Delivering one workload to a central cluster and to a plant site
The two procedures every team says it has and very few have rehearsed. Planning an upgrade against the version skew policy, upgrading the control plane and then the kubelets, cordon and drain with PodDisruptionBudgets in force, certificate renewal, and etcd: taking a snapshot, verifying it, and rebuilding a control plane from it — performed against a fixed window rather than an open afternoon.
Topics: Version skew policy and choosing an upgrade path · kubeadm upgrade plan and apply on the control plane · Upgrading kubelet and kubectl on worker nodes · cordon, drain and PodDisruptionBudgets · Certificate expiry, renewal and what expires silently · etcdctl snapshot save and snapshot status · Restoring etcd and rebuilding a control plane from a snapshot · Upgrading an air-gapped cluster with pre-staged images · Rehearsing and timing the whole procedure against a real change window
Watching a cluster, and diagnosing it under pressure. Metrics from control-plane and node components, application and component logs and their retention on a small cluster, events and describe output, then a disciplined diagnosis path — application, scheduler, node, network or control plane — practised against faults injected into a working cluster rather than described on a slide.
Topics: Monitoring control-plane and node components · Prometheus and metrics-server on a self-managed cluster · Application logs, component logs and retention on constrained storage · Events, describe output and the first sixty seconds of a diagnosis · Application failure: CrashLoopBackOff, ImagePullBackOff, pending pods · Control-plane failure and how it presents to a user · Worker node failure and NotReady conditions · Network and DNS failure, and separating the two · Writing a postmortem a reviewer will accept
We rebuild the agenda around the tools you actually run.
Request a custom agendaStand up one control-plane node and two workers by hand, mirror every image the build needs into a private registry first, then finish the whole thing with the outbound path blocked.
Install a CNI plugin, publish two applications through one ingress controller with internally issued certificates, then lock the namespace down with NetworkPolicy and prove what fails.
Run a stateful workload on local persistent volumes, delete the pod, then drain the node and work through exactly what recovers, what waits, and what never comes back.
Build least-privilege roles for two application teams and a CI account, apply the restricted pod security standard, then spend an hour trying to escalate out of your own model.
Upgrade a live cluster control plane and its kubelets against a timer, draining nodes with PodDisruptionBudgets in force, using only images staged in advance.
Snapshot etcd, destroy the control plane, restore from the snapshot, verify every workload returns, then diagnose two further injected faults and write the postmortem.
Kubernetes in Pune divides along a line most cities do not have. The banking, insurance and payments captives around Kharadi, Yerwada and Magarpatta run it on-premises — a vendor distribution on hardware they own, with no outbound path — so what matters is private registries and offline image mirroring, ingress and load balancing without a cloud controller, cluster-internal DNS, pod security and network policy written so an auditor can read them, and an etcd backup and restore that somebody has actually rehearsed rather than documented. Managed clusters belong to the other Pune audience: the product and SaaS firms around Baner, Balewadi, Viman Nagar and Kalyani Nagar, whose clusters sit in the nearby Mumbai region and whose pressure is autoscaling, spot capacity, multi-tenancy and cost per customer.
The third pattern is genuinely local. Manufacturers along the Pimpri-Chinchwad, Chakan and Ranjangaon corridor are pushing small clusters out to plant sites for line-side analytics and machine-vision workloads, which turns the syllabus toward single-node and three-node topologies, surviving an unreliable link back to a central control plane, local storage instead of a cloud volume driver, and upgrades performed inside a shift changeover window. Pune's hiring picture has moved on from "Kubernetes exposure" to platform-team roles that expect a packaging story with Helm or Kustomize, a working ingress and certificate story, and evidence that the candidate has completed a version upgrade without downtime — which is why these batches end on operations rather than on deploying a first pod.
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.