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 包存储库 (pkgs.k8s.io
) 中提供了从 Kubernetes v1.24.0 开始的版本的 Linux 软件包。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 技术为新的社区管理软件包存储库提供了动力。