Introduction

Yes, you can use kubectl set image to update the image of an initContainer, as long as you target the init container by its exact name in the pod template. The command updates the workload spec, and Kubernetes then rolls out new pods that run the new init container image before the main containers start.

How kubectl set image Matches Containers

kubectl set image works by patching named container entries in the pod template. If the name you provide matches an initContainer, Kubernetes updates that init container image.

Example deployment snippet:

1spec:
2  template:
3    spec:
4      initContainers:
5        - name: init-db
6          image: myrepo/init-db:1.0
7      containers:
8        - name: app
9          image: myrepo/app:1.0

To update the init container:

kubectl set image deployment/my-app init-db=myrepo/init-db:2.0

This is the same general command style used for ordinary containers. The critical part is using the correct container name.

Verify the Names Before Updating

Before running the command, inspect the workload so you target the right field.

kubectl get deployment my-app -o yaml

Look under:

• 'spec.template.spec.initContainers'
• 'spec.template.spec.containers'

If you accidentally use the app container name instead of the init container name, the wrong image gets updated or the command may fail because the name does not exist.

What Happens After the Update

For a Deployment, changing the pod template triggers a rollout. New pods are created, and each new pod runs the updated init container before starting the main application containers.

Check rollout status:

kubectl rollout status deployment/my-app

Then confirm the image:

kubectl get deployment my-app -o jsonpath='{.spec.template.spec.initContainers[*].image}'

That is the cleanest way to confirm the template was updated rather than only assuming the command succeeded.

Updating Multiple Images at Once

You can update both an init container and an app container in one command if needed.

kubectl set image deployment/my-app \
  init-db=myrepo/init-db:2.0 \
  app=myrepo/app:2.0

This can be useful when an init container and main container need to stay version-aligned.

Confirm It on a Real Pod

The deployment template is the source of truth, but it is also worth checking one of the new pods created by the rollout. That confirms the scheduler actually launched a pod from the updated template rather than leaving you looking at an old replica.

kubectl get pods -l app=my-app
kubectl get pod my-app-7d8c9f6b7b-abcde -o jsonpath='{.spec.initContainers[*].image}'

If the pod image and deployment template match, the update was applied end to end.

When kubectl patch Is Better

If the workload is more complex or you need precise JSON patch control, kubectl patch may be more explicit.

1kubectl patch deployment my-app --type='json' -p='[
2  {
3    "op": "replace",
4    "path": "/spec/template/spec/initContainers/0/image",
5    "value": "myrepo/init-db:2.0"
6  }
7]'

kubectl set image is simpler when the container name is enough. kubectl patch is better when you need exact structural control.

Common Pitfalls

The most common mistake is assuming init containers use completely different update commands from normal containers. They do not; the update still targets a named container entry in the pod template. Another is not checking the actual init container name before running kubectl set image. Developers also forget that changing the pod template causes a rollout, so old running pods are not magically edited in place; new pods must start with the new init image.

Summary

• 'kubectl set image can update an init container image by name.'
• Target the workload and the init container’s exact name.
• Verify the update in the pod template, not just from command success output.
• Expect a rollout for Deployment-style workloads after the change.
• Use kubectl patch if you need more explicit structural control than set image provides.