Google Distributed Cloud は、障害の範囲を限定し、ビジネスの継続性に不可欠な機能を優先するように設計されています。このドキュメントでは、障害が発生した際にクラスタの機能がどのような影響を受けるかを説明します。この情報は、問題が発生した場合にトラブルシューティングを行う部分の優先順位を決めるのに役立ちます。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。Google Distributed Cloud のコア機能には次のカテゴリがあります。
- ワークロードの実行: 既存のワークロードを継続して実行できます。これは、ビジネスの継続性を維持するための最も重要な考慮事項です。クラスタに問題が発生しても、既存のワークロードは中断されることなく引き続き実行できます。
- ワークロードの管理: ワークロードの作成、更新、削除を行うことができます。これは、クラスタに問題が発生した場合でも、トラフィックが増加した際にワークロードを拡張するために 2 番目に重要な考慮事項です。
- ユーザー クラスタの管理: ノードの管理、ユーザー クラスタの更新、アップグレード、削除を行うことができます。これは、アプリケーションのライフサイクルの考慮事項よりも重要度が低くなります。既存のノードに使用可能な容量があれば、ユーザー クラスタを変更できなくても、ユーザーのワークロードには影響しません。
- 管理クラスタを管理する: 管理クラスタを更新、アップグレードできます。
- 管理クラスタとユーザー クラスタを別々に使用するデプロイの場合、管理クラスタはユーザーのワークロードをホストしないため、この考慮事項の重要度は最も低くなります。管理クラスタに問題が発生しても、他のクラスタのアプリケーションのワークロードは中断されることなく実行され続けます。
- ハイブリッドやスタンドアロンなど、他のデプロイモデルを使用する場合は、管理クラスタがアプリケーションのワークロードを実行します。管理クラスタに問題が発生してコントロール プレーンが停止すると、アプリケーション ワークロードやユーザー クラスタ コンポーネントも管理できなくなります。
以下のセクションでは、これらのコア機能のカテゴリを使用して、特定のタイプの障害シナリオの影響について説明します。障害シナリオの一環として中断が発生する場合は、可能な限り停止の期間（順序）も記載します。
ノード障害
Google Distributed Cloud のノードが機能しなくなることや、ネットワーク上で到達不能になることがあります。障害が発生したマシンが属しているノードプールとクラスタに応じて、いくつかの障害モードがあります。
コントロール プレーン ノード
次の表に、Google Distributed Cloud のコントロール プレーンの一部であるノードの動作の概要を示します。
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止（期間） | 停止なし | 停止の可能性あり（不明） | 停止の可能性あり（不明） | 停止の可能性あり（不明） |
| 説明 | — | ノードの障害が、高可用性でない（HA）ユーザー クラスタ内の単一のコントロール プレーン ノードに影響する場合、または HA ユーザー クラスタ内のコントロール プレーン ノードの半分以上に影響する場合は停止が発生しています。ユーザー クラスタのコントロール プレーンのクォーラムが失われます。 | ノード障害が、非 HA 管理クラスタ内の単一のコントロール プレーン ノードに影響するか、HA 管理クラスタ内の半分以上のコントロール プレーン ノードに影響する場合は、停止が発生します。管理クラスタのコントロール プレーンのクォーラムが失われます。 | ノード障害が、非 HA 管理クラスタ内の単一のコントロール プレーン ノードに影響するか、HA 管理クラスタ内の半分以上のコントロール プレーン ノードに影響する場合は、停止が発生します。管理クラスタのコントロール プレーンのクォーラムが失われます。 |
| 復旧 | — | 詳細については、クォーラムの損失から回復する方法をご覧ください。 | 詳細については、クォーラムの損失から回復する方法をご覧ください。 | 詳細については、クォーラムの損失から回復する方法をご覧ください。 |
| 予防策 | — | 停止が発生する可能性を最小限に抑えるために、ユーザー クラスタを HA モードでデプロイします。 | 停止が発生する可能性を最小限に抑えるために、管理クラスタを HA モードでデプロイします。 | 停止が発生する可能性を最小限に抑えるために、管理クラスタを HA モードでデプロイします。 |
ロードバランサ ノード
次の表に、Google Distributed Cloud でロードバランサをホストするノードの動作の概要を示します。このガイダンスは、レイヤ 2 モードのバンドル ロードバランサにのみ適用されます。手動によるロード バランシングの場合は、外部ロードバランサの障害モードを確認します。
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止（期間） | 停止の可能性あり（各種） | 停止の可能性あり（各種） | 停止の可能性あり（各種） | 停止の可能性あり（各種） |
| 説明 | 外部ワークロードはクラスタ内のワークロードと通信する際にデータプレーン ロードバランサに依存しており、ロードバランサ ノードが 1 つしかない場合は、停止が発生します。 | ユーザー クラスタのコントロール プレーンの仮想 IP アドレスは、1 つのロードバランサ ノード上に存在します。ユーザー クラスタのロードバランサ ノードプールが HA でない場合、停止が発生します。 | 管理クラスタのコントロール プレーンの仮想 IP アドレスは、1 つのロードバランサ ノード上に存在します。管理クラスタのロードバランサ ノードプールが HA でない場合、停止が発生します。 | 管理クラスタのコントロール プレーンの仮想 IP アドレスは、1 つのロードバランサ ノード上に存在します。管理クラスタのロードバランサ ノードプールが HA でない場合、停止が発生します。 |
| 復旧 | ロードバランサ ノードが複数ある場合、MetalLB フェイルオーバーは数秒以内に発生します。 HA でない場合は、追加のロードバランサ ノードをデプロイすることを検討してください。 |
HA の場合、フェイルオーバーは数秒程度で自動的に行われます。 HA でない場合は、ロードバランサ ノードの追加を検討してください。 |
HA の場合、フェイルオーバーは数秒程度で自動的に行われます。 HA でない場合は、追加のロードバランサ ノードをデプロイすることを検討してください。 |
HA の場合、フェイルオーバーは数秒程度で自動的に行われます。 HA でない場合は、追加のロードバランサ ノードをデプロイすることを検討してください。 |
| 予防策 | 停止が発生する可能性を最小限に抑えるには、ロードバランサのノードプールを HA モードでデプロイします。 | 停止が発生する可能性を最小限に抑えるには、ロードバランサのノードプールを HA モードでデプロイします。 | 停止が発生する可能性を最小限に抑えるには、ロードバランサのノードプールを HA モードでデプロイします。 | 停止が発生する可能性を最小限に抑えるには、ロードバランサのノードプールを HA モードでデプロイします。 |
ワーカーノード
次の表に、Google Distributed Cloud のワーカーノードの動作の概要を示します。
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止（期間） | 停止の可能性あり（数秒程度） | 停止なし | 停止なし | 停止なし |
| 説明 | 障害が発生したノードで実行されている ユーザー アプリケーションが予備のワークロード容量を持ち、複数のノードに分散されている場合、再試行を行うクライアントで停止は検知されません。
|
— | — | — |
| 復旧 | クラスタに予備の容量がない場合は、複数の障害ゾーンに分散したノードを追加でデプロイし、障害が発生したワークロードを新しいノードに移行する必要があります。 | — | — | — |
| 予防策 | 複数の障害ゾーンに分散しているノードをデプロイします。 複数の障害ゾーンに分散された複数のレプリカを使用してワークロードをデプロイし、停止の可能性を最小限に抑えます。 |
— | — | — |
ストレージの障害
Google Distributed Cloud のストレージが機能しなくなることや、ネットワーク上で到達不能になることがあります。障害が発生したストレージに応じて、いくつかの障害モードがあります。
etcd
ノードの突然の電源切断やストレージの根本的な障害が発生した場合、/var/lib/etcd ディレクトリと /var/lib/etcd-events ディレクトリの内容が破損する可能性があります。次の表に、etcd の障害によるコア機能の動作の概要を示します。
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止（期間） | 停止なし | 停止の可能性あり（不明） | 停止の可能性あり（不明） | 停止の可能性あり（不明） |
| 説明 | 既存のワークロードが Kubernetes コントロール プレーンに依存しない場合は、ワークロードは停止することなく機能し続けます。 | 単一のコントロール プレーン ユーザー クラスタの etcd で障害が発生するか、HA ユーザー クラスタ内の半分以上のコントロール プレーン ノードで障害が発生すると、停止が起きます。ユーザー クラスタのコントロール プレーンのクォーラムが失われます。 |
単一のコントロール プレーン管理クラスタの etcd で障害が発生するか、HA 管理クラスタ内の半分以上のコントロール プレーン ノードで障害が発生すると、停止が発生します。管理クラスタのコントロール プレーンのクォーラムが失われます。 |
単一のコントロール プレーン管理クラスタの etcd で障害が発生するか、HA 管理クラスタ内の半分以上のコントロール プレーン ノードで障害が発生すると、停止が発生します。管理クラスタのコントロール プレーンのクォーラムが失われます。 |
| 復旧 | — | 詳細については、クォーラムの損失から回復する方法をご覧ください。 | 詳細については、クォーラムの損失から回復する方法をご覧ください。 | 詳細については、クォーラムの損失から回復する方法をご覧ください。 |
| 予防策 | — | 停止が発生する可能性を最小限に抑えるために、ユーザー クラスタを HA モードでデプロイします。 | 停止が発生する可能性を最小限に抑えるために、管理クラスタを HA モードでデプロイします。 | 停止が発生する可能性を最小限に抑えるために、管理クラスタを HA モードでデプロイします。 |
ユーザー アプリケーションの PersistentVolume
次の表に、PersistentVolume での障害の発生によるコア機能の動作の概要を示します。
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止（期間） | 停止の可能性あり（不明） | 停止なし | 停止なし | 停止なし |
| 説明 | 障害の発生した PersistentVolume を使用するワークロード |
— | — | — |
| 復旧 | — | — | — | — |
| 予防策 | 停止が発生する可能性を最小限に抑えるために、ユーザー ワークロードを HA モードでデプロイします。 | — | — | — |
Fluent Bit の破損したディスク
Fluent Bit のディスクの破損は、コア機能には影響しませんが、Google Cloud でログを収集して検査する機能には影響します。
stackdriver-log-forwarder のログから SIGSEGV イベントが検知される場合があります。このエラーは、ディスク上でバッファリングされたログが破損したことが原因で発生する可能性があります。
Fluent Bit には、壊れたチャンクを除去してドロップするメカニズムがあります。この機能は、Google Distributed Cloud で使用される fluent-bit バージョン（v1.8.3）で使用できます。
LoadBalancer IP の枯渇
割り当てられたプール内の IP アドレスが現在すべて占有されている場合、新しく作成された LoadBalancer サービスは LoadBalancer IP アドレスを取得できません。このシナリオは、サービスのクライアントが LoadBalancer サービスと通信する機能に影響します。
この IP アドレスの枯渇から回復するには、クラスタのカスタム リソースを変更して、アドレスプールにより多くの IP アドレスを割り振ります。
証明書の期限切れ
Google Distributed Cloud は、クラスタのインストール プロセス中に自己署名認証局（CA）を生成します。CA には 10 年間の有効期限があり、1 年後に有効期限が切れる証明書を生成します。証明書を定期的にローテーションして、クラスタのダウンタイムを回避します。証明書をローテーションするには、クラスタのアップグレードが推奨されます。クラスタをアップグレードできない場合は、オンデマンド CA ローテーションを実行できます。クラスタ証明書の詳細については、Kubernetes ドキュメントの PKI 証明書と要件をご覧ください。
クラスタ証明書が期限切れになった場合は、手動で更新する必要があります。
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止（期間） | 停止なし | 停止の可能性あり（不明） | 停止の可能性あり（不明） | 停止の可能性あり（不明） |
| 説明 | ユーザー ワークロードが kubernetes コントロール プレーンのコンポーネントと通信しない場合、中断は発生しません。 | ユーザー クラスタの認証局が期限切れになると、停止が発生します。 | 管理クラスタの認証局が期限切れになると、停止が発生します。 | ユーザー クラスタの認証局が期限切れになると、停止が発生します。 |
| 復旧 | — | ユーザー クラスタで証明書を手動で更新する手順に沿って操作します。 |
ユーザー クラスタで証明書を手動で更新する手順に沿って操作します。 |
ユーザー クラスタで証明書を手動で更新する手順に沿って操作します。 |
| 予防策 | 証明書の有効期限を対象とするモニターを設定します。指標の例 kubelet_certificate_manager_server_expiration_seconds は、指標のリストで確認できます。 |
|||
アップグレードの失敗
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止（期間） | 停止なし | 停止なし | 停止の可能性あり（不明） | 停止の可能性あり（不明） |
| 説明 | ユーザー クラスタのコントロール プレーンでアップグレードに失敗した場合でも、既存のワークロードが停止されることはありません。 特定のワーカーノードでアップグレードが失敗すると、そのノード上のワークロードはドレインされ、その他の正常なノードに追加の容量があればその正常なノードに移動されます。 |
コントロール プレーン ノードのいずれかでアップグレードに失敗すると、アップグレードは停止します。ユーザー クラスタが HA の場合は、アップグレードに失敗してもクラスタは機能します。 | 管理クラスタのコントロール プレーンでアップグレードが失敗した場合は、アップグレードが終了するまで停止が発生します。 | 管理クラスタのコントロール プレーンでアップグレードが失敗した場合は、アップグレードが終了するまで停止が発生します。 |
| 復旧 | — | — | アップグレードは再試行できます。詳細については、アップグレードの問題を診断して再開する方法をご覧ください。 | アップグレードは再試行できます。詳細については、アップグレードの問題を診断して再開する方法をご覧ください。 |
| 予防策 | — | — | 詳細については、アップグレードの前にバックアップを作成する方法をご覧ください。 | 詳細については、アップグレードの前にバックアップを作成する方法をご覧ください。 |
次のステップ
プロダクトの既知の問題と回避策について詳しくは、Google Distributed Cloud の既知の問題をご覧ください。
- さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。