第9章 ネットワークエッジ上にあるリモートワーカーノード

• コントロールプレーンとすべてのリモートワーカーノードの間でトラフィックをルーティングするには、ルートまたはデフォルトゲートウェイが配置されていることを確認する必要があります。
• Ingress VIP をコントロールプレーンに配置する必要があります。
• ユーザープロビジョニングインフラストラクチャー (UPI) を使用してリモートワーカーノードを追加することは、他のワーカーノードを追加することと同じです。
• インストール時にインストーラーがプロビジョニングしたクラスターにリモートワーカーノードを追加するには、インストール前に install-config.yaml ファイルで各ワーカーノードのサブネットを指定します。DHCP サーバーに追加の設定は必要ありません。リモートワーカーノードはローカルプロビジョニングネットワークにアクセスできないため、仮想メディアを使用する必要があります。
• プロビジョニングネットワークでデプロイされたインストーラーでプロビジョニングされたクラスターにリモートワーカーノードを追加するには、仮想メディアを使用してノードを追加するように、install-config.yaml ファイルで virtualMediaViaExternalNetwork フラグが true に設定されていることを確認します。リモートワーカーノードは、ローカルプロビジョニングネットワークにアクセスできません。PXE ではなく、仮想メディアを使用してデプロイする必要があります。さらに、DHCP サーバー内のリモートワーカーノードの各グループとコントロールプレーンノードの各サブネットを指定します。

関連情報

• サブネット間の通信の確立
• サブネット用のホストネットワークインターフェイスの設定
• コントロールプレーンで実行されるネットワークコンポーネントの設定

• デーモンセットを使用したテイントを容認する Pod の作成
• ノードがダウンした場合に自動的に再起動する静的 Pod の使用
• Kubernetes ゾーンを使用した Pod エビクションの制御
• Pod のエビクションを遅延または回避するための Pod 容認の設定
• ノードを正常でないとマークするタイミングを制御するように kubelet を設定します。

• デーモンセットを使用したテイントを容認する Pod の作成
• ノードを使用して自動的に再起動する静的 Pod の使用
• Pod のエビクションを遅延または回避するための Pod 容認の設定
• ノードコントローラーがノードを正常でないとマークするタイミングを制御するための kubelet の設定

• デーモンセットは通常、動作の再スケジュールを必要としません。ノードがクラスターから切断される場合、ノードの Pod は実行を継続できます。OpenShift Container Platform はデーモンセット Pod の状態を変更せず、Pod を最後に報告された状態のままにします。たとえば、デーモンセット Pod が Running 状態の際にノードが通信を停止する場合、Pod は実行し続けますが、これは OpenShift Container Platform によって実行されていることが想定されます。

• デーモンセット Pod はデフォルトで、tolerationSeconds 値のない node.kubernetes.io/unreachable テイントおよび node.kubernetes.io/not-ready テイントの NoExecute 容認で作成されます。これらのデフォルト値により、コントロールプレーンがノードに到達できなくても、デーモンセット Pod がエビクトされることはありません。以下に例を示します。

  デフォルトでデーモンセット Pod に容認を追加

    tolerations:
      - key: node.kubernetes.io/not-ready
        operator: Exists
        effect: NoExecute
      - key: node.kubernetes.io/unreachable
        operator: Exists
        effect: NoExecute
      - key: node.kubernetes.io/disk-pressure
        operator: Exists
        effect: NoSchedule
      - key: node.kubernetes.io/memory-pressure
        operator: Exists
        effect: NoSchedule
      - key: node.kubernetes.io/pid-pressure
        operator: Exists
        effect: NoSchedule
      - key: node.kubernetes.io/unschedulable
        operator: Exists
        effect: NoSchedule

  Copy to Clipboard Toggle word wrap

• デーモンセットは、ワークロードが一致するワーカーノードで実行されるように、ラベルを使用することができます。
• OpenShift Container Platform サービスエンドポイントを使用してデーモンセット Pod の負荷を分散できます。

• node-monitor-grace-period パラメーターは、コントローラーマネージャーがハートビートを受信しない場合に、この MachineConfig オブジェクトに関連付けられたノードが Unhealthy とマークされた後に、OpenShift Container Platform が待機する時間を指定します。この待機時間後も、ノード上のワークロードは引き続き実行されます。node-monitor-grace-period の期限が切れた後にリモートワーカーノードがクラスターに再度加わる場合、Pod は実行を継続します。新規 Pod をノードにスケジュールできます。node-monitor-grace-period の間隔は 40s です。node-status-update-frequency の値は、node-monitor-grace-period の値よりも低い値である必要があります。
• pod-eviction-timeout パラメーターは、MachineConfig オブジェクトに関連付けられたノードを Unreachable としてマークした後、エビクション用に Pod のマークを開始するまでに OpenShift Container Platform が待機する時間を指定します。エビクトされた Pod は、他のノードで再スケジュールされます。pod-eviction-timeout の期限が切れた後にリモートワーカーノードがクラスターに再結合する場合、ノードコントローラーがオンプレミスで Pod をエビクトしたため、リモートワーカーノードで実行されている Pod は終了します。続いて、Pod をそのノードに再スケジュールできます。pod-eviction-timeout の期間は 5m0s です。

• テイントを容認しない Pod は、エビクションのキューに置かれます。
• 容認の仕様に tolerationSeconds 値を指定せずにテイントを容認する Pod は、永久にバインドされたままになります。
• 指定された tolerationSeconds 値でテイントを容認する Pod は、指定された期間バインドされます。時間が経過すると、Pod はエビクションのキューに置かれます。