作者：Bob Killen (Google), Chris Short (AWS), Jeremy Rickard (Microsoft), Marko Mudrinić (Kubermatic), Tim Bannister (The Scale Factory)
译者：Mengjiao Liu (DaoCloud)
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 日 冻结仓库的内容。
请继续阅读以了解这对于作为用户或分发商的你意味着什么，
以及你可能需要采取哪些步骤。
作为 Kubernetes 最终用户，这对我有何影响？
此更改影响直接安装 Kubernetes 的上游版本的用户，
无论是按照官方手动安装
和升级说明，
还是通过使用 Kubernetes 安装工具，该安装工具使用 Kubernetes 项目提供的软件包。
如果你在自己的 PC 上运行 Linux 并使用旧软件包仓库安装了 kubectl，则此更改也会影响你。
我们稍后将解释如何检查是否你会受到影响。
如果你使用完全托管的 Kubernetes，例如从云提供商获取服务，
那么只有在你还使用旧仓库中的软件包在你的 Linux PC 上安装 kubectl 时，
你才会受到此更改的影响。云提供商通常使用他们自己的 Kubernetes 发行版，
因此他们不使用 Kubernetes 项目提供的软件包；更重要的是，如果有其他人为你管理 Kubernetes，
那么他们通常会负责该检查。
如果你使用的是托管的控制平面
但你负责自行管理节点，并且每个节点都运行 Linux，
你应该检查你是否会受到影响。
如果你按照官方的安装和升级说明自己管理你的集群，
请按照本博客文章中的说明迁移到（新的）社区拥有的软件包仓库。
如果你使用的 Kubernetes 安装程序使用 Kubernetes 项目提供的软件包，
请检查安装程序工具的通信渠道，了解有关你需要采取的步骤的信息，最后如果需要，
请与维护人员联系，让他们了解此更改。
下图以可视化形式显示了谁受到此更改的影响（单击图表可查看大图）：
这对我作为 Kubernetes 分发商有何影响？
如果你将旧仓库用作项目的一部分（例如 Kubernetes 安装程序工具），
则应尽快迁移到社区拥有的仓库，并告知用户此更改以及他们需要采取哪些步骤。
变更时间表
- 2023 年 8 月 15 日：Kubernetes 宣布推出一个新的社区管理的 Kubernetes 组件 Linux 软件包源
- 2023 年 8 月 31 日：（本公告） Kubernetes 正式弃用旧版软件包仓库
- 2023 年 9 月 13 日（左右）：Kubernetes 将冻结旧软件包仓库（
apt.kubernetes.io和yum.kubernetes.io）。
冻结将计划于 2023 年 9 月发布补丁版本后立即进行。
计划于 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 项目无法对这会持续多久提供任何保证。
已弃用的旧仓库及其内容可能会在未来随时删除，恕不另行通知。
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，或者 /etc/dnf/dnf.conf 和 /etc/dnf/repos.d/
如果你使用的是 dnf 软件包管理器。检查这些位置并尝试找到如下所示的软件包仓库定义：
[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 的员工投入了他们的时间；
作为一家企业，谷歌既提供了服务于软件包的基础设施，也提供了为这些软件包提供可信数字签名的安全上下文。
这些对于 Kubernetes 的采用和成长非常重要。
发布软件可能并不那么引人注目，但很重要。Kubernetes
贡献者社区中的许多人都为我们作为一个项目构建和发布软件包的新方法做出了贡献。
最后，我们要再次感谢 SUSE 的帮助。SUSE 的 OpenBuildService
为新的社区管理的软件包仓库提供支持的技术。
