Fail icon
Status icon
Docker icon
OutputValues icon
Set icon
If icon
Get icon
Log icon
Pause icon
Patch icon
Rollback icon
SlackIncomingWebhook icon
Schedule icon

Recover a Helm release stuck pending after an interrupted upgrade

Recover a pending Helm upgrade or rollback after a grace window, explicit approval and a cooperative release fence. Verify the restored revision and manifest.

Categories
Infrastructure

A cancelled runner can leave Helm pending-upgrade. Later upgrades refuse another operation in progress.

Safety

Rollback can rerun hooks and change workloads. Confirm data compatibility first.

Guard What it stops
Stable revision/status/time plus KV grace A brief pending window becoming a recovery
Explicit approval and stopped-runner confirmation Cancelling an active deployment
Conditional ConfigMap fence plus fresh reads Cooperating writers and stale approval
Explicit deployed baseline Rolling back into a failed previous attempt

How it works

helm.Status reads one release. A cluster-scoped KV key remembers its revision, status and deployment time. Only unchanged pending-upgrade or pending-rollback observations aged at least grace_seconds qualify. Future observations reset; malformed or oversized records fail.

Native Kubernetes Get reads at most history_window exact Helm Secret names. Their labels select the newest deployed baseline, checked again with helm.Status. Dry-run logs the proposal. Write mode pauses for both confirmations, conditionally acquires a dedicated ConfigMap and re-reads the release and baseline under that fence. helm.Rollback runs once. A final Status must be deployed at initial revision + 1 with the approved manifest. Only then is the fence released.

What you get

A proposal, native outputs and a failed execution when recovery is refused or incomplete. No write retries.

Who it's for

Platform teams with a shared release mutex and a data-compatible previous chart.

Why orchestrate this with Kestra

KV carries the observation across runs. Pause records the recovery decision. Native tasks keep the selected revision, conditional fence changes and verification in one execution. Flow concurrency queues overlapping runs of this flow only.

Tested end to end

Kestra 2.0.6 and 2.0.5 with Helm 4.3.0 and Kubernetes 1.31.5. A real upgrade was killed during a sleeping hook; the next CLI upgrade was blocked. Recovery restored deployed status and the next upgrade succeeded. A fresh cluster reproduced revision 2 to 3 recovery, preserving 2 payload values and an unrelated release. Declined approval did not write. Refused rollback failed. Stale approval failed before rollback. A killed native rollback left pending-rollback and a held fence; a fresh run recovered after manual reconciliation. Two servers contending for one fence produced one rollback.

Prerequisites

Helm Secret storage, a reachable API, Docker workers and the Helm, Kubernetes and Slack plugins. Read access needs Secret get/list. Rollback needs Secret create/update/delete plus the verbs required by the chart and its hooks. Fence get/patch is required. Helm may prune old history at its default retention limit.

Secrets

K8S_MASTER_URL, K8S_CA_CERT (base64 CA), K8S_TOKEN and SLACK_WEBHOOK_URL. The token input is SECRET.

Inputs

release_name/release_namespace select one target. Grace defaults to 1800 seconds, history lookback to 20 (maximum 100). Defaults are dry_run: true, auto_remediate: false. docker_network defaults to bridge.

Quick start

  1. Provision a ConfigMap named helm-recovery-<release> in the release namespace. Set annotations helm-recovery-release: <release> and helm-recovery-holder: "". Every release writer must acquire it conditionally and hold it through its operation.
  2. Set secrets and run twice across the grace interval in dry-run mode.
  3. Stop the original runner, inspect hook effects and enable write mode. Resume with both BOOL confirmations true.
  4. After failure or kill, inspect the actual release and any running client. Clear only the confirmed owner's holder conditionally, then start a new observation. Never blindly retry the Rollback task.

How to extend

Add a service smoke test before releasing the fence. Limits: no fence expiry, no protection from writers ignoring the contract and no reversal of external hook/data effects. Pending-install and failed states are spared. The plugin reads the full release manifest; deployed status is not application-health proof. The disabled schedule forces safe mode.

Links

This blueprint was created by zkasuran.

See How

New to Kestra?

Use blueprints to kickstart your first workflows.