Helm vs kubectl for day-2: when charts win, when raw apply wins

Day-2 Kubernetes is rarely “write one Deployment YAML and forget it.” You install Redis, bump a chart version, tweak values, roll back a bad upgrade, or scale a workload that was never in Helm. Teams argue Helm vs kubectl as if one should win. Both should — for different jobs.

This guide is a decision sheet: when charts are the right abstraction, when raw kubectl (or GitOps manifests) is clearer, and how kprompt fits as a natural-language layer that calls the real Helm CLI for install/upgrade — with template/dry-run style previews and the same plan → approve gate as kubectl mutations. It does not replace Helm, and it does not replace Git as the source of truth for production desired state.

Quick decision

What Helm is actually for

Helm packages Kubernetes apps as charts: templates + values + a release record. You are not “avoiding YAML” — you are parameterizing someone else's (or your team's) templates and tracking upgrades as releases. That shines when the chart encodes probes, RBAC, Services, and sane defaults you would otherwise copy from READMEs.

• Install — create a named release from a chart/repo
• Upgrade — change chart version or values with history
• Rollback — return a release to a prior revision (Helm's meaning, not only Deployment rollout undo)
• Values — the contract between you and the chart authors

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install redis bitnami/redis -n cache --create-namespace
helm upgrade redis bitnami/redis -n cache --version 18.0.0
helm history redis -n cache
helm rollback redis 1 -n cache

What kubectl still owns

kubectl talks directly to the apiserver. It is the right tool when the unit of change is an object you understand cold — scale replicas, rollout undo, describe a Pod, patch a probe. It is also the lingua franca inside scripts, CI, and incident notes. Helm eventually applies objects; kubectl remains how you inspect and surgically mutate them.

kubectl get deploy -n staging
kubectl scale deploy/api --replicas=3 -n staging
kubectl rollout undo deploy/api -n staging
kubectl describe pod -l app=api -n staging
kubectl logs deploy/api -n staging --tail=100

If your “app” is a single Deployment your team wrote, wrapping it in Helm “because platforms use Helm” often adds ceremony without adding leverage. Prefer plain manifests (or Kustomize) in Git until you need values-driven reuse across environments.

deploy vs install in kprompt (easy to confuse)

Natural language blurs the verbs. In kprompt they map to different backends:

kprompt "deploy redis" -n cache
# → Kubernetes Deployment (+ Service) style plan

kprompt "install redis" -n cache
# → helm repo / helm install plan + template/dry-run preview

kprompt tools   # confirm Helm is on PATH before install prompts

If Helm is missing, kprompt should hint you toward install Helm or the Kubernetes deploy shortcut — not invent a successful chart install.

The approval loop stays the same

Whether the plan's backend is kubernetes or helm, mutations are still reviewable. Helm paths surface template/dry-run style previews so you read rendered intent before approve. Wipe-class Helm language (uninstall --all, purge all releases) hard-denies. Named uninstall is not something to casually --approve in production either — treat release deletion like any high-blast-radius change.

$ kprompt "install redis" -n cache

# Plan includes helm steps + preview context
# Risk: medium — mutation requires approval
Apply? [y/N]

Day-2 patterns that mix both

Chart for install, kubectl for incident

Production Redis came from Helm. Tonight it OOMs. You do not need a values PR to confirm OOMKilled — explain/logs first, then a bounded memory patch or Helm values bump as a follow-up. Incident speed and release hygiene are different tempos.

kprompt "explain why redis is crashing" -n cache
# … confirm OOM …

# Later, durable fix via chart values / upgrade — or a reviewed patch plan
kprompt "upgrade redis" -n cache

GitOps owns prod; laptop owns discovery

Use Helm (or Helm via Argo CD) in Git for environments that matter. Use kprompt/kubectl on the laptop for staging discovery, explain, and break-glass scale/rollback — with plan gates. CI can consume PlanResult JSON for operational prompts the same way it gates manifest diffs.

Anti-patterns

• Helm wrapping a single Deployment you fully control — ceremony without reuse
• kubectl apply of chart output with no release record — you lose Helm history on purpose
• Editing live objects that GitOps will overwrite — fix Git, not only the cluster
• helm uninstall --all as cleanup — hard deny exists for a reason
• Assuming NL install invents a private chart you never configured — real Helm + real repos only

Honest scope today

kprompt ships Helm install and upgrade planning with previews when helm is on PATH. It is experimental. It is not a full Helmfile replacement, not a values IDE, and not a promise that every chart flag is expressible in English. Read the plan. Prefer non-production while you learn how previews look for your charts.

Try both paths on staging

curl -fsSL https://kprompt.ai/install | bash
export KPROMPT_GEMINI_API_KEY="..."

kprompt tools
kprompt "deploy redis" -n staging      # Kubernetes recipe path
kprompt "install redis" -n staging     # Helm path — review preview → y/N
kprompt "list deployments" -n staging

For kubectl one-liners paired with prompts, see the cheat sheet. For why plans matter more than chat scroll, see the intent compiler note. Pick Helm when the chart is the product; pick kubectl when the object is.