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 没有提供更早版本的官方 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 的发行版上，仓库定义（sources）位于 /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 是支持新的社区托管软件包仓库的技术。