Managing Helm Releases

Overview

Once a Helm chart is deployed, PodWarden provides tools for monitoring its health, upgrading chart versions, inspecting the resources it created, and troubleshooting failures. This guide covers day-to-day operations for Helm-based deployments.

Viewing Helm Release Status

Every Helm deployment has a Helm Details tab on the deployment detail page. This tab shows:

Release status — Whether the Helm release is installed, upgrading, or failed
Chart version — The currently deployed chart version
Revision history — Each install or upgrade creates a numbered revision
Values — The merged values currently applied to the release

The deployment overview tab also shows Helm-specific information: the chart name and version badge, and a resource health breakdown.

Resource Health Breakdown

Unlike single-service deployments (which have one pod to monitor), Helm charts often create dozens of Kubernetes resources. PodWarden groups them by type and shows a health summary:

Resource Type	What PodWarden checks
Deployments	Ready replicas vs. desired replicas
StatefulSets	Ready replicas vs. desired replicas
DaemonSets	Desired vs. ready on each node
Services	Existence and endpoint readiness
ConfigMaps / Secrets	Existence
PVCs	Bound status
CRDs	Registration status
Jobs	Completion status

Resources that are not ready are highlighted so you can spot problems quickly.

Cluster-Scoped Resources

Some Helm charts create resources outside the deployment's namespace — ClusterRoles, ClusterRoleBindings, CustomResourceDefinitions, and similar objects. PodWarden tracks these separately under Cluster-Scoped Resources in the Helm Details tab.

This matters because:

Cluster-scoped resources persist after uninstall unless explicitly cleaned up
Multiple Helm releases may share the same CRD (uninstalling one could break another)
ClusterRoles grant permissions across all namespaces

PodWarden warns you about cluster-scoped resources during dry-run and shows them clearly after deployment.

Upgrading Chart Versions

To upgrade a Helm deployment to a newer chart version:

Open the deployment detail page
Go to the Helm Details tab
Click Upgrade Chart Version
Enter the new chart version (or select from available versions)
Review the diff — PodWarden shows what values or resources will change
Click Deploy to apply

The Helm Operator handles the upgrade process: it renders the new chart, applies the diff, and rolls back automatically if the upgrade fails (based on the release's upgrade policy).

Upgrade safety

Dry-run first — Run a dry-run with the new version to see what changes before committing
Revision history — Each upgrade creates a new revision. You can inspect previous revisions in the Helm Details tab.
Automatic rollback — If configured, the Helm Operator rolls back to the previous revision on upgrade failure. Set upgrade.remediation.retries in the HelmRelease spec.

Changing Values

You can update Helm values without changing the chart version:

Open the deployment and go to Settings or Helm Details
Edit values in the form (env_schema fields) or switch to the YAML editor for full control
Click Save and Redeploy

PodWarden updates the HelmRelease CRD with the new values, and the Helm Operator reconciles the release.

Canvas Visualization

Helm deployments appear on the Infrastructure Canvas as a single node with a Helm icon. Expanding the node reveals the child resources created by the chart — deployments, services, statefulsets, and other objects — shown as connected sub-nodes.

This gives you a visual map of everything the Helm chart created, how resources relate to each other, and which ones have health issues.

Troubleshooting

Install Failed

The Helm Operator could not install the chart. Common causes:

Symptom	Likely cause	Fix
`failed to fetch chart`	Chart repo URL is wrong or unreachable from the cluster	Verify the repo URL; check cluster network access
`chart version not found`	The specified version doesn't exist in the repo	Check available versions at the repo URL
`timeout waiting for condition`	Chart resources are taking too long to become ready	Increase `install.timeout` or check resource availability
`rendered manifests contain a resource that already exists`	Another release or manual install created the same resource	Remove the conflicting resource or use a different release name

Check the Helm Operator logs for detailed error messages:

kubectl -n podwarden-system logs deployment/helm-operator --tail=200

Resources Not Ready

The chart installed but some resources are stuck in a non-ready state:

Check the Resource Health Breakdown in the Helm Details tab to identify which resources are not ready
Click on a failing resource to see its events and conditions
Common issues:
- Pending PVCs — No storage class available or insufficient disk space
- ImagePullBackOff — Image doesn't exist or registry requires credentials
- CrashLoopBackOff — Application is crashing. Check pod logs.
- Insufficient resources — Cluster doesn't have enough CPU/memory/GPU

Upgrade Failed

The Helm Operator attempted to upgrade but the new version failed:

Check the revision history in the Helm Details tab — the failed revision will show its error
If automatic rollback is configured, the operator reverts to the previous working revision
If no automatic rollback, you can manually roll back by redeploying with the previous chart version and values

Helm Operator Not Detected

If PodWarden shows "Helm Operator not installed" on the cluster:

Verify the operator is running: kubectl -n podwarden-system get pods
Check for the detection ConfigMap: kubectl get configmaps -A -l podwarden.com/system-app=true
If missing, reinstall the operator — see System Apps

Values Not Taking Effect

If you change values but the deployment doesn't update:

Confirm the HelmRelease was updated: check the Helm Details tab for the latest revision
The Helm Operator reconciles on an interval (default: 5 minutes). Changes may take a few minutes.
Some chart values require a pod restart to take effect. The Helm Operator does not automatically restart pods unless the chart's templates include a checksum annotation on config changes.

Uninstalling

Undeploying a Helm deployment removes the HelmRelease and HelmRepository CRDs. The Helm Operator then uninstalls the chart and cleans up namespace-scoped resources.

Cluster-scoped resources (CRDs, ClusterRoles) may be retained depending on the chart's uninstall configuration. PodWarden lists any retained cluster-scoped resources after uninstall so you can clean them up manually if needed.