Private corporate batches delivered onsite across Bangalore, 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 API and a set of control loops rather than a catalogue of YAML: the request path through authentication, RBAC and admission webhooks, the scheduler's filter and score phases, requests and limits driving quality of service and eviction, and custom resources with controllers as the way a platform is extended. Multi-tenancy, network policy, storage classes, ingress, upgrades and etcd operations are taught on clusters attendees build themselves, and every concept is proved by breaking it — an evicted Pod traced to its QoS class, a Service that resolves but never answers, a rollout wedged on a failing readiness probe.
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 for Bangalore platform teams — API machinery, admission control, scheduling, multi-tenancy and cluster economics — 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 is at your own office. Kubernetes sessions in Bangalore commonly run along the Outer Ring Road between Bellandur and Marathahalli, in Whitefield, Koramangala or Electronic City, one site per day so peak-hour travel does not consume lab time. You provide the room, a screen and outbound network access; attendees run their own clusters — kind or a multi-node kubeadm cluster on their laptops for the administration exercises, and a managed cluster in the Mumbai region where the brief needs cloud integration. Teams working on isolated networks are catered for with an offline image bundle prepared in advance. Sessions are scheduled in IST (UTC+5:30) and planned around release and change-freeze windows. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and travel within Bangalore is included in the quote.
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 an API server with a set of controllers attached to it. Every object — a Pod, a Deployment, a Service, a quota, a role binding — is a resource served by that API, stored in etcd, and watched by controllers that compare desired state to observed state and act on the difference. Understanding it as an API rather than as a deployment tool explains most of its behaviour: why an object can exist while nothing has happened yet, why the answer to almost any operational question is in a resource's status field, and why extending the platform means adding resource types and controllers rather than adding scripts.
Every request into that API passes through a pipeline worth knowing in order: authentication, then authorisation via RBAC, then admission — mutating webhooks that can change the object, validating webhooks and policy engines that can reject it — and only then persistence. That pipeline is where a platform team actually enforces standards, because a rule applied at admission cannot be forgotten by a team writing manifests.
Scheduling is the second machine. The scheduler filters nodes that cannot run a Pod and scores the rest, using resource requests, node selectors and affinity, taints and tolerations, topology spread and priority. Requests and limits then determine the quality of service class, which determines what gets evicted when a node comes under memory pressure — the mechanism behind most surprising Pod terminations. Around all this sit the pluggable layers that make a cluster a real platform: a CRI runtime, a CNI plugin implementing pod networking and network policy, CSI drivers providing storage classes and volumes, ingress controllers for external traffic, and custom resource definitions with controllers or operators for everything an organisation wants to make declarative.
Kubernetes has passed the adoption phase and entered the consequences phase. Most organisations that wanted a cluster have one; what they lack is anyone who can make it multi-tenant, affordable, upgradeable and safe. The result is a market that no longer rewards deploying an application to a cluster, and rewards heavily the ability to operate the cluster other people deploy to.
The cost dimension arrived suddenly. Clusters make waste easy to create and hard to see: over-generous requests reserve capacity nobody uses, missing autoscaling leaves nodes idle overnight, and without namespace-level attribution no team believes the bill is theirs. Engineers who can right-size requests from real usage, improve bin packing, configure cluster and pod autoscaling and produce per-team cost reporting are solving a problem with an obvious number attached.
Security and governance closed in at the same time. Pod Security Admission replaced pod security policies, network policy became an expectation rather than an option, supply chain controls on images moved into admission, and RBAC is now audited. And upgrades stopped being optional — a supported Kubernetes version has a short life, so a cluster that cannot be upgraded safely is a liability with a date on it. Between platform engineering, cost and governance, the demand has moved decisively from knowing manifests to operating a shared platform.
Kubernetes as an API server plus controllers. Resources, the resource model and status; the reconciliation loop; then the request pipeline — authentication, RBAC authorisation, mutating and validating admission — traced live with API server audit output.
Topics: Resources, groups, versions and the object model · Spec, status and what a controller actually does · Control plane components and their responsibilities · Authentication methods and service accounts · RBAC: roles, cluster roles, bindings and aggregation · Admission control: mutating and validating webhooks · kubectl as an API client, and reading raw API responses
Pods and the controllers that manage them. Deployments and ReplicaSets, rollout strategy and history, StatefulSets and ordered identity, DaemonSets, Jobs and CronJobs — plus probes, lifecycle hooks, init and sidecar containers, and what actually happens during a rolling update.
Topics: Pod specification, init containers and sidecars · Deployments, ReplicaSets, rollout strategy and history · StatefulSets: identity, ordering and persistent volume claims · DaemonSets, Jobs and CronJobs · Liveness, readiness and startup probes done honestly · Lifecycle hooks, termination grace period and signal handling · Diagnosing a rollout that will not complete
Where Pods go and why they die. The scheduler's filter and score phases, node selectors, affinity and anti-affinity, taints and tolerations, topology spread; then requests and limits, quality of service classes, node pressure eviction, and the OOM kills that look inexplicable until you know the rules.
Topics: Scheduler filtering and scoring, with scheduling events · Node selectors, affinity, anti-affinity and topology spread · Taints, tolerations and dedicated node pools · Requests, limits and QoS classes: Guaranteed, Burstable, BestEffort · Node pressure, eviction order and pod disruption budgets · Priority classes and preemption · Right-sizing from actual usage data
How traffic reaches a Pod. The cluster network model and CNI, Services and their types, kube-proxy and endpoint slices, cluster DNS, ingress controllers and routing, then network policy as the tenant boundary — and a systematic method for debugging connectivity.
Topics: Cluster network model, CNI plugins and pod-to-pod routing · Service types, endpoints, endpoint slices and kube-proxy modes · CoreDNS, service discovery and resolution failures · Ingress controllers, rules, TLS and path routing · Network policy: default deny, tenant isolation and egress control · Gateway API and where it is heading · A repeatable connectivity debugging method
State and configuration done properly. Volumes, persistent volumes and claims, storage classes and dynamic provisioning through CSI, access modes and volume expansion, snapshots and backup; then ConfigMaps and Secrets, how they reach a container, and the external secret patterns teams move to.
Topics: Volumes, PersistentVolumes, claims and binding · StorageClasses, CSI drivers and dynamic provisioning · Access modes, volume expansion and reclaim policies · Snapshots, backup and restore for stateful workloads · ConfigMaps and Secrets as files and environment variables · Secret encryption at rest and why base64 is not encryption · External secret managers and CSI secret drivers
Making one cluster safe for many teams. Namespace boundaries, resource quotas and limit ranges, RBAC per tenant, Pod Security Admission, policy engines at admission, image provenance controls, and the self-service path that lets teams ship without a platform engineer reviewing every change.
Topics: Namespace as a boundary and what it does not isolate · ResourceQuota and LimitRange in practice · Pod Security Admission levels and migration from pod security policies · Policy engines: writing and testing admission policy · Service account tokens, workload identity and least privilege · Image provenance and registry restriction at admission · Designing a self-service tenant onboarding path
Running the cluster rather than using it. Building a cluster with kubeadm, certificates and their renewal, etcd backup and restore, control plane and node upgrades, node maintenance and draining, and the diagnostic path when the control plane itself is unhealthy.
Topics: kubeadm cluster build and component layout · Certificates, rotation and expiry incidents · etcd: backup, restore, compaction and defragmentation · Control plane and node upgrade sequencing · Cordon, drain and pod disruption budgets during maintenance · Managed clusters: what the provider does and what remains yours · Troubleshooting an unhealthy control plane and static pods
The platform around the cluster. Helm and Kustomize for packaging, GitOps delivery with Argo CD, metrics and logs, then horizontal, vertical and cluster autoscaling, bin packing and per-namespace cost attribution — plus custom resources and operators for extending the platform.
Topics: Helm charts, values and release lifecycle · Kustomize overlays and when to prefer them · GitOps with Argo CD: sync, drift and rollback · Metrics, logs and events: what to alert on · Horizontal Pod Autoscaler, Vertical Pod Autoscaler and cluster autoscaling · Bin packing, node pools and spot capacity · Per-namespace cost attribution and showback · Custom resource definitions, controllers and operators
We rebuild the agenda around the tools you actually run.
Request a custom agendaTrace a single kubectl apply through authentication, RBAC and admission webhooks using audit logs, then reject it deliberately at each stage and read the resulting error.
Create memory pressure on a node, observe the eviction order across QoS classes, identify the responsible class for each Pod, and fix the requests so the critical workload survives.
Debug a Service with wrong selectors, a broken readiness probe removing endpoints, and a network policy blocking egress — using a repeatable method rather than trial and error.
Build a repeatable tenant onboarding that creates a namespace with quota, limit range, RBAC, default-deny network policy and admission constraints, then prove the isolation.
Back up etcd on a kubeadm cluster, destroy the control plane state, restore from the snapshot, and verify workloads, secrets and RBAC survived intact.
Deliver a multi-tenant cluster with GitOps delivery, policy at admission, autoscaling, observability and per-namespace cost attribution, then onboard a second team onto it unaided.
The Kubernetes work that gets funded in Bangalore is platform work. A very large share of engineering teams here are not deploying an application to a cluster someone else runs — they are building the cluster other teams use, which turns the syllabus towards multi-tenancy from the first day: namespace-per-team boundaries, resource quotas and limit ranges, RBAC that survives an audit, network policy between tenants, admission control to enforce standards, and a self-service path that does not require a platform engineer to review every manifest. That is the job description behind most senior Kubernetes hiring along the Outer Ring Road and in Whitefield, and it is very different from application deployment.
Two local constraints shape the rest. The first is cost. Bangalore product companies in Koramangala, HSR Layout and Bellandur went through a period of much closer scrutiny of infrastructure spend, and clusters were where the waste was most visible — requests set to whatever the first engineer typed, nodes at twenty per cent utilisation, no autoscaling, and no attribution back to a team. Requests versus limits, quality of service classes, bin packing, cluster autoscaling and per-namespace cost reporting are now standard agenda items rather than advanced extras. The second is that a meaningful number of Bangalore clusters cannot be managed cloud services at all: semiconductor and EDA workloads bound to on-premise licence servers, telecom and embedded teams testing against physical hardware, and aerospace, space and defence engineering on isolated networks. Those teams need etcd operations, upgrade planning, ingress and storage integration and certificate management done by hand — the parts a managed service normally hides — which is why cluster administration depth still sells here while it fades elsewhere.
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.
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.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
| 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.