3.2.2. 専用インフラストラクチャーノードの作成

重要

インストーラーでプロビジョニングされるインフラストラクチャー環境またはコントロールプレーンノード (別名マスターノード) がマシン API によって管理されているクラスターについては、インフラストラクチャーマシンセットの作成を参照してください。

クラスターの要件により、インフラストラクチャー ( infra ノードとも呼ばれる) がプロビジョニングされます。インストーラーは、コントロールプレーンノードとワーカーノードのプロビジョニングのみを提供します。ワーカーノードは、ラベル付けによって、インフラストラクチャーノードまたはアプリケーション (app とも呼ばれる) として指定できます。

手順

  1. アプリケーションノードとして機能させるワーカーノードにラベルを追加します。

    $ oc label node <node-name> node-role.kubernetes.io/app=""
  2. インフラストラクチャーノードとして機能する必要のあるワーカーノードにラベルを追加します。

    $ oc label node <node-name> node-role.kubernetes.io/infra=""
  3. 該当するノードに infra ロールおよび app ロールがあるかどうかを確認します。

    $ oc get nodes
  4. デフォルトのクラスタースコープのセレクターを作成するには、以下を実行します。デフォルトのノードセレクターはすべての namespace で作成された Pod に適用されます。これにより、Pod の既存のノードセレクターとの交差が作成され、Pod のセレクターをさらに制限します。

    重要

    デフォルトのノードセレクターのキーが Pod のラベルのキーと競合する場合、デフォルトのノードセレクターは適用されません。

    ただし、Pod がスケジュール対象外になる可能性のあるデフォルトノードセレクターを設定しないでください。たとえば、Pod のラベルが node-role.kubernetes.io/master="" などの別のノードロールに設定されている場合、デフォルトのノードセレクターを node-role.kubernetes.io/infra="" などの特定のノードロールに設定すると、Pod がスケジュール不能になる可能性があります。このため、デフォルトのノードセレクターを特定のノードロールに設定する際には注意が必要です。

    または、プロジェクトノードセレクターを使用して、クラスター全体でのノードセレクターの競合を避けることができます。

    1. Scheduler オブジェクトを編集します。

      $ oc edit scheduler cluster
    2. 適切なノードセレクターと共に defaultNodeSelector フィールドを追加します。

      apiVersion: config.openshift.io/v1
      kind: Scheduler
      metadata:
        name: cluster
      ...
      spec:
        defaultNodeSelector: topology.kubernetes.io/region=us-east-1 1
      ...
      1
      このサンプルノードセレクターは、デフォルトで us-east-1 リージョンのノードに Pod をデプロイします。
    3. 変更を適用するためにファイルを保存します。

これで、インフラストラクチャーリソースを新しくラベル付けされた infra ノードに移動できます。

関連情報

  • プロジェクトノードセレクターを設定してクラスター全体のノードセレクターキーの競合を回避する方法に関する詳細は、Project node selectors を参照してください。