⏰ k8s.gcr.io Kubernetes image registry is being frozen April 3rd

[jpmcb]

On April 3rd, 2023, the k8s.gcr.io Kubernetes image registry will be frozen.

On the 3rd of April 2023, the old registry k8s.gcr.io will be frozen and no further images for Kubernetes and related subprojects will be pushed to the old registry.

https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/

This means that no new images will be added to that registry. And while legacy images may exist there for the time being, it is recommended that all uses of k8s.gcr.io be migrated to use the new, community operated registry: registry.k8s.io.

I use Bottlerocket for my Kubernetes cluster nodes. Am I impacted?

The VMware variant uses the k8s.gcr.io/pause pod. v1.13.0 of Bottlerocket will have this patched here:

#2786 and #2861

But you should consider setting this explicitly in your Bottlerocket node's user-data to ensure no remaining usage of the old registry:

settings.kubernetes.pod-infra-container-image = "registry.k8s.io/pause:3.2"

or

settings.kubernetes.pod-infra-container-image = "public.ecr.aws/eks-distro/kubernetes/pause:3.2"

When deployed through EKS Anywhere, these values are automatically set to the pause pod packaged with the EKS-Distribution.

Other variants of Kubernetes Bottlerocket are not affected.

My platform stack uses k8s.gcr.io. What do you recommend?

Utilization of k8s.gcr.io for a variety of software is fairly common and should be migrated to a different registry as soon as possible.

You should consider auditing the registries used by pods in your clusters. The following command will list what registries are pulled from by pods:

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

Any references to k8s.gcr.io should be replaced with their equivalent in registry.k8s.io or another mirror.

I can't move off k8s.gcr.io.

If you have a network policy that dictates the IP/Domain that pods pull images through or have some other constraint on using a different registry, you should consider hosting an internal or in-network mirror:

If you want to increase the reliability of your cluster and remove dependency on the community-owned registry or you are running Kubernetes in networks where external traffic is restricted, you should consider hosting local image registry mirrors. Some cloud vendors may offer hosted solutions for this.

https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/