Deploying to Multiple Environments (Overview)

Real-world teams rarely deploy straight to a single cluster. You often maintain long-lived environments like staging and production and may spin up temporary clusters for feature testing. Rather than duplicating YAML by hand, we need a repeatable way to share common configuration and apply environment specific changes.

This section highlights popular approaches and when you might choose each.

Kustomize

• Built into kubectl using a base/overlay model
• Overlays patch only the fields that differ per environment
• Simple to start, but patching arrays or multiline strings can be painful

Example code lives in 12-deploying-to-multiple-environments/kustomize.

Helm

• Packages resources into charts with templated variables
• Each environment supplies its own values.yaml
• Supports hooks for ordering operations (like migrations)
• Adds packaging overhead and CRD management can be tricky

See the chart in helm.

Kluctl

• Combines templating with a GitOps style workflow
• Requires less boilerplate than Helm and can reuse existing configs
• Provides diffing and an optional controller for continuous deployment

Start with kluctl-single-service then explore the full kluctl project.

Other Tools

• Simple scripts using envsubst or yq
• Timoni packages applications with CUE
• Terraform and Pulumi providers for Kubernetes
• cdk8s enables generating manifests in languages like TypeScript or Python

In the next lessons we'll dive into the Kustomize, Helm, and Kluctl examples to deploy the demo application to multiple clusters.