Google Kubernetes Engine へのデプロイ

このガイドでは、Artifact Registry からイメージを pull して Google Kubernetes Engine にデプロイする方法について説明します。自己ホスト型またはサードパーティの Kubernetes サービスにデプロイする場合は、Artifact Registry からイメージを pull する前に Google Cloud への認証を構成する必要があります。Google Cloud の外部にある Kubernetes ワークロードから Google Cloud への認証を行う方法については、Kubernetes との Workload Identity 連携を構成するをご覧ください。

Google Kubernetes Engine は、Docker リポジトリから直接イメージを pull できます。一部のバージョンには、Artifact Registry Docker リポジトリからイメージを pull するための事前構成サポートが含まれています。

要件

このセクションでは、GKE と統合するための要件について説明します。

権限

GKE は、ノードプールまたはクラスタの作成時に次のデフォルトを使用します。

Compute Engine のデフォルトのサービスアカウントがノードの ID となっています。基本編集者ロールの付与を無効にしている場合、このデフォルトのサービスアカウントには Artifact Registry の読み取りロール（roles/artifactregistry.reader）が設定されています。
デフォルトのサービスアカウントで作成したノードには、Compute Engine のデフォルトのアクセススコープ（ストレージへの読み取り専用アクセス権を含む）が設定されています。既存のノードのアクセススコープは変更できません。

これらのデフォルトを使用すると、GKE は同じ Google Cloud プロジェクトの Artifact Registry リポジトリからイメージを pull できます。ノードからイメージを push する場合、プロジェクト間でイメージを pull または push する場合、ユーザー指定のサービスアカウントを使用する場合、またはデフォルト設定でサポートされていない他の要件がある場合は、アクセスの構成についてアクセス制御のドキュメントをご覧ください。

「アクセスが拒否されました」というエラーが発生した場合は、権限拒否エラーをご覧ください。

GKE バージョン

次の表に、同じプロジェクトの Docker リポジトリからコンテナを pull するデフォルトの権限を持つクラスタを作成するために必要な GKE の最小バージョンを示します。

バージョン	最低限必要なパッチ
1.14	1.14.10-gke.22
1.15	1.15.9-gke.8

GKE のバージョンが最小バージョンよりも前の場合は、Kubernetes imagePullSecret を構成して GKE がイメージを pull できるようにする必要があります。

GKE が Artifact Registry とは異なるプロジェクトにある場合、GKE ノードが使用するサービスアカウントに Artifact Registry の権限を付与します。デフォルトでは、ノードは Compute Engine のデフォルトのサービスアカウントを使用します。

イメージを実行する

次のコマンドを使用して、Google Kubernetes Engine クラスタで Artifact Registry イメージを実行できます。

kubectl run [NAME] --image=LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

ここで

LOCATION は、リポジトリのリージョンまたはマルチリージョンのロケーションです。
PROJECT は、Google Cloud コンソールプロジェクト ID です。プロジェクト ID にコロン（:）が含まれている場合は、ドメインをスコープとするプロジェクトをご覧ください。
REPOSITORY は、イメージが保存されるリポジトリの名前です。
IMAGE は、リポジトリ内のイメージの名前です。
TAG は、pull するイメージバージョンのタグです。

Kubernetes コマンドの詳細については、kubectl の概要をご覧ください。

containerd ノードイメージのトラブルシューティング

GKE ノードバージョン 1.19 以降、Linux ノードのデフォルトノードイメージは、Docker（cos）バリアントを含む Container-Optimized OS から、Containerd（cos_containerd）バリアントが含まれている Container-Optimized OS に代わっています。

Docker バイナリは、containerd をランタイムとして使用する Linux ノードで使用できますが、使用しないことをおすすめします。Docker では、Kubernetes が containerd ノードで実行するコンテナを管理しません。このため、Docker コマンドや Docker API を使用して、実行中の Kubernetes コンテナの表示や操作を行うことはできません。

Linux ノードでのデバッグやトラブルシューティングのため、Kubernetes コンテナランタイム用にビルドされたポータブルコマンドラインツール crictl を使用して、containerd と対話できます。crictl は、コンテナやイメージの表示、ログの読み取り、コンテナでのコマンドの実行などの一般的な機能をサポートします。

詳細については、crictl ユーザーガイドと containerd に関する GKE ドキュメントをご覧ください。

Windows Server ノードの場合、containerd デーモンは containerd という名前の Windows サービスとして実行されます。ログは C:\etc\kubernetes\logs\containerd.log ディレクトリに格納され、ログエクスプローラの LOG NAME: "container-runtime" に表示されます。

公開 Artifact Registry リポジトリからの pull

containerd ノードを含む GKE クラスタにイメージをデプロイしたら、SSH を使用して VM インスタンスに接続し、crictl コマンドを実行してトラブルシューティングを行うことができます。

公開 Artifact Registry リポジトリには認証は必要ありません。crictl は、限定公開 Artifact Registry リポジトリ内のイメージを pull するためにも使用できます。

Console

Google Cloud コンソールで、[VM インスタンス] ページに移動します。

[VM インスタンス] に移動
仮想マシンインスタンスのリストで、接続するインスタンスの行にある [SSH] の横の矢印をクリックします。

注: Google Cloud コンソールから VM に接続すると、Compute Engine によって一時的な SSH 認証鍵が自動的に作成されます。SSH 認証鍵の詳細については、Linux VM への SSH 接続をご覧ください。
[ブラウザウィンドウで開く] を選択するか、プルダウンオプションから任意の接続方法を選択します。
Google Cloud コンソールで新しいターミナルウィンドウが開きます。crictl を使用して、Artifact Registry からイメージを pull します。
```
crictl pull IMAGE_LOCATION:TAG
```
出力は次のようになります。
```
Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5
```
Artifact Registry 非公開リポジトリからイメージを pull する場合は、リポジトリに対して認証する必要があります。アクセストークンを使用して認証情報を指定できます。

gcloud

Google Cloud CLI が最新バージョンであることを確認します。
```
gcloud components update
```
VM に接続します。
```
gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME
```
次のように置き換えます。
- PROJECT_ID: VM が含まれているプロジェクトの ID
- ZONE: VM が存在するゾーンの名前
- VM_NAME: VM の名前
Google Cloud CLI のデフォルトプロパティを設定している場合、このコマンドの --project フラグと --zone フラグは省略できます。次に例を示します。
```
gcloud compute ssh VM_NAME
```
SSH 認証鍵をまだ作成していない場合は、SSH keygen によって生成されます。プロンプトが表示されたら、パスフレーズを入力するか、空白のままにします。
crictl を使用して Artifact Registry からイメージを pull します。
```
crictl pull IMAGE_LOCATION:TAG
```
出力は次のようになります。
```
Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5
```
Artifact Registry 非公開リポジトリからイメージを pull する場合は、リポジトリに対して認証する必要があります。アクセストークンを使用して認証情報を指定できます。

非公開 Artifact Registry リポジトリからの pull

Console

Google Cloud コンソールで、[VM インスタンス] ページに移動します。

[VM インスタンス] に移動
仮想マシンインスタンスのリストで、接続するインスタンスの行にある [SSH] の横の矢印をクリックします。

注: Google Cloud コンソールから VM に接続すると、Compute Engine によって一時的な SSH 認証鍵が自動的に作成されます。SSH 認証鍵の詳細については、Linux VM への SSH 接続をご覧ください。
プルダウンオプションから [ブラウザウィンドウで開く] を選択します。

Google Cloud コンソールで新しいターミナルウィンドウが開きます。curl を使用して、Compute Engine サービスアカウントのアクセストークンを生成します。

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"

出力は、次の例のようになります。

"access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
sh","expires_in":3526,"token_type":"Bearer"}

返された出力から access_token の値を引用符なしでコピーします。

crictl pull --creds と前の手順でコピーした access_token 値を使用してイメージを pull します。

crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

出力は次のようになります。

Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

gcloud

Google Cloud CLI が最新バージョンであることを確認します。
```
gcloud components update
```
VM に接続します。
```
gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME
```
次の変数を置き換えます。
- PROJECT_ID: VM が含まれているプロジェクトの ID
- ZONE: VM が存在するゾーンの名前
- VM_NAME: VM の名前
Google Cloud CLI のデフォルトプロパティを設定している場合、このコマンドの --project フラグと --zone フラグは省略できます。次に例を示します。
```
gcloud compute ssh VM_NAME
```
SSH 認証鍵をまだ作成していない場合は、SSH keygen によって生成されます。プロンプトが表示されたら、パスフレーズを入力するか、空白のままにします。

curl を使用して、Compute Engine サービスアカウントのアクセストークンを生成します。

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"

出力は次のようになります。

"access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
sh","expires_in":3526,"token_type":"Bearer"}

返された出力から access_token の値を引用符なしでコピーします。

crictl pull --creds と前の手順でコピーした access_token 値を使用してイメージを pull します。

crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

出力は次のようになります。

Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

crictl を使用すると、デベロッパーは Kubernetes コンポーネントを設定することなくランタイムをデバッグできます。コマンドの一覧については、crictl のドキュメントと Kubernetes デバッグのドキュメントをご覧ください。