Set image

Set image

Set image… changes the container images of a workload in one small dialog, like kubectl set image: every container with its current image, a field for the new one with a check of the image name, an optional preview of what the API server would store, and a change that touches nothing but the image fields.

Contents: Where it is · Changing images · Preview · What is sent · When the object changed meanwhile · Pods · After the change

Where it is

Set image… is in the actions of a Deployment, StatefulSet, DaemonSet, CronJob or Pod: in the details panel and the row's ⋮ menu (and in the command palette under the object's actions).

ReplicaSets and Jobs do not have it: changing a ReplicaSet's template does not replace its pods, and a Job's pod template cannot be changed.

Changing images

The dialog lists every container and init container (marked init container) with its Current image and a New image field filled in with it. Ephemeral (debug) containers are not listed. Change one or several fields; What changes lists each change, for example web: nginx:1.25 → nginx:1.27. That list is what you confirm.

Each new image is checked as you type, by the image reference rules registries use: an optional registry host and port, a lowercase repository path, a tag of up to 128 letters, digits, _, . and -, and a digest written as sha256: and 64 hexadecimal digits (a tag and a digest together are allowed). Kubernetes itself checks almost nothing here, so without this check a typo would only show up later as ImagePullBackOff. An image tagged latest, or without a tag (which means latest), gets a warning but can be set: such a tag can point to another image at each pull.

A short note at the top says what happens next for that kind: for a Deployment, StatefulSet or DaemonSet the pods are replaced by its update strategy; for a CronJob only Jobs started after the change use the new images; for a Pod see below.

Preview

Preview changes asks the API server what it would store, with a server-side dry run of the same change — defaults, admission webhooks and validation included, nothing changed — and shows it next to the live object, as for the YAML editor (see Safe apply). Back to editing returns to the fields; Set image sends exactly the previewed changes.

On a cluster set to Preview changes before applying (by default, clusters named like production), the main button is Preview and set image…: the preview always comes first.

What is sent

One strategic-merge patch, built by Sextant's backend, containing only the name and image of each changed container under the kind's pod template (spec.template.spec; a CronJob's spec.jobTemplate.spec.template.spec; a Pod's spec). Nothing else in the object is touched. Right before sending, Sextant reads the object again and refuses when:

• a container you changed is no longer there (the patch would otherwise add a new container with only a name and an image);
• a container's image is no longer the one the dialog showed;
• the object is a Pod a controller owns, or a static Pod.

The patch carries the version of the object it was checked against, so a write that lands in between makes it fail instead of being merged. It is sent once and never repeated. The change is made with the field manager sextant, and Sextant adds no kubernetes.io/change-cause annotation (kubectl set image no longer adds one either).

When the object changed meanwhile

If the object changed after the preview — scaled, relabelled, another image set — Sextant sends nothing. The dialog runs the preview again on the live object and shows it with the note "… changed after the preview": check it and press Set image again. Without a preview, the change is refused with an error when one of the images you are changing is no longer the one the dialog showed; reopen the dialog to see the current images.

Pods

• A Pod owned by a controller (a ReplicaSet, a Job, a DaemonSet…) opens a dialog that names its owner instead, with a button to open it. Through a ReplicaSet it opens the Deployment, and through a Job the CronJob, where the image belongs: the controller would otherwise replace the Pod or ignore the new image.
• A static Pod (a mirror of a manifest file on its node) cannot be changed through the API; the dialog says to change the manifest on the node.
• A bare Pod can change only its images in place, which Kubernetes allows: the kubelet restarts each changed container with its new image.

After the change

• For a Deployment, StatefulSet or DaemonSet the pods are replaced as for any update; the change becomes a new revision in the History tab and can be rolled back with Roll back… (see Rollout history and rollback).
• The change appears in the Change timeline, signed by sextant.
• Set image… is a window action. AI agents can change images with their patch_resource tool under the rules you set; there is no separate tool, and extensions get nothing new.

Next: Safe apply (Preview changes), Using Sextant.