Image Registry Snowed In: What You Need to Know About the k8s.gcr.io Freeze

The time has come folks. The day we’ve all been waiting for…Kubernetes now has a new community owned image registry, registry.k8s.io. As of April 3, 2023, the k8s.gcr.io registry will be frozen, and all images will be redirected to registry.k8s.io. k8s.gcr.io will not get any new releases, patches, or security updates. It will continue to remain available to help people migrate, but it **WILL** be phased out entirely in the future.
This change might seem daunting, but don't worry, we've got you covered. In this blog post, we'll take a closer look at what this means and what you need to do to prepare.
For more information on registry.k8s.io and why it was developed, see registry.k8s.io: faster, cheaper and Generally Available.

## The Gist
As of Monday, March 20th, traffic from the older k8s.gcr.io registry was redirected to registry.k8s.io with the eventual goal of sunsetting k8s.gcr.io. Here are some tips from the Kubernetes Blog site
• If you run in a restricted environment, and apply strict domain name or IP address access policies limited to k8s.gcr.io, **the image pulls will not function** after k8s.gcr.io starts redirecting to the new registry.
• A small subset of non-standard clients do not handle HTTP redirects by image registries, and will need to be pointed directly at registry.k8s.io.
• The redirect is a stopgap to assist users in making the switch. The deprecated k8s.gcr.io registry will be phased out at some point. **Please update your manifests as soon as possible to point to registry.k8s.io**.
• If you host your own image registry, you can copy images you need there as well to reduce traffic to community owned registries.

## Why the Freeze?
The decision to freeze the k8s.gcr.io Image Registry comes as part of a broader effort to streamline and simplify Kubernetes' infrastructure. The registry.k8s.io provides a centralized location for all Kubernetes images, making it easier to manage, update, and secure.

## What You Need to Know
How can I check if I am impacted?
The following example commands will check your connection to the registry and if you’re able to pull images
kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- date$ kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- datepod "hello-world" deleted### Find images using the legacy$ kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\tr -s '[[:space:]]' '\n' |\sort |\uniq -c## Krew has a plugin that will scan and report any images using the legacy endpoint$ kubectl krew install community-images$ kubectl community-images
Common errors if impacted will look like FailedCreatePodSandBox
If you're currently using the k8s.gcr.io Image Registry, you'll need to make some changes before April 3, 2023. Here are the key things you need to know:
• Update Your Configurations
You'll need to update your Kubernetes configurations to point to the new registry.k8s.io. This change will ensure that all of your images continue to function correctly after the k8s.gcr.io registry is frozen.

## 2. Check Your Dependencies
Make sure you're not relying on any images that are only available on the k8s.gcr.io registry. Check your dependencies and update them as necessary to avoid any disruptions in your workflow.

## 3. Review Your Security
With the switch to the new registry, it's a good time to review your security protocols. Take the opportunity to ensure that all of your images are up-to-date and secure.

## 4. Stay Up-to-Date
Keep an eye on the Kubernetes blog and other resources to stay up-to-date on any further changes and updates to the registry.

## In Conclusion
The upcoming freeze of the k8s.gcr.io Image Registry may seem like a significant change, but with a bit of preparation, it shouldn't cause any disruptions to your workflow. By following the steps outlined in this post, you can ensure that your Kubernetes environment remains stable and secure.
So, get your snow gear ready and prepare for the k8s.gcr.io Image Registry freeze. Remember, it's all part of the effort to improve and streamline the Kubernetes infrastructure, and the future looks bright!

## Still have questions?
Check out the Kubernetes
If you would like to know more about the image freeze and the last images that will be available there, see the blog post: k8s.gcr.io Image Registry Will Be Frozen From the 3rd of April 2023.
Information on the architecture of registry.k8s.io and its request handling decision tree can be found in the kubernetes/registry.k8s.io repo.
If you believe you have encountered a bug with the new registry or the redirect, please open an issue in the kubernetes/registry.k8s.io repo. **Please check if there is an issue already open similar to what you are seeing before you create a new issue**.
‍

Why This Matters

• The k8s.gcr.io registry freeze required every Kubernetes user to update image references to registry.k8s.io — a breaking change affecting manifests, Helm charts, and operator deployments worldwide.
• Organizations that had not automated image reference management discovered how widely hardcoded registry URLs were scattered across their infrastructure-as-code repositories.
• The transition highlighted the importance of internal image mirroring policies for reducing dependency on upstream registries in production clusters.

What the k8s.gcr.io Freeze Meant for Operations Teams

On April 3, 2023, the Kubernetes project moved from k8s.gcr.io to registry.k8s.io as the primary image registry for all Kubernetes components. The old registry was frozen — images already published remained accessible, but no new images would be pushed. Any cluster configuration referencing k8s.gcr.io for new Kubernetes versions would fail to pull the required images.

For teams running managed Kubernetes (EKS, GKE, AKS), the cloud providers handled image location transparently. For teams running self-managed clusters, upgrading Kubernetes required updating every reference to the old registry in kubeadm configurations, cluster component manifests, and any addon deployments that used Kubernetes-maintained container images.

The Broader Lesson: Registry Independence

The k8s.gcr.io transition is the clearest illustration of why production Kubernetes clusters should not depend directly on upstream public registries. An internal registry (Harbor, Amazon ECR, Google Artifact Registry) that mirrors required images provides: independence from upstream registry availability, control over image scanning before images reach production, and the ability to manage the transition window when upstream registries change.

A registry mirroring policy — automated daily sync of required images to an internal registry — is a small operational investment that eliminates a category of production incidents. THNKBIG's Kubernetes operations practice implements internal registry architectures and image lifecycle management for production clusters. Talk to us.