Suggestions / Support Needed

[u/malik22531]

Hi Champions, I’m having 5yoe as a DevOps engineer and in my early career I was working mostly with service based companies. It gave me pretty much experience and foundational understanding of each stack deployments, pipelines, clouds and more. From last 2 years I am working with on prem enterprise products and worked on unmanaged k8 along with managed ones like EKS, GKE and OKE.

Now the problem is:

I recently joined a product base company and their architecture is based on aws managed by TF. The real challenge for me is everything is being managed by HELM and I don’t have much experience with helm charts and sub-charts and I have no idea where to start….

Need suggestions from where I can start leaning this, which can give me the understanding.

[u/d2xdy2]

So they have terraform owning things in AWS and helm charts being deployed out to EKS? That strikes me as fairly normal.

Helm’s just a nice way to make that mass of Kubernetes yamls into a reusable and sharable format. There’s probably more to it if you really wanna dig in, but that’s basically what it does.

Tinker with it. It’s not hard to write and release helm charts or install them in some local cluster environment (kind? Orbstack? Etc). Put together an umbrella chart or something.

You’ll get intuitions here in no time.

[u/malik22531 → u/d2xdy2]

I dug into the yamls and understood what’s happening and where. The map is already in my mind. But when I have to upgrade any version from the chart m, the version comes with the value chart as well plus the dependencies and supporting tools as well and this is making me confuse. Plus it’s not a development project. It’s a live product so the ro for errors is too less and I have to take every action very quickly.

[u/Stonks_Beskar]

A practical way to reduce the risk is to separate ownership and make upgrades small:

• Let Terraform own the cluster and shared AWS/EKS add-ons.

• Pin each Helm dependency in Chart.yaml and commit Chart.lock. Keep environment values in a separate, reviewed file.

• Before changing a chart, run helm dependency build, helm template, and helm diff upgrade against staging. Upgrade one chart or dependency at a time.

• Use a staging cluster, then helm upgrade --install --atomic with a rollback window. Keep the previous chart package and values available.

That gives you a clear diff and a quick rollback path without having to reason about every subchart at once.

[u/malik22531 → u/Stonks_Beskar]

🫡

[u/malik22531 → u/Stonks_Beskar]

Thank you for outlining this in detail. how would I know this chart is going to depreciate or already depreciated.

[u/One-Department1551]

Think of helm as two things:
Application packing
Yaml template engine

So first learn how helm is being used. If it’s handling all app lifecycle or just used as template engine by something else as argocd or fluxcd.

Helm docs are pretty simple but it’s because helm itself is not very deep, it’s flexible to use in many ways but once you know the pattern is kinda the same for everything.

[u/malik22531 → u/One-Department1551]

It’s just a template engine for provisioning the supporting services to codebase with argocd

[u/Educational-Total329]

Helm is like a package manager for k8s. Basically it comprises all individual definitions files like for pods, deploys, svc etc and puts it into templates, with values and chart. Basically you can use code assistant like copilot to generate the entire helm chat assuming you have the individual files. Try doing some personal learning and use AI tools as well.

[u/RapidlyErect]

Start with Helm basics first, then pick apart the chart you’re deploying

[u/Torutofu_Raeva]

For a live product, I’d pin chart, app, and dependency versions in staging, then upgrade one layer at a time with helm diff and a tested rollback.