ノード障害ガイド

ノード障害を管理するためのガイド

ノード障害は、ハードウェア障害やネットワーク停止など、様々な理由で発生する可能性があります。このガイドでは、ノード障害が発生した場合に予測されることと、ノード障害からの復旧方法について説明します。復旧は、Storage Provisionerおよび使用するストレージのタイプによって異なります。

予測されること

デフォルトでは、ノードに障害が発生した場合:

  • 障害がKubernetes APIサーバーに反映され、ノードのステータスがNotReadyに更新されるまで、最大1分かかる場合があります。

  • ノードのステータスがNotReadyになってから約5分後に、そのノードのポッドのステータスがUnknownまたはNodeLostに変わります。

  • コントローラ付きのポッドのステータス(Daemonsets、Statefulsets、Deploymentsなど)は、Terminatingに変わります。

    ノート: コントローラがないポッドはPodSpecで開始し、終了しません。手動で削除して再作成する必要があります。

  • 新しいポッドは、Readyステータスのままのノードから開始されます。

    ノート: Statefulsetsは特殊なケースです。Statefulsetコントローラは、指定された名前に対してポッドの順序付きリストを1つずつ保持します。Statefulsetコントローラは、既存のポッドの名前で新しいポッドを起動しません。

  • ReadWriteOnce型のPersistent Volumesが関連付けられているポッドは、Readyになりません。これは、ポッドが、まだTerminatingである古いポッドにアタッチされている既存のボリュームにアタッチしようとするためです。この状況は、特定の時点でReadWriteOnce型のPersistent Volumesを関連付けることができるのは単一のノードのみで、新しいポッドは別のノードに存在するために発生します。

  • Kubernetesクラスタで複数の可用性ドメインが使用され、障害が発生したノードがその可用性ドメインの最後のノードである場合、既存のボリュームは別の可用性ドメインの新しいポッドからアクセスできなくなります。

復旧について

ノードに障害が発生した後、ノードを5分以内に復旧できる場合、ポッドはRunning状態に戻ります。ノードが5分後に復旧されていない場合、ポッドは終了を完了し、Kubernetes APIサーバーから削除されます。ReadWriteOnce型の永続ボリュームを持つ新しいポッドは、永続ボリュームをマウントしてRunningに変更できるようになります。

ノードが復旧できずに置換された場合、Kubernetes APIサーバーからノードを削除すると、古いポッドが終了し、新しいポッドによってマウントされるReadWriteOnce型の永続ボリュームが解放されます。

Kubernetesクラスタで複数の可用性ドメインを使用する場合は、削除したノードが占有していたものと同じ可用性ドメインに置換ノードを追加する必要があります。これにより、その可用性ドメイン内の永続ボリュームに到達できる置換ノードでポッドをスケジュールでき、その後、ポッドのステータスがRunningに変更されます。

復旧または置換する予定の障害ノード内のポッドまたは永続ボリュームは強制的に削除しないでください。障害ノードでポッドまたは永続ボリュームを強制的に削除すると、データが失われる可能性があり、Statefulsetsの場合はスプリットブレイン・シナリオが発生する可能性があります。Statefulsetsの詳細は、Kubernetesドキュメントの「Force Delete StatefulSet Pods」を参照してください。

障害ノードを元のノードと同じ可用性ドメインで復旧または置換できない場合は、ポッドおよび永続ボリュームを強制的に削除できます。