Helm + K8s Distributions
25 min
Day 70: Helm charts, values, templating
Helm: a package manager for Kubernetes manifests
Applying dozens of raw YAML files by hand doesn't scale, and copy-pasting manifests between environments (staging vs prod) invites drift. A Helm chart packages a set of templated manifests plus a values.yaml of configurable parameters — the same app deployed to different environments becomes one chart plus different values files, not duplicated YAML.
A templated Deployment (Go template syntax)
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-api
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: api
image: '{{ .Values.image.repository }}:{{ .Values.image.tag }}'
resources: {{ toYaml .Values.resources | nindent 12 }}values.yaml — what actually changes per environment
replicaCount: 3
image:
repository: myregistry/api
tag: '1.4.0'
resources:
requests: { cpu: 250m, memory: 256Mi }
limits: { cpu: 500m, memory: 512Mi }Installing with environment-specific overrides
helm install myapp ./chart -f values-staging.yaml
helm upgrade myapp ./chart -f values-prod.yaml --set replicaCount=5Key terms
- Helm chart
- A package of templated Kubernetes manifests plus configurable values.
- values.yaml
- The configuration file supplying parameters into a chart's templates.
Why is a single Helm chart with different values files preferable to maintaining separate full YAML manifests per environment?
