Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第8章 インフラストラクチャーマシンセットの作成

重要

高度なマシン管理およびスケーリング機能は、Machine API が動作しているクラスターでのみ使用できます。user-provisioned infrastructure を持つクラスターでは、Machine API を使用するために追加の検証と設定が必要です。

インフラストラクチャープラットフォームタイプが none のクラスターでは、Machine API を使用できません。この制限は、クラスターに接続されている計算マシンが、この機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。

クラスターのプラットフォームタイプを表示するには、以下のコマンドを実行します。 

$ oc get infrastructure cluster -o jsonpath='{.status.platform}'

インフラストラクチャーマシンセットを使用して、デフォルトのルーター、統合コンテナーイメージレジストリー、およびクラスターメトリクスおよびモニタリングのコンポーネントなどのインフラストラクチャーコンポーネントのみをホストするマシンを作成できます。これらのインフラストラクチャーマシンは、環境の実行に必要なサブスクリプションの合計数にカウントされません。

8.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」セクションを参照してください。

インフラストラクチャーノードおよびインフラストラクチャーノードで実行できるコンポーネントの詳細は、OpenShift sizing and subscription guide for enterprise Kubernetes の「Red Hat OpenShift control plane and infrastructure nodes」セクションを参照してください。

インフラストラクチャーノードを作成するには、マシンセットを使用する か、ノードにラベル を付けるか、マシン設定プールを使用 します。

8.1.1. さまざまなクラウドのインフラストラクチャーマシンセットの作成
リンクのコピー

クラウド用のサンプルコンピュートマシンセットを使用します。

8.1.1.1. AWS 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

このサンプル YAML は、Amazon Web Services (AWS) Local Zone の us-east-1a で実行され、node-role.kubernetes.io/infra: "" というラベルが付けられたノードを作成するコンピュートマシンセットを定義します。

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<infra> は追加するノードラベルです。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <infrastructure_id>-infra-<zone>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: infra
3 

        machine.openshift.io/cluster-api-machine-type: infra
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone>
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9
4 

          apiVersion: machine.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone>
5 

            region: <region>
6 

          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-node
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-lb
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructure_id>-subnet-private-<zone>
7 

          tags:
            - name: kubernetes.io/cluster/<infrastructure_id>
              value: owned
            - name: <custom_tag_name>
8 

              value: <custom_tag_value>
          userDataSecret:
            name: worker-user-data
      taints:
9 

        - key: node-role.kubernetes.io/infra
          effect: NoSchedule
1
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2
インフラストラクチャー ID、infra ロールノードラベル、およびゾーンを指定します。
3
infra ロールノードラベルを指定します。
4
OpenShift Container Platform ノードの AWS ゾーンに有効な Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) を指定します。AWS Marketplace イメージを使用する場合は、AWS Marketplace から OpenShift Container Platform サブスクリプションを完了して、リージョンの AMI ID を取得する必要があります。 
$ oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \
    get machineset/<infrastructure_id>-<role>-<zone>
1 5
ゾーン名を指定します (例: us-east-1a)。
6
リージョン (例: us-east-1) を指定します。
7
インフラストラクチャー ID とゾーンを指定します。
8
オプション: クラスターのカスタムタグデータを指定します。たとえば、name:value のペアである Email:admin-email@example.com を指定して、管理者の連絡先電子メールアドレスを追加できます。
注記

カスタムタグは、インストール中に install-config.yml ファイルで指定することもできます。install-config.yml ファイルとマシンセットに同じ name のデータを持つタグが含まれている場合、マシンセットのタグの値が install-config.yml ファイルのタグの値よりも優先されます。

9
ユーザーのワークロードが infra ノードにスケジュールされないように taint を指定します。
注記

インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

AWS で実行されるマシンセットは保証されていない Spot インスタンス をサポートします。AWS のオンデマンドインスタンスと比較すると、スポットインスタンスをより低い価格で使用することでコストを節約できます。MachineSet YAML ファイルに spotMarketOptions を追加して スポットインスタンスを設定 します。

8.1.1.2. Azure 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

このサンプル YAML は、リージョンの 1 Microsoft Azure ゾーンで実行され、node-role.kubernetes.io/infra: "" というラベルの付けられたノードを作成するコンピュートマシンセットを定義します。

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、infra は追加するノードラベルです。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

    machine.openshift.io/cluster-api-machine-role: infra
2 

    machine.openshift.io/cluster-api-machine-type: infra
  name: <infrastructure_id>-infra-<region>
3 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region>
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: infra
        machine.openshift.io/cluster-api-machine-type: infra
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region>
    spec:
      metadata:
        creationTimestamp: null
        labels:
          machine.openshift.io/cluster-api-machineset: <machineset_name>
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
4 

            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/galleries/gallery_<infrastructure_id>/images/<infrastructure_id>-gen2/versions/latest
5 

            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region>
6 

          managedIdentity: <infrastructure_id>-identity
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg
          sshPrivateKey: ""
          sshPublicKey: ""
          tags:
            <custom_tag_name_1>: <custom_tag_value_1>
7 

            <custom_tag_name_2>: <custom_tag_value_2>
          subnet: <infrastructure_id>-<role>-subnet
          userDataSecret:
            name: worker-user-data
          vmSize: Standard_D4s_v3
          vnet: <infrastructure_id>-vnet
          zone: "1"
8 

      taints:
9 

      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
1
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

以下のコマンドを実行してサブネットを取得できます。 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

以下のコマンドを実行して vnet を取得できます。 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1
2
infra ノードラベルを指定します。
3
インフラストラクチャー ID、infra ノードラベル、およびリージョンを指定します。
4
コンピュートマシンセットのイメージの詳細を指定します。Azure Marketplace イメージを使用する場合は、「Azure Marketplace オファリングの使用」を参照してください。
5
インスタンスタイプと互換性のあるイメージを指定します。インストールプログラムによって作成された Hyper-V 世代の V2 イメージには接尾辞 -gen2 が付いていますが、V1 イメージには接尾辞のない同じ名前が付いています。
6
マシンを配置するリージョンを指定します。
7
オプション: マシンセットでカスタムタグを指定します。<custom_tag_name> フィールドにタグ名を指定し、対応するタグ値を <custom_tag_value> フィールドに指定します。
8
マシンを配置するリージョン内のゾーンを指定します。指定したゾーンがリージョンでサポートされていることを確認してください。
重要

アベイラビリティーゾーンがリージョンでサポートされている場合は、ゾーンを指定する必要があります。ゾーンを指定すると、Pod に永続的なボリューム接続が必要な場合にボリュームノードのアフィニティー障害を回避できます。これを行うには、同じリージョン内の各ゾーンにコンピュートマシンセットを作成します。

9
ユーザーのワークロードが infra ノードにスケジュールされないように taint を指定します。
注記

インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

Azure で実行されるマシンセットは、保証されていない Spot 仮想マシン をサポートします。Azure の標準仮想マシンと比較すると、Spot 仮想マシンをより低い価格で使用することでコストを節約できます。MachineSet YAML ファイルに spotVMOptions を追加することで、Spot VM を設定 できます。

8.1.1.3. Azure Stack Hub 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

Microsoft Azure Stack Hub 上にマシンセットを作成できます。特定のクラスター ID とプロバイダーの詳細を含む YAML 設定を定義することで、特殊ノードのプロビジョニングを自動化できます。

Microsoft Azure のサンプル YAML は、リージョン内の 1 つの Azure ゾーンで実行されるコンピュートマシンセットを定義し、node-role.kubernetes.io/infra: "" というラベルが付いたノードを作成します。サンプル YAML では、ユーザーワークロードがインフラノードにスケジュールされないようにするための taint を指定しています。インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

サンプルでは、<infrastructure_id> はクラスターをプロビジョニングしたときに設定したクラスター ID に基づくインフラストラクチャー ID ラベルであり、<infra> は追加するノードラベルです。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    machine.openshift.io/cluster-api-machine-role: <infra>
    machine.openshift.io/cluster-api-machine-type: <infra>
  name: <infrastructure_id>-infra-<region>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region>
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <infra>
        machine.openshift.io/cluster-api-machine-type: <infra>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region>
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
      taints:
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          availabilitySet: <availability_set>
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id>
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region>
          managedIdentity: <infrastructure_id>-identity
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg
          sshPrivateKey: ""
          sshPublicKey: ""
          subnet: <infrastructure_id>-<role>-subnet
          userDataSecret:
            name: worker-user-data
          vmSize: Standard_DS4_v2
          vnet: <infrastructure_id>-vnet
          zone: "1"

ここでは、以下のようになります。

<infrastructure_id>

クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift Container Platform CLI がインストールされている場合は、次のコマンドを実行することでインフラストラクチャー ID を取得できます。 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

以下のコマンドを実行してサブネットを取得できます。 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

以下のコマンドを実行して vnet を取得できます。 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1
< インフラ >
<infra> ノードのラベルを指定します。
<infrastructure_id>-infra-<region>
インフラストラクチャー ID、<infra> ノードラベル、およびリージョンを指定します。
< 領域 >

マシンを配置するリージョンを指定します。

注記

spec.template.spec.providerSpec.value.zone は、マシンを配置するリージョン内のゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。

<availability_set>
クラスターの可用性セットを指定します。
注記

Azure Stack Hub で実行されるマシンセットは、保証されていない Spot 仮想マシンをサポートしません。

8.1.1.4. IBM Cloud 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

サンプル YAML ファイルを使用すると、特定の Virtual Private Cloud (VPC) 内でコンピュートノードまたはインフラストラクチャーノードのプロビジョニングを自動化できます。サンプル YAML は、リージョン内の指定された IBM Cloud® ゾーンで実行されるコンピュートマシンセットを定義し、node-role.kubernetes.io/infra: "" というラベルが付いたノードを作成します。

サンプルでは、<infrastructure_id> はクラスターをプロビジョニングしたときに設定したクラスター ID に基づくインフラストラクチャー ID ラベルであり、<infra> は追加するノードラベルです。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    machine.openshift.io/cluster-api-machine-role: <infra>
    machine.openshift.io/cluster-api-machine-type: <infra>
  name: <infrastructure_id>-<infra>-<region>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <infra>
        machine.openshift.io/cluster-api-machine-type: <infra>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region>
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: ibmcloudproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: ibmcloud-credentials
          image: <infrastructure_id>-rhcos
          kind: IBMCloudMachineProviderSpec
          primaryNetworkInterface:
              securityGroups:
              - <infrastructure_id>-sg-cluster-wide
              - <infrastructure_id>-sg-openshift-net
              subnet: <infrastructure_id>-subnet-compute-<zone>
          profile: <instance_profile>
          region: <region>
          resourceGroup: <resource_group>
          userDataSecret:
              name: <role>-user-data
          vpc: <vpc_name>
          zone: <zone>
        taints:
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule

ここでは、以下のようになります。

<infrastructure_id>

クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
< インフラ >
<infra> ノードのラベルを指定します。
<infrastructure_id>-<infra>-<region>
インフラストラクチャー ID、<infra> ノードラベル、およびリージョンを指定します。
<infrastructure_id>-rhcos
クラスターのインストールに使用されたカスタムの Red Hat Enterprise Linux CoreOS(RHCOS) イメージを指定します。
<infrastructure_id>-subnet-compute-<zone>
マシンを配置するリージョン内のインフラストラクチャー ID とゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。
<instance_profile>
IBM Cloud® インスタンスプロファイル を指定します。
< 領域 >
マシンを配置するリージョンを指定します。
< リソースグループ >
マシンリソースが配置されるリソースグループを指定します。これは、インストール時に指定された既存のリソースグループ、またはインフラストラクチャー ID に基づいて名前が付けられたインストーラーによって作成されたリソースグループのいずれかです。
<vpc_name>
VPC 名を指定します。
< ゾーン >
お使いのリージョン内の、マシンを配置するゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。
taints

インフラノード上でユーザーワークロードがスケジュールされないようにするための taint を指定します。

注記

インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

8.1.1.5. Google Cloud 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

このサンプル YAML は、Google Cloud 用のコンピュートマシンセットを定義しており、特定の VPC 内でノードを自動的にプロビジョニングすることを可能にします。OpenShift Container Platform CLI を使用してこの設定を適用すると、クラスター内のコンピュートリソースのスケーリング、スケジューリング、およびインフラストラクチャー ID のラベル付けの一貫性を確保できます。

サンプル YAML は、Google Cloud で実行されるコンピュートマシンセットを定義し、node-role.kubernetes.io/infra: "" というラベルが付けられたノードを作成します。ここで、infra は追加するノードラベルです。

8.1.1.5.1. OpenShift CLI を使用して取得した値
リンクのコピー

次の例では、OpenShift Container Platform CLI を使用して、クラスターのいくつかの値を取得できます。

インフラストラクチャー ID

<infrastructure_id> 文字列は、クラスターをプロビジョニングしたときに設定したクラスター ID に基づくインフラストラクチャー ID です。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
イメージパス

<path_to_image> 文字列は、ディスクの作成に使用されたイメージへのパスです。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してイメージへのパスを取得できます。 

$ oc -n openshift-machine-api \
  -o jsonpath='{.spec.template.spec.providerSpec.value.disks[0].image}{"\n"}' \
  get machineset/<infrastructure_id>-worker-a

Google Cloud MachineSet の値のサンプル

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-w-a
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <infra>
        machine.openshift.io/cluster-api-machine-type: <infra>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <path_to_image>
            labels: null
            sizeGb: 128
            type: pd-ssd
          gcpMetadata:
          - key: <custom_metadata_key>
            value: <custom_metadata_value>
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          metadata:
            creationTimestamp: null
          networkInterfaces:
          - network: <infrastructure_id>-network
            subnetwork: <infrastructure_id>-worker-subnet
          projectID: <project_name>
          region: us-central1
          serviceAccounts:
          - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
            - <infrastructure_id>-worker
          userDataSecret:
            name: worker-user-data
          zone: us-central1-a
      taints:
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

ここでは、以下のようになります。

<infrastructure_id>
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。
< インフラ >
<infra> ノードのラベルを指定します。
< イメージへのパス >

現在のコンピュートマシンセットで使用されているイメージへのパスを指定します。Google Cloud Marketplace イメージを使用するには、使用するサービスを指定します。

  • OpenShift Container Platform: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-413-x86-64-202305021736
  • OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-413-x86-64-202305021736
  • OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-413-x86-64-202305021736
<gcpMetadata>
オプション: キーと値の ペアの形式でカスタムメタデータを指定します。ユースケースの例は、カスタムメタデータの設定 に関する Google Cloud のドキュメントを参照してください。
<project_name>
クラスターに使用する Google Cloud プロジェクトの名前を指定します。
< サービスアカウント >
単一のサービスアカウントを指定します。複数のサービスアカウントはサポートされていません。
< 汚染 >
インフラノード上でユーザーワークロードがスケジュールされないようにするための taint を指定します。
注記

インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

Google Cloud で実行しているマシンセットは、保証されていない プリエンプション可能な仮想マシンインスタンス をサポートします。Google Cloud の通常のインスタンスと比較して、プリエンプション可能な仮想マシンインスタンスをより低い価格で使用することでコストを節約できます。MachineSet YAML ファイルに preemptible を追加することで、プリエンプション可能な仮想マシンインスタンスを設定 することができます。

8.1.1.6. Nutanix 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

YAML ファイルを使用すると、ノードのプロビジョニングを自動化し、ロールとインフラストラクチャーの要件に基づいてワークロードが正しくスケジュールされるようにすることができます。

このサンプル YAML は、クラスター用の Nutanix コンピュートマシンセットを定義する方法を示しています。このドキュメントでは、新しいノードが一貫して作成されるように、ロール、ラベル、サイジング、ネットワーク設定、およびブート設定を設定する方法について説明します。

サンプル YAML は 、node-role.kubernetes.io/infra: "" というラベルが付いたノードを作成する Nutanix コンピュートマシンセットを定義します。

サンプルでは、<infrastructure_id> はクラスターをプロビジョニングしたときに設定したクラスター ID に基づくインフラストラクチャー ID ラベルであり、<infra> は追加するノードラベルです。

8.1.1.6.1. OpenShift CLI を使用して取得した値
リンクのコピー

以下の例では、OpenShift CLI (oc) を使用してクラスターの値の一部を取得できます。

インフラストラクチャー ID

<infrastructure_id> 文字列は、クラスターをプロビジョニングしたときに設定したクラスター ID に基づくインフラストラクチャー ID です。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
 
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    machine.openshift.io/cluster-api-machine-role: <infra>
    machine.openshift.io/cluster-api-machine-type: <infra>
  name: <infrastructure_id>-<infra>-<zone>
  namespace: openshift-machine-api
  annotations:
    machine.openshift.io/memoryMb: "16384"
    machine.openshift.io/vCPU: "4"
spec:
  replicas: 3
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <infra>
        machine.openshift.io/cluster-api-machine-type: <infra>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone>
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          bootType: ""
          categories:
          - key: <category_name>
            value: <category_value>
          cluster:
            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-credentials
          image:
            name: <infrastructure_id>-rhcos
            type: name
          kind: NutanixMachineProviderConfig
          memorySize: 16Gi
          project:
            type: name
            name: <project_name>
          subnets:
          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi
          userDataSecret:
            name: <user_data_secret>
          vcpuSockets: 4
          vcpusPerSocket: 1
      taints:
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

ここでは、以下のようになります。

<infrastructure_id>
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。
< インフラ >
<infra> ノードのラベルを指定します。
<infrastructure_id>-<role>-<zone>
インフラストラクチャー ID、<infra> ノードラベル、およびゾーンを指定します。
annotations
クラスターオートスケーラーのアノテーションを指定します。
ブートタイプ

コンピュートマシンが使用するブートタイプを指定します。ブートタイプの詳細は、仮想化環境内の UEFI、セキュアブート、および TPM について を参照してください。有効な値は、Legacy、SecureBoot、または UEFI です。デフォルトは、Legacy です。

注記

OpenShift Container Platform 4.20 では、Legacy ブートタイプを使用する必要があります。

< カテゴリー >
コンピュートマシンに適用する Nutanix Prism カテゴリーを 1 つ以上指定します。このスタンザには、Prism Central に存在するカテゴリーのキーと値のペアの key および value パラメーターが必要です。カテゴリーの詳細は、カテゴリー管理 を参照してください。
<cluster>
Nutanix Prism Element のクラスター設定を指定します。この例のクラスタータイプは uuid であるため、uuid スタンザがあります。
<infrastructure_id>-rhcos
使用するイメージを指定します。クラスターに設定されている既存のコンピュートデフォルトマシンのイメージを使用します。
16Gi
クラスターのメモリー量を Gi 単位で指定します。
project
クラスターに使用する Nutanix プロジェクトを指定します。この例のプロジェクトタイプは name であるため、name スタンザがあります。
subnets
Prism Element サブネットオブジェクトの 1 つ以上の UUID を指定します。指定したサブネットのいずれかの CIDR IP アドレス接頭辞に、OpenShift Container Platform クラスターが使用する仮想 IP アドレスが含まれている必要があります。クラスター内の Prism Element 障害ドメインごとに最大 32 個のサブネットがサポートされます。すべてのサブネット UUID 値が一意である必要があります。
120 ギガ
システムディスクのサイズを Gi 単位で指定します。
<user_data_secret>
openshift-machine-api namespace にあるユーザーデータ YAML ファイルで、シークレットの名前を指定します。インストールプログラムがデフォルトのコンピュートマシンセットに入力する値を使用します。
4
vCPU ソケットの数を指定します。
1
ソケットごとの vCPU 数を指定します。
taints

インフラノード上でユーザーワークロードがスケジュールされないようにするための taint を指定します。

注記

インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

8.1.1.7. RHOSP 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

Machine API を使用してコンピュートノードのスケーリングと管理を自動化するには、イメージ ID やネットワーク ID などの Red Hat OpenStack Platform (RHOSP) パラメーターを使用して MachineSet リソースを定義します。

サンプル YAML は Red Hat OpenStack Platform (RHOSP) 上で実行されるコンピュートマシンセットを定義し、node-role.kubernetes.io/infra: "" というラベルの付いたノードを作成します。これは、ユーザーのワークロードがインフラノードにスケジュールされるのを防ぐための taint を指定します。インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

サンプルでは、<infrastructure_id> はクラスターをプロビジョニングしたときに設定したクラスター ID に基づくインフラストラクチャー ID ラベルであり、<infra> は追加するノードラベルです。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    machine.openshift.io/cluster-api-machine-role: infra
    machine.openshift.io/cluster-api-machine-type: infra
  name: <infrastructure_id>-infra
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas>
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: infra
        machine.openshift.io/cluster-api-machine-type: infra
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
      taints:
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1alpha1
          cloudName: openstack
          cloudsSecret:
            name: openstack-cloud-credentials
            namespace: openshift-machine-api
          flavor: <nova_flavor>
          image: <glance_image_name_or_location>
          serverGroupID: <optional_UUID_of_server_group>
          kind: OpenstackProviderSpec
          networks:
          - filter: {}
            subnets:
            - filter:
                name: <subnet_name>
                tags: openshiftClusterID=<infrastructure_id>
          primarySubnet: <rhosp_subnet_UUID>
          securityGroups:
          - filter: {}
            name: <infrastructure_id>-worker
          serverMetadata:
            Name: <infrastructure_id>-worker
            openshiftClusterID: <infrastructure_id>
          tags:
          - openshiftClusterID=<infrastructure_id>
          trunk: true
          userDataSecret:
            name: worker-user-data
          availabilityZone: <optional_openstack_availability_zone>

ここでは、以下のようになります。

<infrastructure_id>

クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift Container Platform CLI がインストールされている場合は、次のコマンドを実行することでインフラストラクチャー ID を取得できます。 

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
<infrastructure_id>-infra
インフラストラクチャー ID と インフラ ノードラベルを指定します。
< サーバーグループのオプションの UUID>
サーバーグループの作成 時に返される値を入力することで、MachineSet YAML のサーバーグループポリシーを設定します。ほとんどのデプロイメントでは、anti-affinity または soft-anti-affinity が推奨されます。
< サブネット名 >

使用するサブネットを指定します。

注記

複数のネットワークへのデプロイメントには、spec.template.spec.providerSpec.value.networks スタンザが必要です。複数のネットワークにデプロイする場合、primarySubnet 値として使用されるネットワークをこのリストに含める必要があります。

<rhosp_subnet_UUID>
ノードのエンドポイントを公開する RHOSP サブネットを指定します。通常、これは install-config.yaml ファイルの machinesSubnet の値として使用される同じサブネットです。

8.1.1.8. vSphere 上のコンピュートマシンセットカスタムリソースのサンプル YAML
リンクのコピー

Machine API を使用して VMware vSphere インフラストラクチャー上のノードプロビジョニングを自動化するには、データセンター、リソースプール、テンプレートなど、VMware vSphere に固有のパラメーターを持つ MachineSet リソースを定義します。

サンプル YAML ファイルは、VMware vSphere 上で実行されるコンピュートマシンセットを定義し、node-role.kubernetes.io/infra: "" というラベルの付いたノードを作成します。

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、infra は追加するノードラベルです。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-infra
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: infra
        machine.openshift.io/cluster-api-machine-type: infra
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          dataDisks:
          - name: "<disk_name>"
            provisioningMode: "<mode>"
            sizeGiB: 20
          diskGiB: 120
          kind: VSphereMachineProviderSpec
          memoryMiB: 8192
          metadata:
            creationTimestamp: null
          network:
            devices:
            - networkName: "<vm_network_name>"
          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <vm_template_name>
          userDataSecret:
            name: worker-user-data
          workspace:
            datacenter: <vcenter_data_center_name>
            datastore: <vcenter_datastore_name>
            folder: <vcenter_vm_folder_path>
            resourcepool: <vsphere_resource_pool>
            server: <vcenter_server_ip>
      taints:
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

以下は、

<infrastructure_id>
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI (oc) がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
<infrastructure_id>-infra
インフラストラクチャー ID と インフラ ノードラベルを指定します。
infra
インフラ ノードのラベルを指定します。
< ディスク名 >
1 つ以上のデータディスク定義を指定します。詳細は、「マシンセットを使用してデータディスクを設定する」を参照してください。
<vm_network_name>
コンピュートマシンセットをデプロイする vSphere 仮想マシンネットワークを指定します。この仮想マシンネットワークは、他のコンピューティングマシンがクラスター内に存在する場所である必要があります。
<vm_template_name>
user-5ddjd-rhcos など、使用する vSphere VM テンプレートを指定します。
<vcenter_data_center_name>
コンピュートマシンセットをデプロイする vCenter データセンターを指定します。
<vcenter_datastore_name>
コンピュートマシンセットをデプロイする vCenter データストアを指定します。
<vcenter_vm_folder_path>
/dc1/vm/user-inst-5ddjd などの vCenter の vSphere 仮想マシンフォルダーへのパスを指定します。
<vsphere_resource_pool>
仮想マシンの vSphere リソースプールを指定します。
<vcenter_server_ip>
vCenter サーバーの IP または完全修飾ドメイン名を指定します。
taints
インフラノード上でユーザーワークロードがスケジュールされないようにするための taint を指定します。
注記

インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

+ :!infra:

8.1.2. コンピュートマシンセットの作成
リンクのコピー

インストールプログラムによって作成されるコンピュートマシンセットに加えて、独自のコンピュートマシンセットを作成することで、選択した特定のワークロードに合わせてマシンコンピュートリソースを動的に管理できます。OpenShift Container Platform CLI を使用して、ノードのプロビジョニングを自動化します。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

  1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

  2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。 

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
  name: <infrastructure_id>-<role>
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
        ...

      ここでは、以下のようになります。

      metadata.labels.machine.openshift.io/cluster-api-cluster
      クラスターインフラストラクチャー ID を指定します。
      メタデータ.ラベル.名前

      デフォルトのノードラベルを指定します。

      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      spec.template.metadata.spec.providerSpec
      コンピュートマシンセット CR の値を指定します。これらの値はプラットフォーム固有のものです。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

  3. 次のコマンドを実行して MachineSet CR を作成します。 

    $ oc create -f <file_name>.yaml

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

8.1.3. インフラストラクチャーノードの作成
リンクのコピー

ラベルを使用すると、コンピュートノードをインフラストラクチャーノードとして設定でき、そこにインフラストラクチャーリソースを移動できます。インフラストラクチャーノードを作成した後、taint と toleration を使用して、適切なワークロードをそれらのノードに移動できます。

重要

installer-provisioned infrastructure 環境、または制御プレーンノードがマシン API によって管理されるクラスターについては、インフラストラクチャーマシンセットの作成を参照してください。

必要に応じて、クラスター全体のデフォルトのノードセレクターを作成できます。デフォルトのノードセレクターは、すべての namespace で作成された Pod に適用され、Pod の既存のノードセレクターと重なります。これにより、Pod のセレクターがさらに制約されます。

重要

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

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

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

手順

  1. インフラストラクチャーノードとして機能させたいコンピュートノードにラベルを追加します。 

    $ oc label node <node-name> node-role.kubernetes.io/infra=""

  2. 該当するノードに infra ロールがあるかどうかを確認します。 

    $ oc get nodes

  3. オプション: クラスター全体のデフォルトのノードセレクターを作成します。

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

      $ oc edit scheduler cluster

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

      apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
spec:
  defaultNodeSelector: node-role.kubernetes.io/infra=""
# ...

      この例のノードセレクターは、デフォルトでインフラストラクチャーノードに Pod をデプロイします。

    3. 変更を適用するためにファイルを保存します。

    これで、インフラストラクチャーリソースを新しいインフラストラクチャーノードに移動できるようになりました。また、新しいインフラストラクチャーノード上の不要なワークロードやノードに属さないワークロードを削除してください。「OpenShift Container Platform インフラストラクチャーコンポーネント」で、インフラストラクチャーノードでの使用がサポートされているワークロードのリストを参照してください。

8.1.4. インフラストラクチャーマシンのマシン設定プール作成
リンクのコピー

インフラストラクチャーマシンに専用の設定が必要な場合は、infra プールを作成する必要があります。

重要

カスタムマシン設定プールを作成すると、デフォルトのワーカープール設定がオーバーライドされます (デフォルトのワーカープール設定が同じファイルまたはユニットを参照する場合)。

手順

  1. 特定のラベルを持つ infra ノードとして割り当てるノードに、ラベルを追加します。 

    $ oc label node <node_name> <label>
     
    $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=

  2. ワーカーロールとカスタムロールの両方をマシン設定セレクターとして含まれるマシン設定プールを作成します。 

    $ cat infra.mcp.yaml

    出力例

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
    1 
    
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/infra: ""
    2

    1
    ワーカーロールおよびカスタムロールを追加します。
    2
    ノードに追加したラベルを nodeSelector として追加します。
    注記

    カスタムマシン設定プールは、ワーカープールからマシン設定を継承します。カスタムプールは、ワーカープールのターゲット設定を使用しますが、カスタムプールのみをターゲットに設定する変更をデプロイする機能を追加します。カスタムプールはワーカープールから設定を継承するため、ワーカープールへの変更もカスタムプールに適用されます。

  3. YAML ファイルを用意した後に、マシン設定プールを作成できます。 

    $ oc create -f infra.mcp.yaml

  4. マシン設定をチェックして、インフラストラクチャー設定が正常にレンダリングされていることを確認します。 

    $ oc get machineconfig

    出力例

    NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
99-master-ssh                                                                                          3.2.0             31d
99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
99-worker-ssh                                                                                          3.2.0             31d
rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             23m
rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.5.0             31d
rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             17d
rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             13d
rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             7d3h
rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             7d3h
rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             17d
rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.5.0             31d
rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             13d

    新規のマシン設定には、接頭辞 rendered-infra-* が表示されるはずです。

  5. オプション: カスタムプールへの変更をデプロイするには、infra などのラベルとしてカスタムプール名を使用するマシン設定を作成します。これは必須ではありませんが、説明の目的でのみ表示されていることに注意してください。これにより、インフラストラクチャーノードのみに固有のカスタム設定を適用できます。

    注記

    新規マシン設定プールの作成後に、MCO はそのプールに新たにレンダリングされた設定を生成し、そのプールに関連付けられたノードは再起動して、新規設定を適用します。

    1. マシン設定を作成します。 

      $ cat infra.mc.yaml

      出力例

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: 51-infra
  labels:
    machineconfiguration.openshift.io/role: infra
      1 
      
spec:
  config:
    ignition:
      version: 3.5.0
    storage:
      files:
      - path: /etc/infratest
        mode: 0644
        contents:
          source: data:,infra

      1
      ノードに追加したラベルを nodeSelector として追加します。

    2. マシン設定を infra のラベルが付いたノードに適用します。 

      $ oc create -f infra.mc.yaml

  6. 新規のマシン設定プールが利用可能であることを確認します。 

    $ oc get mcp

    出力例

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

    この例では、ワーカーノードが infra ノードに変更されました。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る