Introduction

With Helm, you do not usually replace a pod directly. You update the Helm release values, let Helm render new Kubernetes manifests, and then let the owning controller, such as a Deployment or StatefulSet, roll out new pods that match the updated configuration.

Think in Terms of Controllers, Not Individual Pods

A pod created by a Deployment is disposable. If you delete it manually, Kubernetes will create a replacement that still uses the current Deployment spec. That means changing the live pod itself does not solve a configuration problem in a durable way.

The durable change must happen in one of these places:

• The Helm values passed into the chart.
• The templates inside the chart.
• The referenced ConfigMap or Secret together with rollout logic.

Once the rendered manifest changes, the controller replaces pods according to its rollout strategy.

Update Values with helm upgrade

The standard workflow is:

helm get values my-release
helm upgrade my-release ./my-chart -f values.yaml

If you only need to change one or two values, you can override them inline:

helm upgrade my-release ./my-chart \
  --set image.tag=2.0.1 \
  --set config.logLevel=debug

After the upgrade, inspect the rollout:

kubectl get pods -n my-namespace
kubectl rollout status deployment/my-app -n my-namespace

If the Deployment template changed, Kubernetes will create a new ReplicaSet and rotate the pods.

Make Sure Config Changes Trigger a Rollout

One subtle issue is that updating a ConfigMap or Secret does not always restart pods automatically. If the pod template in the Deployment remains unchanged, Kubernetes may keep running the old pods.

A common Helm pattern is to place a checksum annotation on the pod template so that config file changes change the template hash too.

Example template snippet:

1spec:
2  template:
3    metadata:
4      annotations:
5        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

When the ConfigMap template content changes, the checksum changes, the pod template changes, and Kubernetes performs a rollout.

When Deleting a Pod Is Useful

Deleting a pod can still be useful, but only in a narrow sense. If the Deployment spec already contains the correct values and you simply want the controller to recreate a stuck pod, then deleting it is fine:

kubectl delete pod my-app-abc123 -n my-namespace

Kubernetes will replace it using the current controller specification. What deletion will not do is apply new Helm values that have not been upgraded into the release yet.

Reuse and Compare Existing Values Carefully

When updating a release, be deliberate about where values come from. helm upgrade --reuse-values can help if you want to keep existing values and override only a subset:

helm upgrade my-release ./my-chart --reuse-values --set replicaCount=3

It is also often helpful to preview changes before applying them:

helm diff upgrade my-release ./my-chart -f values.yaml

That helps you confirm whether the pod template will actually change.

Common Pitfalls

The most common mistake is editing or deleting a pod and expecting Helm state to change. Pods are outputs of the desired state, not the source of truth.

Another issue is updating a ConfigMap but forgetting to wire that change into the pod template. Without a template change, the controller may not restart anything.

People also use helm upgrade with the wrong values file, then wonder why the replacement pod still has the old settings. Always confirm the effective values with helm get values and the rendered manifests if needed.

Finally, do not ignore rollout status. A Helm upgrade can succeed as a release operation while the workload rollout still fails afterward.

Summary

• Do not replace Helm-managed pods by editing them directly.
• Change the Helm release values and apply them with helm upgrade.
• Let the owning controller roll out new pods from the updated pod template.
• Use checksum annotations when ConfigMap or Secret changes should trigger restarts.
• Delete individual pods only when you want Kubernetes to recreate them from the already-correct spec.