Skip to content

Helm

Role in the Platform

Helm packages Kubernetes Deployments, Services, ConfigMaps, Secret references, and ServiceMonitors into versioned charts. WxCDI keeps reusable chart templates separate from environment-specific values so the same application can be deployed consistently across clusters.

Chart Anatomy

Path Purpose
Chart.yaml Chart metadata and semantic chart version
values.yaml Safe defaults consumed by templates
templates/ Kubernetes resource templates
helm_cfg.yaml Integration metadata for the managed Kubed build/deployment flow
cfg-templates/ Templates for values populated from approved secret/config systems
example-configs/ Non-sensitive examples for validation and onboarding

Chart.yaml contains both version and appVersion. Increment the chart version whenever chart content changes. Update appVersion when it is used to describe a new application release; the deployed image tag remains controlled by environment values.

Chart and Configuration Flow

sequenceDiagram
    participant Dev as Engineer
    participant Chart as Chart Repository
    participant Registry as Chart Registry
    participant Config as Environment Config Repository
    participant Argo as WBX3 / Argo
    participant K8s as Kubernetes

    Dev->>Chart: Update templates and chart version
    Chart->>Registry: Validate and publish approved chart
    Dev->>Config: Update image tag or Helm values
    Config->>Argo: Merge approved configuration
    Argo->>Registry: Resolve chart version
    Argo->>K8s: Render and reconcile resources

Application values for WxCDI are managed in the wxcdi-kubed-configs configuration tree. Do not copy production credentials into a values file; charts should reference Keeper-backed secret material through the approved integration.

Local Validation

From the chart directory:

helm lint .
helm template <release-name> . -f <non-secret-values-file>

Review the rendered output for:

  • expected namespace, image repository, tag, and pull policy;
  • resource requests/limits and probes;
  • Service selectors and ports;
  • ConfigMap/Secret names and mounts;
  • ServiceMonitor labels, ports, and scrape path;
  • cluster-specific values accidentally embedded in the chart.

If the chart uses the managed helm cfg build workflow, follow its repository instructions and ensure generated secret-bearing files are ignored and removed after validation.

Release Checklist

  1. Identify whether the change belongs in the chart or environment values.
  2. Update the chart version for chart changes.
  3. Run linting and render with representative non-secret values.
  4. Review the resulting Kubernetes diff and rollback version.
  5. Publish through the chart pipeline.
  6. Update the environment configuration to the intended chart/image version.
  7. Verify rollout, service health, telemetry freshness, and alerts in both production clusters.

Common Problems

Problem Likely cause
Pipeline reports existing version Chart.yaml version was not incremented
Resource renders but has no endpoints Service selector does not match pod labels
Prometheus target missing ServiceMonitor labels/port do not match Prometheus discovery
Pod cannot mount configuration Name or key mismatch between template and values
One cluster differs unexpectedly Configuration was updated in only one regional path

See Kubernetes for runtime checks and Deployment for the full change workflow.