Remote-first private corporate batches in MYT (UTC+8), onsite in Malaysia 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 on infrastructure you own: cluster bootstrap and lifecycle without a cloud provider, etcd backup, restore and certificate rotation, on-premises load balancing and ingress, storage with real failure modes, and image mirroring for restricted or air-gapped networks. Every module runs live against a cluster that attendees build and deliberately break, and sessions are scheduled in MYT so in-house and supplier engineers can sit in the same batch.
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 on your own hardware — bare-metal clusters, etcd operations, on-premises load balancing and air-gapped delivery — 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 Malaysia is arranged with two to three 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. Live online is the default, scheduled in MYT (UTC+8), with a second sitting where supplier teams work a different shift. Quotes are issued in MYR with INR retained as the source price, purchase orders and vendor registration are handled before day one, and applicable service tax is shown on the invoice. Batches run 8 to 30 engineers and routinely mix in-house and supplier staff; where the estate is air-gapped, we mirror the lab artefacts in advance so the exercises work without outbound access.
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 declarative control system for running containers across a pool of machines: you state the desired outcome, and controllers work continuously to reconcile reality with it. Where the machines come from is left deliberately open — and in Malaysian engagements that openness is the whole story, because a large share of clusters here run on hardware the customer owns, in a data centre the customer operates.
That changes the syllabus significantly. On a managed service, the control plane, its backing store, certificate rotation, load balancer provisioning and storage classes all arrive as someone else's problem. On your own hardware you inherit each one. The control plane is three machines you patch. The backing store is an etcd cluster whose disk latency you care about. A Service of type LoadBalancer does nothing at all until something on the network answers for it. Persistent volumes require a storage system you have chosen, sized and can restore.
Kubernetes on premises is therefore less about writing manifests and more about operating a distributed system: quorum, certificate lifetimes, upgrade sequencing, capacity that cannot be conjured with a scaling group, and a registry that keeps working when the internet link does not. Those are learnable skills, but they are not the ones a managed-service tutorial teaches.
Two forces keep Malaysian Kubernetes work close to the ground. In-country data expectations and sector guidance push regulated and public-sector workloads onto infrastructure the organisation can point at, and existing capital investment in virtualisation and hardware makes an all-cloud plan hard to justify inside one budget cycle.
At the same time platform ambitions have not shrunk. Telecommunications operators want container-based network functions, government-linked corporations want self-service delivery for internal teams, and shared-services organisations want the same runtime everywhere so a workload can move between an on-premises cluster and a cloud one without being rewritten.
The result is demand for a specific and comparatively rare engineer: someone who can build and keep a cluster alive without a cloud provider underneath it. Backing up and restoring etcd, rotating certificates before they expire, giving a Service an address on a real network, running storage with actual failure modes, and mirroring images so a cluster can be rebuilt when the outbound link is closed. Those tasks are where on-premises estates fail, and where training pays for itself the first time a node has to be replaced.
Sizing and standing up a cluster without a cloud provider underneath. Control-plane quorum, node roles and sizing, container runtime choices, and the host-level prerequisites that cause most first-attempt failures.
Topics: Control-plane quorum and node sizing · Bare metal versus virtualised nodes · Container runtime selection and configuration · Host prerequisites: kernel modules, swap, cgroups · Bootstrapping with kubeadm or a distribution installer · Verifying a cluster is genuinely healthy
The component that decides whether your cluster exists. How etcd stores cluster state, what quorum loss looks like from the outside, backup and restore procedure, compaction and defragmentation, and the disk characteristics it genuinely needs.
Topics: etcd architecture and quorum · Disk latency requirements and symptoms of starvation · Scheduled backups and offsite copies · Restore procedure and its pitfalls · Compaction, defragmentation and database size · Monitoring etcd health before it fails
The silent expiry that takes clusters down. Cluster public-key infrastructure, certificate lifetimes and renewal, kubeconfig distribution, joining new nodes safely, and access control across in-house and supplier engineers.
Topics: Cluster certificate authority and component certificates · Certificate lifetimes and renewal · Recovering a cluster with expired certificates · Node join tokens and their expiry · kubeconfig distribution and rotation · RBAC boundaries between internal and supplier staff
Making Services reachable without a cloud load balancer. Pod networking choices, address assignment for Services of type LoadBalancer, ingress controllers, TLS termination, and integration with the hardware load balancers already in the data centre.
Topics: CNI selection and pod network design · Address pools for on-premises load balancing · Ingress controllers and TLS termination · Integrating with existing hardware load balancers · NetworkPolicy and segmentation between tenants · DNS inside and outside the cluster
Persistent data when there is no managed volume service. Container storage interface drivers, choosing between a distributed storage system and existing enterprise storage, snapshots, capacity planning, and the failure modes each option actually has.
Topics: Container storage interface drivers and provisioners · Distributed storage versus existing enterprise arrays · StorageClasses, reclaim policy and expansion · Snapshots and restoration of persistent volumes · Capacity planning and monitoring · Failure behaviour and rebuild time
Where standard defaults are not enough. Multiple network interfaces per pod, node feature discovery, huge pages and CPU pinning, device plugins, and the scheduling behaviour needed by workloads with hard performance requirements.
Topics: Multiple interfaces per pod · Node feature discovery and labelling · CPU management, pinning and huge pages · Device plugins and hardware access · Topology-aware scheduling · Validating performance-sensitive workloads
Running Kubernetes where the outbound link is closed or filtered. Private registries and mirroring, chart and dependency mirrors, image promotion into the restricted zone, and cluster installation and upgrade with no internet access at all.
Topics: Private registry design and mirroring · Mirroring charts and dependencies · Promotion of images into a restricted zone · Installing a cluster with no internet access · Upgrading in an air-gapped estate · Verifying integrity of imported artefacts
Steady-state operation on fixed hardware. Upgrade sequencing across control plane and nodes, disruption budgets, overcommit strategy when there is no elastic capacity, eviction behaviour under pressure, and dividing responsibility between in-house and supplier teams.
Topics: Upgrade sequencing and version skew · Draining nodes and PodDisruptionBudgets · Overcommit strategy without elastic capacity · Node pressure, eviction and quality of service classes · Capacity forecasting on fixed hardware · Responsibility split across operating parties
We rebuild the agenda around the tools you actually run.
Request a custom agendaBootstrap a three-node control plane and workers on bare hosts, verify component health, then break a prerequisite and diagnose it from the logs.
Back up etcd, destroy cluster state deliberately, restore from the backup, and measure how long the whole recovery actually took.
Give a Service an address on the corporate network, front it with an ingress controller and TLS, then segment tenants with a default-deny policy.
Run a database on operated storage with dynamic provisioning, snapshot it, destroy the node it lives on, and prove the data came back intact.
Mirror images and charts into a private registry, disconnect outbound access, and complete an installation and upgrade entirely from local artefacts.
Inherit a cluster with expired certificates, degraded etcd and a full node, recover it in sequence, then write the runbook that prevents a repeat.
Kubernetes demand in Malaysia sits noticeably closer to the hardware than it does in neighbouring markets. The organisations that call are telecommunications operators containerising network and support functions, government-linked corporations in energy, transport and utilities, banks operating their own data centres, electronics and semiconductor manufacturers with plant-adjacent systems, and the local delivery arms of systems integrators running platforms on a client's behalf. Managed cloud clusters exist in all of them, but rarely alone.
The technical brief follows from that. Clusters on virtualised or bare-metal hosts, storage provided by an array the storage team already owns, load balancing that has to interoperate with appliances in the data centre, and a strong preference for keeping certain workloads in-country. Registries are mirrored because outbound access is restricted, and upgrades are planned around change windows rather than performed on a whim. Because delivery is frequently shared between an in-house platform group and one or more suppliers, the hardest question in a Malaysian engagement is often not technical at all — it is who owns the cluster, who owns the platform layer above it, and who is called when a node dies at three in the morning.
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 advisorPrefer to call or email?
More ways to reach us on the contact page.