Package and template your manifests with Helm, then ship safely with progressive delivery — rolling updates, blue-green, and canary releases — plus a look at extending Kubernetes with CRDs.
Why: a real app is a dozen manifests that differ only by environment — repetitive and error-prone to maintain by hand. Helm is the package manager for Kubernetes: a "chart" bundles templated manifests, and a values file fills in the per-environment differences. Install, upgrade, and roll back the whole app as one unit.
mychart/
├── Chart.yaml # name + version of the chart
├── values.yaml # default values (image, replicas, ...)
└── templates/
├── deployment.yaml # manifests with {{ }} placeholders
└── service.yamlWhy: a Helm template is a normal manifest with {{ }} placeholders pulled from values.yaml. One template renders differently per environment just by swapping values — three replicas in prod, one in dev, a different image tag each — without copying the file.
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: app
image: "{{ .Values.image.repo }}:{{ .Values.image.tag }}"Why: helm install renders the chart and applies it as one release; helm upgrade rolls out a change; helm rollback reverts to a previous release in one command. Override any value at the command line with --set, or point at a per-environment values file with -f.
Install the chart as a release named "shop"
helm install shop ./mychart -f values-prod.yamlRoll out a new image tag
helm upgrade shop ./mychart --set image.tag=1.4.0Something broke — revert to the previous release
helm rollback shopWhy: a rolling update (the Deployment default) is the simplest progressive rollout, but two others reduce risk further. Blue-green runs the new version (green) alongside the old (blue) and flips all traffic at once by repointing the Service — instant rollback by flipping back. Canary sends a small slice of traffic to the new version first, watches it, then ramps up. Both are usually driven by a tool like Argo Rollouts or Flagger.
# Blue-green by hand: the Service selector chooses which version is live.
# Flip "version: blue" to "version: green" to cut traffic over instantly.
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
version: blue # change to green to switch all traffic
ports:
- port: 80
targetPort: 80Why: a Custom Resource Definition (CRD) teaches the cluster a new kind of object — beyond the built-in Pod, Service, and so on. Paired with a controller (an "operator") that acts on it, CRDs are how tools like cert-manager and Prometheus add their own resources you manage with plain kubectl apply. You rarely write one early, but you use them constantly.
# After a CRD is installed, you create its custom kind like any resource:
apiVersion: cert-manager.io/v1
kind: Certificate # a custom kind added by a CRD
metadata:
name: shop-tls
spec:
secretName: shop-tls
dnsNames:
- shop.example.com
issuerRef:
name: letsencrypt
kind: ClusterIssuer