このドキュメントでは、GKE on VMware をアップグレードするためのベスト プラクティスと考慮事項について説明します。ここでは、クラスタのアップグレードを準備する方法と、アップグレード前に行うベスト プラクティスについて説明します。以下のベスト プラクティスは、クラスタのアップグレードに関連するリスクの軽減に役立ちます。
テスト、開発、本番環境などの複数の環境がある場合、テストなどの重要度の低い環境から開始し、アップグレード機能を確認することをおすすめします。アップグレードが正常に完了したことを確認したら、次の環境に進みます。本番環境をアップグレードするまで、このプロセスを繰り返します。この方法により、重要なポイントから次のポイントに進行し、アップグレードとワークロードがすべて正しく実行されることを確認できます。
アップグレードのチェックリスト
アップグレードをできる限りスムーズに行うため、クラスタのアップグレードを開始する前に、次の点を確認します。
アップグレードを計画する
アップグレードが中断される可能性があります。アップグレードを開始する前に、慎重に計画を行って環境とアプリケーションの準備ができていることを確認してください。
所要時間を見積もり、メンテナンスの時間枠を計画する
デフォルトでは、すべてのノードプールが並行してアップグレードされますが、各ノードプール内ではノードは順次アップグレードされます。そのため、アップグレードの合計時間は、最大規模のノードプール内のノード数によって異なります。アップグレードの大まかな見積もり時間を計算するには、15 分 × 最大規模のノードプール内のノード数を適用します。たとえば、最大規模のプールに 10 個のノードがある場合、合計アップグレード時間は約 150 分になります。
バージョン 1.28 以降では、個々のノードプールに maxSurge の値を設定することでアップグレードを高速化できます。
ユーザー クラスタと管理クラスタをバックアップする
アップグレードを開始する前に、ユーザー クラスタと管理クラスタをバックアップします。
ユーザー クラスタのバックアップは、ユーザー クラスタの etcd ストアのスナップショットです。 etcd ストアには、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタム オブジェクトが含まれています。スナップショットには、クラスタのコンポーネントとワークロードを再作成するために必要なデータが含まれています。詳細については、ユーザー クラスタをバックアップする方法をご覧ください。
GKE on VMware バージョン 1.8 以降では、管理クラスタ構成ファイルの clusterBackup.datastore で自動バックアップを設定できます。既存のクラスタでこの機能を有効にするには、管理クラスタの構成ファイルを編集して clusterBackup.datastore フィールドを追加し、つづいて gkectl update admin を実行します。
clusterBackup.datastore を有効にすると、構成済みの vSphere データストア上の etcd に管理クラスタが自動的にバックアップされます。このバックアップ プロセスは、管理クラスタに変更があるたびに繰り返されます。クラスタのアップグレードを開始すると、クラスタをアップグレードする前にバックアップ タスクが実行されます。
問題が発生した場合にバックアップから管理クラスタを復元するには、gkectl を使用して管理クラスタをバックアップおよび復元するをご覧ください。
PodDisruptionBudgets の使用方法を確認する
Kubernetes では、PodDisruptionBudgets（PDB）によって不要なアプリケーションのダウンタイムや停止を防ぐことができます。PDB は、他の Pod で障害が発生しても、常に一定数の Pod を稼働させておくようにスケジューラへ指示します。この動作は、アプリケーションの可用性を確保する便利な方法です。
クラスタで構成されている PDB を確認するには、
kubectl get pdbコマンドを使用します。kubectl get pdb -A --kubeconfig KUBECONFIGKUBECONFIGは、kubeconfig ファイルの名前に置き換えます。次の出力例では、
istio-ingress、istiod、kube-dnsという名前の PDB を示します。NAMESPACE NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE gke-system istio-ingress 1 N/A 1 16d gke-system istiod 1 N/A 1 16d kube-system kube-dns 1 N/A 1 16d
上の表では、各 PDB で、少なくとも 1 つの Pod が常に使用可能でなければならないことを指定しています。ノードがドレインされた場合、この可用性がアップグレード時に重要になります。
満たすことができない PDB を確認します。たとえば、Deployment にはレプリカが 1 つしか存在しないのに、最小可用性を 1 に設定するような場合です。この例では、リソース コントローラが PDB を満たせないため、ドレイン オペレーションが中断されます。
PDB がアップグレード手順の妨げにならないことを確認するため、アップグレードを開始する前に、所定のクラスタ上のすべての PDB を確認してください。クラスタのアップグレード中に PDB を一時的に変更または無効にするには、開発チームやアプリケーション オーナーと調整する必要が生じる場合があります。
GKE on VMware では、アップグレード プロセス中にプリフライト チェックを実行して、PDB に関する警告が表示されます。ただし、スムーズなアップグレードを実現するためには、PDB を手動で確認する必要もあります。PDB の詳細については、アプリケーションの停止予算の指定をご覧ください。
使用可能な IP アドレスを確認する
クラスタをアップグレードする際には、次の IP アドレスに関する考慮事項が適用されます。
- クラスタのアップグレード プロセスでは、新しいノードを作成し、リソースをドレインしてから古いノードを削除します。管理クラスタやユーザー クラスタには、常に N+1 個の IP アドレスを割り当てることをおすすめします。ここで、N は、クラスタ内のノードの数です。
- 静的 IP アドレスを使用する場合は、必要な IP アドレスが IP ブロック ファイルに記載されている必要があります。
- DHCP を使用する場合は、アップグレード中に新しい VM が目的のサブネットで追加の IP リースを取得できることを確認してください。
- IP アドレスを追加する必要がある場合は、IP ブロック ファイルを更新し、つづいて
gkectl updateコマンドを実行します。詳細については、IP アドレスを計画するをご覧ください。
- IP アドレスを追加する必要がある場合は、IP ブロック ファイルを更新し、つづいて
- 静的 IP アドレスを使用し、ユーザー クラスタのアップグレード プロセスを高速化する場合は、各ノードプールで追加の IP アドレスを使用できるように、IP ブロック ファイルに十分な IP アドレスを記載します。この方法では、ノードプールごとに VM の追加と削除が行われるため、プロセスが高速化されます。
- この方法は、ユーザー クラスタのアップグレードを高速化する場合には適していますが、vSphere 環境のリソースと性能上の余裕を考慮したうえで進めてください。
- ユーザー クラスタ全体に予備 IP が 1 つしかない場合、複数のノードプールが使用されていても、この制限によってアップグレード プロセスでは一度に 1 つの VM しか処理できず速度が低下します。
クラスタの使用率を確認する
ノードがドレインしたときに Pod が強制排除できることを確認し、アップグレードを管理するためにアップグレード中のクラスタに十分なリソースがあることを確認します。クラスタの現在のリソース使用量を確認するには、カスタム ダッシュボードを、Google Cloud Observability, で使用するか、kubectl top nodes などのコマンドを使いクラスタ上で直接使用します。
クラスタに対して実行するコマンドは、現在のクラスタ リソースの使用状況のスナップショットを示します。ダッシュボードでは、リソースが時間経過とともに消費される様子を、より詳細に表示できます。このリソースの使用状況データは、実行中のワークロードとユースケースに応じて、アップグレードが中断を最小限にとどめる要因（週末や夜間など）を判断する際に活用できます。
通常、管理クラスタのアップグレードはアプリケーションのダウンタイムを発生させないため、そのタイミングはユーザー クラスタよりも重要でない場合があります。ただし、管理クラスタのアップグレードを開始する前に、vSphere でフリーなリソースを確認することが重要です。また、管理クラスタのアップグレードはある程度のリスクを伴うため、クラスタへの管理アクセスが重要でない、あまり使われていない期間中に推奨されることがあります。
詳細については、クラスタのアップグレード中に影響を受けるサービスをご覧ください。
vSphere の使用率を確認する
基盤となる vSphere インフラストラクチャに十分なリソースがあることを確認します。このリソース使用量を確認するには、vCenter でクラスタを選択し、[サマリー] タブを確認します。
[サマリー] タブには、クラスタ全体のメモリ、CPU、ストレージの使用量が表示されます。GKE on VMware のアップグレードでは追加のリソースが必要になるため、クラスタが追加のリソース リクエストを処理できるかどうかも確認する必要があります。
原則として、vSphere クラスタは、次の追加リソースをサポートできる必要があります。
- 管理クラスタのアップグレードごとに +1 VM
- ユーザー クラスタごとにアップグレードごとに 1 ノードプールあたり +1 VM
たとえば、1 つのユーザー クラスタにノードプールが 3 つあり、各ノードプールのノードは、8 つの vCPU と 32 GB 以上の RAM を使用するとします。デフォルトでは、アップグレードが 3 つのノードプールに対して並行して行われるため、アップグレード手順では、3 つの追加のサージノードに対して次のリソースが追加で使用されます。
- 24 vCPU
- 256 GB の RAM
- VM ディスク容量 + 256 GB の vSwap
アップグレード プロセスでは、vSphere クローン オペレーションを使用して VM が作成されます。テンプレートから複数の VM のクローンを作成すると、I/O オペレーションの増加という形で、基盤となるストレージ システムに負荷がかかる可能性があります。基盤となるストレージ サブシステムがアップグレード中に十分なパフォーマンスを提供できない場合は、アップグレードが大幅に遅くなることがあります。
vSphere は同時リソース使用向けに設計されており、オーバーコミットの場合でもリソースを提供するメカニズムを備えていますが、VM メモリをオーバーコミットしないことを強くおすすめします。vSphere では、データベースにページをスワップアウトすることから「RAM が欠落」するため、メモリがオーバーコミットされると、パフォーマンスが著しく低下しクラスタ全体に影響を与える可能性があります。この動作により、クラスタのアップグレード中に問題が発生し、vSphere クラスタで動作している他の VM のパフォーマンスに影響を与える可能性があります。
利用可能なリソースがすでに不足している場合は、不要な VM の電源を切ることで、これらの追加要件を満たすことができ、パフォーマンスが低下する可能性を小さくできます。
クラスタの健全性と構成を確認する
アップグレード前に、すべてのクラスタで次のツールを実行します。
gkectl diagnoseコマンド:gkectl diagnoseは、すべてのクラスタが正常であることを確認します。このコマンドは、正しく構成されていないノードや停止している Pod があるノードを特定するなど、高度なチェックを実行します。アップグレード前のツール: クラスタの健全性と構成を確認するのに加えて、アップグレード前のツールは、クラスタのアップグレード中に発生する可能性がある既知の問題を確認します。
gkectl upgrade コマンドは、プリフライト チェックを実行し、これらのチェックが成功しなかった場合はアップグレード プロセスを停止しますが、プリフライト チェックにより起こりうる損傷からクラスタを保護できます。プリフライト チェックに依存せず、アップグレード前に問題を特定して修正することをおすすめします。
gkectl diagnose コマンドで Cluster unhealthy 警告が表示される場合は、その問題を修正してからアップグレードを試してください。
詳細については、クラスタの問題の診断をご覧ください。
Deployment を使用してアプリケーションの中断を最小限に抑える
更新中にノードをドレインする必要があるため、クラスタのアップグレードでは、アプリケーションの中断が発生する可能性があります。ノードをドレインすると、実行中のすべての Pod をクラスタ内の残りのノードでシャットダウンして再起動する必要があります。
可能な場合、アプリケーションでは、Deployment を使用する必要があります。この方法では、アプリケーションが中断を処理するように設計されます。複数のレプリカがある Deployment への影響は、最小限に抑える必要があります。アプリケーションが Deployment を使用しない場合でも、クラスタをアップグレードできます。
また、Deployment には、設定した数のレプリカが常に実行され続けるようにするためのルールもあります。このルールは PodDisruptionBudgets（PDB）と呼ばれます。PDB を使用すると、クラスタノードでのアップグレードやメンテナンスなど、なんらかの理由で Pod の再スケジュールが必要になった場合のワークロードの中断を制限できます。また、アップグレード前に確認することが重要です。
高可用性ロードバランサのペアを使用する。
クラスタでロードバランサとして Seesaw を使用する場合、クラスタをアップグレードすると、ロードバランサは自動的にアップグレードされます。このアップグレードにより、サービスが停止することがあります。アップグレードと最終的なロードバランサの障害の影響を小さくするには、高可用性ペア（HA ペア）を使用します。この構成では、もう一方の類似アプリへのフェイルオーバーが発生するように、システムによって 2 つのロードバランサ VM が作成され、構成されます。
サービスの可用性（つまり、Kubernetes API サーバーに対して）を高めるには、常に管理クラスタの前に HA ペアを使用することをおすすめします。Seesaw とその HA 構成の詳細については、Seesaw によるバンドル型ロード バランシングをご覧ください。
HA ペアを使用したアップグレード中のサービス中断を防ぐため、クラスタでは、新しいロードバランサ VM を作成する前にフェイルオーバーが開始されます。ユーザー クラスタが単一のロードバランサ インスタンスのみを使用している場合、サービスはロードバランサのアップグレードが完了するまで中断します。
ユーザー クラスタ自体も高可用性を有する構成の場合は、HA ロードバランサのペアを使用することをおすすめします。このベスト プラクティス シリーズでは、HA ユーザー クラスタが HA ロードバランサのペアを使用していることを前提としています。
GKE on VMware バージョン 1.11 または 1.12 は、バンドル ロードバランサとして MetalLB を使用します。この場合、アップグレード前の設定は必要ありません。ロードバランサは、クラスタのアップグレード プロセス中にアップグレードされます。
各ユーザー クラスタのアップグレード方法を決定する
バージョン 1.14 以降では、ユーザー クラスタ全体をアップグレードする（つまり、コントロール プレーンとクラスタ内のすべてのノードプールをアップグレードする）か、ユーザー クラスタのコントロール プレーンをアップグレードし、ノードプールを現在のバージョンのままにするかを選択できます。コントロール プレーンを個別にアップグレードする理由については、ユーザー クラスタのアップグレードをご覧ください。
マルチクラスタ環境では、アップグレードされたユーザー クラスタを追跡し、そのバージョン番号を記録します。コントロール プレーンとノードプールを個別にアップグレードする場合は、各クラスタ内のコントロール プレーンと各ノードプールのバージョンを記録します。
ユーザー クラスタと管理クラスタのバージョンを確認する
gkectl
ユーザー クラスタのバージョンを確認するには:
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_KUBECONFIGは、管理クラスタの kubeconfig ファイルのパスに置き換えます。管理クラスタのバージョンを確認するには:
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
gcloud CLI
GKE On-Prem API に登録されているクラスタの場合、gcloud CLI を使用してユーザー クラスタ、ユーザー クラスタ上のノードプール、管理クラスタのバージョンを取得できます。
最新バージョンの gcloud CLI を使用していることを確認します。 必要に応じて gcloud CLI コンポーネントを更新します。
gcloud components update次のコマンドを実行してバージョンを確認します。
ユーザー クラスタのバージョンを確認するには:
gcloud container vmware clusters list \ --project=PROJECT_ID \ --location=-PROJECT_IDは、フリートホスト プロジェクトのプロジェクト ID に置き換えます。--location=-と設定すると、すべてのリージョンのクラスタがすべて一覧表示されます。リストを絞り込む必要がある場合は、クラスタの登録時に指定したリージョンを--locationに設定します。コマンドの出力にはクラスタのバージョンが含まれます。
管理クラスタのバージョンを確認するには:
gcloud container vmware admin-clusters list \ --project=PROJECT_ID \ --location=-
クラスタノードのバージョンを確認する
クラスタノードのバージョンを取得するには kubectl を使用しますが、kubectl は Kubernetes のバージョンを返します。Kubernetes バージョンに対応する GKE on VMware バージョンを取得するには、バージョン履歴をご覧ください。
kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG
USER_CLUSTER_KUBECONFIG は、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。
CA 証明書をローテーションする必要があるかどうかを確認する
アップグレード中、リーフ証明書はローテーションされますが、CA 証明書はローテーションされません。CA 証明書は少なくとも 5 年に一度手動でローテーションする必要があります。詳細については、ユーザー クラスタ認証局のローテーションと管理クラスタの CA 証明書のローテーションをご覧ください。
クラスタタイプの相違点
クラスタは 2 種類あります。
- ユーザー クラスタ
- 管理クラスタ
ユーザー クラスタの作成方法によっては、ワーカーノードとコントロール プレーン ノードの両方が含まれる（Controlplane V2）か、ワーカーノードのみが含まれる場合（kubeception）があります。kubeception では、ユーザー クラスタのコントロール プレーンは管理クラスタ内の 1 つ以上のノードで実行されます。いずれの場合も、バージョン 1.14 以降では、ワークロードを実行するノードプールとは別にユーザー クラスタのコントロール プレーンをアップグレードできます。
ユーザー クラスタのアップグレードと管理クラスタのアップグレードの効果の違い
GKE on VMware アップグレード手順には、すべての Pod をノードから削除するノードのドレイン プロセスが含まれます。このプロセスでは、ドレインされたワーカーノードごとに新しい VM を作成し、クラスタに追加します。ドレインされたワーカーノードは、VMware のインベントリから削除されます。このプロセス中に、こうしたノードで動作しているワークロードは停止し、クラスタ内の他の使用可能なノードで再起動します。
選択したワークロードのアーキテクチャによっては、この手順がアプリケーションの可用性に影響を与える場合があります。クラスタのリソース能力に過度の負担がかからないようにするため、GKE on VMware は一度に 1 つのノードをアップグレードします。
ユーザー クラスタの中断
次の表では、ユーザー クラスタのインプレース アップグレードの影響を示します。
| Function | 管理クラスタ | 非 HA ユーザー クラスタ | HA ユーザー クラスタ |
|---|---|---|---|
| Kubernetes API アクセス | 影響なし | 影響なし | 影響なし |
| ユーザー ワークロード | 影響なし | 影響なし | 影響なし |
| PodDisruptionBudgets* | 影響なし | 影響なし | 影響なし |
| コントロール プレーン ノード | 影響なし | 影響あり | 影響なし |
| Pod オートスケーラー（VMware） | 影響なし | 影響なし | 影響なし |
| 自動修復 | 影響なし | 影響なし | 影響なし |
| ノード自動スケーリング（VMware） | 影響なし | 影響なし | 影響なし |
| 水平 Pod 自動スケーリング | 影響あり | 影響あり | 影響なし |
- * : PDB が原因で、アップグレードが失敗するか停止する場合があります。
- 影響あり: アップグレードが完了するまでアップグレード中にサービスが中断します。
- 影響なし: 非常に短い期間にサービスが中断する可能性がありますが、ほとんど気づきません。
ユーザー クラスタ コントロール プレーン ノードは、管理クラスタ（kubeception）で実行されているか、ユーザー クラスタ自体（Controlplane V2）で実行されているかに関係なく、ユーザー ワークロードは実行しません。アップグレード中は、これらのコントロール プレーン ノードがドレインされ、それに応じて更新されます。
高可用性（HA）コントロール プレーンがある環境では、ユーザー クラスタのコントロール プレーンをアップグレードしてもユーザー ワークロードは中断されません。HA 環境では、管理クラスタをアップグレードしても、ユーザー ワークロードは中断されません。Controlplane V2 を使用するユーザー クラスタでは、コントロール プレーンのみをアップグレードしてもユーザー ワークロードは中断されません。
HA 以外のコントロール プレーン環境では、アップグレード中にコントロール プレーンは Pod のスケーリング、復元、デプロイ アクションを制御できません。アップグレード中にコントロール プレーンが短時間中断されると、ユーザー ワークロードがスケーリング、デプロイ、または復元の状態にある場合に影響が及ぶ可能性があります。つまり、非 HA 環境ではアップグレード中にロールアウトが失敗します。
アップグレード中の可用性を向上させ、本番環境のユーザー クラスタの停止を減らすには、3 つのコントロール プレーン ノード（高可用性モード）を使用することをおすすめします。
管理クラスタの中断
次の表では、インプレース管理クラスタのアップグレードの影響を示します。
| Function | 管理クラスタ | 非 HA ユーザー クラスタ | HA ユーザー クラスタ |
|---|---|---|---|
| Kubernetes API アクセス | 影響あり | 影響あり | 影響なし |
| ユーザー ワークロード | 影響なし | 影響なし | 影響なし |
| コントロール プレーン ノード | 影響あり | 影響あり | 影響なし |
| Pod オートスケーラー | 影響あり | 影響あり | 影響なし |
| 自動修復 | 影響あり | 影響あり | 影響なし |
| ノードの自動スケーリング | 影響あり | 影響あり | 影響なし |
| 水平 Pod 自動スケーリング | 影響あり | 影響あり | 影響なし |
- 影響あり: アップグレードが完了するまでアップグレード中にサービスが中断します。
- 影響なし: 非常に短い期間にサービスが中断する可能性がありますが、ほとんど気づきません。