Remote-first private corporate batches in ICT (UTC+7), onsite in Thailand 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 for distributed and peak-driven estates: lightweight clusters at remote sites, fleet configuration from Git with drift visible per cluster, image pre-pull and registry mirroring for constrained links, autonomous behaviour when connectivity drops, and horizontal and queue-driven autoscaling rehearsed against a modelled campaign load. Sessions run in ICT against clusters the attendees build, and every failure mode is produced deliberately rather than described.
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 — clusters at the edge and clusters under peak — fleet management, offline-tolerant sites and campaign-day autoscaling — 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 Thailand is booked with two to three weeks' lead time, and travel to a plant, warehouse or distribution site outside the capital is planned into the schedule rather than assumed; the client provides the room, network access and a screen while the trainer brings the lab, cluster material and assessment. Live online is the default, scheduled in ICT (UTC+7), with a second sitting where operations staff work shifts. Quotes are issued in THB with INR retained as the source price, purchase orders and vendor registration are completed before day one, and applicable value-added tax appears on the invoice. Batches run 8 to 30 engineers; where a campaign date is fixed we schedule the batch to finish before the rehearsal window so the load work lands in time to be useful.
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 scheduler and a set of controllers that keep a declared workload running across whatever machines you give them. Most training assumes those machines are a comfortable pool of identical nodes in one data centre. A great many Thai deployments are not that. They are one central cluster plus a scattering of very small clusters living in stores, plants, warehouses and branches, connected by links that are slower and less reliable than head office believes.
That distribution changes which Kubernetes properties matter. At a site, the valuable property is autonomy: when the link drops, the node must keep running what it already has, resume when connectivity returns, and never require a person on site to type a command. At the centre, the valuable property is elasticity, because consumer platforms here concentrate a large share of annual revenue into a handful of campaign days.
So Kubernetes in Thailand is usually two problems wearing one name. Managing many small clusters as a fleet — registering them, configuring them from Git, upgrading them without a truck roll and knowing which version each one is running — and making one central cluster absorb a traffic peak that is an order of magnitude above its normal day without falling over or costing a fortune the rest of the year.
Thai retailers, manufacturers and logistics operators are pushing compute towards the places where the business actually happens. Point-of-sale, vision inspection, sensor aggregation and local caching all want to run near the site rather than round-trip to a central platform, and Kubernetes distributions light enough for a small industrial box have made that practical.
The moment a company has thirty such sites, the problem changes shape. Nobody can hand-manage thirty clusters, so fleet tooling, declarative configuration and remote recovery stop being nice-to-have and become the operating model.
On the consumer side the pressure is different but equally concrete: campaign days generate traffic multiples that a static cluster cannot serve economically, so autoscaling behaviour, warm capacity, queue-driven scaling and graceful degradation are rehearsed engineering rather than theory. Both patterns need engineers who understand what the scheduler and the controllers will actually do under pressure — not just how to apply a manifest — and that is the skill Thai teams report the most difficulty hiring.
The placement decision before any installation. What has to run at a site, what must stay central, what a small box can realistically host, and how a lightweight distribution differs from a full control plane in ways that matter operationally.
Topics: Workload placement between centre and site · Lightweight distributions and what they trade away · Sizing a cluster for constrained hardware · Single-node versus multi-node site clusters · Hardware and operating-system baseline for sites · Cost and support model per additional site
Operating thirty clusters with the effort of operating one. Cluster registration and inventory, declarative configuration applied per cluster and per group, rollout rings for site classes, and knowing precisely which version is where.
Topics: Cluster inventory and registration · Declarative configuration per cluster and per group · Rollout rings and staged fleet updates · Per-cluster drift visibility · Bootstrapping a new site into the fleet · Fleet-wide reporting on version and health
Getting images and manifests to a site without assuming bandwidth. Registry mirrors and pull-through caching, image pre-pull ahead of a rollout, image size discipline, retry and back-off behaviour, and rollout strategies for a fleet on a thin pipe.
Topics: Registry mirrors and pull-through caches · Pre-pull strategies before a rollout · Image size and layer reuse across workloads · Pull back-off, retries and timeouts · Staged rollout across a fleet · Verifying what actually landed at each site
What a site cluster does alone. Node behaviour when the control plane or the network is unreachable, local caching and queue-and-forward patterns, tolerations and eviction settings tuned for disconnection, and clean reconciliation on reconnect.
Topics: Node behaviour under control-plane disconnection · Eviction timeouts and tolerations for unstable links · Local caching and queue-and-forward designs · Reconciliation and conflict handling on reconnect · Health checks that do not depend on the centre · Alert suppression during known outages
The central cluster on the day that matters. Horizontal pod autoscaling on the right signal, queue-driven scaling, cluster autoscaling and node warm pools, cold-start reality, and the limits that bite before capacity does.
Topics: Horizontal autoscaling on custom and external metrics · Queue-driven scaling for asynchronous work · Cluster autoscaling and node warm pools · Cold start, image pull time and readiness · Connection limits, quotas and downstream bottlenecks · Cost profile between peak and normal days
Proving the plan before the traffic does. Building a realistic load model, running the rehearsal, agreeing a degradation ladder with the business, testing rollback under load, and turning the findings into concrete work.
Topics: Building a load model from historical traffic · Load rehearsal and game-day practice · Back-pressure, shedding and admission control · Degradation ladders agreed with the business · Rollback and pausing releases under load · Post-rehearsal actions and re-testing
Persistence where there is no storage team. Local persistent volumes and their limits, backup over a thin link, synchronisation patterns to the centre, and keeping personal data handling compliant with Thailand's data-protection expectations.
Topics: Local persistent volumes and node affinity · Backup strategies over constrained bandwidth · Synchronisation and conflict resolution to the centre · Retention and deletion at the site · Personal data minimisation in edge telemetry · Encryption at rest on hardware in a public space
Running the estate with nobody technical on site. Zero-touch provisioning, remote recovery when a site cluster will not start, monitoring that distinguishes a failed workload from a failed link, and runbooks written for the people actually present.
Topics: Zero-touch provisioning and bootstrap tokens · Remote recovery and out-of-band access · Distinguishing workload failure from connectivity loss · Fleet monitoring and alert routing · Runbooks for non-engineers, in two languages · Escalation between site staff and central engineering
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall a lightweight Kubernetes distribution on constrained resources, run a real workload on it, and measure what the control plane costs you in memory and CPU.
Register multiple clusters, configure them declaratively with per-group differences, roll a change to one ring only, and produce a version report for the fleet.
Pre-pull images to simulated sites, disconnect one during rollout, and make the deployment complete correctly with verification at the far end.
Sever a site cluster from the control plane, keep the workload serving, queue outbound data, then reconnect and reconcile without duplicates.
Drive a campaign-shaped load, scale on queue depth and external metrics, hit the first non-application bottleneck, then add back-pressure and repeat.
Run a modelled peak on the central cluster while a site loses connectivity, degrade gracefully, recover the site remotely, and write the review.
The Kubernetes work that comes out of Thailand splits cleanly into two populations. One is industrial: electronics, automotive component and food manufacturers, cold-chain and logistics operators, and retail chains with hundreds of outlets, all of which want workloads running physically close to the operation rather than round-tripping to a central platform. The other is consumer: marketplaces, delivery platforms, travel and hospitality services and bank digital channels whose year is shaped by a small number of campaign days.
The technical requests differ accordingly. Industrial teams ask about lightweight clusters on small hardware, managing dozens of them without a truck roll, behaviour when the link to a site drops, and backup over a connection that will not carry a full copy. Consumer teams ask about autoscaling on the right signal, warm capacity, cold-start time, and where a platform breaks before the application does. Both sets share two constraints that shape every Thailand engagement: bandwidth to remote locations is worse than the central architecture assumes, and operations staff on site are not engineers, so recovery has to be remote and runbooks have to be written for the people who are actually present in both Thai and English.
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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
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.
| 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.