Free — no signup required

Introduction: Escaping "YAML Hell

2 min read

The Problem with Plain Kubernetes

By now, you know that deploying an application on Kubernetes rarely involves just one file.

To deploy a standard application like WordPress, you might need:
1. A Deployment for the WordPress web server Pods.
2. A Service to expose those Pods internally.
3. A StatefulSet for the MySQL database.
4. A Headless Service for the database.
5. Secrets to store the database passwords.
6. PersistentVolumeClaims for database storage.
7. An Ingress rule to expose the website to the internet.

That's 7+ separate YAML files just for one application. Now imagine you have 50 applications. And imagine you need to deploy them slightly differently for "staging" versus "production" — different replica counts, different resource limits, different hostnames, different image tags.

Managing hundreds of individual YAML files, manually changing image tags and replica counts for different environments, is often called "YAML Hell." The problems compound quickly: files drift out of sync, copy-paste errors creep in, and there's no reliable way to roll back a bad change across a set of related files.

Enter Helm

Helm is the solution to this problem. It is the package manager for Kubernetes, similar to how apt or yum manages packages on Linux, or brew on macOS. Just as those tools let you install, upgrade, and remove software with a single command, Helm does the same for Kubernetes applications.

Helm lets you bundle all those related YAML files into a single logical package called a Chart, parametrize them so they are reusable across environments, and deploy or upgrade the entire application with a single command. It also tracks what you've deployed and lets you roll back to a previous state if something goes wrong.

The key insight is that most Kubernetes applications share the same structural patterns — a Deployment, a Service, maybe an Ingress — but differ only in their configuration details. Helm separates the structure (the Chart) from the configuration (the Values), letting you reuse the structure while swapping in environment-specific configuration.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free