Remote-first private corporate batches in SGT (UTC+8), onsite in Singapore 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 as a shared platform service rather than a single team's runtime: tenancy and quota design, identity federated from a corporate provider into cluster roles, admission policy that rejects unsigned or over-privileged workloads, workload identity that removes long-lived cloud keys, and upgrade and failover drills that produce the evidence a risk review will ask for. Every module runs live against a working cluster, and sessions are scheduled in SGT so an on-call engineer can attend without losing a day.
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 — multi-tenant clusters for regional platform teams — tenancy boundaries, admission policy, workload identity and chargeback — 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 Kubernetes delivery in Singapore is a travel engagement: two to three weeks' lead time secures a date, the client provides the room, network access and a screen, and the trainer brings the lab, the cluster material and the assessment, with travel and accommodation itemised separately. Live online is the default and runs in SGT (UTC+8), or in half-day blocks when the cohort is on call. Quotes are issued in SGD with INR retained as the source price, and purchase orders, vendor onboarding and supplier registration are completed before day one. Batches run 8 to 30 engineers; attendees build their own clusters so the environment survives the course, and the agenda is rebuilt around your topology, identity provider and residency constraints 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 control system. You declare what should be running and the control plane works continuously to make the cluster match that declaration, replacing failed containers, rescheduling around dead nodes and reconciling drift without anyone being paged. That much is true everywhere. What differs is the shape of the cluster estate a team ends up owning.
In Singapore, the common shape is a small platform group operating shared clusters on behalf of product teams distributed across several South-East Asian markets. Kubernetes therefore stops being a single-team runtime and becomes a multi-tenant service with internal customers: namespaces handed out as tenancy units, resource quotas that stop one team starving another, admission policy standing in for a review board, and a cost line that has to be attributed back to whoever created it.
That multi-tenant framing changes which parts of Kubernetes matter most. Deployments and Services are quickly learned. The parts that decide whether a shared cluster survives contact with eight teams are namespace and quota design, role-based access mapped to a corporate identity provider, admission control that rejects unsigned or over-privileged workloads, node-level isolation for workloads that must not share a host, and a clear answer to which data may cross which border.
Managed control planes have made cluster creation trivial, which has quietly moved the difficulty somewhere else. Organisations in Singapore rarely struggle to get a cluster; they struggle to run one cluster for many teams without it becoming either a free-for-all or a bottleneck.
The regional structure amplifies this. When a platform team of ten supports product groups in four or five countries, everything has to be self-service, and self-service without guardrails becomes an incident. Meanwhile technology-risk expectations mean that access into a production cluster, the provenance of what runs in it and the evidence of upgrades and recovery are all subject to review.
So the skills in demand are not the ones a certification exam concentrates on. They are tenancy design, identity federation, admission policy, workload identity into cloud services, cost attribution per tenant, and upgrade and failover procedures that produce evidence. Engineers who have only ever deployed into someone else's namespace do not have them, and that gap is what the market is currently paying to close.
The first decision that is expensive to reverse. How many clusters, split by what, and where the data-residency boundaries fall when product teams sit in several countries but the platform team sits in one.
Topics: Cluster-per-environment versus cluster-per-tenant · Blast radius and failure-domain design · Data-residency boundaries and workload placement · Managed control plane versus self-managed trade-offs · Regional and zonal topology · Cost and operational load per additional cluster
Namespaces as a product. Quotas and limit ranges that stop one team starving another, priority and preemption, tenant onboarding as automation, and the point at which soft multi-tenancy is no longer sufficient.
Topics: Namespace design as a tenancy unit · ResourceQuota and LimitRange in practice · PriorityClass and preemption behaviour · Automated tenant onboarding · Soft versus hard multi-tenancy · Node isolation with taints and dedicated pools
Who can do what in a cluster serving many teams. Authentication federated from a corporate identity provider, groups mapped to roles, service-account hygiene, time-bound elevation for production, and an audit policy that captures what a reviewer will ask about.
Topics: OIDC federation from a corporate identity provider · Mapping groups to Roles and ClusterRoles · Service accounts and token projection · Just-in-time elevation for production access · Audit policy and log retention · Reviewing and reducing over-privileged bindings
The guardrail that runs on every request. Pod Security Admission levels, policy engines such as Kyverno or Gatekeeper, image allow-lists and signature verification, mutation for sane defaults, and exception handling that expires.
Topics: Pod Security Admission levels and namespace labelling · Policy engines: validating and mutating admission · Image allow-lists and registry restrictions · Signature verification at admission · Required labels, requests and probes · Exceptions with an expiry and an owner
Removing long-lived credentials from the cluster. Workload identity federation to cloud services, external secret synchronisation, encryption of secrets at rest, and rotation that does not require a redeploy of everything.
Topics: Workload identity federation to cloud IAM · Removing static keys from manifests and images · External secret operators and sync patterns · Encryption at rest and key management · Rotation without redeploying the fleet · Break-glass access and its evidence
Making a shared cluster financially legible. Requests and limits discipline, measuring real utilisation against reservations, node autoscaling and bin-packing, spot capacity where it is safe, and a showback report each tenant can read.
Topics: Requests versus real utilisation · Vertical and horizontal autoscaling behaviour · Node autoscaling and consolidation · Spot and burst capacity for suitable workloads · Cost attribution by namespace and label · Showback reporting per tenant
Day-two work on a cluster other teams depend on. Version skew and upgrade sequencing, node pool rotation, disruption budgets, deprecated API migration, and the change record produced by the process rather than after it.
Topics: Control-plane and node version skew · Upgrade sequencing and rollback options · Node pool rotation and surge settings · PodDisruptionBudgets and eviction behaviour · Deprecated API detection and migration · Change evidence from the upgrade pipeline
What happens when a zone or a region goes away. Backup and restore of cluster state and persistent data, cross-zone spread, traffic failover, honest recovery objectives, and the parts of a stack that do not fail over cleanly.
Topics: Backing up cluster state and persistent volumes · Restore testing as a scheduled activity · Topology spread and zone failure behaviour · Traffic failover and DNS considerations · Stateful workloads and replication limits · Documenting recovery objectives honestly
We rebuild the agenda around the tools you actually run.
Request a custom agendaAutomate namespace creation with quotas, limit ranges, roles and default policies, then onboard a new team and prove isolation by trying to break it.
Wire cluster authentication to an identity provider, map groups to least-privilege roles, and implement a production elevation path that times out.
Enforce signature verification, image allow-lists and required resource requests at admission, then attempt four non-compliant deployments and read the rejections.
Replace a hardcoded cloud credential with workload identity federation, then rotate the backing configuration without redeploying the application.
Compare requests to actual utilisation across namespaces, right-size the worst offenders, enable consolidation and measure the change in node count.
Upgrade a live multi-tenant cluster with no downtime, simulate a zone loss, restore from backup, and produce the change and recovery evidence a review would request.
Kubernetes conversations in Singapore start further along than they do in most markets. Almost every team that calls already has clusters running — usually a managed control plane, occasionally a self-managed estate inherited from an earlier platform project — and the question is how to operate them for other people. The buyers are regional platform groups inside banks, insurers and payment institutions, the engineering functions of shipping, aviation and commodity-trading businesses, regional technology hubs of software vendors, and government-linked technology organisations.
That produces a consistent set of asks. Namespace tenancy that survives eight product teams with different release rhythms, cluster access federated from the corporate identity provider rather than kubeconfig files circulated by hand, admission policy standing in for a review board that nobody has time to run, and cost per tenant that finance can actually read. Data residency is a live design input, not a footnote, because a Singapore platform frequently serves users in Indonesia, Vietnam and the Philippines under different expectations about where records may sit. Cohorts are small, senior and hard to free up, so training is usually scheduled in two-day blocks and judged on whether the team leaves with policies and automation they can keep.
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.
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.
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.
| 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.