本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
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 之前，請檢查是否已經有與你所見類似的問題。