このチュートリアルでは、マルチクラスタ 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.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify 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.comCloud Shell で、このチュートリアルのファイルを取得するリポジトリのクローンを作成します。
cd ${HOME} git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samplesWORKDIRディレクトリを作成します。cd kubernetes-engine-samples/networking/gke-multicluster-upgrade-mci/ export WORKDIR=`pwd`Cloud Shell で、次の 3 つの GKE クラスタを作成します。
gcloud container clusters create ingress-config --location 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 --location 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 --location 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: RUNNINGkubeconfigファイルを作成し、すべてのクラスタに接続して、kubeconfigファイルにエントリを生成します。touch gke-upgrade-kubeconfig export KUBECONFIG=gke-upgrade-kubeconfig gcloud container clusters get-credentials ingress-config \ --location us-west1-a --project ${PROJECT} gcloud container clusters get-credentials blue --location us-west1-b \ --project ${PROJECT} gcloud container clusters get-credentials green --location 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_green3 つのクラスタをフリートとして登録します。
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-944754a0d725Hub で
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 キーを押します。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.Cloud Shell で、
MulticlusterIngressリソースをingress-configクラスタにデプロイします。kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mci.yaml次のような出力が表示されます。
multiclusteringress.networking.gke.io/whereami-mci createdMulticlusterServiceリソースをingress-configクラスタにデプロイします。kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml次のような出力が表示されます。
multiclusterservice.networking.gke.io/whereami-mcs created2 つのリソースを比較する手順は次のとおりです。
MulticlusterIngressリソースを検査します。kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusteringress -o yaml出力には次のものが含まれます。
spec: template: spec: backend: serviceName: whereami-mcs servicePort: 8080MulticlusterIngressリソースは 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: whereamiMulticlusterServiceリソースは Kubernetes Service リソースと似ていますが、clusters仕様がある点が異なります。clustersの値は、MulticlusterServiceリソースが作成される登録済みクラスタの一覧です。MulticlusterIngressリソースが、MulticlusterServiceリソースを指すバックエンド サービスを使用してロードバランサを作成したことを確認します。watch kubectl --context ${INGRESS_CONFIG_CLUSTER} \ get multiclusteringress -o jsonpath="{.items[].status.VIP}"この処理には最大で 10 分かかります。出力が次のようになるまで待ちます。
34.107.246.9watchコマンドを終了するには、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.9curlを使用して、ロードバランサとデプロイされたアプリケーションにアクセスします。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 に送信するように
loadgeneratorマニフェストを構成します。TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}ingress-configクラスタにloadgeneratorをデプロイします。kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/loadgen-manifestsingress-configクラスタのloadgeneratorPod のステータスが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でない場合は、数分待ってからコマンドを再度実行します。マルチクラスタ 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のクラスタで実行されていることが示されます。
Cloud Shell で、
ingress-configクラスタのMulticlusterServiceリソースを更新します。kubectl --context ${INGRESS_CONFIG_CLUSTER} \ apply -f ${WORKDIR}/multicluster-manifests/mcs-green.yamlclusters仕様に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クラスタのみがトラフィックを受信していることを示しています。
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 --location 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 --location 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 \ --location 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 \ --location=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: RUNNINGCloud Shell で、アプリケーションのデプロイが
blueクラスタで実行されていることを確認してから、このクラスタをロード バランシング プールに追加し直します。kubectl --context ${BLUE_CLUSTER} get pods出力は次のようになります。
NAME READY STATUS RESTARTS AGE whereami-deployment-756c7dc74c-xdnb6 1/1 Running 0 17mMutliclusterServiceリソースを更新して、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にすべて置き換えてください。Cloud Shell で、
blueクラスタとgreenクラスタの登録を解除して削除します。gcloud container fleet memberships unregister blue --gke-cluster=us-west1-b/blue gcloud container clusters delete blue --location us-west1-b --quiet gcloud container fleet memberships unregister green --gke-cluster=us-west1-c/green gcloud container clusters delete green --location us-west1-c --quietingress-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 --location us-west1-a --quietすべてのクラスタが削除されたことを確認します。
gcloud container clusters list次のような出力が表示されます。
*<null>*kubeconfigファイルをリセットします。unset KUBECONFIGWORKDIRフォルダを削除します。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 アーキテクチャ センターをご覧ください。
環境を設定する
GKE クラスタを作成して Hub に登録する
このセクションでは、3 つの GKE クラスタを作成し、GKE Hub に登録します。
GKE クラスタを作成する
GKE クラスタをフリートに登録する
クラスタをフリートに登録すると、ハイブリッド環境全体で Kubernetes クラスタを運用できます。フリートに登録されているクラスタは、マルチクラスタ Ingress などの高度な GKE 機能を使用できます。GKE クラスタをフリートに登録するには、 Google Cloudサービス アカウントを直接使用するか、または推奨される Workload Identity Federation for GKE アプローチを使用します。これにより GKE クラスタ内の Kubernetes サービス アカウントが Identity and Access Management サービス アカウントとして機能します。
サンプル アプリケーションを blue クラスタと green クラスタにデプロイする
マルチクラスタ Ingress を構成する
このセクションでは、blue クラスタと green クラスタの両方で実行されているアプリケーションにトラフィックを送信するマルチクラスタ Ingress を作成します。Cloud Load Balancing を使用して、blue クラスタと green クラスタの両方で whereami アプリをバックエンドとして使用するロードバランサを作成します。ロードバランサを作成するには、MultiClusterIngress と 1 つ以上の MultiClusterServices からなる 2 つのリソースが必要です。MultiClusterIngress オブジェクトと MultiClusterService オブジェクトには、単一クラスタ コンテキストで使用される既存の Kubernetes Ingress および Service リソースとのマルチクラスタ類似性があります。
負荷生成ツールを設定する
このセクションでは、Cloud Load Balancing VIP へのクライアント トラフィックを生成する loadgenerator サービスを設定します。両方のクラスタにトラフィックを送信するように MulticlusterService リソースが設定されているため、最初に blue クラスタと green クラスタにトラフィックが送信されます。その後、単一のクラスタにトラフィックを送信するように MulticlusterService リソースを構成します。
トラフィックを監視する
このセクションでは、Google Cloud コンソールを使用して whereami アプリへのトラフィックをモニタリングします。
前のセクションで、Cloud Load Balancing VIP を介して whereami アプリにアクセスすることで、クライアント トラフィックをシミュレートする loadgenerator デプロイメントを設定しました。このような指標はGoogle Cloud コンソールからモニタリングできます。モニタリングしてアップグレードのクラスタをドレインできるよう、まずモニタリングを設定します(次のセクションで説明します)。
blue クラスタをドレインしてアップグレードする
このセクションでは、blue クラスタをドレインします。ドレインされたクラスタは、ロード バランシング プールから削除されます。blue クラスタをドレインすると、アプリケーション宛てのすべてのクライアント トラフィックは green クラスタに移動します。
前のセクションで説明したように、このプロセスをモニタリングできます。クラスタのドレイン後に、ドレインされたクラスタをアップグレードできます。クラスタのアップグレードが完了すると、ロード バランシング プールに戻すことができます。上記の手順を繰り返して他のクラスタをアップグレードします(このチュートリアルでは示していません)。
blue クラスタをドレインするには、ingress-cluster クラスタの MulticlusterService リソースを更新し、clusters 仕様から blue クラスタを削除します。
blue クラスタをドレインする
blue クラスタのアップグレード
これで blue クラスタがクライアント トラフィックを受信できなくなったので、このクラスタ(コントロール プレーンとノード)をアップグレードできます。
blue クラスタをロード バランシング プールに追加し直す
このセクションでは、blue クラスタをロード バランシング プールに追加し直します。
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
課金をなくす最も簡単な方法は、チュートリアル用に作成した Google Cloud プロジェクトを削除することです。また、リソースを個別に削除することもできます。