CRI-O 1.34, image short names are now disabled by default.

by shaokatullaha
October 17, 2025
0
4.63k

CRI-O Users — Be Careful When Moving to Kubernetes 1.34

The Kubernetes ecosystem continues to evolve rapidly, and CRI-O users need to stay alert when upgrading to Kubernetes 1.34. A major change in CRI-O 1.34 affects how container images are pulled — a small configuration difference that can lead to large-scale deployment failures if not handled properly.

The Change: Image Short Names Are Now Disabled

In CRI-O 1.34, image short names are disabled by default.
That means an image reference such as:
image: nginx

will no longer automatically pull from Docker Hub (docker.io/library/nginx).
CRI-O now treats this name as ambiguous and refuses to pull it.

The correct approach is to specify the fully qualified image name, for example:
image: docker.io/library/nginx

This ensures CRI-O knows exactly where to fetch the image.

Why Did CRI-O Make This Change?

CRI-O, the lightweight container runtime built by Red Hat, now checks multiple default registries — most notably docker.io and quay.io.

If the same image name (like nginx) exists in both registries, CRI-O cannot determine which one to use, resulting in a failed image pull.

By disabling short names, CRI-O enforces deterministic and secure image sourcing, aligning with Red Hat’s policy to promote Quay.io as the preferred container registry.

This change also improves security and traceability, helping prevent unintentional image pulls from untrusted or unexpected registries.

If You Need to Revert (Not Recommended)

For testing or backward compatibility, you can re-enable short name behavior by creating a drop-in configuration:

File: /etc/crio/crio.conf.d/shortnames.conf

[crio.image]
short_name_mode = “disabled”

However, Red Hat and the CRI-O maintainers strongly recommend avoiding this unless absolutely necessary.

What You Should Do Before Upgrading

Before moving your clusters to Kubernetes 1.34, perform the following steps:

Review all Kubernetes manifests
– Check every image: field and replace short names with full registry paths.
Update Helm charts and CI/CD pipelines
– Ensure all templates and automation scripts reference fully qualified image names.
Audit third-party charts
– Many community Helm charts still use short names; update them before production rollout.
Validate the upgrade in a staging environment
– Deploy test workloads to ensure there are no unexpected image pull failures.

A Note from the Field

While setting up Kubernetes 1.34 in my R&D lab, I noticed several pull errors related to CRI-O’s new short name behavior.

The fix was straightforward — using full image paths — but the lesson was clear:
small configuration changes can cause major deployment disruptions if overlooked.

I’ve already observed upstream projects like Helm Charts and Operators pushing pull requests to fix this issue.
This reinforces how important it is to standardize image naming conventions early.

Final Thoughts

The CRI-O 1.34 update is another step toward improving security, predictability, and transparency in Kubernetes environments.

Although it may require a bit of manifest cleanup, the benefits — fewer ambiguities, better image control, and improved compliance — are well worth it.

Before your next cluster upgrade, take the time to:

Use fully qualified image names
Verify Helm values and manifests
Test image pulls in staging

Stay ahead of the change and keep your container environment stable and secure.

BLOGGER