このドキュメントでは、Google Distributed Cloud をアップグレードするためのベスト プラクティスと考慮事項について説明します。ここでは、クラスタのアップグレードを準備する方法と、アップグレード前に行うベスト プラクティスについて説明します。以下のベスト プラクティスは、クラスタのアップグレードに関連するリスクの軽減に役立ちます。
テスト、開発、本番環境などの複数の環境がある場合、テストなどの重要度の低い環境から開始し、アップグレード機能を確認することをおすすめします。アップグレードが正常に完了したことを確認したら、次の環境に進みます。本番環境をアップグレードするまで、このプロセスを繰り返します。この方法により、重要なポイントから次のポイントに進行し、アップグレードとワークロードがすべて正しく実行されることを確認できます。
アップグレードのチェックリスト
このドキュメントのすべてのベスト プラクティスに従うことをおすすめします。以下のチェックリストを使用して、進捗状況の追跡に活用してください。リスト内の各項目は、詳細情報が記載されているこのドキュメントのセクションにリンクしています。
これらのチェックが完了したら、アップグレード プロセスを開始できます。すべてのクラスタが正常にアップグレードされるまで、進捗状況をモニタリングします。
アップグレードを計画する
アップグレードが中断される可能性があります。アップグレードを開始する前に、慎重に計画を行って環境とアプリケーションの準備ができていることを確認してください。
所要時間を見積もり、メンテナンスの時間枠を計画する
クラスタのアップグレードにかかる時間は、ノード数とクラスタ上で実行されるワークロードの密度によって異なります。クラスタのアップグレードを正常に完了するには、メンテナンスの時間枠に十分な時間を確保します。
アップグレードの大まかな見積もり時間を計算するには、10 minutes * the number of
nodes を単一の同時ノード アップグレードに使用します。
たとえば、クラスタ内に 50 個のノードがある場合、合計アップグレード時間は約 500 分（10 minutes * 50 nodes = 500 minutes）になります。
他の GKE Enterprise コンポーネントの互換性を確認する
クラスタが Anthos Service Mesh、Config Sync、Policy Controller、Config Controller などの GKE Enterprise コンポーネントを実行している場合は、GKE Enterprise のバージョンとアップグレードのサポートで、アップグレード前後の GKE on Bare Metal でサポートされているバージョンを確認します。
互換性チェックは、Anthos Service Mesh、Config Sync、Policy Controller、または Config Controller がデプロイされている管理クラスタやユーザー クラスタをベースとします。
クラスタのリソース使用量を確認する
ノードがドレインされたときに Pod が強制排除され、アップグレードを管理するのに十分なリソースがアップグレード中のクラスタ内にあることを確認するには、クラスタの現在のリソース使用量を確認します。クラスタのリソース使用量を確認するには、Google Cloud Observability のカスタム ダッシュボードを使用します。
kubectl top nodes などのコマンドを使用して現在のクラスタのリソース使用量を取得できますが、ダッシュボードでは時間の経過に伴うリソースの使用状況について詳細を確認できます。このリソースの使用状況データは、実行中のワークロードとユースケースに応じて、アップグレードが中断を最小限にとどめる要因（週末や夜間など）を判断する際に活用できます。
通常、管理クラスタのアップグレードはアプリケーションのダウンタイムを発生させないため、そのタイミングはユーザー クラスタよりも重要でない場合があります。ただし、管理クラスタのアップグレードを開始する前に、利用可能なリソースを確認することが引き続き重要です。また、管理クラスタのアップグレードはある程度のリスクを伴うため、クラスタへの管理アクセスが重要でない、あまり使われていない期間中に推奨されることがあります。
管理クラスタ コントロール プレーンのリソース
すべてのアップグレード コントローラとジョブが、管理クラスタ コントロール プレーン ノードで実行されます。使用可能なコンピューティング リソースを把握するには、これらのコントロール プレーン ノードのリソース使用量を確認します。アップグレード プロセスでは通常、ライフサイクル コントローラの各セットに 1,000 ミリコアの CPU（1,000 mCPU）と、2～3 GiB の RAM が必要です。CPU ユニット「mCPU」は「コアの 1,000 分の 1」を表します。つまり、1,000 ミリコアは、各ライフサイクル コントローラの各ノードで 1 コアに相当します。アップグレード中に、要求される追加のコンピューティング リソースを削減するには、ユーザー クラスタを同じバージョンに維持してみてください。
次のデプロイ例では、2 つのユーザー クラスタが管理クラスタとは異なるバージョンになっています。
| 管理クラスタ | ユーザー クラスタ 1 | ユーザー クラスタ 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.2 |
使用されているバージョンごとに、ライフサイクル コントローラのセットが管理コントローラにデプロイされます。この例では、ライフサイクル コントローラのセット（1.13.3、1.13.0、1.13.2）が 3 つあります。ライフサイクル コントローラの各セットは、合計で 1,000 mCPU と 3 GiB の RAM を使用します。これらのライフサイクル コントローラの現在の合計リソース使用量は、3,000 mCPU と 9 GiB の RAM です。
ユーザー クラスタ 2 が 1.13.3 にアップグレードされると、ライフサイクル コントローラのセットが 2 つ（1.13.3 と 1.13.0）になります。
| 管理クラスタ | ユーザー クラスタ 1 | ユーザー クラスタ 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.3 |
ライフサイクル コントローラは、合計で 2,000 mCPU と 6 GiB の RAM を使用することになります。
ユーザー クラスタ 1 が 1.13.3 にアップグレードされた場合、フリートはすべて同じバージョン（1.13.3）で実行されることになります。
| 管理クラスタ | ユーザー クラスタ 1 | ユーザー クラスタ 2 |
|---|---|---|
| 1.13.3 | 1.13.3 | 1.13.3 |
ライフサイクル コントローラのセットは 1 つのみになり、合計で 1, 000 mCPU と 3 GiB の RAM を使用します。
次の例では、すべてのユーザー クラスタが同じバージョンになっています。管理クラスタがアップグレードされると、ライフサイクル コントローラのセットが 2 つだけ使用されるため、コンピューティング リソースの使用量が削減されます。
| 管理クラスタ | ユーザー クラスタ 1 | ユーザー クラスタ 2 |
|---|---|---|
| 1.14.0 | 1.13.3 | 1.13.3 |
この例では、すべてのユーザー コントローラが管理クラスタと同じバージョンにアップグレードされるまで、ライフサイクル コントローラが再び合計で 2, 000 mCPU と 6 GiB の RAM を使用します。
アップグレード中にコントロール プレーン ノードに追加のコンピューティング リソースがない場合は、Pending 状態の anthos-cluster-operator、capi-controller-manager、cap-controller-manager、または cap-kubeadm-bootstraper などの Pod が表示される可能性があります。この問題を解決するには、一部のユーザー クラスタを同じバージョンにアップグレードしてバージョンを統合し、使用しているライフサイクル コントローラの数を減らします。アップグレードがすでに停止している場合は、kubectl edit deployment を使用して保留中のデプロイを編集し、管理クラスタのコントロール プレーンに収まるように CPU リクエストと RAM リクエストを減らすこともできます。
次の表に、さまざまなアップグレード シナリオにおけるコンピューティング リソースの要件の詳細を示します。
| クラスタ | 必要な管理クラスタ リソース |
|---|---|
| ユーザー クラスタ アップグレード | 他のクラスタの同じバージョンにアップグレード: なし 他の管理クラスタまたはユーザー クラスタの別のバージョンへのアップグレード: 1,000 mCPU と 3 GiB の RAM ハイブリッド クラスタ内のユーザー クラスタには、同じリソース要件が設定されます。 |
| 管理クラスタのアップグレード（ユーザー クラスタを含む） | 1,000 mCPU と 3 GiB の RAM |
| ハイブリッド クラスタのアップグレード（ユーザー クラスタなし） | 1,000 mCPU と 3 GiB の RAM サージ。リソースは使用後に返却されます。 |
| スタンドアロン | 200 mCPU と 1 GiB の RAM サージ。リソースは使用後に返却されます。 |
クラスタをバックアップする
アップグレードを開始する前に、bmctl backup cluster コマンドを使用してクラスタをバックアップします。
バックアップ ファイルには機密情報が含まれているため、バックアップ ファイルは安全に保管してください。
クラスタが構成され、正しく動作していることを確認する
アップグレード前にクラスタの健全性を確認するには、クラスタで bmctl check cluster を実行します。このコマンドは、正しく構成されていないノードや停止している Pod があるノードを特定するなど、高度なチェックを実行します。
bmctl upgrade cluster コマンドを実行してクラスタをアップグレードすると、いくつかのプリフライト チェックが実行されます。これらのチェックが成功しなかった場合、アップグレード プロセスは停止します。潜在的な損害からクラスタを保護するためのプリフライト チェックに頼るのではなく、こうした問題を bmctl check cluster コマンドを使用して事前に特定して修正することをおすすめします。
ユーザー ワークロードのデプロイを確認する
ユーザー ワークロードについて考慮すべき領域は、ドレインと API 互換性の 2 つです。
ワークロードのドレイン
アップグレード中に、ノード上のユーザー ワークロードがドレインされます。ワークロードに単一のレプリカがある場合、またはすべてのレプリカが同じノードにある場合、ワークロードのドレインにより、クラスタで実行されているサービスが中断される可能性があります。複数のレプリカを持つワークロードを実行します。レプリカ番号は、同時実行ノード数より大きくする必要があります。
アップグレードの停止を回避するために、バージョン 1.29 までアップグレードするドレイン プロセスでは Pod Disruption Budget（PDB）は考慮されません。ワークロードは縮退状態で実行される可能性があり、最小数のサービス提供レプリカは total
replica number - concurrent upgrade number になります。
API の互換性
API の互換性については、マイナー バージョンのアップグレードを実施する際に、ワークロード API と新しいマイナー バージョンの Kubernetes との互換性を確認してください。必要に応じて、ワークロードを互換性のあるバージョンにアップグレードします。可能な場合は、GKE Enterprise のエンジニアリング チームが、互換性のない API（削除された Kubernetes API など）を使用してワークロードを識別する手順を提供します。
Anthos Service Mesh、Config Sync、Policy Controller、Config Controller、その他の GKE Enterprise コンポーネントを使用している場合は、インストールされたバージョンが Google Distributed Cloud の新しいバージョンと互換性があるかどうかを確認します。GKE Enterprise コンポーネントのバージョン互換性情報については、GKE Enterprise のバージョンとアップグレードのサポートをご覧ください。
Webhook の使用を監査する
クラスタに Webhook（特に Policy Controller などの監査を目的とする Pod リソース）があるかどうかを確認します。クラスタのアップグレード中のドレイン プロセスにより、Policy Controller Webhook サービスが中断され、アップグレードが停止したり長時間を要したりする場合があります。これらの Webhook を一時的に無効にするか、高可用性（HA）デプロイを使用することをおすすめします。
プレビュー機能の使用を確認する
プレビュー機能は変更される場合があり、テストと評価のみを目的として提供されています。 本番環境のクラスタでプレビュー機能を使用しないでください。プレビュー機能を使用するクラスタを必ずアップグレードできるというわけではありません。場合によっては、プレビュー機能を使用するクラスタのアップグレードを明示的にブロックすることがあります。
アップグレードに関連する重要な変更点については、リリースノートをご覧ください。
SELinux のステータスを確認する
コンテナを保護するために SELinux を有効にする場合は、すべてのホストマシンで SELinux を Enforced モードで有効にする必要があります。リリース 1.9.0 以降の Google Distributed Cloud では、クラスタの作成またはクラスタのアップグレードの前または後に SELinux を有効または無効にできます。Red Hat Enterprise Linux（RHEL）では、SELinux がデフォルトで有効になっています。ホストマシンで SELinux が無効になっている場合や、不明な場合は、SELinux を使用したコンテナの保護をご覧ください。
Google Distributed Cloud は、RHEL システムの SELinux のみをサポートしています。
Pod の密度構成を変更しない
Google Distributed Cloud は、nodeConfig.PodDensity.MaxPodsPerNode を持つノードあたり最大 250 個の Pod の構成をサポートしています。Pod 密度はクラスタの作成時にのみ構成できます。既存のクラスタのポッド密度設定を更新することはできません。 アップグレード中は、Pod の密度構成を変更しないでください。
コントロール プレーンとロードバランサのノードがメンテナンス モードになっていないことを確認する
アップグレードを開始する前に、コントロール プレーンとロードバランサのノードがメンテナンス中でないことを確認します。いずれかのノードがメンテナンス モードの場合、コントロール プレーンとロードバランサのノードプールを十分に利用できるようにするために、アップグレードは一時停止します。