Breaking Change: Kubernetes 1.34 Tightens Image Name Resolution Rules — What It Means for You

If you (or your customers) run workloads on RedHat OpenShift or Oracle Cloud Infrastructure Kubernetes Engine (OKE), there’s a breaking change in Kubernetes 1.34 that deserves your attention.

Starting with this release, Kubernetes distributions using the CRI-O runtime (like OpenShift and OKE) have started enforcing stricter image name resolution rules. In short: Kubernetes will no longer pull container images that aren’t fully qualified.

‍

What Changed in Kubernetes 1.34

In previous versions, you could get away with using short image names like [.inline]nginx:latest[.inline] or [.inline]myapp/backend[.inline]. Kubernetes would automatically resolve the image source — often defaulting to Docker Hub or another configured registry.

With Kubernetes 1.34, that convenience goes away when using CRI-O. Now, every image reference must include its fully qualified registry path, or the deployment may fail to pull the image.

Before (worked fine):

[.inline]image: nginx:latest[.inline]

Now (required in CRI-O-based clusters):

[.inline]image: docker.io/library/nginx:latest[.inline]

‍

Why It Matters 

This change is part of a broader security effort upstream to eliminate ambiguity in how container images are resolved. While it improves supply chain integrity, it also means some existing manifests, Helm charts, and deployment pipelines might break unexpectedly if they rely on short image names.

If your application is deployed into customer-managed clusters, this could surface as failed image pulls or pods stuck in ImagePullBackOff — especially for customers running OpenShift or OKE with Kubernetes 1.34.

We are already seeing software developers that we work with experiencing deployment errors such as the following due to usage of short image names in a distribution now enforcing fully qualified paths.

[.inline]Back-off pulling image "nginx": ErrImagePull: short name mode is enforcing, but image name nginx:latest returns ambiguous list[.inline]

‍

What to Do Next

Audit your manifests and charts for unqualified image references and update them to include a full registry path. For example, replace:

[.inline]myapp/backend:1.2.3[.inline]

with

[.inline]registry.example.com/myapp/backend:1.2.3[.inline]

‍

Replicated’s Response

When we learned of this upstream breaking change, we immediately notified Replicated customers to ensure their applications and their end-customers were minimally affected. Our team reviewed distribution compatibility and shared mitigation guidance so users could continue to deliver reliable, Kubernetes-based applications without disruption.

This type of proactive communication is part of how Replicated helps software vendors and enterprise customers navigate the fast-moving Kubernetes ecosystem—especially when upstream changes could impact production workloads.

‍

Staying Ahead of Kubernetes Changes

The Kubernetes project continues to evolve quickly, refining APIs and improving reliability at scale. While these improvements are overwhelmingly positive, they can occasionally introduce breaking changes like this one. If your organization manages or ships software into Kubernetes clusters, staying current on release notes and testing against new versions early is critical. 

Replicated was able to catch this breaking change early for our own software products due to our internal usage of our testing product, Compatibility Matrix. We were able to identify that we were using a few short image names ourselves, which we are actively correcting. 

For ongoing discussion and technical details about this change, see the full post in the Replicated Community.