クラスター化された Azure Stack Edge デバイスでの Kubernetes フェールオーバー シナリオ

  • [アーティクル]

Kubernetes クラスターは、コンテナー化されたアプリケーションを調整するための一般的なオープンソース プラットフォームとしてデプロイされます。 この記事では、障害のモードや対応するデバイスの応答など、2 ノード Azure Stack Edge デバイスで Kubernetes がどのように動作するのかについて説明します。

Azure Stack Edge での Kubernetes について

Azure Stack Edge デバイス上で、Kubernetes クラスターを作成するにはコンピューティングを構成します。 コンピューティング ロールが構成されると、マスターおよびワーカー ノードを含む Kubernetes クラスターはすべて自動的にデプロイおよび構成されます。 その後、このクラスターは、kubectl、IoT Edge、または Azure Arc を介したワークロードのデプロイに使用されます。

Azure Stack Edge デバイスは、インフラストラクチャ クラスターを構成する 1 ノード構成または 2 ノード構成として使用できます。 Kubernetes クラスターはインフラストラクチャ クラスターから分離され、インフラストラクチャ クラスターの上にデプロイされます。 インフラストラクチャ クラスターは、Azure Stack Edge デバイス用の永続的なストレージを提供します。一方、Kubernetes クラスターはアプリケーション オーケストレーション専用となります。

Kubernetes クラスターは、マスター ノードとワーカー ノードで構成されます。 クラスター内の Kubernetes ノードは、ご利用のアプリケーションとクラウド ワークフローを実行する仮想マシンです。

  • Kubernetes マスター ノードは、ご利用のクラスターにとって望ましい状態を維持する役割を担います。 マスター ノードはワーカー ノードの制御も行います。
  • ワーカー ノードは、コンテナー化されたアプリケーションを実行します。

2 ノード デバイスの Kubernetes クラスター

2 ノード デバイスの Kubernetes クラスターには、1 つのマスター ノードと 2 つのワーカー ノードがあります。 2 ノード デバイスは高可用性であり、ノードの 1 つで障害が発生した場合でも、デバイスと Kubernetes クラスターの両方の実行が維持されます。 Kubernetes クラスター アーキテクチャの詳細については、Kubernetes の主要な概念に関するドキュメントを参照してください。

2 ノード Azure Stack Edge デバイスでは、Kubernetes マスター VM と Kubernetes worker VM がデバイスのノード A で実行されています。 ノード B では、単一の Kubernetes worker VM が実行されています。

Kubernetes クラスター内の各 worker VM は、ピン留めされた Hyper-V VM です。 ピン留めされた VM は、実行されている特定のノードに関連付けられています。 デバイス上のノード A で障害が発生した場合、マスター VM はノード B にフェールオーバーします。ただし、ピン留めされた VM であるノード A 上の worker VM はノード B にフェールオーバーされません。その逆も同様です。 代わりに、ノード A の worker VM からのポッドがノード B に再バランスされます。

再バランスされたポッドがデバイス ノード B で実行するのに十分な容量を持つには、システムによって、通常の 2 ノード Azure Stack Edge クラスター操作中に各 ASE ノードの容量の 50% 以上を使用しないようにする必要があります。 この容量の使用量はベスト エフォートに基づいて行われ、再バランスされたポッドの実行に十分なリソースがない状況 (たとえば、ASE ノード B に再バランスされた場合に使用できない GPU リソースを必要とするワークロードなど) も考えられます。

これらのシナリオについては、次のセクションの「障害モードと動作」で詳しく説明します。

障害モードと動作

Azure Stack Edge デバイス ノードには、特定の条件下で障害が発生する可能性があります。 このセクションでは、さまざまな障害モードと対応するデバイスの応答について表にまとめています。

Azure Stack Edge ノードの障害または再起動

ノード 失敗 応答
ノード A で障害が発生している
(ノード B に障害は発生していない)		 次の障害が発生する可能性があります。
  • 両方の PSU に障害が発生する
  • ポート 3、ポート 4 のいずれかまたは両方に障害が発生する
  • マザーボード、DIMM、OS ディスクを含むコア コンポーネントの障害
  • ノード全体のエラー
    		 これらの各障害に対して、次の応答が確認されます。
    • Kubernetes マスター VM がノード A からノード B にフェールオーバーする
    • マスター VM が数分でノード B で起動される
    • ノード A からのポッドがノード B 上に再バランスされる
    • ノード B で GPU が使用可能な場合、GPU ワークロードは引き続き実行される
    ノード A の再起動
    (ノード B に障害は発生していない)    		 ノードの再起動 ノード A の再起動が完了し、worker VM が使用可能になると、マスター VM によりノード B からのポッドが再バランスされます。
    ノード B に障害が発生する
    (ノード A に障害は発生していない)    		 次の障害が発生する可能性があります。
    • 両方の PSU に障害が発生する
    • ポート 3、ポート 4 のいずれかまたは両方に障害が発生する
    • マザーボード、DIMM、OS ディスクを含むコア コンポーネントの障害
    • ノード全体のエラー
      		 これらの各障害に対して、次の応答が確認されます。
      • Kubernetes マスター VM は、ノード B からのポッドを再バランスします。これには数分かかる場合があります。
      ノード B の再起動
      (ノード A に障害は発生していない)      		 ノードの再起動 ノード B の再起動が完了し、worker VM が使用可能になると、マスター VM によりノード B からのポッドが再バランスされます。

      Azure Stack Edge ノードの更新

      更新の種類 応答
      デバイス ノードの更新 ローリング更新がデバイス ノードに適用され、ノードは再起動されます。
      Kubernetes サービスの更新 Kubernetes サービスの更新には、次のものが含まれます。
      • デバイス ノード A からデバイス ノード B への Kubernetes マスター VM のフェールオーバー。
      • Kubernetes マスターの更新。
      • Kubernetes ワーカー ノードの更新 (必ずしもこの順序ではありません)。
      更新プロセス全体に 30 分以上かかる場合があります。この期間中、Kubernetes クラスターを任意の管理操作 (新しいワークロードのデプロイなど) で使用できます。 更新中にデバイス ノードからポッドがドレインされますが、このプロセスの間、ワークロードは数秒間オフラインになる可能性があります。

      次のステップ