helm

Helm Provider

The Helm Provider extends the platform-health server to enable monitoring the status of Helm releases. It does this by interacting with the Helm API to check the status of the specified Helm release.

Usage

Once the Helm Provider is configured, any query to the platform health server will trigger validation of the configured Helm release(s). The server will attempt to check the status of each Helm release, and it will report each release as "healthy" if the Helm release exists and is in deployed state, or "unhealthy" otherwise.

Configuration

The Helm Provider is configured through the platform-health server's configuration file. Each instance is defined with its name as the YAML key under components.

• type (required): Must be helm.
• timeout (optional): Per-instance timeout override.
• spec: Provider-specific configuration:
  • release (required): The name of the Helm release to monitor.
  • namespace (required): The namespace of the Helm release to monitor.
  • context (optional): Kubeconfig context to use.
• checks: A list of CEL expressions for custom health validation. Each check has:
  • check (required): A CEL expression that must evaluate to true for the release to be healthy.
  • message (optional): Custom error message when the check fails.

For queries to succeed, the platform-health server must be run in a context with appropriate access privileges to list and get the Secret resources that Helm uses internally to track releases. Running "in-cluster", this means an appropriate service account, role and role binding must be configured.

CEL Check Context

The following variables are available in CEL expressions:

Release Properties

• release.Name - Release name
• release.Namespace - Release namespace
• release.Revision - Release revision number (int)
• release.Status - Release status (string: "deployed", "failed", etc.)
• release.FirstDeployed - First deployment timestamp
• release.LastDeployed - Last deployment timestamp
• release.Deleted - Deletion timestamp
• release.Description - Release description
• release.Notes - Chart NOTES.txt content
• release.Manifest - Parsed manifest resources (list of maps, one per YAML document)
• release.Labels - Release labels (map)
• release.Config - User-provided value overrides (map)
• release.ApplyMethod - Apply strategy used for the release: "csa" (client-side apply) or "ssa" (server-side apply). Defaults to "csa" for pre-v4 releases.
• release.Hooks - List of lifecycle hooks (list of maps). Each hook has:
  • Name - Hook resource name (string)
  • Kind - Kubernetes kind, e.g. "Job" (string)
  • Path - Chart-relative template path (string)
  • Events - When the hook fires (list of strings: "pre-install", "post-install", "pre-upgrade", "post-upgrade", "pre-delete", "post-delete", "pre-rollback", "post-rollback", "test")
  • Weight - Execution order among same-event hooks (int)
  • DeletePolicies - Cleanup policies (list of strings: "hook-succeeded", "hook-failed", "before-hook-creation")
  • OutputLogPolicies - Log capture policies (list of strings: "hook-succeeded", "hook-failed")
  • LastRun - Last execution result (map):
    • StartedAt - Execution start timestamp
    • CompletedAt - Execution completion timestamp
    • Phase - Result: "" (never run), "Unknown", "Running", "Succeeded", "Failed"

Chart Properties

• chart.Name - Chart name
• chart.Version - Chart version
• chart.AppVersion - Application version
• chart.Description - Chart description
• chart.Deprecated - Whether chart is deprecated (bool)
• chart.KubeVersion - Required Kubernetes version
• chart.Type - Chart type
• chart.Annotations - Chart annotations (map)
• chart.Values - Chart default values (map)

Examples

Basic Helm Release Check

components:
  example:
    type: helm
    timeout: 5s
    spec:
      release: example-chart
      namespace: example-namespace

In this example, the Helm Provider will check the status of the Helm release named "example-chart" in the "example-namespace" namespace, and it will wait for 5s before timing out.

Helm Release with CEL Checks

components:
  my-app:
    type: helm
    timeout: 10s
    spec:
      release: my-app
      namespace: production
    checks:
      - check: "release.Revision >= 2"
        message: "Release must have at least one upgrade"
      - check: "!chart.Deprecated"
        message: "Chart is deprecated"
      - check: "'team' in release.Labels && 'env' in release.Labels"
        message: "Release must have team and env labels"
      - check: "release.Config['replicas'] >= 3"
        message: "Production must have at least 3 replicas"

This example validates that:

• The release has been upgraded at least once
• The chart is not deprecated
• Required labels are present
• The replica count meets production requirements

Hook Validation

components:
  my-app:
    type: helm
    spec:
      release: my-app
      namespace: production
    checks:
      - check: '!release.Hooks.exists(h, h.LastRun.Phase == "Failed")'
        message: "One or more hooks have failed"
      - check: 'release.Hooks.filter(h, h.Events.exists(e, e == "test")).size() > 0'
        message: "Release must have test hooks"
      - check: 'release.ApplyMethod == "ssa"'
        message: "Release must use server-side apply"