home / skills / laurigates / claude-plugins / helm-debugging

This skill helps you diagnose and resolve Helm deployment failures and template issues with targeted, actionable guidance.

npx playbooks add skill laurigates/claude-plugins --skill helm-debugging

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
5.8 KB
---
model: haiku
created: 2025-12-16
modified: 2026-02-14
reviewed: 2025-12-16
name: helm-debugging
description: |
  Debug and troubleshoot Helm deployment failures, template errors, and configuration
  issues. Covers helm template, helm lint, dry-run, debugging YAML parse errors,
  value type errors, and resource conflicts. Use when user mentions Helm errors,
  debugging Helm, template rendering issues, or troubleshooting Helm deployments.
allowed-tools: Bash, Read, Grep, Glob
---

# Helm Debugging & Troubleshooting

Comprehensive guidance for diagnosing and fixing Helm deployment failures, template errors, and configuration issues.

## When to Use

Use this skill automatically when:
- User reports Helm deployment failures or errors
- User mentions debugging, troubleshooting, or fixing Helm issues
- Template rendering problems occur
- Value validation or type errors
- Resource conflicts or API errors
- Image pull failures or pod crashes
- User needs to inspect deployed resources

## Context Safety (CRITICAL)

**Always specify `--context`** explicitly in all kubectl and helm commands. Never rely on the current context.

```bash
# CORRECT: Explicit context
kubectl --context=prod-cluster get pods -n prod
helm --kube-context=prod-cluster status myapp -n prod

# WRONG: Relying on current context
kubectl get pods -n prod  # Which cluster?
```

This prevents accidental operations on the wrong cluster.

---

## Layered Validation Approach

**ALWAYS follow this progression** for robust deployments:

```bash
# 1. LINT - Static analysis (local charts only)
helm lint ./mychart --strict

# 2. TEMPLATE - Render templates locally
helm template myapp ./mychart \
  --debug \
  --values values.yaml

# 3. DRY-RUN - Server-side validation
helm install myapp ./mychart \
  --namespace prod \
  --values values.yaml \
  --dry-run --debug

# 4. INSTALL - Actual deployment
helm install myapp ./mychart \
  --namespace prod \
  --values values.yaml \
  --atomic --wait

# 5. TEST - Post-deployment validation (if chart has tests)
helm test myapp --namespace prod --logs
```

## Core Debugging Commands

### Template Rendering & Inspection

```bash
# Render all templates locally
helm template myapp ./mychart \
  --debug \
  --values values.yaml

# Render specific template file
helm template myapp ./mychart \
  --show-only templates/deployment.yaml \
  --values values.yaml

# Render with debug output (shows computed values)
helm template myapp ./mychart \
  --debug \
  --values values.yaml \
  2>&1 | less

# Validate against Kubernetes API (dry-run)
helm install myapp ./mychart \
  --namespace prod \
  --values values.yaml \
  --dry-run \
  --debug
```

### Inspect Deployed Resources

```bash
# Get deployed manifest (actual YAML in cluster)
helm get manifest myapp --namespace prod

# Get deployed values (what was actually used)
helm get values myapp --namespace prod

# Get ALL values (including defaults)
helm get values myapp --namespace prod --all

# Get release status with resources
helm status myapp --namespace prod --show-resources

# Get everything about a release
helm get all myapp --namespace prod
```

### Chart Validation

```bash
# Lint chart structure and templates
helm lint ./mychart

# Lint with strict mode (treats warnings as errors)
helm lint ./mychart --strict

# Lint with specific values
helm lint ./mychart --values values.yaml --strict

# Validate chart against Kubernetes API
helm install myapp ./mychart \
  --dry-run --validate --namespace prod
```

### Verbose Debugging

```bash
# Enable Helm debug logging
helm install myapp ./mychart \
  --namespace prod \
  --debug \
  --dry-run

# Enable Kubernetes client logging
helm install myapp ./mychart \
  --namespace prod \
  --v=6  # Verbosity level 0-9
```

## Common Failure Scenarios

| Scenario | Symptom | Quick Fix |
|----------|---------|-----------|
| YAML parse error | `error converting YAML to JSON` | Check indentation, use `{{- ... }}` for whitespace chomping |
| Template rendering error | `nil pointer evaluating interface` | Add defaults: `{{ .Values.key \| default "value" }}` |
| Value type error | `cannot unmarshal string into Go value of type int` | Use `{{ .Values.port \| int }}` in template |
| Resource already exists | `resource that already exists` | `helm uninstall` conflicting release or adopt resource |
| Image pull failure | `ImagePullBackOff` | Fix image name/tag, create pull secret |
| CRD not found | `no matches for kind` | Install CRDs first: `kubectl apply -f crds/` |
| Timeout | `timed out waiting for the condition` | Increase `--timeout`, check readiness probes |
| Hook failure | `pre-upgrade hooks failed` | Delete failed hook job, retry with `--no-hooks` |

For detailed debugging steps, fixes, and examples for each failure scenario, see [REFERENCE.md](REFERENCE.md).

## Agentic Optimizations

| Context | Command |
|---------|---------|
| Release status (JSON) | `helm status <release> -n <ns> -o json` |
| All values (JSON) | `helm get values <release> -n <ns> --all -o json` |
| Pod status (compact) | `kubectl get pods -n <ns> -l app.kubernetes.io/instance=<release> -o wide` |
| Events (sorted) | `kubectl get events -n <ns> --sort-by='.lastTimestamp' -o json` |
| Render + validate | `helm template <release> ./chart --debug 2>&1 \| head -100` |

## Related Skills

- **Helm Release Management** - Install, upgrade, uninstall operations
- **Helm Values Management** - Advanced configuration management
- **Helm Release Recovery** - Rollback and recovery strategies
- **Kubernetes Operations** - Managing and debugging K8s resources
- **ArgoCD CLI Login** - GitOps debugging with ArgoCD

## References

- [Helm Debugging Documentation](https://helm.sh/docs/chart_template_guide/debugging/)
- [Helm Troubleshooting Guide](https://helm.sh/docs/faq/troubleshooting/)
- [Kubernetes Debugging](https://kubernetes.io/docs/tasks/debug/)
- [Template Function Reference](https://helm.sh/docs/chart_template_guide/function_list/)

Overview

This skill diagnoses and fixes Helm deployment failures, template rendering problems, and configuration issues. It guides a layered validation workflow from linting to dry-run to live installs and provides concrete commands and quick fixes for common error patterns. Always requires specifying kube/helm context to avoid operating on the wrong cluster.

How this skill works

It inspects template rendering, rendered manifests, release values, and cluster state using helm and kubectl commands. It follows a stepwise validation flow: helm lint, helm template, helm install --dry-run, then install with atomic/wait, and post-deploy tests. It highlights common failure signatures and maps them to targeted remediation steps.

When to use it

  • User reports Helm install/upgrade failures or errors
  • Template rendering errors (nil pointer, YAML conversion)
  • Value validation or value type mismatch errors
  • Resource conflicts, CRD missing, or hook failures
  • Image pull failures, pod crashes, or readiness timeouts
  • Need to inspect deployed release manifests or used values

Best practices

  • Always provide explicit kube context: use --context / --kube-context in all commands
  • Follow layered validation: lint → template → dry-run → install → test
  • Use --debug and higher verbosity for detailed template and client logs
  • Render specific templates with --show-only to isolate faults
  • Prefer --atomic and --wait for production installs to auto-rollback on failure
  • Store and review helm get values / manifest output to reproduce cluster behavior

Example use cases

  • Render templates locally to find template errors: helm template myapp ./mychart --debug --values values.yaml
  • Lint chart with strict mode before CI: helm lint ./mychart --strict --values values.yaml
  • Validate server-side with dry-run and debug: helm install myapp ./mychart --namespace prod --values values.yaml --dry-run --debug --kube-context=prod-cluster
  • Inspect deployed release and values: helm get manifest myapp --namespace prod --kube-context=prod-cluster
  • Resolve resource conflict by uninstalling or adopting the resource, then reinstalling with --atomic and --wait

FAQ

Why must I always set --context or --kube-context?

Specifying context prevents accidental changes to the wrong cluster. Commands without explicit context use the current kubeconfig default, which can cause destructive mistakes.

What order should I follow to debug a failing release?

Follow the layered approach: helm lint → helm template → helm install --dry-run --debug → helm install with --atomic --wait → helm test. This moves from static checks to server-side validation to a safe install.