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