このチュートリアルでは、マルチクラスタ 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
クラスタ)にサンプルアプリをデプロイします。
目標
- 3 つの GKE クラスタを作成し、フリートとして登録します。
- 1 つの GKE クラスタ(
ingress-config
)を中央構成クラスタとして構成します。 - サンプルアプリを他の GKE クラスタにデプロイします。
- 両方のアプリクラスタで動作しているアプリにクライアント トラフィックを送信するようにマルチクラスタ Ingress を構成します。
- アプリに負荷生成ツールを設定し、モニタリングを構成します。
- マルチクラスタ Ingress から 1 つのアプリクラスタを削除(ドレイン)し、ドレインされたクラスタをアップグレードします。
- マルチクラスタ Ingress を使用して、アップグレードされたクラスタにトラフィックを戻します。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
- このチュートリアルでは、マルチクラスタ Ingress を設定する必要があります。設定は以下のように行います。
- すべてのクラスタで実行される同じアプリ(Namespace、Deployment、Service など)がデプロイされたクラスタを 2 つ以上用意します。
- すべてのクラスタで自動アップグレードをオフにします。
- クラスタは、エイリアス IP アドレス範囲を使用する VPC ネイティブ クラスタです。
- HTTP ロード バランシングを有効にします(デフォルトで有効になっています)。
gcloud --version
は 369 以上である必要があります。GKE クラスタの登録手順は、このバージョンかそれ以降のバージョンによって異なります。
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate 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/kubernetes-engine-samples
WORKDIR
ディレクトリを作成します。cd kubernetes-engine-samples/networking/gke-multicluster-upgrade-mci/ 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
クラスタをドレインしてアップグレードする
このセクションでは、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
バージョンを使用します。クラスタのバージョンは、このチュートリアルを完了するタイミングで使用可能になるバージョンによって、異なる場合があります。アップグレードの詳細については、クラスタとノードプールのアップグレードをご覧ください。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
次のような出力が表示されます。
*<null>*
kubeconfig
ファイルをリセットします。unset KUBECONFIG
WORKDIR
フォルダを削除します。cd ${HOME} rm -rf ${WORKDIR}
プロジェクトの削除
- In the Google Cloud console, go to the Manage resources page.
- 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 アーキテクチャ センターをご覧ください。