What the Kubernetes Package Repo Migration Means for Your Clusters

Background

On August 15, 2023 the Kubernetes project announced that community‑owned Debian and RPM package repositories would be served from https://pkgs.k8s.io. These new repositories replace the previously Google‑hosted apt.kubernetes.io and yum.kubernetes.io endpoints. The announcement blog states that the old repositories will be phased out and no longer receive new packages.

Impact on Kubernetes End Users

The change directly affects users who manually install the latest Kubernetes version—whether following the official install/upgrade guide or using an installer that pulls packages from the Kubernetes project. It also affects users who run kubectl on personal Linux machines via the old repositories. Managed Kubernetes services are only impacted if they still rely on the old repos for kubectl; most cloud providers use their own distributions and therefore are not affected.

If you manage your own cluster, you should follow the migration instructions in the blog post and switch to the new community‑owned repository.

Impact on Kubernetes Distributors

Distributors that embed the old repositories in their installer tools must migrate to pkgs.k8s.io as soon as possible and inform their users about the required steps.

Change Timeline

2023‑08‑15 : Announcement of the new community‑owned repository.

2023‑08‑31 : Official deprecation of the old repositories.

~2023‑09‑13 : Freeze of the old repositories – no further packages will be published there.

2023‑10 onward : Patch releases for v1.28, v1.27, v1.26, and v1.25 will be published only to pkgs.k8s.io.

Future minor releases (e.g., v1.29 and later) will be published exclusively to pkgs.k8s.io.

Can You Keep Using the Old Repositories?

Existing packages in the old repositories will remain available for the foreseeable future, but the Kubernetes project gives no guarantee on how long they will be kept. After the September 13 freeze, no new patch or minor versions will be released to the old repos, and security‑critical updates may require migration.

How to Check If You Are Using the Old Repositories

Determine whether your cluster uses a Debian‑based or RPM‑based distribution and inspect the relevant repository definition files.

Debian‑based Linux Distributions

Check /etc/apt/sources.list and any files under /etc/apt/sources.list.d/ for lines similar to:

deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main

If you find such a line, you are using the legacy repository and need to migrate. If the line points to https://pkgs.k8s.io, you are already on the community‑owned repo.

RPM‑based Linux Distributions

For yum, examine files under /etc/yum.repos.d. For dnf, check /etc/dnf/dnf.conf and /etc/dnf/repos.d/. Look for a repository definition like:

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl

If you see the baseurl pointing to https://packages.cloud.google.com, you are using the legacy repo and must update it to https://pkgs.k8s.io. If the definition already uses pkgs.k8s.io, no action is required.

How to Migrate to the New Community‑Owned Repository

Replace the old repository URLs in the relevant configuration files with https://pkgs.k8s.io. After editing, run the usual package manager update commands (e.g., apt update or yum clean all && yum makecache) and reinstall or upgrade your Kubernetes components.

Why the Change?

Since Kubernetes v1.5, the project has relied on Google‑hosted package repositories for seven years. Moving to the community‑managed registry.k8s.io and pkgs.k8s.io marks a milestone toward fully community‑owned infrastructure, while still thanking Google for its long‑term support.

Are There Tools to Help with Migration?

Currently there are no official tools; users must manually edit repository configurations. Automated migration is technically challenging and could introduce risks.

Acknowledgements

The project thanks Alphabet/Google for providing the original infrastructure and digital signatures, the many contributors who built the new publishing workflow, and SUSE for its OpenBuildService that underpins the new community‑managed repository.