Anthos clusters on VMware は、VMware 用 Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

Google Distributed Cloud クラスタのアップグレードに関するベストプラクティス

このドキュメントでは、Google Distributed Cloud をアップグレードするためのベストプラクティスと考慮事項について説明します。ここでは、クラスタのアップグレードを準備する方法と、アップグレード前に行うベストプラクティスについて説明します。以下のベストプラクティスは、クラスタのアップグレードに関連するリスクの軽減に役立ちます。

テスト、開発、本番環境などの複数の環境がある場合、テストなどの重要度の低い環境から開始し、アップグレード機能を確認することをおすすめします。成功したら、次の環境に進みます。本番環境をアップグレードするまで、このプロセスを繰り返します。この方法により、重要なポイントから次のポイントに進行し、アップグレードとワークロードがすべて正しく実行されることを確認できます。

アップグレードのチェックリスト

アップグレードをできる限りスムーズに行うため、クラスタのアップグレードを開始する前に、次の点を確認します。

アップグレードの所要時間を見積もり、メンテナンスの時間枠を計画する。

ユーザークラスタと管理クラスタのバックアップを準備する。

ユーザークラスタの PodDisruptionBudgets を確認する。

使用可能な IP アドレスとニーズを確認する。

ユーザークラスタの使用率と使用可能なリソースを確認する。

vSphere クラスタの容量を確認し、CPU、メモリ、準備完了時間などの使用可能なリソースを確認する。

アップグレード前にクラスタの健全性と構成を確認して、問題を解決する。

Deployment を使用してアプリケーションの中断を最小限に抑える。

高可用性ロードバランサのペアを使用する。

各ユーザークラスタのアップグレード方法を決定する。

CA 証明書をローテーションする必要があるかどうかを確認する。

アップグレードを計画する

アップグレードが中断される可能性があります。アップグレードを開始する前に、慎重に計画を行って環境とアプリケーションの準備ができていることを確認してください。

所要時間を見積もり、メンテナンスの時間枠を計画する

デフォルトでは、すべてのノードプールが並列でアップグレードされますが、各ノードプール内でノードは順番にアップグレードされます。そのため、アップグレードの合計時間は、最大規模のノードプール内のノード数によって異なります。アップグレードの大まかな見積もり時間は、15 分 × 最大規模のノードプール内のノード数で計算します。たとえば、最大規模のプールに 10 個のノードがある場合、合計アップグレード時間は約 150 分になります。

バージョン 1.28 以降では、個々のノードプールの maxSurge の値を設定することで、アップグレードを高速化できます。

ユーザークラスタと管理クラスタをバックアップする

アップグレードを開始する前に、ユーザークラスタと管理クラスタをバックアップします。

ユーザークラスタのバックアップは、ユーザークラスタの etcd ストアのスナップショットです。etcd ストアには、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタムオブジェクトが含まれています。スナップショットには、クラスタのコンポーネントとワークロードを再作成するために必要なデータが含まれています。詳細については、ユーザークラスタをバックアップする方法をご覧ください。

Google Distributed Cloud バージョン 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 KUBECONFIG

KUBECONFIG は、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 を一時的に変更または無効にするには、開発チームやアプリケーションオーナーと調整する必要が生じる場合があります。

Google Distributed Cloud では、アップグレードプロセス中にプリフライトチェックを実行して、PDB に関する警告が表示されます。ただし、スムーズなアップグレードを実現するためには、PDB を手動で確認する必要もあります。PDB の詳細については、アプリケーションの停止予算の指定をご覧ください。

使用可能な IP アドレスを確認する

クラスタをアップグレードする際には、IP アドレスに関して次のことを考慮してください。

クラスタのアップグレードプロセスでは、新しいノードを作成し、リソースをドレインしてから古いノードを削除します。管理クラスタやユーザークラスタには、常に N+1 個の IP アドレスを割り当てることをおすすめします。ここで、N は、クラスタ内のノードの数です。
静的 IP アドレスを使用する場合は、必要な IP アドレスが IP ブロックファイルに記載されている必要があります。
DHCP を使用する場合は、アップグレード中に新しい VM が目的のサブネットで追加の IP リースを取得できることを確認してください。
- IP アドレスを追加する必要がある場合は、IP ブロックファイルを更新し、gkectl update コマンドを実行します。詳細については、IP アドレスを計画するをご覧ください。
静的 IP アドレスを使用し、ユーザークラスタのアップグレードプロセスを高速化する場合は、各ノードプールで追加の IP アドレスを使用できるように、IP ブロックファイルに十分な IP アドレスを記載します。この方法では、ノードプールごとに VM の追加と削除が行われるため、プロセスが高速化されます。
- この方法は、ユーザークラスタのアップグレードを高速化する場合には適していますが、vSphere 環境のリソースと性能上の余裕を考慮したうえで進めてください。
ユーザークラスタ全体に予備 IP が 1 つしかない場合、複数のノードプールが使用されていても、この制限によってアップグレードプロセスでは一度に 1 つの VM しか処理できず速度が低下します。

クラスタの使用率を確認する

ノードがドレインしたときに Pod が強制排除できることを確認し、アップグレードを管理するためにアップグレード中のクラスタに十分なリソースがあることを確認します。クラスタの現在のリソース使用量を確認するには、カスタムダッシュボードを、Google Cloud Observability, で使用するか、kubectl top nodes などのコマンドを使いクラスタ上で直接使用します。

クラスタに対して実行するコマンドは、現在のクラスタリソースの使用状況のスナップショットを示します。ダッシュボードでは、リソースが時間経過とともに消費される様子を、より詳細に表示できます。このリソースの使用状況データは、実行中のワークロードとユースケースに応じて、アップグレードが中断を最小限にとどめる要因（週末や夜間など）を判断する際に活用できます。

通常、管理クラスタのアップグレードはアプリケーションのダウンタイムを発生させないため、そのタイミングはユーザークラスタよりも重要でない場合があります。ただし、管理クラスタのアップグレードを開始する前に、vSphere でフリーなリソースを確認することが重要です。また、管理クラスタのアップグレードはある程度のリスクを伴うため、クラスタへの管理アクセスが重要でない、あまり使われていない期間中に推奨されることがあります。

詳細については、クラスタのアップグレード中に影響を受けるサービスをご覧ください。

vSphere の使用率を確認する

基盤となる vSphere インフラストラクチャに十分なリソースがあることを確認します。このリソース使用量を確認するには、vCenter でクラスタを選択し、[Summary] タブを確認します。

[Summary] タブには、クラスタ全体のメモリ、CPU、ストレージの使用量が表示されます。Google Distributed Cloud のアップグレードでは追加のリソースが必要になるため、クラスタがこれらの追加のリソースリクエストを処理できるかどうかも確認する必要があります。

原則として、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 diagnose コマンドで Cluster unhealthy 警告が表示される場合は、その問題を修正してからアップグレードを試してください。詳細については、クラスタの問題の診断をご覧ください。
アップグレード前のツール: アップグレード前のツールは、クラスタの健全性と構成を確認するだけでなく、クラスタのアップグレード中に発生する可能性がある既知の問題を確認します。

また、ユーザークラスタを 1.29 以降にアップグレードする場合は、--dry-run フラグを指定して gkectl upgrade cluster コマンドを実行することをおすすめします。--dry-run フラグはプリフライトチェックを実行しますが、アップグレードプロセスは開始しません。以前のバージョンの Google Distributed Cloud では、プリフライトチェックが実行されますが、アップグレードとは別に実行することはできません。--dry-run フラグを追加すると、アップグレード前にプリフライトチェックでユーザークラスタで見つかった問題を見つけて修正できます。

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 ロードバランサのペアを使用することを前提としています。

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 バージョンに対応する Google Distributed Cloud バージョンを取得するには、バージョニングをご覧ください。

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

USER_CLUSTER_KUBECONFIG は、ユーザークラスタの kubeconfig ファイルのパスに置き換えます。

CA 証明書をローテーションする必要があるかどうかを確認する

アップグレード中、リーフ証明書はローテーションされますが、CA 証明書はローテーションされません。CA 証明書は少なくとも 5 年に 1 回手動でローテーションする必要があります。詳細については、ユーザークラスタの認証局のローテーションと管理クラスタの CA 証明書のローテーションをご覧ください。

クラスタタイプの相違点

クラスタは 2 種類あります。

ユーザークラスタ
管理クラスタ

ユーザークラスタの作成方法によっては、ワーカーノードとコントロールプレーンノードの両方が含まれる場合（Controlplane V2）と、ワーカーノードのみが含まれる場合（kubeception）があります。kubeception では、ユーザークラスタのコントロールプレーンが管理クラスタ内の 1 つ以上のノードで実行されます。どちらの場合も、バージョン 1.14 以降では、ワークロードを実行するノードプールとは別に、ユーザークラスタのコントロールプレーンをアップグレードできます。

ユーザークラスタのアップグレードと管理クラスタのアップグレードの効果の違い

Google Distributed Cloud のアップグレード手順には、すべての Pod をノードから削除するノードのドレインプロセスが含まれます。このプロセスでは、ドレインされたワーカーノードごとに新しい VM が作成され、クラスタに追加されます。ドレインされたワーカーノードは、VMware のインベントリから削除されます。このプロセス中に、こうしたノードで動作しているワークロードは停止し、クラスタ内の他の使用可能なノードで再起動します。

選択したワークロードのアーキテクチャによっては、この手順がアプリケーションの可用性に影響を与える場合があります。クラスタのリソース能力に過度の負担がかからないようにするため、Google Distributed Cloud は一度に 1 つのノードをアップグレードします。

ユーザークラスタの中断

次の表では、ユーザークラスタに対するインプレースアップグレードの影響を示します。

機能	管理クラスタ	非 HA ユーザークラスタ	HA ユーザークラスタ
Kubernetes API アクセス	影響なし	影響なし	影響なし
ユーザーワークロード	影響なし	影響なし	影響なし
PodDisruptionBudgets^*	影響なし	影響なし	影響なし
コントロールプレーンノード	影響なし	影響あり	影響なし
Pod オートスケーラー（VMware）	影響なし	影響なし	影響なし
自動修復	影響なし	影響なし	影響なし
ノードの自動スケーリング（VMware）	影響なし	影響なし	影響なし
水平 Pod 自動スケーリング	影響あり	影響あり	影響なし

* PDB が原因で、アップグレードが失敗または停止する場合があります。
影響あり: アップグレードが完了するまでアップグレード中にサービスが中断します。
影響なし: 非常に短い時間、サービスが中断する可能性がありますが、ほとんど気づきません。

ユーザークラスタコントロールプレーンノードは、管理クラスタで実行されているか（kubeception）、ユーザークラスタで実行されているか（Controlplane V2）に関係なく、ユーザーワークロードは実行しません。アップグレード中、これらのコントロールプレーンノードはドレインされ、必要に応じて更新されます。

高可用性（HA）コントロールプレーンを使用する環境では、ユーザークラスタのコントロールプレーンをアップグレードしてもユーザーワークロードは中断されません。HA 環境では、管理クラスタをアップグレードしてもユーザーワークロードは中断されません。Controlplane V2 を使用するユーザークラスタでは、コントロールプレーンのみをアップグレードしても、ユーザーワークロードは中断されません。

非 HA コントロールプレーン環境では、アップグレード中にコントロールプレーンは Pod のスケーリング、復元、デプロイアクションを制御できません。アップグレード中にコントロールプレーンが短時間中断されると、ユーザーワークロードがスケーリング、デプロイ、または復元の状態にある場合に、影響が及ぶ可能性があります。つまり、非 HA 環境でのアップグレード中にロールアウトが失敗します。

アップグレード中の可用性を向上させ、本番環境のユーザークラスタの停止を減らすには、3 つのコントロールプレーンノード（高可用性モード）を使用することをおすすめします。

管理クラスタの中断

次の表では、管理クラスタに対するインプレースアップグレードの影響を示します。

機能	管理クラスタ	非 HA ユーザークラスタ	HA ユーザークラスタ
Kubernetes API アクセス	影響あり	影響あり	影響なし
ユーザーワークロード	影響なし	影響なし	影響なし
コントロールプレーンノード	影響あり	影響あり	影響なし
Pod オートスケーラー	影響あり	影響あり	影響なし
自動修復	影響あり	影響あり	影響なし
ノードの自動スケーリング	影響あり	影響あり	影響なし
水平 Pod 自動スケーリング	影響あり	影響あり	影響なし

影響あり: アップグレードが完了するまでアップグレード中にサービスが中断します。
影響なし: 非常に短い時間、サービスが中断する可能性がありますが、ほとんど気づきません。

次のステップ

Anthos clusters on VMware のアップグレード