本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
k8s.gcr.io 重定向到 registry.k8s.io - 你需要知道什么
3 月 20 日星期一，k8s.gcr.io 镜像库将被重定向到社区拥有的镜像库 registry.k8s.io。
TL;DR: 关于此更改你需要知道什么
- 3 月 20 日星期一，来自旧镜像库 k8s.gcr.io 的流量将被重定向到 registry.k8s.io，最终目标是淘汰 k8s.gcr.io。
- 如果你在受限环境中运行，并应用了严格的域名或 IP 地址访问策略，且仅限于 k8s.gcr.io，那么在 k8s.gcr.io 开始重定向到新镜像库后，镜像拉取将无法工作。
- 一小部分非标准客户端不处理镜像库的 HTTP 重定向，需要直接指向 registry.k8s.io。
- 重定向是帮助用户进行切换的权宜之计。已弃用的 k8s.gcr.io 镜像库将在某个时候被淘汰。请尽快更新你的清单，以指向 registry.k8s.io。
- 如果你托管自己的镜像库，也可以将需要的镜像复制到那里，以减少对社区拥有的镜像库的流量。
如果你认为自己可能会受到影响，或者想了解更多关于此更改的信息，请继续阅读。
我如何检查自己是否受到影响？
要测试到 registry.k8s.io 的连接性以及是否能够从中拉取镜像，可以在你选择的命名空间中执行以下示例命令
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：如果你无法直接访问集群，或者管理许多集群——最好的方法是在你的清单和 chart 中搜索 "k8s.gcr.io"。
选项 4：如果你希望阻止基于 k8s.gcr.io 的镜像在你的集群中运行，AWS EKS 最佳实践仓库中提供了 Gatekeeper 和 Kyverno 的示例策略，这些策略将阻止它们被拉取。你可以在任何 Kubernetes 集群中使用这些第三方策略。
选项 5：作为最后可能的选项，你可以使用变更准入 Webhook（Mutating Admission Webhook）来动态更改镜像地址。这只应被视为更新清单之前的权宜之计。你可以在 k8s-gcr-quickfix 中找到一个（第三方的）变更 Webhook 和 Kyverno 策略。
为什么 Kubernetes 要更换到不同的镜像库？
k8s.gcr.io 托管在一个专门为 Kubernetes 项目设置的自定义Google 容器镜像库 (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 将不会获得任何新的发布、补丁或安全更新。它将继续可用以帮助人们迁移，但它将来会被完全淘汰。
我还有问题，应该去哪里？
有关 registry.k8s.io 的更多信息以及开发它的原因，请参阅 registry.k8s.io：更快、更便宜且正式可用。
如果你想了解更多关于镜像冻结以及将在那里提供的最后批次镜像的信息，请参阅博文：k8s.gcr.io 镜像库将从 2023 年 4 月 3 日起冻结。
有关 registry.k8s.io 的架构及其请求处理决策树的信息可以在 kubernetes/registry.k8s.io 仓库中找到。
如果你认为在新镜像库或重定向方面遇到了错误，请在 kubernetes/registry.k8s.io 仓库中提出一个 issue。在创建新 issue 之前，请检查是否已经有与你所见类似的问题。