Private corporate batches, live online cohorts and 1-on-1 mentoring in packaging, templating, releasing and upgrading Kubernetes applications with Helm — 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 Helm as a release lifecycle rather than a templating exercise — what Helm stores between upgrades, how the three-way merge decides what changes, when a hook fires and what happens when it fails, and why an upgrade can silently drop a field that someone edited by hand. Charts are written live, deliberately broken with template errors and bad upgrades, then diagnosed with helm template, helm get manifest and helm diff, so attendees leave able to debug someone else's chart, not just author their own.
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 Helm that means a trainer who has run it in production — packaging, templating, releasing and upgrading Kubernetes applications with Helm — 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 Helm batchHelm is the package manager for Kubernetes. A chart is a versioned bundle of templated manifests plus a values file that parameterises them; installing a chart produces a release, and Helm records the rendered state of that release in a Secret inside the cluster so it can upgrade, roll back or uninstall it later as one unit. That release history is the part that distinguishes Helm from simply applying YAML — it turns a pile of manifests into something with a lifecycle.
The templating layer is Go templates with the Sprig function library, plus Helm's own additions: the .Values, .Release, .Chart and .Capabilities objects, named templates in _helpers.tpl, and the include and tpl functions that make partials composable. Charts declare dependencies on other charts in Chart.yaml, so an application chart can pull in a database or a cache subchart and override its values from the parent. Library charts let an organisation share template logic without shipping deployable resources.
Operationally, Helm has become the distribution format for Kubernetes software. Vendors and open-source projects publish charts to HTTP repositories or, increasingly, to OCI registries alongside container images, with provenance files for signature verification. Argo CD and Flux both render Helm charts as part of GitOps delivery, and helm template is routinely used to produce plain manifests for policy scanning or diffing before anything reaches a cluster. Knowing how the three-way strategic merge patch behaves during an upgrade, and where Helm's hooks fire, is what separates a chart that survives production from one that works once.
Every team running Kubernetes eventually confronts the same problem: the same application has to be deployed to several environments and several clusters, differing only in replicas, resource limits, hostnames and secrets, and copying YAML per environment stops scaling almost immediately. Helm is the answer most organisations reach for, which makes chart literacy a baseline expectation rather than a specialisation.
It is also how third-party software arrives. Ingress controllers, monitoring stacks, databases, service meshes and operators are nearly all distributed as charts, so an engineer who cannot read a chart cannot audit what is about to run in their cluster — which values are exposed, which security context is set, what RBAC it grants itself, and what the upgrade will actually change. That is a security review problem as much as a deployment one.
The GitOps shift raised the bar again. Argo CD and Flux render charts on the way in, which means chart authoring quality now determines whether declarative delivery is reliable or fragile. Charts that misuse hooks, generate random values on every render, or rely on lookup functions break sync loops in ways that are hard to debug. Teams increasingly need someone who can write charts that render deterministically, diff cleanly and upgrade safely — not just someone who can run helm install.
Why templated packaging exists, and what Helm actually adds over kubectl apply. The chart, release and revision model; where release state is stored and what it contains; the anatomy of a chart directory; and the client-only architecture of Helm 3 with no Tiller and namespace-scoped releases.
Topics: The problem: environment drift and copied YAML · Charts, releases, revisions and release state storage · Helm 3 architecture — client-only, no Tiller, namespaced releases · Chart directory structure: Chart.yaml, values.yaml, templates, charts, crds · Chart versions versus appVersion · helm install, list, status, get and uninstall · Reading what a release actually deployed
Using other people's charts safely. Repositories and search, pinning versions, the layering order of values files and --set overrides, and the upgrade behaviour that determines whether a release survives. Rollbacks, atomic upgrades, wait and timeout flags, and the diagnostic commands that show what is really being applied.
Topics: Repositories: helm repo add, update, search and version pinning · Values precedence — chart defaults, values files, --set and --set-file · helm upgrade, --install, --atomic, --wait and --timeout · Release history, helm rollback and revision management · helm template and helm get manifest for inspecting output · helm diff and previewing an upgrade before it runs · Three-way strategic merge and what happens to hand-edited fields · Uninstall, --keep-history and orphaned resources
Writing a chart properly rather than editing helm create output until it works. Chart.yaml metadata, template files and the resources that belong in each, values.yaml as a public interface rather than a dumping ground, and schema validation so bad input fails at render time instead of in the cluster.
Topics: helm create and what to keep, change or delete from the scaffold · Chart.yaml metadata, versioning and annotations · Templating Deployments, Services, Ingress, ConfigMaps and Secrets · values.yaml design — defaults, structure and naming as a public interface · values.schema.json validation · NOTES.txt and .helmignore · helm lint, helm template and the render-debug loop · Chart documentation and keeping values documented
The part where charts go wrong. Go template syntax and evaluation, the built-in objects and what each contains, Sprig functions worth knowing, named templates and helpers, and the whitespace control that decides whether the output is valid YAML. Determinism is treated as a requirement: random and lookup functions are covered specifically so their consequences are understood.
Topics: Go template syntax, actions, pipelines and evaluation order · Built-in objects: .Values, .Release, .Chart, .Capabilities, .Files · Conditionals, with, range and variable scoping · Named templates, define, include versus template, and _helpers.tpl · The tpl function and rendering values as templates · Sprig functions: default, required, quote, toYaml, indent, nindent · Whitespace control and producing valid YAML output · Non-determinism: randAlphaNum, lookup, and why they break GitOps
Composing charts rather than duplicating them. Declaring dependencies in Chart.yaml, the lock file and update workflow, how parent charts override child values and where global values apply. Then library charts for sharing template logic across an organisation, and the conditions and tags that make dependencies optional.
Topics: Declaring dependencies in Chart.yaml and Chart.lock · helm dependency update, build and the charts directory · Overriding subchart values from a parent · Global values and their scope across subcharts · Conditions and tags for optional dependencies · Library charts: type library, shared helpers and no rendered resources · Aliases and using the same subchart twice · Umbrella charts versus separate releases — the honest trade-off
The lifecycle extensions and their sharp edges. Hooks — when each fires, weights, and the deletion policies that determine whether a failed hook blocks every future upgrade. Chart tests as executable verification. And CRD handling, where Helm's deliberate limitations catch teams out during upgrades.
Topics: Hook types: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete · Hook weights and execution ordering · Hook deletion policies and recovering from a failed hook · Migration and initialisation jobs done safely · Chart tests with helm test and the test hook · CRDs: the crds directory versus templating them, and upgrade limitations · Resource policy annotations and keeping resources on uninstall · Common hook anti-patterns and what to do instead
Getting charts into production responsibly. Packaging and publishing to HTTP repositories and OCI registries, provenance files and signature verification, secret handling that does not put credentials in values files, then Helm inside delivery — CI pipelines, and Argo CD and Flux rendering charts as part of GitOps.
Topics: helm package, helm repo index and hosting a chart repository · OCI registries: helm push, pull and versioning alongside images · Provenance files, helm sign and helm verify · Secrets: external secret operators, SOPS and why values files are the wrong place · Helm in CI: lint, template, policy scan, package, publish · Argo CD with Helm — value sources, rendering and drift · Flux HelmRelease and HelmRepository resources · Diffing and progressive rollout of chart changes across environments
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall a release, edit a field directly in the cluster, upgrade again, and use helm get manifest and helm diff to explain exactly which change survived and why.
Write a chart from an empty directory for a real application, add a values schema, and prove that invalid input fails before a single resource is applied.
Take a chart that uses random values and lookups, rewrite it to render deterministically, and verify by rendering it ten times and diffing the output.
Build a parent chart with two subcharts, override every child value from the parent, and factor shared template logic into a versioned library chart.
Write a pre-upgrade migration hook, make it fail, watch the release wedge, then recover it with the correct deletion policy rather than by deleting the release.
Author, lint, scan, package and sign a chart, publish it to an OCI registry, and deploy it to two environments through Argo CD or Flux with drift reconciliation.
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.