コンテンツに移動
Containers & Kubernetes

Kubernetes k8s.gcr.io のリダイレクト: Anthos または GKE ユーザーに必須の情報

2023年4月7日
Google Cloud Japan Team

※この投稿は米国時間 2023 年 3 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

2022 年 11 月、オープンソースの Kubernetes プロジェクトが、新しいイメージ レジストリ registry.k8s.gcr.io の一般提供が正式に開始されたことを発表しました。この新しいレジストリは以前の k8s.gcr.io レジストリの後継となるもので、k8s.gcr.io は 2023 年 4 月 3 日以降、一切更新されなくなります。この移行を支援するため、また前の Kubernetes リリースとツールのユーザーが期限内に確実にサポート対象バージョンに更新できるように、Kubernetes プロジェクトは Google と連携して、2023 年 3 月 20 日から段階的に k8s.gcr.io から registry.k8s.io へのイメージ リクエストのリダイレクトを開始しました。

本日の投稿では、今回の対応の内容と理由に加えて、registry.k8s.io に移行して将来的に問題が発生しないようにするためにユーザーが取るべきアクションというより重要なポイントについて説明します。

Kubernetes が新しいレジストリに移行する理由

Google は Kubernetes プロジェクトをオープンソース化し、Cloud Native Computing Foundation(CNCF)を創設時から支援しています。現在、このプロジェクトと CNCF は数百万人のユーザーを抱え、大規模なベンダーおよびプロジェクトが構成する世界レベルのエコシステムによって支えられています。registry.k8s.io は、Google、Amazon、VMware などの Kubernetes コミュニティ メンバーによってビルドされた、ベンダーに依存しない新しいレジストリであり、プロジェクトのコンテナ イメージのためのグローバル CDN を実現し、負荷を複数のクラウド プロバイダに分散します。新しいレジストリはよりこのプロジェクトに適しており、すべての Kubernetes ユーザーの操作性を向上させます。

このレジストリについて詳しくは、リリースに関する Kubernetes コミュニティのブログ投稿をご覧ください。

リクエストをリダイレクトする理由

リダイレクトは、registry.k8s.io への移行を円滑に進めるための一時的な措置です。Kubernetes コミュニティが k8s.gcr.io の将来的な廃止を計画しているため、クラスタは長期的にこれに依存するべきではありません。

幸いなことに、registry.k8s.io は k8s.gcr.io のミラーであるため、大部分のユーザーは直接入れ替えることができます。ただし、Google Kubernetes Engine(GKE)または AnthosVPC Service Controls などの厳格なドメイン名または IP アドレス アクセス ポリシーが適用される制限された環境で使用しており、k8s.gcr.io の Kubernetes コミュニティ イメージに依存している場合は影響を受ける可能性があるため、今後も互換性を維持するには調整を加える必要があります。

リダイレクトの影響を受けるクラスタ構成

影響を受ける可能性があるのは、VPC Service Controls などのネットワーク アクセス ツールを使用して、厳格なドメイン名または IP アドレス アクセス ポリシーが適用される制限された環境で実行されている GKE および Anthos クラスタで実行されるワークロードです。

registry.k8s.io の接続の確認

registry.k8s.io への接続とイメージのアクセスをテストするには、次のコマンドを実行します。

読み込んでいます...

出力が次のようになった場合は、レジストリ変更の影響はありません。

読み込んでいます...

影響を受ける場合に表示されるエラー

ErrImagePull エラーまたは ImagePullBackOff エラーが増える可能性があります。コンテナの作成が失敗し、k8s.gcr.io を参照するコンテナ イメージについて、FailedCreatePodSandBox という警告が表示されることがあります。

リダイレクトは実行中のワークロードには影響しません。ワークロード数をスケールアップするとき、または k8s.gcr.io を参照する新しいワークロードを作成するときにエラーが発生します。

クラスタ内にある、影響を受けるイメージを検出する方法

Kubernetes コミュニティによって次のような方法が考案されています。

マニフェストとチャートをスキャンする
複数のクラスタを管理している場合やクラスタに直接アクセスできない場合は、マニフェストとチャートで「k8s.gcr.io」を検索します。この方法は、大規模な環境や複雑な環境におすすめです。

kubectl を使用する
k8s.gcr.io に対するイメージ参照を含む Pod を特定します。

読み込んでいます...

注: マニフェストを直接更新すると、このコマンドから返される一部の Pod の参照が変更されないことがあります。システムレベルのサービスまたは他のコントローラによって制御される Pod は、ソースで更新しないと変更が反映されない場合があります。

krew プラグインを使用する

community-images という kubectl krew プラグインを使用します。このプラグインは、k8s.gcr.io を参照するコンテナを実行する Pod すべてをスキャンしてレポートを生成します。

krew をインストール済みの場合は、community-images プラグインをインストールします。

読み込んでいます...

次に、レポートを生成します。

読み込んでいます...

このプラグインをインストールする他の方法については、GitHub の kubernetes-sigs/community-images リポジトリをご覧ください。

注: kubectl を使用する場合と同様、マニフェストを直接更新すると、このコマンドから返される一部の Pod の参照が変更されないことがあります。システムレベルのサービスまたは他のコントローラによって制御される Pod は、ソースで更新しないと変更が反映されない場合があります。

サードパーティのツールを使用して k8s.gcr.io への参照を含むコンテナを検出およびブロックするその他の方法については、Kubernetes のブログをご覧ください。

ワークロードが影響を受ける場合の対処方法

VPC Service Controls を使用している場合、または同様の制限がある環境の場合、registry.k8s.io へのアクセスを許可するルールを追加します。ルールを追加できない場合、前方互換性を持たせるためのおすすめの方法は、gcrane を使用して、影響を受けるイメージを Artifact Registry のプライベート インスタンスにミラーリングし、新しい場所にあるイメージを参照するようにマニフェストを更新します。

その他の方法や全般的なサポートが必要な場合は、Google Cloud サポートまでお問い合わせください。

リダイレクトによる影響を受けない場合のイメージ参照の更新の必要性

更新が必要です。リダイレクトは一時的な措置であり、Kubernetes コミュニティは今後、k8s.gcr.io のサポートを段階的に終了することを計画しています。

困ったときは

不明な点がある場合や問題が発生した場合は、このトピックに関するコミュニティのリソースを確認するか、通常のサポート チャネルからご連絡ください。


- Google オープンソース プログラム オフィス担当プログラム マネージャー Bob Killen
投稿先