本文已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已不正确。

k8s.gcr.io 重定向到 registry.k8s.io - 您需要了解的

作者：Bob Killen (Google)，Davanum Srinivas (AWS)，Chris Short (AWS)，Frederico Muñoz (SAS Institute)，Tim Bannister (The Scale Factory)，Ricky Sadowski (AWS)，Grace Nguyen (Expo)，Mahamed Ali (Rackspace Technology)，Mars Toktonaliev (独立)，Laura Santamaria (Dell)，Kat Cosgrove (Dell) |

3 月 20 日星期一，k8s.gcr.io 镜像仓库将重定向到社区拥有的镜像仓库，即 registry.k8s.io。

TL;DR: 关于此变更你需要了解的内容

  • 3 月 20 日星期一，来自旧的 k8s.gcr.io 镜像仓库的流量将重定向到 registry.k8s.io，最终目标是淘汰 k8s.gcr.io。
  • 如果你在受限环境中运行，并且应用了仅限于 k8s.gcr.io 的严格域名或 IP 地址访问策略，那么在 k8s.gcr.io 开始重定向到新仓库后，镜像拉取将无法工作。 
  • 一小部分非标准客户端无法处理镜像仓库的 HTTP 重定向，需要直接指向 registry.k8s.io。
  • 重定向是一个权宜之计，旨在帮助用户完成切换。废弃的 k8s.gcr.io 镜像仓库将在某个时候逐步淘汰。请尽快更新你的 Manifest 指向 registry.k8s.io。
  • 如果你托管自己的镜像仓库，也可以将所需的镜像复制到那里，以减少社区拥有的仓库的流量。

如果你认为自己可能受到影响，或者想了解更多关于此变更的信息，请继续阅读。

如何检查我是否受到影响？

为了测试与 registry.k8s.io 的连接并能从那里拉取镜像，这里提供一个示例命令，可以在你选择的 Namespace 中执行

kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- date

当你运行上述命令时，如果一切正常，你会看到以下结果

$ kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- date
Fri Feb 31 07:07:07 UTC 2023
pod "hello-world" deleted

如果我受到影响，会看到什么样的错误？

错误可能取决于你使用的容器运行时以及被路由到的端点，但应该会显示诸如 ErrImagePull、ImagePullBackOff 或带有警告 FailedCreatePodSandBox 的容器创建失败信息。

下面是一个示例错误消息，显示由于未知证书导致代理部署拉取失败

FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority

哪些镜像会受到影响？

k8s.gcr.io 上的所有镜像都将受到此变更的影响。k8s.gcr.io 托管了许多 Kubernetes 发布版本之外的镜像。大量 Kubernetes 子项目也将其镜像托管在那里。一些示例包括 dns/k8s-dns-node-cache、ingress-nginx/controller 和 node-problem-detector/node-problem-detector 镜像。

我受到影响了。我该怎么办？

对于在受限环境中运行并受到影响的用户，最好的选择是将所需镜像复制到私有仓库或在其仓库中配置拉取缓存。

有几种工具可以在仓库之间复制镜像；crane 就是其中之一，可以使用 crane copy SRC DST 将镜像复制到私有仓库。还有一些特定于供应商的工具，例如 Google 的 gcrane，它们执行类似的功能，但针对其平台进行了优化。

如何找到哪些镜像正在使用旧版仓库，并修复它们？

选项 1：请参阅我们之前的博客文章中的一行 kubectl 命令

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

选项 2：已开发了一个名为 community-images 的 kubectl krew 插件，它将扫描并报告任何使用 k8s.gcr.io 端点的镜像。

如果你安装了 krew，可以使用以下命令安装它

kubectl krew install community-images

并使用以下命令生成报告

kubectl community-images

有关其他安装方法和示例输出，请查看仓库：kubernetes-sigs/community-images。

选项 3：如果你无法直接访问集群，或者管理着许多集群 - 最好的方法是在你的 Manifest 和 Chart 中搜索 “k8s.gcr.io”。

选项 4：如果你希望阻止基于 k8s.gcr.io 的镜像在你的集群中运行，Gatekeeper 和 Kyverno 的示例策略可在 AWS EKS 最佳实践仓库中找到，这些策略将阻止这些镜像被拉取。你可以在任何 Kubernetes 集群中使用这些第三方策略。

选项 5：作为最后一个可能选项，你可以使用修改性准入 Webhook (Mutating Admission Webhook) 动态更改镜像地址。这应仅被视为在你的 Manifest 更新完成之前的权宜之计。你可以在 k8s-gcr-quickfix 中找到一个 (第三方) 修改性 Webhook 和 Kyverno 策略。

为什么 Kubernetes 更换了镜像仓库？

k8s.gcr.io 托管在专门为 Kubernetes 项目设置的自定义 Google Container Registry (GCR) 域名上。自项目成立以来，这运行良好，我们感谢 Google 提供的这些资源。但如今，还有其他云提供商和供应商也希望托管镜像，以便为其平台上的用户提供更好的体验。除了 Google 去年再次承诺捐赠 300 万美元支持项目基础设施外，Amazon Web Services 在底特律举行的 Kubecon NA 2022 主题演讲中宣布了相应的捐赠。这将为用户提供更好的体验 (服务器更近 = 下载更快)，同时减少 GCR 的出口带宽和成本。

有关此变更的更多详细信息，请查看registry.k8s.io: 更快、更便宜且普遍可用 (GA)。

为什么会进行重定向？

该项目去年在 1.25 版本中切换到了registry.k8s.io；然而，大部分镜像拉取流量仍然指向旧端点 k8s.gcr.io。这对于我们项目来说是不可持续的，因为它没有利用其他提供商捐赠给项目的资源，并且我们面临因服务此流量而资金耗尽的风险。

重定向将使项目能够利用这些新资源，显著降低我们的出口带宽成本。我们预计此变更仅影响在受限环境中运行或使用不正确处理重定向的非常旧客户端的一小部分用户。

k8s.gcr.io 将会怎样？

除了重定向，k8s.gcr.io 将被冻结，2023 年 4 月 3 日之后不会更新新的镜像。k8s.gcr.io 将不会获得任何新的发布、补丁或安全更新。它将继续可用以帮助人们迁移，但将来会完全淘汰。请尽快将你的 Manifest 更新到 registry.k8s.io。

我还有疑问，应该去哪里？

有关 registry.k8s.io 及其开发原因的更多信息，请参阅registry.k8s.io: 更快、更便宜且普遍可用。

如果你想了解更多关于镜像冻结以及在那里可用的最新镜像，请参阅博客文章：k8s.gcr.io 镜像仓库将从 2023 年 4 月 3 日起冻结。

有关 registry.k8s.io 的架构及其请求处理决策树的信息可以在 kubernetes/registry.k8s.io 仓库中找到。

如果你认为在新仓库或重定向方面遇到了 Bug，请在 kubernetes/registry.k8s.io 仓库中提交一个 Issue。请在创建新 Issue 之前检查是否已有与你遇到的类似问题已打开。