I don't think you can, because a pod an atomic unit, contains all the containers.

You must delete and recreate the entire Pod. If you look at the API definition of the Kubernetes PodSpec, both the containers and initContainers fields contain the phrase Cannot be updated. A Pod is immutable once created, and the various higher-level objects work by creating and destroying Pods.

In the standard practice I'm used to:

• Always use higher-level objects to manage your containers, most often Deployments; don't deal directly in Pods. You can change the Pod spec embedded in a Deployment spec, and the deployment controller will create new pods matching the new spec and then tear down the old pods (that is, a zero-downtime rolling upgrade).

• Put only one container in a Pod if at all possible. You mention an initContainer so this may not be 100% possible for you, but the only way you can achieve "update A without restarting B" is to have them be in different Pods (and therefore different Deployments).

• Don't stress about restarting things. If a Node fails, or you need to update a container image like you show, or in some other cases, a Pod can get stopped and deleted and a new Pod started in its place. This is totally normal, and if you have a Deployment with multiple replicas, fairly transparent. Your application may need to do a little work to be happy in this environment (not keeping state only in memory or local disk).

If you are asking yourself this question, maybe you should reconsider some things.

As stated in the others comment/answers, a pod once created is one unit whatever is inside of it.

If you ever needs to scale some part of the pod and not the rest or do updates of just a part and don't want to restart the rest (a caching system for example), you should look to take out the container from you deployment and create another independent one.