8.3. マシンセットリソースのインフラストラクチャーノードへの割り当て

手順

1. テイントを infra ノードに追加し、ユーザーのワークロードをこれにスケジュールできないようにします。

   1. ノードにテイントがあるかどうかを判別します。

      $ oc describe nodes <node_name>

      出力例

      oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Roles:              worker
       ...
      Taints:             node-role.kubernetes.io/infra:NoSchedule
       ...

      この例では、ノードにテイントがあることを示しています。次の手順に進み、容認を Pod に追加してください。

   2. ユーザーワークロードをスケジューリングできないように、テイントを設定していない場合は、以下を実行します。

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>

      以下に例を示します。

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute

      ヒント

      または、以下の YAML を適用してテイントを追加できます。

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoExecute
            value: reserved
        ...

      この例では、テイントを、キー node-role.kubernetes.io/infra およびテイントの effect NoSchedule を持つ node1 に配置します。effect が NoSchedule のノードは、テイントを容認する Pod のみをスケジュールしますが、既存の Pod はノードにスケジュールされたままになります。

      注記

      Descheduler が使用されると、ノードのテイントに違反する Pod はクラスターからエビクトされる可能性があります。

2. ルーター、レジストリーおよびモニタリングのワークロードなどの、infra ノードにスケジュールする必要のある Pod 設定の容認を追加します。以下のコードを Pod オブジェクトの仕様に追加します。

   tolerations:
     - effect: NoExecute 1
       key: node-role.kubernetes.io/infra 2
       operator: Exists 3
       value: reserved 4

   1

   ノードに追加した effect を指定します。

   2

   ノードに追加したキーを指定します。

   3

   Exists Operator を、キー node-role.kubernetes.io/infra のあるテイントがノードに存在するように指定します。

   4

   ノードに追加したキーと値のペア Taint の値を指定します。

   この容認は、oc adm taint コマンドで作成されたテイントと一致します。この容認のある Pod は infra ノードにスケジュールできます。

   注記

   OLM でインストールされた Operator の Pod を infra ノードに常に移動できる訳ではありません。Operator Pod を移動する機能は、各 Operator の設定によって異なります。

3. スケジューラーを使用して Pod を infra ノードにスケジュールします。詳細は、Pod のノードへの配置の制御 についてのドキュメントを参照してください。