6.13. インフラストラクチャーノードの作成
高度なマシン管理およびスケーリング機能は、Machine API が動作しているクラスターでのみ使用できます。user-provisioned infrastructure を持つクラスターでは、Machine API を使用するために追加の検証と設定が必要です。
インフラストラクチャープラットフォームタイプが none
のクラスターでは、Machine API を使用できません。この制限は、クラスターに接続されている計算マシンが、この機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。
クラスターのプラットフォームタイプを表示するには、以下のコマンドを実行します。
oc get infrastructure cluster -o jsonpath='{.status.platform}'
$ oc get infrastructure cluster -o jsonpath='{.status.platform}'
インフラストラクチャーマシンセットを使用して、デフォルトのルーター、統合コンテナーイメージレジストリー、およびクラスターメトリクスおよびモニタリングのコンポーネントなどのインフラストラクチャーコンポーネントのみをホストするマシンを作成できます。これらのインフラストラクチャーマシンは、環境の実行に必要なサブスクリプションの合計数にカウントされません。
実稼働デプロイメントでは、インフラストラクチャーコンポーネントを保持するために 3 つ以上のマシンセットをデプロイすることが推奨されます。OpenShift Logging と Red Hat OpenShift Service Mesh の両方が Elasticsearch をデプロイします。これには、3 つのインスタンスを異なるノードにインストールする必要があります。これらの各ノードは、高可用性のために異なるアベイラビリティーゾーンにデプロイできます。この設定には、可用性ゾーンごとに 1 つずつ、合計 3 つの異なるマシンセットが必要です。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。
インフラストラクチャーノードに NoSchedule
taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled
としてマークされます。misscheduled
DNS Pod に対する toleration の追加 または削除を行う必要があります。
6.13.1. OpenShift Container Platform インフラストラクチャーコンポーネント
セルフマネージド Red Hat OpenShift の各サブスクリプションには、OpenShift Container Platform とその他の OpenShift 関連コンポーネントのエンタイトルメントが含まれています。これらのエンタイトルメントは、OpenShift Container Platform のコントロールプレーンおよびインフラストラクチャーのワークロードを実行するために含まれています。サイジング時にこれらのエンタイトルメントを考慮する必要はありません。
インフラストラクチャーノードとしての要件を満たし、含まれるエンタイトルメントを使用するには、(エンドユーザーのアプリケーションに含まれない) クラスターをサポートするコンポーネントだけを、それらのインスタンス上で実行します。たとえば、次のコンポーネントがあります。
- Kubernetes および OpenShift Container Platform コントロールプレーンサービス
- デフォルトルーター
- 統合コンテナーイメージレジストリー
- HAProxy ベースの Ingress Controller
- ユーザー定義プロジェクトのモニタリング用のコンポーネントを含む、クラスターメトリクスの収集またはモニタリングサービス
- クラスター集計ロギング
- Red Hat Quay
- Red Hat OpenShift Data Foundation
- Red Hat Advanced Cluster Management for Kubernetes
- Kubernetes 用 Red Hat Advanced Cluster Security
- Red Hat OpenShift GitOps
- Red Hat OpenShift Pipelines
- Red Hat OpenShift Service Mesh
他のコンテナー、Pod またはコンポーネントを実行するノードは、サブスクリプションが適用される必要のあるワーカーノードです。
インフラストラクチャーノードおよびインフラストラクチャーノードで実行できるコンポーネントの詳細は、OpenShift sizing and subscription guide for enterprise Kubernetes の「Red Hat OpenShift control plane and infrastructure nodes」セクションを参照してください。
インフラストラクチャーノードを作成するには、マシンセットを使用する か、ノードにラベルを付ける か、マシン設定プールを使用します。
6.13.1.1. 専用インフラストラクチャーノードの作成
installer-provisioned infrastructure 環境またはコントロールプレーンノードが Machine API によって管理されるクラスターの場合は、「インフラストラクチャーマシンセットの作成」を参照してください。
クラスターの要件によっては、インフラストラクチャー (infra) ノードをプロビジョニングする必要があります。インストールプログラムによってプロビジョニングされるのは、コントロールプレーンとワーカーノードだけです。ワーカーノードは、ラベル付けによってインフラストラクチャーノードとして指定できます。その後、taint と toleration を使用して、適切なワークロードをインフラストラクチャーノードに移動できます。詳細は、「インフラストラクチャーマシンセットへのリソースの移動」を参照してください。
必要に応じて、クラスター全体のデフォルトのノードセレクターを作成できます。デフォルトのノードセレクターは、すべての namespace で作成された Pod に適用され、Pod の既存のノードセレクターと重なります。これにより、Pod のセレクターがさらに制約されます。
デフォルトのノードセレクターのキーが Pod のラベルのキーと競合する場合、デフォルトのノードセレクターは適用されません。
ただし、Pod がスケジュール対象外になる可能性のあるデフォルトノードセレクターを設定しないでください。たとえば、Pod のラベルが node-role.kubernetes.io/master=""
などの別のノードロールに設定されている場合、デフォルトのノードセレクターを node-role.kubernetes.io/infra=""
などの特定のノードロールに設定すると、Pod がスケジュール不能になる可能性があります。このため、デフォルトのノードセレクターを特定のノードロールに設定する際には注意が必要です。
または、プロジェクトノードセレクターを使用して、クラスター全体でのノードセレクターの競合を避けることができます。
手順
インフラストラクチャーノードとして機能する必要のあるワーカーノードにラベルを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node <node-name> node-role.kubernetes.io/infra=""
$ oc label node <node-name> node-role.kubernetes.io/infra=""
該当するノードに
infra
ロールがあるかどうかを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodes
$ oc get nodes
オプション: クラスター全体のデフォルトのノードセレクターを作成します。
Scheduler
オブジェクトを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit scheduler cluster
$ oc edit scheduler cluster
適切なノードセレクターと共に
defaultNodeSelector
フィールドを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: config.openshift.io/v1 kind: Scheduler metadata: name: cluster spec: defaultNodeSelector: node-role.kubernetes.io/infra="" # ...
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: name: cluster spec: defaultNodeSelector: node-role.kubernetes.io/infra=""
1 # ...
- 1
- この例のノードセレクターは、デフォルトでインフラストラクチャーノードに Pod をデプロイします。
- 変更を適用するためにファイルを保存します。
これで、インフラストラクチャーリソースを新しいインフラストラクチャーノードに移動できるようになりました。また、新しいインフラストラクチャーノード上の不要なワークロードやノードに属さないワークロードを削除してください。「OpenShift Container Platform インフラストラクチャーコンポーネント」で、インフラストラクチャーノードでの使用がサポートされているワークロードのリストを参照してください。