本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

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 (independent)、Laura Santamaria (Dell)、Kat Cosgrove (Dell) | 2023 年 3 月 10 日星期五

在 3 月 20 日星期一，k8s.gcr.io 登錄檔將重新導向至社群擁有的登錄檔，registry.k8s.io。

摘要：您需要了解的關於此變更的資訊

在 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 登錄檔將在稍後逐步淘汰。請盡快更新您的 manifests 以指向 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。

以下是一個範例錯誤訊息，顯示由於不明憑證而導致 Proxy 部署提取失敗

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：已開發一個 kubectl krew 外掛程式，稱為 community-images，它將掃描並報告任何使用 k8s.gcr.io 端點的映像檔。

如果您已安裝 krew，您可以使用以下命令安裝它

kubectl krew install community-images

並使用以下命令產生報告

kubectl community-images

如需替代安裝方法和範例輸出，請查看儲存庫：kubernetes-sigs/community-images。

選項 3：如果您無法直接存取叢集，或管理許多叢集 - 最好的方法是在您的 manifests 和 charts 中搜尋 "k8s.gcr.io"。

選項 4：如果您希望防止基於 k8s.gcr.io 的映像檔在您的叢集中執行，Gatekeeper 和 Kyverno 的範例策略可在 AWS EKS 最佳實務儲存庫中找到，這將阻止它們被提取。您可以將這些第三方策略與任何 Kubernetes 叢集一起使用。

選項 5：作為最後可能的選項，您可以使用 Mutating Admission Webhook 動態變更映像檔位址。這應該僅被視為臨時措施，直到您的 manifests 已更新為止。您可以在 k8s-gcr-quickfix 中找到 (第三方) Mutating Webhook 和 Kyverno 策略。

為何 Kubernetes 變更為不同的映像檔登錄檔？

k8s.gcr.io 託管在自訂的 Google Container Registry (GCR) 網域上，該網域專門為 Kubernetes 專案設定。自專案成立以來，這一直運作良好，我們感謝 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 儲存庫中開啟一個問題。在您建立新問題之前，請檢查是否已經有與您看到的問題類似的問題開啟。