Kubernetes 旧软件包仓库将于 2023 年 9 月 13 日冻结
2023 年 8 月 15 日，Kubernetes 项目宣布社区拥有的 Debian 和 RPM 软件包仓库在 pkgs.k8s.io 上正式可用。新的软件包仓库将替代由 Google 托管的旧版软件包仓库：apt.kubernetes.io 和 yum.kubernetes.io。关于 pkgs.k8s.io 的公告博文强调，我们未来将停止向旧版仓库发布软件包。
今天，我们正式弃用旧版软件包仓库（apt.kubernetes.io 和 yum.kubernetes.io），并宣布计划于 2023 年 9 月 13 日起冻结这些仓库的内容。
请继续阅读，以了解这对您作为用户或分发者意味着什么，以及您可能需要采取哪些步骤。
ℹ️ 更新 (2024 年 3 月 26 日): 旧版由 Google 托管的仓库已于 2024 年 3 月 4 日下线。已无法再从旧版由 Google 托管的软件包仓库中安装 Kubernetes 软件包。
作为 Kubernetes 最终用户，这对我有何影响？
此变更会影响到那些直接安装上游 Kubernetes 版本的用户，无论他们是手动遵循官方安装和升级指南，还是使用某个 Kubernetes 安装器来安装由 Kubernetes 项目提供的软件包。
如果您在个人 PC 上运行 Linux，并且使用旧版软件包仓库安装了 kubectl，此变更也会影响到您。稍后我们将解释如何检查您是否受到影响。
如果您使用完全托管的 Kubernetes，例如通过云提供商的服务，那么只有当您也使用旧版仓库的软件包在 Linux PC 上安装了 kubectl 时，此变更才会影响到您。云提供商通常使用自己的 Kubernetes 发行版，因此他们不使用 Kubernetes 项目提供的软件包；更重要的是，如果其他人为您管理 Kubernetes，那么他们通常会负责进行此项检查。
如果您有一个托管的控制平面，但您负责自己管理节点，并且其中任何节点运行 Linux，您应该检查您是否受到影响。
如果您是按照官方安装和升级指南自行管理集群，请遵循本博文中的说明，迁移到（新的）社区拥有的软件包仓库。
如果您使用的 Kubernetes 安装器依赖于 Kubernetes 项目提供的软件包，请查看该安装器工具的沟通渠道，了解您需要采取的步骤，并在必要时联系维护人员，告知他们此变更。
下图以可视化的形式展示了谁会受到此变更的影响（点击图表查看大图）
作为 Kubernetes 分发者，这对我有何影响？
如果您在您的项目中（例如，一个 Kubernetes 安装工具）使用了旧版仓库，您应该尽快迁移到社区拥有的仓库，并通知您的用户此变更以及他们需要采取的步骤。
变更时间线
（2024 年 3 月 26 日更新）
- 2023 年 8 月 15 日
Kubernetes 宣布为 Kubernetes 组件的 Linux 软件包提供一个新的、由社区管理的来源 - 2023 年 8 月 31 日
（本次公告） Kubernetes 正式弃用旧版软件包仓库 - 2023 年 9 月 13 日（大约）
Kubernetes 将冻结旧版软件包仓库（apt.kubernetes.io和yum.kubernetes.io）。冻结将在 2023 年 9 月计划的补丁版本发布后立即进行。 - 2024 年 1 月 12 日
Kubernetes 宣布计划于 2024 年 1 月移除旧版软件包仓库 - 2024 年 3 月 4 日
旧版软件包仓库已被移除。已无法再从旧版软件包仓库安装 Kubernetes 软件包
计划于 2023 年 9 月发布的 Kubernetes 补丁版本（v1.28.2、v1.27.6、v1.26.9、v1.25.14）的软件包将同时发布到社区拥有的仓库和旧版仓库。
在发布 9 月的补丁版本后，我们将冻结旧版仓库，这意味着届时我们将完全停止向旧版仓库发布软件包。
从 2023 年 10 月及以后的 v1.28、v1.27、v1.26 和 v1.25 补丁版本，我们将只向新的软件包仓库（pkgs.k8s.io）发布软件包。
未来的次要版本会怎样？
Kubernetes 1.29 及更高版本的软件包将只发布到社区拥有的仓库（pkgs.k8s.io）。
新的社区拥有的软件包仓库中有哪些可用版本？
从 Kubernetes v1.24.0 开始的版本的 Linux 软件包可在 Kubernetes 软件包仓库（pkgs.k8s.io）中找到。Kubernetes 没有为更早版本的 Kubernetes 提供官方的 Linux 软件包；但是，您的 Linux 发行版可能会提供自己的软件包。
我还能继续使用旧版软件包仓库吗？
（2024 年 3 月 26 日更新）
旧版由 Google 托管的仓库已于 2024 年 3 月 4 日下线。已无法再从旧版由 Google 托管的软件包仓库安装 Kubernetes 软件包。
旧版仓库中现有的软件包在可预见的未来仍将可用。然而，Kubernetes 项目无法对其可用时长提供任何保证。已弃用的旧版仓库及其内容可能在未来的任何时候被移除，且不会再有进一步的通知期。
Kubernetes 项目强烈建议尽快迁移到新的社区拥有的仓库。迁移到新的软件包仓库是使用官方 Kubernetes 软件包的必要条件。
鉴于在 2023 年 9 月 13 日截止日期之后，不会有新版本发布到旧版仓库，您将无法升级到自该日期起的任何补丁或次要版本。
虽然项目尽一切努力发布安全的软件，但未来某一天 Kubernetes 可能会出现高危漏洞，从而需要进行重要的升级。我们今天宣布的建议将帮助您为未来的任何安全更新做好准备，无论是微不足道的还是紧急的。
如何检查我是否正在使用旧版仓库？
检查您是否正在使用旧版仓库的步骤取决于您在集群中使用的是基于 Debian 的发行版（Debian、Ubuntu 等）还是基于 RPM 的发行版（CentOS、RHEL、Rocky Linux 等）。
在集群中的一个节点上运行这些指令。
基于 Debian 的 Linux 发行版
在基于 Debian 的发行版中，仓库定义（源）位于 /etc/apt/sources.list 和 /etc/apt/sources.list.d/。检查这两个位置，并尝试找到一个看起来像这样的软件包仓库定义：
deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main
如果您找到一个像这样的仓库定义，那么您正在使用旧版仓库，需要进行迁移。
如果仓库定义使用的是 pkgs.k8s.io，那么您已经在社区托管的仓库上，无需采取任何行动。
在大多数系统上，这个仓库定义应该位于 /etc/apt/sources.list.d/kubernetes.list（根据 Kubernetes 文档的建议），但在某些系统上它可能位于不同的位置。
如果您找不到与 Kubernetes 相关的仓库定义，很可能您没有使用包管理器来安装 Kubernetes，因此无需采取任何行动。
基于 RPM 的 Linux 发行版
如果您使用 yum 包管理器，仓库定义位于 /etc/yum.repos.d；如果您使用 dnf 包管理器，则位于 /etc/dnf/dnf.conf 和 /etc/dnf/repos.d/。检查这些位置，并尝试找到一个看起来像这样的软件包仓库定义：
[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
如果您找到一个像这样的仓库定义，那么您正在使用旧版仓库，需要进行迁移。
如果仓库定义使用的是 pkgs.k8s.io，那么您已经在社区托管的仓库上，无需采取任何行动。
在大多数系统上，这个仓库定义应该位于 /etc/yum.repos.d/kubernetes.repo（根据 Kubernetes 文档的建议），但在某些系统上它可能位于不同的位置。
如果您找不到与 Kubernetes 相关的仓库定义，很可能您没有使用包管理器来安装 Kubernetes，因此无需采取任何行动。
如何迁移到新的社区运营的仓库？
有关如何迁移到新的社区管理软件包的更多信息，请参阅关于 pkgs.k8s.io 的公告博文。
Kubernetes 项目为何要进行此项变更？
自 Kubernetes v1.5 以来，Kubernetes 一直仅在 Google 托管的仓库上发布软件包，至今已有七年之久！继迁移到我们社区管理的镜像仓库 registry.k8s.io 之后，我们现在正在将 Kubernetes 软件包仓库迁移到我们自己的社区管理的基础设施上。我们感谢 Google 多年来持续的托管和支持，但这次迁移标志着项目向完全社区拥有的基础设施迁移目标的又一个重要里程碑。
是否有 Kubernetes 工具可以帮助我迁移？
关于这方面的工具，我们目前没有任何公告。作为 Kubernetes 用户，您必须手动修改您的配置以使用新的仓库。从旧版仓库到社区拥有的仓库的自动化迁移在技术上具有挑战性，我们希望避免与此相关的任何潜在风险。
致谢
首先，我们要感谢 Alphabet 的贡献。Google 的员工付出了他们的时间；Google 作为一家企业，既提供了服务软件包的基础设施，也为这些软件包提供了可信数字签名的安全环境。这些对于 Kubernetes 的普及和发展至关重要。
发布软件可能并不光鲜，但它很重要。Kubernetes 贡献者社区中的许多人都为我们项目构建和发布软件包的新方式做出了贡献。
最后，我们要再次感谢 SUSE 的帮助。来自 SUSE 的 OpenBuildService 是驱动新的社区管理软件包仓库的技术。