Merge pull request #42813 from sftim/20230831_tweak_legacy_package_repository_deprecation

Tweak legacy package repository deprecation article

Author: Tim Bannister

content/en/blog/_posts/2023-08-31-legacy-package-repository-deprecation.md

@@ -1,40 +1,72 @@
 ---
 layout: blog
 title: "Kubernetes Legacy Package Repositories Will Be Frozen On September 13, 2023"
-date: 2023-08-31T16:30:00-07:00
+date: 2023-08-31T15:30:00-07:00
 slug: legacy-package-repository-deprecation
+evergreen: true
 ---
 
 **Authors**: Bob Killen (Google), Chris Short (AWS), Jeremy Rickard (Microsoft), Marko Mudrinić (Kubermatic), Tim Bannister (The Scale Factory)
 
-On August 15, 2023, the Kubernetes project announced the general availability of the community-owned package repositories for Debian and RPM packages available at `pkgs.k8s.io`. The new package repositories are replacement for the legacy Google-hosted package repositories: `apt.kubernetes.io` and `yum.kubernetes.io`. The [announcement blog post for `pkgs.k8s.io`](/blog/2023/08/15/pkgs-k8s-io-introduction/) highlighted that we will stop publishing packages to the legacy repositories in the future.
+On August 15, 2023, the Kubernetes project announced the general availability of
+the community-owned package repositories for Debian and RPM packages available
+at `pkgs.k8s.io`. The new package repositories are replacement for the legacy
+Google-hosted package repositories: `apt.kubernetes.io` and `yum.kubernetes.io`.
+The
+[announcement blog post for `pkgs.k8s.io`](/blog/2023/08/15/pkgs-k8s-io-introduction/)
+highlighted that we will stop publishing packages to the legacy repositories in
+the future.
 
-Today, we're formally deprecating the legacy package repositories (`apt.kubernetes.io` and `yum.kubernetes.io`), and we're announcing our plans to freeze the contents of the repositories  as of **September 13, 2023**.
+Today, we're formally deprecating the legacy package repositories (`apt.kubernetes.io`
+and `yum.kubernetes.io`), and we're announcing our plans to freeze the contents of
+the repositories as of **September 13, 2023**.
 
-Please continue reading in order to learn what does this mean for you as an user or distributor, and what steps you may need to take.
+Please continue reading in order to learn what does this mean for you as an user or
+distributor, and what steps you may need to take.
 
 ## How does this affect me as a Kubernetes end user?
 
-This change affects users **directly installing upstream versions of Kubernetes**, either manually by following the official [installation](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) and [upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) instructions, or by **using a Kubernetes installer** that's using packages provided by the Kubernetes project.
+This change affects users **directly installing upstream versions of Kubernetes**,
+either manually by following the official
+[installation](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) and
+[upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) instructions, or
+by **using a Kubernetes installer** that's using packages provided by the Kubernetes
+project.
 
-**This change also affects you if you run Linux on your own PC and have installed `kubectl` using the legacy package repositories**. We'll explain later on how to [check](#check-if-affected) if you're affected.
+**This change also affects you if you run Linux on your own PC and have installed `kubectl` using the legacy package repositories**.
+We'll explain later on how to [check](#check-if-affected) if you're affected.
 
-If you use **fully managed** Kubernetes, for example through a service from a cloud provider, you would only be affected by this change if you also installed `kubectl` on your Linux PC using packages from the legacy repositories. Cloud providers are generally using their own Kubernetes distributions and therefore they don't use packages provided by the Kubernetes project; more importantly,
-if someone else is managing Kubernetes for you, then they would usually take responsibility for that check.
+If you use **fully managed** Kubernetes, for example through a service from a cloud
+provider, you would only be affected by this change if you also installed `kubectl`
+on your Linux PC using packages from the legacy repositories. Cloud providers are
+generally using their own Kubernetes distributions and therefore they don't use
+packages provided by the Kubernetes project; more importantly, if someone else is
+managing Kubernetes for you, then they would usually take responsibility for that check.
 
-If you have a managed [control plane](/docs/concepts/overview/components/#control-plane-components) but you are responsible for **managing the nodes yourself**, and any of those nodes run Linux, you should [check](#check-if-affected) whether you are affected.
+If you have a managed [control plane](/docs/concepts/overview/components/#control-plane-components)
+but you are responsible for **managing the nodes yourself**, and any of those nodes run Linux,
+you should [check](#check-if-affected) whether you are affected.
 
-If you're managing your clusters on your own by following the official installation and upgrade instructions, please follow the instructions in this blog post to migrate to the (new) community-owned package repositories.
+If you're managing your clusters on your own by following the official installation
+and upgrade instructions, please follow the instructions in this blog post to migrate
+to the (new) community-owned package repositories.
 
 
-If you're using a Kubernetes installer that's using packages provided by the Kubernetes project, please check the installer tool's communication channels for information about what steps you need to take, and eventually if needed, follow up with maintainers to let them know about this change.
+If you're using a Kubernetes installer that's using packages provided by the
+Kubernetes project, please check the installer tool's communication channels for
+information about what steps you need to take, and eventually if needed, follow up
+with maintainers to let them know about this change.
 
 ## How does this affect me as a Kubernetes distributor?
 
-If you're using the legacy repositories as part of your project (e.g. a Kubernetes installer tool), you should migrate to the community-owned repositories as soon as possible and inform your users about this change and what steps they need to take.
+If you're using the legacy repositories as part of your project (e.g. a Kubernetes
+installer tool), you should migrate to the community-owned repositories as soon as
+possible and inform your users about this change and what steps they need to take.
 
 ## Timeline of changes
 
+<!-- note to maintainers - the trailing whitespace is significant -->
+
 - **15th August 2023:**  
   Kubernetes announces a new, community-managed source for Linux software packages of Kubernetes components
 - **31st August 2023:**  
@@ -45,53 +77,76 @@ If you're using the legacy repositories as part of your project (e.g. a Kubernet
   (`apt.kubernetes.io` and `yum.kubernetes.io`).
   The freeze will happen immediately following the patch releases that are scheduled for September, 2023.
 
-The Kubernetes patch releases scheduled for September 2023 (v1.28.2, v1.27.6, v1.26.9, v1.25.14) will have packages published **both** to the community-owned and the legacy repositories.
+The Kubernetes patch releases scheduled for September 2023 (v1.28.2, v1.27.6,
+v1.26.9, v1.25.14) will have packages published **both** to the community-owned and
+the legacy repositories.
 
-We'll freeze the legacy repositories after cutting the patch releases for September which means that we'll completely stop publishing packages to the legacy repositories at that point.
+We'll freeze the legacy repositories after cutting the patch releases for September
+which means that we'll completely stop publishing packages to the legacy repositories
+at that point.
 
-For the v1.28, v1.27, v1.26, and v1.25 patch releases from October 2023 and onwards, we'll only publish packages to the new package repositories (`pkgs.k8s.io`).
+For the v1.28, v1.27, v1.26, and v1.25 patch releases from October 2023 and onwards,
+we'll only publish packages to the new package repositories (`pkgs.k8s.io`).
 
 ### What about future minor releases?
 
-Kubernetes 1.29 and onwards will have packages published **only** to the community-owned repositories (`pkgs.k8s.io`).
+Kubernetes 1.29 and onwards will have packages published **only** to the
+community-owned repositories (`pkgs.k8s.io`).
 
 ## Can I continue to use the legacy package repositories?
 
-The existing packages in the legacy repositories will be available for the foreseeable future. However, the Kubernetes project can't provide _any_ guarantees on how long is that going to be. The deprecated legacy repositories, and their contents, might be removed at any time in the future and without a further notice period.
+The existing packages in the legacy repositories will be available for the foreseeable
+future. However, the Kubernetes project can't provide _any_ guarantees on how long
+is that going to be. The deprecated legacy repositories, and their contents, might
+be removed at any time in the future and without a further notice period.
 
-The Kubernetes project **strongly recommends** migrating to the new community-owned repositories **as soon as possible**.
+The Kubernetes project **strongly recommends** migrating to the new community-owned
+repositories **as soon as possible**.
 
-Given that no new releases will be published to the legacy repositories **after the September 13, 2023**, **you will not be able to upgrade to any patch or minor release made from that date onwards.**
+Given that no new releases will be published to the legacy repositories **after the September 13, 2023**
+cut-off point, **you will not be able to upgrade to any patch or minor release made from that date onwards.**
 
-Whilst the project makes every effort to release secure software, there may one day be a high-severity vulnerability in Kubernetes, and consequently an important release to upgrade to.
-The advice we're announcing will help you be as prepared
-for any future security update, whether trivial or urgent.
+Whilst the project makes every effort to release secure software, there may one
+day be a high-severity vulnerability in Kubernetes, and consequently an important
+release to upgrade to. The advice we're announcing will help you be as prepared for
+any future security update, whether trivial or urgent.
 
 ## How can I check if I'm using the legacy repositories? {#check-if-affected}
 
-The steps to check if you're using the legacy repositories depend on whether you're using Debian-based distributions (Debian, Ubuntu, and more) or RPM-based distributions (CentOS, RHEL, Rocky Linux, and more) in your cluster.
+The steps to check if you're using the legacy repositories depend on whether you're
+using Debian-based distributions (Debian, Ubuntu, and more) or RPM-based distributions
+(CentOS, RHEL, Rocky Linux, and more) in your cluster.
 
 Run these instructions on one of your nodes in the cluster.
 
 ### Debian-based Linux distributions
 
-The repository definitions (sources) are located in `/etc/apt/sources.list` and `/etc/apt/sources.list.d/` on Debian-based distributions. Inspect these two locations and try to locate a package repository definition that looks like:
+The repository definitions (sources) are located in `/etc/apt/sources.list` and `/etc/apt/sources.list.d/`
+on Debian-based distributions. Inspect these two locations and try to locate a
+package repository definition that looks like:
 
 ```
 deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main
 ```
 
 **If you find a repository definition that looks like this, you're using the legacy repository and you need to migrate.**
 
-If the repository definition uses `pkgs.k8s.io`, you're already using the community-hosted repositories and you don't need to take any action.
+If the repository definition uses `pkgs.k8s.io`, you're already using the
+community-hosted repositories and you don't need to take any action.
 
-On most systems, this repository definition should be located in `/etc/apt/sources.list.d/kubernetes.list` (as recommended by the Kubernetes documentation), but on some systems it might be in a different location.
+On most systems, this repository definition should be located in
+`/etc/apt/sources.list.d/kubernetes.list` (as recommended by the Kubernetes
+documentation), but on some systems it might be in a different location.
 
-If you can't find a repository definition related to Kubernetes, it's likely that you don't use package managers to install Kubernetes and you don't need to take any action.
+If you can't find a repository definition related to Kubernetes, it's likely that you
+don't use package managers to install Kubernetes and you don't need to take any action.
 
 ### RPM-based Linux distributions
 
-The repository definitions are located in `/etc/yum.repos.d` if you're using the `yum` package manager, or `/etc/dnf/dnf.conf` and `/etc/dnf/repos.d/` if you're using `dnf` package manager. Inspect those locations and try to locate a package repository definition that looks like this:
+The repository definitions are located in `/etc/yum.repos.d` if you're using the
+`yum` package manager, or `/etc/dnf/dnf.conf` and `/etc/dnf/repos.d/` if you're using
+`dnf` package manager. Inspect those locations and try to locate a package repository
+definition that looks like this:
 
 ```
 [kubernetes]
@@ -105,30 +160,50 @@ exclude=kubelet kubeadm kubectl
 
 **If you find a repository definition that looks like this, you're using the legacy repository and you need to migrate.**
 
-If the repository definition uses `pkgs.k8s.io`, you're already using the community-hosted repositories and you don't need to take any action.
+If the repository definition uses `pkgs.k8s.io`, you're already using the
+community-hosted repositories and you don't need to take any action.
 
-On most systems, that repository definition should be located in `/etc/yum.repos.d/kubernetes.repo` (as recommended by the Kubernetes documentation), but on some systems it might be in a different location.
+On most systems, that repository definition should be located in `/etc/yum.repos.d/kubernetes.repo`
+(as recommended by the Kubernetes documentation), but on some systems it might be
+in a different location.
 
-If you can't find a repository definition related to Kubernetes, it's likely that you don't use package managers to install Kubernetes and you don't need to take any action.
+If you can't find a repository definition related to Kubernetes, it's likely that you
+don't use package managers to install Kubernetes and you don't need to take any action.
 
 ## How can I migrate to the new community-operated repositories?
 
-For more information on how to migrate to the new community managed packages, please refer to the [announcement blog post for `pkgs.k8s.io`](/blog/2023/08/15/pkgs-k8s-io-introduction/).
+For more information on how to migrate to the new community
+managed packages, please refer to the
+[announcement blog post for `pkgs.k8s.io`](/blog/2023/08/15/pkgs-k8s-io-introduction/).
 
 ## Why is the Kubernetes project making this change?
 
-Kubernetes has been publishing packages solely to the Google-hosted repository since Kubernetes v1.5, or the past **seven** years! Following in the footsteps of migrating to our community-managed registry, registry.k8s.io, we are now migrating the Kubernetes package repositories to our own community-managed infrastructure. We’re thankful to Google for their continuous hosting and support all these years, but this transition marks another big milestone for the project’s goal of migrating to complete community-owned infrastructure.
+Kubernetes has been publishing packages solely to the Google-hosted repository
+since Kubernetes v1.5, or the past **seven** years! Following in the footsteps of
+migrating to our community-managed registry, `registry.k8s.io`, we are now migrating the
+Kubernetes package repositories to our own community-managed infrastructure. We’re
+thankful to Google for their continuous hosting and support all these years, but
+this transition marks another big milestone for the project’s goal of migrating
+to complete community-owned infrastructure.
 
 ## Is there a Kubernetes tool to help me migrate?
 
-We don't have any announcement to make about tooling there. As a Kubernetes user, you have to manually modify your configuration to use the new repositories. Automating the migration from the legacy to the community-owned repositories is technically challenging and we want to avoid any potential risks associated with this.
+We don't have any announcement to make about tooling there. As a Kubernetes user, you
+have to manually modify your configuration to use the new repositories. Automating
+the migration from the legacy to the community-owned repositories is technically
+challenging and we want to avoid any potential risks associated with this.
 
 ## Acknowledgments
 
-First of all, we want to acknowledge the contributions from Alphabet. Staff at Google have provided their time; Google as a business has provided both the infrastructure to serve packages, and the security context for giving those packages trustworthy digital signatures.
+First of all, we want to acknowledge the contributions from Alphabet. Staff at Google
+have provided their time; Google as a business has provided both the infrastructure
+to serve packages, and the security context for giving those packages trustworthy
+digital signatures.
 These have been important to the adoption and growth of Kubernetes.
 
-Releasing software might not be glamorous but it's important. Many people within the Kubernetes contributor community have contributed to the new way that we, as a project, have for building and publishing packages.
+Releasing software might not be glamorous but it's important. Many people within
+the Kubernetes contributor community have contributed to the new way that we, as a
+project, have for building and publishing packages.
 
-And finally, we want to once again acknowledge the help from SUSE. OpenBuildService, from SUSE, is the technology
-that the powers the new community-managed package repositories.
+And finally, we want to once again acknowledge the help from SUSE. OpenBuildService,
+from SUSE, is the technology that the powers the new community-managed package repositories.