Automatic Image Updates

Edka updates the container image of a Deployment or a Cron Job when a newer image is published. The Edka Agent in your cluster checks the registry, sets the new image on the workload, and reports the change to Edka. The check runs inside your cluster, so updates continue while Edka is unreachable.

Prerequisites

• A Deployment or a Cron Job created from a container image. Branch deployments are built from your repository and have no Automation tab.
• The Edka Agent add-on, which is installed with every cluster.
• For a private registry, pull credentials applied to the cluster. See Registry.

Turn on automatic updates

1. Open the Deployment or the Cron Job and select the Automation tab.
2. Turn on Enable automatic image updates.
3. Select a Version Policy.
4. Select a Check Frequency, from Every minute to Every 24 hours.
5. Optional: turn on Require approval.
6. Save the changes.

The first check runs within a minute, and the Update Status panel shows its result. Select Check now to check at once. The answer takes a few seconds.

Version policies

Policy	Updates to	Example
Minor versions	Newer minor and patch versions	1.2.3 to 1.3.0, not 2.0.0
Patch only	Newer patch versions	1.2.3 to 1.2.4, not 1.3.0
Major versions	Any newer stable version	1.5.2 to 2.0.0
All updates	Any newer version, pre-releases included	1.0.0 to 2.0.0-beta
Current tag	A new image pushed to the tag the workload runs	main to main
Custom pattern	The newest tag that matches a pattern	glob:1.0.*

Rules that apply to the version policies:

• Tags are read as versions with one, two, or three parts, with or without a leading v: 16, 1.27, 1.27.2, v1.27.2.
• A suffix stays the same. 1.27.2-alpine moves to 1.28.0-alpine, never to 1.28.0. All updates is the exception and allows any newer version.
• An update never moves to a lower version.
• A tag that is not a version, such as latest or main, is updated by Current tag or Custom pattern only.

Current tag

Current tag follows new pushes to the tag the workload runs. The image is pinned by digest, as repo:tag@sha256:…, so every pod runs the same image.

Custom pattern

A custom pattern starts with glob: or regexp:.

Pattern	Matches
glob:1.0.*	1.0.1, 1.0.2
glob:release-*	release-42, release-2026-09
regexp:^v[0-9]+\.[0-9]+\.[0-9]+$	v1.2.3

Matching tags are compared as versions when they parse as versions, so 1.10.0-alpine ranks above 1.9.0-alpine.

Regular expressions use RE2 syntax. RE2 has no lookaheads and no backreferences, so regexp:^(?!dev) is refused. The Custom Pattern field shows the reason when a pattern can’t be used.

Approve updates

With Require approval on, a new version waits until someone applies or skips it.

1. Open the Automation tab. Update Status shows Awaiting approval with the running and the new version, for example 1.4.2 → 1.5.0.
2. Select Apply to roll out the new version, or Skip to pass over it.

After Skip, the next version the policy allows is offered. When there is none, the workload waits for a newer one. The Versions tab records who approved an update.

Update status

State	Meaning
Up to date	The workload runs the newest image the policy allows.
Awaiting approval	A newer image is waiting for Apply or Skip.
Blocked	A newer image exists and can’t be used. The message names the tag and the reason.
Failing	A check or a rollout failed. The message names the cause.
Not checked yet	No check has run since automatic updates were turned on.

The panel also shows the running image, the time of the last automatic update, and the version you skipped.

Images for every node

An image has to support the CPU architecture of every node the workload can run on. On a cluster with amd64 and arm64 node pools, a tag published for amd64 only is passed over, and the next newer tag that covers both is used. When no tag does, the state is Blocked:

1.6.0 is not used: no linux/arm64 image

To run the workload on one architecture, select a node pool in the Placement tab.

Rollouts

No update is applied while a rollout of the Deployment is in progress. When the rollout of an updated image doesn’t complete, the state is Failing, and no further update is applied until the rollout completes or the image changes.

Version history and rollback

The Versions tab of a Deployment and the Automation tab of a Cron Job list every image change, with its time and its source: a user, an automatic update, or an approved update.

Select Restore on an earlier version to roll back. Restoring a version turns automatic updates off, so the workload stays on the restored image. Turn them on again in the Automation tab.

Notifications

Automatic updates add four notifications, delivered to the channels of your organization:

Notification	Severity	Appears when
Image updated	info	An image was updated
Update awaiting approval	info	A new version waits for approval
Auto-update failing	warning	Checks have failed for 15 minutes
Auto-update blocked	info	A newer image can’t be used

Troubleshooting

The Automation tab says edka-agent does not update images yet

The cluster runs an earlier Edka Agent. Open Cluster Settings → Add-ons and upgrade Edka Agent.

The state stays on Not checked yet

Check that the agent runs:

kubectl -n edka-system get pods -l app.kubernetes.io/name=edka-agent

The agent writes what it found on the workload. Read it with:

kubectl -n <namespace> get deployment <name> \
  -o jsonpath='{.metadata.annotations.agent\.edka\.io/auto-update-status}'

For a Cron Job, replace deployment with cronjob.

The state is Failing with a registry error

The agent reads the registry with the pull secrets of the workload and of the ServiceAccount in its namespace. Check that the registry is applied to the cluster under Registry → External Registries, then select Check now.

A newer tag exists and the workload doesn’t update

• The tag is outside the policy. 2.0.0 is not a Minor versions update of 1.5.2.
• The tag has another suffix. 1.28.0 is not an update of 1.27.2-alpine.
• The running tag is not a version. Use Current tag or Custom pattern for tags such as latest.
• The version was skipped. Update Status shows it under Skipped.