Private corporate batches, live online cohorts and 1-on-1 mentoring in Kubernetes-native GitOps delivery with Argo CD, Rollouts, Workflows and Events — taught by a practitioner who runs it 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 Argo around the reconciliation loop rather than the UI — the Application CRD and its source/destination contract, how repo-server rendering differs across Helm, Kustomize and plugins, sync waves and hooks for ordering, and custom Lua health checks for resources Argo cannot assess on its own. Sessions cover the multi-tenancy design most courses skip: AppProject constraints, ApplicationSet generators across fleets of clusters, RBAC and SSO wiring, secret handling outside Git, and progressive delivery with Argo Rollouts gated on real analysis metrics.
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 Argo that means a trainer who has run it in production — Kubernetes-native GitOps delivery with Argo CD, Rollouts, Workflows and Events — 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.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
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 Argo batchArgo is a family of Kubernetes-native delivery projects: Argo CD for continuous delivery, Argo Rollouts for progressive deployment, Argo Workflows for container-native pipelines, and Argo Events for triggering them. They share a design principle — everything is a custom resource, reconciled by a controller running inside the cluster, so the cluster itself is the delivery engine rather than something a pipeline pushes into.
Argo CD is the piece most teams meet first. Its unit of work is the Application resource: a source (repository, path, target revision) and a destination (cluster, namespace). Three components do the work — the repo-server renders manifests through Helm, Kustomize, Jsonnet or a config management plugin; the application-controller diffs the rendered output against live cluster state and reconciles; the API server backs the CLI, the web UI, SSO and RBAC. Sync waves and resource hooks order what would otherwise be a single unordered apply, and health assessment — built in for common kinds, extensible with Lua — decides whether a sync actually succeeded.
Around that sit the pieces that make Argo work beyond one team: AppProjects to constrain which repositories, clusters and resource kinds a tenant may touch; ApplicationSets with list, Git, cluster and matrix generators to template hundreds of Applications from one definition; and Argo Rollouts, which replaces the Deployment controller with a Rollout resource that runs canary or blue-green steps and gates promotion on AnalysisRuns against Prometheus, Datadog or a web endpoint.
Push-based deployment gave every CI job cluster-admin credentials and no memory of what it had done. GitOps inverts that: the controller lives in the cluster, pulls from Git, and reconciles continuously — so credentials stay inside the cluster boundary, and manual changes are detected instead of quietly persisting until the next incident.
Argo CD is the most widely deployed implementation of that model, and it is increasingly the interface engineers use to see what is actually running. That makes the skill less about installing a controller and more about the design questions underneath it: repository topology, how environments are promoted, how many Applications a cluster should carry, and where the boundary sits between what Git owns and what a controller or operator owns at runtime.
The operational depth matters too. Teams routinely hit sync loops caused by mutating webhooks, drift they cannot explain because a field is server-populated, secrets that cannot go in Git, and repo-server memory exhaustion at a few hundred Applications. Those are the problems that separate a working demo from a platform other teams can rely on.
The model before the tool. Why a controller inside the cluster beats a pipeline with cluster credentials, what continuous reconciliation actually guarantees, and how Argo CD, Rollouts, Workflows and Events divide the problem between them.
Topics: Push pipelines vs pull reconciliation · The four GitOps principles · Argo CD, Rollouts, Workflows and Events compared · Where Argo CD fits against Flux · What GitOps does not solve · Repository topology options
The three components and what each is responsible for. API server, repo-server and application-controller, plus Redis and the resource cache — then installing in both non-HA and HA form and understanding what the manifests actually created.
Topics: API server, repo-server, application-controller · Redis and the resource cache · Non-HA vs HA install manifests · Installing with Helm and with kustomize · argocd CLI and login · Declarative setup vs the UI
The core object and every knob on it. Source, destination and syncPolicy; automated sync with prune and selfHeal; the difference between OutOfSync and Degraded; and the sync options that exist because Kubernetes apply semantics are not simple.
Topics: Application spec: source, destination, project · Manual vs automated sync, prune and selfHeal · Sync status vs health status · Sync options: ServerSideApply, Replace, CreateNamespace · ignoreDifferences and known drift · App-of-apps pattern · Resource tracking methods
How repo-server turns a repository into YAML, and why the same chart behaves differently under Argo CD than under helm install. Values files, parameter overrides, multi-source Applications, and writing a config management plugin when nothing fits.
Topics: Helm rendering under Argo CD vs helm install · Values files, parameters and valueFiles from another source · Kustomize overlays and image overrides · Multi-source Applications · Jsonnet and directory sources · Config management plugins · Private repository credentials and known hosts
Making one Argo CD instance safe for many teams. AppProject as a blast-radius boundary, RBAC policy syntax and role mapping, SSO through OIDC or Dex, and the difference between Argo CD RBAC and Kubernetes RBAC.
Topics: AppProject: source, destination and resource whitelists · Project roles and scoped tokens · RBAC policy.csv syntax · OIDC and Dex integration · Group-to-role mapping · Argo CD RBAC vs Kubernetes RBAC · Cluster registration and scoped credentials
One resource that generates many Applications. The generator types and when each is right, template patching, progressive syncs across a fleet, and the operational limits you meet as Application counts grow.
Topics: List and cluster generators · Git file and directory generators · Matrix and merge generators · Pull request generator for preview environments · Template patching and goTemplate · Progressive syncs · Scaling limits: repo-server memory, sharding, reconciliation timeout
Replacing the Deployment controller when a rolling update is not enough. The Rollout resource, canary and blue-green strategies, traffic shaping through an ingress or mesh, and gating promotion on AnalysisRuns instead of on someone watching a dashboard.
Topics: Rollout resource vs Deployment · Canary steps, pause and setWeight · Blue-green with preview and active services · Traffic management via NGINX, Istio, SMI and Gateway API · AnalysisTemplate and AnalysisRun · Metric providers: Prometheus, Datadog, web, job · Automatic rollback and abort · kubectl argo rollouts plugin
The pipeline half of the family. Workflow and WorkflowTemplate structure, DAG and steps execution, artifacts and parameters, then Events — EventSource, Sensor and trigger — for driving workflows from Git, webhooks, queues or schedules.
Topics: Workflow spec: templates, steps and DAG · Artifacts, parameters and the artifact repository · WorkflowTemplate and ClusterWorkflowTemplate · CronWorkflow · Workflow controller and executor · EventSource, Sensor and triggers · Chaining Events to Workflows to Argo CD
Everything that decides whether Argo CD survives its second year. Secret strategies, drift and self-heal behaviour under pressure, notifications, backup and restore, controller sharding, and the upgrade path across CRD changes.
Topics: Sealed Secrets, External Secrets and SOPS compared · Drift detection, selfHeal and manual override · Argo CD Notifications: triggers and templates · Backup and restore with argocd admin export · Controller sharding and performance tuning · Disaster recovery of the Argo CD instance itself · Upgrades and CRD migration · Metrics and alerting on sync failure
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Argo CD, then move its own configuration into Git so the controller manages itself and survives a full namespace delete.
Enable automated sync with selfHeal, then edit live resources with kubectl and observe exactly what reconciles, what does not, and why.
Build AppProjects, RBAC policy and SSO group mapping so each team can deploy only into its own namespace from its own repository.
Use a matrix generator over clusters and Git directories to produce per-cluster Applications, then roll a change through with progressive syncs.
Convert a Deployment to a Rollout with weighted canary steps and a Prometheus AnalysisTemplate, then deploy a deliberately broken build.
Destroy the Argo CD installation and its cluster state, then restore the entire environment from Git and an export with a documented runbook.
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.
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.
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.
| 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.