Skip to main content

Rendering and Helm

Stage 5 · Payload Integration

Managing duplicate Kubernetes YAML manifests across development, staging, and production environments leads to inevitable configuration drift.

Helm packages Kubernetes manifests into reusable charts, separating common structural templates from environment-specific configuration values.

Two outputs of a Helm operation​

Diagram DL-01 — Helm renders plain Kubernetes YAML for the API server and stores revision metadata in a cluster Secret.

When running helm install or helm upgrade, Helm produces two distinct artifacts:

  • 1. Rendered Kubernetes manifests: Standard YAML definitions (Deployments, Services, ConfigMaps). The Kubernetes API server accepts these objects without knowing Helm rendered them.
  • 2. Release record: A compressed, base64-encoded Secret stored in the application namespace tracking release history, chart versions, and values for rollback auditing.

The discipline of dry-run rendering​

Chart templates can generate unexpected YAML through misconfigured indentation or conditional evaluation. Always render and inspect manifests locally before applying to a live cluster:

  • Render templates locally: 
    helm template apollo-dev ./stages/stage5/helm/apollo11 \
      -f ./stages/stage5/helm/apollo11/values-dev.yaml
  • Audit image tags in output: 
    helm template apollo-dev ./stages/stage5/helm/apollo11 \
      -f ./stages/stage5/helm/apollo11/values-dev.yaml | grep "image:"

Core template mechanics​

  • Value substitution: Injecting values dynamically from values files: 
    replicas: {{ .Values.replicas }}
  • Conditional inclusion: Enabling objects only in production environments: 
    {{- if .Values.pdb.enabled }}
    apiVersion: policy/v1
    kind: PodDisruptionBudget
    {{- end }}
  • Whitespace control (nindent): Ensures multiline blocks format with valid YAML indentation: 
    resources:
      {{- toYaml .Values.resources | nindent 4 }}

Evidence and limits​

  • 1. Template validation: Confirm templates render without syntax errors: 
    helm lint ./stages/stage5/helm/apollo11
  • 2. Release revision history: Inspect deployed release versions: 
    helm history apollo-airlines -n apollo-airlines-apps
  • 3. Active release status: 
    helm status apollo-airlines -n apollo-airlines-apps
  • 4. Rollback execution: Revert to a known good revision: 
    helm rollback apollo-airlines 2 -n apollo-airlines-apps