Remote-first private corporate batches in CET (UTC+1), onsite in Netherlands by arrangement — 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 at fleet scale: clusters declared and created as resources, GitOps delivery with generated applications across many clusters, service-mesh identity and mutual TLS replacing network trust, admission-time verification of image signatures and provenance, and efficiency work backed by measured utilisation. Sessions run in CET against clusters attendees build themselves, and each control is demonstrated by attempting to violate it and watching the cluster refuse.
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 — cluster fleets managed as code — Cluster API, GitOps at scale, mesh-enforced zero trust and efficiency you can report — 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 in the Netherlands is a travel engagement with three to four weeks' lead time; the client provides the room, network access and a screen, the trainer brings the lab, cluster material and assessment, and travel and accommodation are itemised separately rather than folded into the day rate. Live online is the default and runs in CET (UTC+1), with the window shifted when a team also spans India or the United States. Quotes are issued in EUR with INR retained as the source price; purchase orders and supplier onboarding are completed before the first session, and VAT treatment is stated explicitly on the invoice. Batches run 8 to 30 engineers, attendees build clusters in their own accounts so the environment outlives the course, and the agenda is rebuilt around your cluster inventory, GitOps tooling and policy engine during a discovery call.
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 reconciliation engine: controllers observe the difference between what is declared and what exists, and act to close it. Once a team internalises that, the interesting question becomes what else can be expressed as a resource and reconciled — and that is precisely the direction Dutch engineering organisations have taken it.
Here Kubernetes is rarely a single cluster with a few applications on it. It is a fleet: clusters per environment, per region and sometimes per business unit, themselves declared as resources and created by a management cluster, with applications delivered onto them from Git rather than by a pipeline pushing manifests. Cloud infrastructure outside the cluster is increasingly declared through the same control plane, so a database or a bucket becomes a resource a product team requests through a template rather than a ticket.
Around that sits a control layer the local regulatory climate makes unavoidable. Mutual TLS between services rather than implicit trust inside a network, admission-time verification that an image was signed and its provenance is known, policy engines refusing configurations that would breach a rule, and evidence produced continuously instead of assembled before an audit. Kubernetes ends up being the place where platform ambition and compliance obligation meet, which is why the operational depth expected of engineers here is unusually high.
Dutch organisations adopted containers early enough that the current problems are second-generation. Very few teams need to be convinced to use Kubernetes; many are managing more clusters than they intended, created by different teams at different times, with configuration that has quietly diverged.
That makes fleet management the live skill. Creating clusters declaratively, upgrading them on a predictable cadence, keeping their configuration identical where it should be identical, and decommissioning them without archaeology.
Regulation pushes in the same direction. Supply-chain and incident obligations arriving through EU rules mean an organisation has to be able to state what is running, where it came from and who approved it — a question that is trivial with signed images and admission verification, and nearly unanswerable without them. Financial entities face resilience testing expectations on top. And with energy costs and sustainability reporting now part of the same conversation, cluster efficiency has moved from an infrastructure preference to a number someone external may read. Engineers who can run a fleet, prove its contents and show its efficiency are scarce here for entirely rational reasons.
Designing for many clusters from the start. Splitting by environment, region and tenancy, deciding what must be identical across the fleet, and how a European data boundary constrains where workloads and their backups may live.
Topics: Fleet segmentation by environment, region and tenant · What must be identical across clusters and what may vary · Data-boundary constraints on placement and backup · Managed versus self-managed control planes in a fleet · Cluster naming, metadata and inventory · Decommissioning a cluster cleanly
Creating clusters the same way you create workloads. A management cluster and declarative cluster definitions, reusable cluster templates, controlled version rollout across the fleet, and upgrades that follow a schedule rather than an incident.
Topics: Management cluster and declarative cluster resources · Cluster templates and reusable classes · Provider integration for cloud infrastructure · Version cadence and staged fleet upgrades · Node pool lifecycle and rotation · Recovering a cluster whose definition has drifted
Delivering to many clusters without duplicating manifests. Generated application definitions per cluster and tenant, environment promotion by reviewed change, drift reconciliation, and secret handling that keeps the model declarative without plaintext.
Topics: Generated applications across clusters and tenants · Repository structure for fleet delivery · Promotion between environments by review · Drift detection and self-healing · Encrypted manifests and external secret operators · Rollback by revert across many clusters
Replacing network trust with cryptographic identity. Mesh architecture and its cost, mutual TLS between services, authorisation policy at the service level, traffic shifting for progressive delivery, and honest guidance on when a mesh is not worth it.
Topics: Mesh architecture, sidecars and alternatives · Workload identity and certificate rotation · Mutual TLS and authorisation policy · Traffic shifting and canary routing · Observability the mesh provides for free · When a mesh costs more than it returns
Extending the control plane so product teams serve themselves. Custom resources and operators, provisioning cloud infrastructure through Kubernetes, templated self-service with guardrails, and the maintenance burden a custom API creates.
Topics: Custom resource definitions and controllers · Operator patterns and their failure modes · Provisioning cloud resources through the control plane · Self-service templates with embedded guardrails · Versioning a platform API · Support burden and deprecation strategy
Establishing what is running and where it came from. Image signing and provenance attestation, verification at admission, software bills of materials tied to running workloads, vulnerability triage with exploitability context, and evidence gathered continuously.
Topics: Signing images and attaching provenance · Verifying signatures and attestations at admission · Linking bills of materials to running workloads · Vulnerability triage with exploitability context · Policy for base images and registries · Continuous evidence rather than audit-time assembly
Proving the cluster survives what it claims to survive. Disruption budgets and topology spread, zone-failure simulation, stateful workload behaviour under partition, chaos experiments with defined hypotheses, and recovery testing that produces evidence.
Topics: PodDisruptionBudgets and eviction behaviour · Topology spread and anti-affinity · Zone-loss simulation · Stateful workloads under partition · Chaos experiments with a hypothesis · Backup, restore and documented recovery objectives
The number that now leaves the engineering department. Requests versus measured utilisation, vertical recommendations, node consolidation and bin-packing, workload placement and spot capacity, and reporting cost and energy per service credibly.
Topics: Requests, limits and measured utilisation · Vertical recommendations and safe right-sizing · Node consolidation and bin-packing · Spot and burst capacity for tolerant workloads · Cost attribution per namespace and team · Energy and carbon reporting inputs
We rebuild the agenda around the tools you actually run.
Request a custom agendaStand up a management cluster, define a workload cluster as a resource, create it from a template, then change its shape declaratively and watch the rollout.
Generate application definitions across a fleet from a single source, promote a release by review, then introduce drift on one cluster and let reconciliation correct it.
Enforce mutual TLS and authorisation policy between namespaces, verify that unauthenticated traffic is refused, then shift traffic progressively between two versions.
Sign an image with provenance, enforce verification at admission, attempt to deploy an unsigned build, then trace a vulnerable dependency across the fleet.
Set disruption budgets and topology spread, simulate the loss of an availability zone, measure real impact, and restore a stateful workload from backup.
Assemble declarative clusters, GitOps delivery, mesh identity, admission verification and an efficiency review into one platform, documented well enough to transfer to another team.
The Netherlands produces a particular kind of Kubernetes conversation: the team on the call has been running clusters for years and is now dealing with the consequences. Typical customers are payments and banking platforms, logistics and transport technology groups built around port and airfreight flows, energy and grid operators, health-technology companies, high-traffic consumer platforms, and the EMEA engineering hubs of multinationals. Interconnection and hosting density in the Netherlands is genuinely high, so traffic-heavy and latency-sensitive platforms appear far more often than the size of the country suggests.
What they ask for is second-generation work. Too many clusters created by too many teams, a version cadence nobody owns, GitOps repositories that grew organically and now duplicate the same manifest eleven times, and a compliance function asking questions about provenance that the platform cannot currently answer. Contractor turnover raises the stakes: an undocumented cluster estate becomes unmaintainable when the people who built it rotate off. Add resilience testing expectations for financial entities and reporting pressure on energy and cost, and the shape of the engagement becomes consistent — consolidate the fleet, make it declarative, make what runs on it verifiable, and be able to show the numbers.
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.
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.
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.
| 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.