Helm Charts with Python — Core Concepts

What Helm actually does

Kubernetes requires you to define your application as a collection of YAML manifests — Deployments, Services, ConfigMaps, Secrets, and more. For a typical Python web app with a database, you might need 8-12 separate YAML files. Helm is a package manager that bundles these manifests into a chart, adds templating, and provides versioned releases with rollback capability.

Think of Helm as apt or pip, but for Kubernetes deployments.

Anatomy of a Helm chart

A chart has a standard directory structure:

• Chart.yaml — metadata (name, version, description)
• values.yaml — default configuration values users can override
• templates/ — Kubernetes manifests with Go template syntax
• charts/ — dependency sub-charts (like a database chart)

When you run helm install, Helm renders the templates by substituting values, then applies the resulting YAML to your Kubernetes cluster.

Why Python teams care

Python applications destined for Kubernetes need charts. Common scenarios:

• A FastAPI service with horizontal pod autoscaling, health probes, and environment-specific configs
• A Celery worker deployment that needs separate Deployment objects for workers and beat scheduler
• A data pipeline combining Airflow, Redis, and PostgreSQL — each as a sub-chart dependency

Without Helm, every environment (dev, staging, production) requires manually editing YAML files. With Helm, you override values: helm install myapp ./chart --set replicas=3 --set image.tag=v2.1.

Python tooling for Helm

Several Python approaches exist for working with Helm:

Scripting Helm operations — Python subprocess calls to the Helm CLI, useful for CI/CD pipelines. Libraries like pyhelm (now somewhat dated) and python-on-whales (Docker-focused but composable) handle orchestration.

Generating charts programmatically — When you manage dozens of microservices, Python scripts can generate Helm charts from a shared template, ensuring consistency. Companies like Yelp and Lyft have built internal tools that produce charts from service definitions.

CDK8s with Python — AWS’s CDK for Kubernetes lets you define Kubernetes resources (and by extension, Helm-compatible manifests) using Python classes instead of YAML. This brings type checking and IDE support to chart authoring.

Common misconception

Many developers think Helm is only for complex enterprise deployments. In practice, even a single Python service benefits from a Helm chart because it makes deployments repeatable, configurable, and rollback-safe. The chart becomes documentation of everything your service needs to run.

Values and templating

The power of Helm lies in values.yaml and templates. A Python team’s values file typically includes:

• Image configuration — registry, repository, tag, pull policy
• Resource limits — CPU and memory requests/limits for the Python process
• Environment variables — database URLs, API keys (referenced from Secrets)
• Scaling — replica count, autoscaling thresholds
• Probes — liveness and readiness endpoints (often /health in Python frameworks)

Templates reference these values with Go’s {{ .Values.image.tag }} syntax. This separation means the same chart works across environments by swapping values files.

Lifecycle and releases

Helm tracks each deployment as a release with a revision history. This enables:

• helm upgrade — deploy a new version
• helm rollback — revert to a previous release
• helm history — see all past deployments with timestamps
• helm diff (plugin) — preview changes before applying

For Python teams practicing continuous deployment, Helm integrates with GitHub Actions, GitLab CI, and ArgoCD to automate the upgrade cycle.

The one thing to remember: Helm charts give Python services a versioned, configurable, rollback-safe deployment package — turning Kubernetes YAML sprawl into a managed workflow.