マルチクラスタ Ingress を使用してマルチクラスタ GKE 環境をアップグレードする

Last reviewed 2022-12-15 UTC

Autopilot Standard

このチュートリアルでは、マルチクラスタ Ingress を使用してマルチクラスタ Google Kubernetes Engine（GKE）環境をアップグレードする方法について説明します。このチュートリアルは、プロセス、アーキテクチャ、用語について解説しているマルチクラスタ Ingress を使用したマルチクラスタ GKE のアップグレードのドキュメントの後続チュートリアルです。このチュートリアルをお読みになる前に、コンセプトドキュメントを確認することをおすすめします。

マルチクラスタ Ingress（MCI）、マルチクラスタ Gateway（MCG）、スタンドアロンネットワークエンドポイントグループを使用するロードバランサ（LB とスタンドアロン NEG）の詳細な比較については、GKE のマルチクラスタロードバランシング API を選択するをご覧ください。

このドキュメントは、GKE クラスタのフリートを管理する Google Cloud 管理者を対象としています。

GKE クラスタは自動アップグレードすることをおすすめします。自動アップグレードは、Google Cloud によって決定されるリリーススケジュールで、クラスタ（コントロールプレーンとノード）を自動的に更新する、フルマネージドの方法です。オペレーターの介入は不要です。ただし、クラスタのアップグレードの方法とタイミングを詳細に管理する必要がある場合は、このチュートリアルで、アプリがすべてのクラスタで実行される複数のクラスタをアップグレードする方法をご確認ください。その後、マルチクラスタ Ingress を使用して、アップグレード前に一度に 1 つずつクラスタをドレインします。

アーキテクチャ

このチュートリアルでは、次のアーキテクチャを使用します。クラスタは 3 つあり、2 つのクラスタ（blue と green）は、同じアプリがデプロイされている同一クラスタとして機能し、残り 1 つのクラスタ（ingress-config）は、マルチクラスタ Ingress を構成するコントロールプレーンクラスタとして機能します。このチュートリアルでは、2 つのアプリクラスタ（blue クラスタと green クラスタ）にサンプルアプリをデプロイします。

2 つの同一クラスタと 1 つのコントロールプレーンクラスタのアーキテクチャ

目標

3 つの GKE クラスタを作成し、フリートとして登録します。
1 つの GKE クラスタ（ingress-config）を中央構成クラスタとして構成します。
サンプルアプリを他の GKE クラスタにデプロイします。
両方のアプリクラスタで動作しているアプリにクライアントトラフィックを送信するようにマルチクラスタ Ingress を構成します。
アプリに負荷生成ツールを設定し、モニタリングを構成します。
マルチクラスタ Ingress から 1 つのアプリクラスタを削除（ドレイン）し、ドレインされたクラスタをアップグレードします。
マルチクラスタ Ingress を使用して、アップグレードされたクラスタにトラフィックを戻します。

料金

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

このチュートリアルでは、マルチクラスタ Ingress を設定する必要があります。設定は以下のように行います。
- すべてのクラスタで実行される同じアプリ（Namespace、Deployment、Service など）がデプロイされたクラスタを 2 つ以上用意します。
- すべてのクラスタで自動アップグレードをオフにします。
- クラスタは、エイリアス IP アドレス範囲を使用する VPC ネイティブクラスタです。
- HTTP ロードバランシングを有効にします（デフォルトで有効になっています）。
- gcloud --version は 369 以上である必要があります。GKE クラスタの登録手順は、このバージョンかそれ以降のバージョンによって異なります。
Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

プロジェクトセレクタに移動
Google Cloud プロジェクトで課金が有効になっていることを確認します。
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

デフォルトプロジェクトを設定します。

export PROJECT=$(gcloud info --format='value(config.project)')
gcloud config set project ${PROJECT}

GKE、Hub、multiclusteringress の各 API を有効にします。

gcloud services enable container.googleapis.com \
                       gkehub.googleapis.com \
                       multiclusteringress.googleapis.com \
                       multiclusterservicediscovery.googleapis.com

環境を設定する

Cloud Shell で、このチュートリアルのファイルを取得するリポジトリのクローンを作成します。
```
cd ${HOME}
git clone https://github.com/GoogleCloudPlatform/gke-multicluster-upgrades.git
```

WORKDIR ディレクトリを作成します。

cd gke-multicluster-upgrades
export WORKDIR=`pwd`

GKE クラスタを作成して Hub に登録する

このセクションでは、3 つの GKE クラスタを作成し、GKE Enterprise Hub に登録します。

GKE クラスタを作成する

Cloud Shell で、次の 3 つの GKE クラスタを作成します。

gcloud container clusters create ingress-config --zone us-west1-a \
--release-channel=None --no-enable-autoupgrade --num-nodes=4 \
--enable-ip-alias --workload-pool=${PROJECT}.svc.id.goog --quiet --async
gcloud container clusters create blue --zone us-west1-b --num-nodes=3 \
--release-channel=None --no-enable-autoupgrade --enable-ip-alias \
--workload-pool=${PROJECT}.svc.id.goog --quiet --async
gcloud container clusters create green --zone us-west1-c --num-nodes=3 \
--release-channel=None --no-enable-autoupgrade --enable-ip-alias \
--workload-pool=${PROJECT}.svc.id.goog --quiet

このチュートリアルでは、単一のリージョンの 3 つのゾーン（us-west1-a、us-west1-b、us-west1-c）にクラスタを作成します。リージョンとゾーンの詳細については、地域とリージョンをご覧ください。

すべてのクラスタが作成されるまで数分かかります。クラスタが実行されていることを確認します。

gcloud container clusters list

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

NAME: ingress-config
LOCATION: us-west1-a
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.233.186.135
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 4
STATUS: RUNNING

NAME: blue
LOCATION: us-west1-b
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 34.82.35.222
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

NAME: green
LOCATION: us-west1-c
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.185.204.26
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

kubeconfig ファイルを作成し、すべてのクラスタに接続して、kubeconfig ファイルにエントリを生成します。
```
touch gke-upgrade-kubeconfig
export KUBECONFIG=gke-upgrade-kubeconfig
gcloud container clusters get-credentials ingress-config \
    --zone us-west1-a --project ${PROJECT}
gcloud container clusters get-credentials blue --zone us-west1-b \
    --project ${PROJECT}
gcloud container clusters get-credentials green --zone us-west1-c \
    --project ${PROJECT}
```
kubeconfig ファイルを作成して、クラスタごとにユーザーとコンテキストを作成し、クラスタに対する認証を作成します。kubeconfig ファイルを作成すると、クラスタ間でコンテキストをすばやく切り替えられるようになります。

kubeconfig ファイルに 3 つのクラスタがあることを確認します。

kubectl config view -ojson | jq -r '.clusters[].name'

次のような出力が表示されます。

gke_gke-multicluster-upgrades_us-west1-a_ingress-config
gke_gke-multicluster-upgrades_us-west1-b_blue
gke_gke-multicluster-upgrades_us-west1-c_green

後で使用できるように、3 つのクラスタのコンテキストを取得します。

export INGRESS_CONFIG_CLUSTER=$(kubectl config view -ojson | jq \
    -r '.clusters[].name' | grep ingress-config)
export BLUE_CLUSTER=$(kubectl config view -ojson | jq \
    -r '.clusters[].name' | grep blue)
export GREEN_CLUSTER=$(kubectl config view -ojson | jq \
    -r '.clusters[].name' | grep green)
echo -e "${INGRESS_CONFIG_CLUSTER}\n${BLUE_CLUSTER}\n${GREEN_CLUSTER}"

次のような出力が表示されます。

gke_gke-multicluster-upgrades_us-west1-a_ingress-config
gke_gke-multicluster-upgrades_us-west1-b_blue
gke_gke-multicluster-upgrades_us-west1-c_green

GKE クラスタをフリートに登録する

クラスタをフリートに登録すると、ハイブリッド環境全体で Kubernetes クラスタを運用できます。フリートに登録されているクラスタは、マルチクラスタ Ingress などの高度な GKE 機能を使用できます。GKE クラスタをフリートに登録するには、Google Cloud サービスアカウントを直接使用するか、または推奨される Workload Identity アプローチを使用します。これにより GKE クラスタ内の Kubernetes サービスアカウントが Identity and Access Management サービスアカウントとして機能します。

3 つのクラスタをフリートとして登録します。

gcloud container fleet memberships register ingress-config \
    --gke-cluster=us-west1-a/ingress-config \
    --enable-workload-identity

gcloud container fleet memberships register blue \
    --gke-cluster=us-west1-b/blue \
    --enable-workload-identity

gcloud container fleet memberships register green \
    --gke-cluster=us-west1-c/green \
    --enable-workload-identity

クラスタが登録されていることを確認します。

gcloud container fleet memberships list

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

NAME: blue
EXTERNAL_ID: 401b4f08-8246-4f97-a6d8-cf1b78c2a91d

NAME: green
EXTERNAL_ID: 8041c36a-9d42-40c8-a67f-54fcfd84956e

NAME: ingress-config
EXTERNAL_ID: 65ac48fe-5043-42db-8b1e-944754a0d725

Hub で multiclusteringress 機能を有効にして、ingress-config クラスタをマルチクラスタ Ingress の構成クラスタとして構成します。
```
gcloud container fleet ingress enable --config-membership=ingress-config
```
上記のコマンドにより、MulticlusterIngress と MulticlusterService の CRD（カスタムリソース定義）が ingress-config クラスタに追加されます。このコマンドが完了するまでに数分かかります。このまま待ってから次のステップに進みます。

マルチクラスタ Ingress 用に ingress-cluster クラスタが正常に構成されていることを確認します。

watch gcloud container fleet ingress describe

出力が次のようになるまで待ちます。

createTime: '2022-07-05T10:21:40.383536315Z'
membershipStates:
  projects/662189189487/locations/global/memberships/blue:
    state:
      code: OK
      updateTime: '2022-07-08T10:59:44.230329189Z'
  projects/662189189487/locations/global/memberships/green:
    state:
      code: OK
      updateTime: '2022-07-08T10:59:44.230329950Z'
  projects/662189189487/locations/global/memberships/ingress-config:
    state:
      code: OK
      updateTime: '2022-07-08T10:59:44.230328520Z'
name: projects/gke-multicluster-upgrades/locations/global/features/multiclusteringress
resourceState:
  state: ACTIVE
spec:
  multiclusteringress:
    configMembership: projects/gke-multicluster-upgrades/locations/global/memberships/ingress-config
state:
  state:
    code: OK
    description: Ready to use
    updateTime: '2022-07-08T10:57:33.303543609Z'
updateTime: '2022-07-08T10:59:45.247576318Z'

watch コマンドを終了するには、Ctrl+C キーを押します。

サンプルアプリケーションを blue クラスタと green クラスタにデプロイする

Cloud Shell で、サンプル whereami アプリを blue クラスタと green クラスタにデプロイします。

kubectl --context ${BLUE_CLUSTER} apply -f ${WORKDIR}/application-manifests
kubectl --context ${GREEN_CLUSTER} apply -f ${WORKDIR}/application-manifests

数分待ってから、blue クラスタと green クラスタ内のすべての Pod のステータスが Running になっていることを確認します。

kubectl --context ${BLUE_CLUSTER} get pods
kubectl --context ${GREEN_CLUSTER} get pods

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

NAME                                   READY   STATUS    RESTARTS   AGE
whereami-deployment-756c7dc74c-zsmr6   1/1     Running   0          74s
NAME                                   READY   STATUS    RESTARTS   AGE
whereami-deployment-756c7dc74c-sndz7   1/1     Running   0          68s.

マルチクラスタ Ingress を構成する

このセクションでは、blue クラスタと green クラスタの両方で実行されているアプリケーションにトラフィックを送信するマルチクラスタ Ingress を作成します。Cloud Load Balancing を使用して、blue クラスタと green クラスタの両方で whereami アプリをバックエンドとして使用するロードバランサを作成します。ロードバランサを作成するには、MultiClusterIngress と 1 つ以上の MultiClusterServices からなる 2 つのリソースが必要です。MultiClusterIngress オブジェクトと MultiClusterService オブジェクトには、単一クラスタコンテキストで使用される既存の Kubernetes Ingress および Service リソースとのマルチクラスタ類似性があります。

Cloud Shell で、MulticlusterIngress リソースを ingress-config クラスタにデプロイします。

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mci.yaml

次のような出力が表示されます。

multiclusteringress.networking.gke.io/whereami-mci created

MulticlusterService リソースを ingress-config クラスタにデプロイします。

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml

次のような出力が表示されます。

multiclusterservice.networking.gke.io/whereami-mcs created

2 つのリソースを比較する手順は次のとおりです。
- MulticlusterIngress リソースを検査します。
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusteringress -o yaml
```
  出力には次のものが含まれます。
```
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080
```
  MulticlusterIngress リソースは Kubernetes Ingress リソースと似ていますが、serviceName 仕様が MulticlusterService リソースを指している点が異なります。
- MulticlusterService リソースを検査します。
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice -o yaml
```
  出力には次のものが含まれます。
```
spec:
  clusters:
  - link: us-west1-b/blue
  - link: us-west1-c/green
  template:
    spec:
      ports:
      - name: web
        port: 8080
        protocol: TCP
        targetPort: 8080
      selector:
        app: whereami
```
  MulticlusterService リソースは Kubernetes Service リソースと似ていますが、clusters 仕様がある点が異なります。clusters の値は、MulticlusterService リソースが作成される登録済みクラスタの一覧です。
- MulticlusterIngress リソースが、MulticlusterService リソースを指すバックエンドサービスを使用してロードバランサを作成したことを確認します。
```
watch kubectl --context ${INGRESS_CONFIG_CLUSTER} \
      get multiclusteringress -o jsonpath="{.items[].status.VIP}"
```
  この処理には最大で 10 分かかります。出力が次のようになるまで待ちます。
```
34.107.246.9
```
  watch コマンドを終了するには、Control+C を押します。

Cloud Shell で、Cloud Load Balancing VIP を取得します。

export GCLB_VIP=$(kubectl --context ${INGRESS_CONFIG_CLUSTER} \
       get multiclusteringress -o json | jq -r '.items[].status.VIP') \
       && echo ${GCLB_VIP}

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

34.107.246.9

curl を使用して、ロードバランサとデプロイされたアプリケーションにアクセスします。

curl ${GCLB_VIP}

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

{
  "cluster_name": "green",
  "host_header": "34.107.246.9",
  "pod_name": "whereami-deployment-756c7dc74c-sndz7",
  "pod_name_emoji": "😇",
  "project_id": "gke-multicluster-upgrades",
  "timestamp": "2022-07-08T14:26:07",
  "zone": "us-west1-c"
}

curl コマンドを繰り返し実行します。blue と green の 2 つのクラスタにデプロイされた whereami アプリケーション間でリクエストがロードバランスされています。

負荷生成ツールを設定する

このセクションでは、Cloud Load Balancing VIP へのクライアントトラフィックを生成する loadgenerator サービスを設定します。両方のクラスタにトラフィックを送信するように MulticlusterService リソースが設定されているため、最初に blue クラスタと green クラスタにトラフィックが送信されます。その後、単一のクラスタにトラフィックを送信するように MulticlusterService リソースを構成します。

クライアントトラフィックを Cloud Load Balancing に送信するように loadgenerator マニフェストを構成します。
```
TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}
```

ingress-config クラスタに loadgenerator をデプロイします。

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/loadgen-manifests

ingress-config クラスタの loadgenerator Pod のステータスが Running であることを確認します。

kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods

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

NAME                             READY   STATUS    RESTARTS   AGE
loadgenerator-5498cbcb86-hqscp   1/1     Running   0          53s
loadgenerator-5498cbcb86-m2z2z   1/1     Running   0          53s
loadgenerator-5498cbcb86-p56qb   1/1     Running   0          53s

いずれかの Pod のステータスが Running でない場合は、数分待ってからコマンドを再度実行します。

トラフィックを監視する

このセクションでは、Google Cloud コンソールを使用して whereami アプリへのトラフィックをモニタリングします。

前のセクションで、Cloud Load Balancing VIP を介して whereami アプリにアクセスすることで、クライアントトラフィックをシミュレートする loadgenerator デプロイメントを設定しました。このような指標は Google Cloud コンソールからモニタリングできます。モニタリングしてアップグレードのクラスタをドレインできるよう、まずモニタリングを設定します（次のセクションで説明します）。

マルチクラスタ Ingress に到達するトラフィックを表示するダッシュボードを作成します。

export DASH_ID=$(gcloud monitoring dashboards create \
    --config-from-file=dashboards/cloud-ops-dashboard.json \
    --format=json | jq  -r ".name" | awk -F '/' '{print $4}')

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

Created [721b6c83-8f9b-409b-a009-9fdf3afb82f8]

Cloud Load Balancing からの指標は Google Cloud コンソールで使用できます。次の URL を生成します。

echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"

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

https://console.cloud.google.com/monitoring/dashboards/builder/721b6c83-8f9b-409b-a009-9fdf3afb82f8/?project=gke-multicluster-upgrades&timeDomain=1h"

ブラウザで、上記のコマンドで生成された URL に移動します。

サンプルアプリケーションへのトラフィックは、負荷生成ツールから blue クラスタと green クラスタの両方（クラスタが含まれる 2 つのゾーンで示されます）に送信されます。タイムライン指標グラフには、両方のバックエンドに送信されるトラフィックが表示されます。k8s1- のマウスオーバー値には、2 つのフロントエンド MulticlusterServices のネットワークエンドポイントグループ（NEG）が blue と green のクラスタで実行されていることが示されます。

注: グラフの色は、blue クラスタと green クラスタに対応していない場合があります。トラフィックがグラフに表示されるまでに数分かかることがあります。

`blue` クラスタをドレインしてアップグレードする

このセクションでは、blue クラスタをドレインします。ドレインされたクラスタは、ロードバランシングプールから削除されます。blue クラスタをドレインすると、アプリケーション宛てのすべてのクライアントトラフィックは green クラスタに移動します。前のセクションで説明したように、このプロセスをモニタリングできます。クラスタのドレイン後に、ドレインされたクラスタをアップグレードできます。クラスタのアップグレードが完了すると、ロードバランシングプールに戻すことができます。上記の手順を繰り返して他のクラスタをアップグレードします（このチュートリアルでは示していません）。

blue クラスタをドレインするには、ingress-cluster クラスタの MulticlusterService リソースを更新し、clusters 仕様から blue クラスタを削除します。

blue クラスタをドレインする

Cloud Shell で、ingress-config クラスタの MulticlusterService リソースを更新します。

kubectl --context ${INGRESS_CONFIG_CLUSTER} \
          apply -f ${WORKDIR}/multicluster-manifests/mcs-green.yaml

clusters 仕様に green クラスタのみがあることを確認します。
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
        -o json | jq '.items[].spec.clusters'
```
次のような出力が表示されます。
```
[
  {
    "link": "us-west1-c/green"
  }
]
```
clusters 仕様に green クラスタのみが表示されるため、green クラスタのみがロードバランシングプールに含まれます。
指標は、Google Cloud コンソールで Cloud Load Balancing の指標から確認できます。次の URL を生成します。
```
echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
```
ブラウザで、前のコマンドで生成された URL に移動します。

このグラフは、green クラスタのみがトラフィックを受信していることを示しています。

`blue` クラスタのアップグレード

これで blue クラスタがクライアントトラフィックを受信できなくなったので、このクラスタ（コントロールプレーンとノード）をアップグレードできます。

Cloud Shell で、クラスタの現在のバージョンを取得します。

gcloud container clusters list

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

NAME: ingress-config
LOCATION: us-west1-a
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.233.186.135
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 4
STATUS: RUNNING

NAME: blue
LOCATION: us-west1-b
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 34.82.35.222
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

NAME: green
LOCATION: us-west1-c
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.185.204.26
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

このチュートリアルを完了するタイミングによって、クラスタのバージョンが異なる場合があります。

ゾーン内で使用可能な MasterVersions のバージョンのリストを取得します。

gcloud container get-server-config --zone us-west1-b --format=json | jq \
'.validMasterVersions[0:20]'

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

[
  "1.24.1-gke.1400",
  "1.23.7-gke.1400",
  "1.23.6-gke.2200",
  "1.23.6-gke.1700",
  "1.23.6-gke.1501",
  "1.23.6-gke.1500",
  "1.23.5-gke.2400",
  "1.23.5-gke.1503",
  "1.23.5-gke.1501",
  "1.22.10-gke.600",
  "1.22.9-gke.2000",
  "1.22.9-gke.1500",
  "1.22.9-gke.1300",
  "1.22.8-gke.2200",
  "1.22.8-gke.202",
  "1.22.8-gke.201",
  "1.22.8-gke.200",
  "1.21.13-gke.900",
  "1.21.12-gke.2200",
  "1.21.12-gke.1700"
]

ゾーン内で使用可能な NodeVersions のバージョンのリストを取得します。

gcloud container get-server-config --zone us-west1-b --format=json | jq \
'.validNodeVersions[0:20]'

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

[
  "1.24.1-gke.1400",
  "1.23.7-gke.1400",
  "1.23.6-gke.2200",
  "1.23.6-gke.1700",
  "1.23.6-gke.1501",
  "1.23.6-gke.1500",
  "1.23.5-gke.2400",
  "1.23.5-gke.1503",
  "1.23.5-gke.1501",
  "1.22.10-gke.600",
  "1.22.9-gke.2000",
  "1.22.9-gke.1500",
  "1.22.9-gke.1300",
  "1.22.8-gke.2200",
  "1.22.8-gke.202",
  "1.22.8-gke.201",
  "1.22.8-gke.200",
  "1.22.7-gke.1500",
  "1.22.7-gke.1300",
  "1.22.7-gke.900"
]

MasterVersions と NodeVersions リストにあり、blue クラスタの現在のバージョンよりも新しい MasterVersion と NodeVersion バージョンの環境変数を設定します。次に例を示します。
```
export UPGRADE_VERSION="1.22.10-gke.600"
```
このチュートリアルでは、1.22.10-gke.600 バージョンを使用します。クラスタのバージョンは、このチュートリアルを完了するタイミングで使用可能になるバージョンによって、異なる場合があります。アップグレードの詳細については、クラスタとノードプールのアップグレードをご覧ください。

注: コントロールプレーンやノードの非互換性の問題を回避するため、クラスタのマイナーバージョンをスキップしないことをおすすめします。詳細については、クラスタのアップグレード中に複数の GKE バージョンをスキップできますか？をご覧ください。
blue クラスタの control plane ノードをアップグレードします。
```
gcloud container clusters upgrade blue \
    --zone us-west1-b --master --cluster-version ${UPGRADE_VERSION}
```
アップグレードを確認するには、Y を押します。

このプロセスが完了するまでに数分かかります。アップグレードが完了するまで待ってから、処理を続行します。

更新が完了すると、次のように出力されます。
```
Updated
[https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
```
blue クラスタのノードをアップグレードします。
```
gcloud container clusters upgrade blue \
    --zone=us-west1-b --node-pool=default-pool \
    --cluster-version ${UPGRADE_VERSION}
```
更新を確認するには、Y を押します。

このプロセスが完了するまでに数分かかります。ノードのアップグレードが完了するまで待ってから、処理を続行します。

アップグレードが完了すると、次のように出力されます。
```
Upgrading blue... Done with 3 out of 3 nodes (100.0%): 3 succeeded...done.
Updated [https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
```

blue クラスタがアップグレードされていることを確認します。

gcloud container clusters list

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

NAME: ingress-config
LOCATION: us-west1-a
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.233.186.135
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 4
STATUS: RUNNING

NAME: blue
LOCATION: us-west1-b
MASTER_VERSION: 1.22.10-gke.600
MASTER_IP: 34.82.35.222
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.10-gke.600
NUM_NODES: 3
STATUS: RUNNING

NAME: green
LOCATION: us-west1-c
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 35.185.204.26
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING

`blue` クラスタをロードバランシングプールに追加し直す

このセクションでは、blue クラスタをロードバランシングプールに追加し直します。

Cloud Shell で、アプリケーションのデプロイが blue クラスタで実行されていることを確認してから、このクラスタをロードバランシングプールに追加し直します。
```
kubectl --context ${BLUE_CLUSTER} get pods
```
出力は次のようになります。
```
NAME                                   READY   STATUS    RESTARTS   AGE
whereami-deployment-756c7dc74c-xdnb6   1/1     Running   0          17m
```

MutliclusterService リソースを更新して、blue クラスタを負荷分散プールに再び追加します。

kubectl --context ${INGRESS_CONFIG_CLUSTER} apply \
        -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml

クラスタ仕様に blue クラスタと green クラスタの両方があることを確認します。
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
        -o json | jq '.items[].spec.clusters'
```
次のような出力が表示されます。
```
[
  {
    "link": "us-west1-b/blue"
  },
  {
    "link": "us-west1-c/green"
  }
]
```
blue クラスタと green クラスタが clusters 仕様に含まれるようになりました。
Cloud Load Balancing の指標は Google Cloud コンソールで使用できます。次の URL を生成します。
```
echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
```
ブラウザで、前のコマンドで生成された URL に移動します。

次のグラフは、blue クラスタと green クラスタの両方がロードバランサ経由で負荷生成ツールからトラフィックを受信していることを示しています。

注: トラフィックの再調整には数分かかることがあります。

これで操作は完了です。マルチクラスタ Ingress を使用して、マルチクラスタアーキテクチャで GKE クラスタを正常にアップグレードしました。
green クラスタをアップグレードするには、blue クラスタをドレインしてアップグレードするプロセスを繰り返します。その際、blue を green にすべて置き換えてください。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

課金を停止する最も簡単な方法は、チュートリアル用に作成した Google Cloud プロジェクトを削除することです。また、リソースを個別に削除することもできます。

クラスタを削除する

Cloud Shell で、blue クラスタと green クラスタの登録を解除して削除します。

gcloud container fleet memberships unregister blue --gke-cluster=us-west1-b/blue
gcloud container clusters delete blue --zone us-west1-b --quiet

gcloud container fleet memberships unregister green --gke-cluster=us-west1-c/green
gcloud container clusters delete green --zone us-west1-c --quiet

ingress-config クラスタから MuticlusterIngress リソースを削除します。
```
kubectl --context ${INGRESS_CONFIG_CLUSTER} delete -f ${WORKDIR}/multicluster-manifests/mci.yaml
```
このコマンドにより、プロジェクトから Cloud Load Balancing リソースが削除されます。

ingress-config クラスタの登録を解除して削除します。

gcloud container fleet memberships unregister ingress-config --gke-cluster=us-west1-a/ingress-config
gcloud container clusters delete ingress-config --zone us-west1-a --quiet

すべてのクラスタが削除されたことを確認します。
```
gcloud container clusters list
```
次のような出力が表示されます。
```
*&lt;null&gt;*
```
kubeconfig ファイルをリセットします。
```
unset KUBECONFIG
```
WORKDIR フォルダを削除します。
```
cd ${HOME}
rm -rf ${WORKDIR}
```

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

マルチクラスタ Ingress の詳細を確認する。
クラスタ間でマルチクラスタ Ingress をデプロイする方法を確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。

マルチクラスタ Ingress を使用してマルチクラスタ GKE 環境をアップグレードする

アーキテクチャ

目標

料金

始める前に

環境を設定する

GKE クラスタを作成して Hub に登録する

GKE クラスタを作成する

GKE クラスタをフリートに登録する

サンプル アプリケーションを blue クラスタと green クラスタにデプロイする

マルチクラスタ Ingress を構成する

負荷生成ツールを設定する

トラフィックを監視する

blue クラスタをドレインしてアップグレードする

blue クラスタをドレインする

blue クラスタのアップグレード

blue クラスタをロード バランシング プールに追加し直す

クリーンアップ

クラスタを削除する

プロジェクトの削除

次のステップ

サンプルアプリケーションを blue クラスタと green クラスタにデプロイする

`blue` クラスタをドレインしてアップグレードする

`blue` クラスタのアップグレード

`blue` クラスタをロードバランシングプールに追加し直す