マシン管理

使用するイメージを指定します。クラスターに設定されている既存のコンピュートデフォルトマシンのイメージを使用します。

コンピュートマシンセットに使用するインスタンスタイプを指定します。

コンピュートマシンセットに使用する RAM ロールの名前を指定します。インストーラーが既定のコンピュートマシンセットに入力する値を使用します。

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

クラスターのリソースグループとタイプを指定します。インストーラーが既定のコンピュートマシンセットに入力する値を使用するか、別の値を指定できます。

16 18 20

コンピュートマシンセットに使用するタグを指定します。少なくとも、この例に示されているタグを、クラスターに適切な値とともに含める必要があります。必要に応じて、インストーラーが作成する既定のコンピュートマシンセットに入力するタグなど、追加のタグを含めることができます。

ルートディスクのタイプとサイズを指定します。インストーラーが作成する既定のコンピューティングマシンセットに入力する category 値を使用します。必要に応じて、size にギガバイト単位の別の値を指定します。

openshift-machine-api 名前空間にあるユーザーデータ YAML ファイルでシークレットの名前を指定します。インストーラーが既定のコンピュートマシンセットに入力する値を使用します。

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

2.1.1.1. Alibaba Cloud 使用統計のマシンセットパラメーター

インストーラーが Alibaba Cloud クラスター用に作成するデフォルトのコンピュートマシンセットには、Alibaba Cloud が使用統計を追跡するために内部的に使用する不要なタグ値が含まれています。これらのタグは、spec.template.spec.provider Spec.valueリストの securityGroups、tag、およびvSwitch パラメーターに入力されます。

追加のマシンをデプロイするコンピュートマシンセットを作成するときは、必要な Kubernetes タグを含める必要があります。使用統計タグは、作成するコンピュートマシンセットで指定されていない場合でも、デフォルトで適用されます。必要に応じて、追加のタグを含めることもできます。

次の YAML スニペットは、デフォルトのコンピュートマシンセットのどのタグがオプションでどれが必須かを示しています。

spec.template.spec.providerSpec.value.securityGroups のタグ

spec:
  template:
    spec:
      providerSpec:
        value:
          securityGroups:
          - tags:
            - Key: kubernetes.io/cluster/<infrastructure_id> 1
              Value: owned
            - Key: GISV
              Value: ocp
            - Key: sigs.k8s.io/cloud-provider-alibaba/origin 2
              Value: ocp
            - Key: Name
              Value: <infrastructure_id>-sg-<role> 3
            type: Tags

1 2

オプション: このタグは、コンピュートマシンセットで指定されていない場合でも適用されます。

必須。

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

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

spec.template.spec.providerSpec.value.tag のタグ

spec:
  template:
    spec:
      providerSpec:
        value:
          tag:
          - Key: kubernetes.io/cluster/<infrastructure_id> 1
            Value: owned
          - Key: GISV 2
            Value: ocp
          - Key: sigs.k8s.io/cloud-provider-alibaba/origin 3
            Value: ocp

2 3: オプション: このタグは、コンピュートマシンセットで指定されていない場合でも適用されます。
1: 必須。
<infrastructure_id> は、クラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID です。

spec.template.spec.providerSpec.value.vSwitch のタグ

spec:
  template:
    spec:
      providerSpec:
        value:
          vSwitch:
            tags:
            - Key: kubernetes.io/cluster/<infrastructure_id> 1
              Value: owned
            - Key: GISV 2
              Value: ocp
            - Key: sigs.k8s.io/cloud-provider-alibaba/origin 3
              Value: ocp
            - Key: Name
              Value: <infrastructure_id>-vswitch-<zone> 4
            type: Tags

1 2 3

オプション: このタグは、コンピュートマシンセットで指定されていない場合でも適用されます。

必須。

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

<infrastructure_id> は、クラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID です。
<zone> は、マシンを配置するリージョン内のゾーンです。

2.1.2. コンピュートマシンセットの作成

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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 の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

2.2. AWS でコンピュートマシンセットを作成する

Amazon Web Services (AWS) で OpenShift Container Platform クラスターの特定の目的を果たすように異なるコンピュートマシンセットを作成することができます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-<role>-<zone> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 4
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 8
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 10
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile 11
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone> 12
            region: <region> 13
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-worker-sg 14
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructure_id>-private-<zone> 15
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id> 16
              value: owned
            - name: <custom_tag_name> 17
              value: <custom_tag_value> 18
          userDataSecret:
            name: worker-user-data

1 3 5 11 14 16

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

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

2 4 8

インフラストラクチャー ID、ロールノードラベル、およびゾーンを指定します。

6 7 9

追加するロールノードラベルを指定します。

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>

17 18

オプション: クラスターのカスタムタグデータを指定します。たとえば、name:value のペアである Email:admin-email@example.com を指定して、管理者の連絡先電子メールアドレスを追加できます。

注記

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

ゾーン (例: us-east-1a) を指定します。

リージョン (例: us-east-1) を指定します。

インフラストラクチャー ID とゾーンを指定します。

2.2.2. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.2.3. Amazon EC2 インスタンスメタデータサービスのマシンセットオプション

マシンセットを使用して、Amazon EC2 インスタンスメタデータサービス (IMDS) の特定のバージョンを使用するマシンを作成できます。マシンセットは、IMDSv1 と IMDSv2 の両方を使用できるマシン、または IMDSv2 の使用を必要とするマシンを作成できます。

既存のマシンの IMDS 設定を変更するには、それらのマシンを管理するマシンセット YAML ファイルを編集します。好みの IMDS 設定で新しいコンピュートマシンを展開するには、適切な値を使用してマコンピュートシンセット YAML ファイルを作成します。

重要

IMDSv2 を必要とするマシンを作成するようにマシンセットを設定する前に、AWS メタデータサービスと相互作用するすべてのワークロードが IMDSv2 をサポートしていることを確認してください。

2.2.3.1. マシンセットを使用した IMDS の設定

マシンのマシンセット YAML ファイルで metadataServiceOptions.authentication の値を追加または編集することで、IMDSv2 の使用を要求するかどうかを指定できます。

手順

providerSpec フィールドの下に次の行を追加または編集します。
```
providerSpec:
  value:
    metadataServiceOptions:
      authentication: Required 1
```
1
IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。

2.2.4. マシンを専有インスタンス (Dedicated Instance) としてデプロイするマシンセット

マシンを専有インスタンス (Dedicated Instance) としてデプロイする AWS で実行されるマシンセットを作成できます。専有インスタンス (Dedicated Instance) は、単一のお客様専用のハードウェア上の仮想プライベートクラウド (VPC) で実行されます。これらの Amazon EC2 インスタンスは、ホストのハードウェアレベルで物理的に分離されます。インスタンスが単一つの有料アカウントにリンクされている別の AWS アカウントに属する場合でも、専有インスタンス (Dedicated Instance) の分離が生じます。ただし、専用ではない他のインスタンスは、それらが同じ AWS アカウントに属する場合は、ハードウェアを専有インスタンス (Dedicated Instance) と共有できます。

パブリックまたは専用テナンシーのいずれかを持つインスタンスは、マシン API によってサポートされます。パブリックテナンシーを持つインスタンスは、共有ハードウェア上で実行されます。パブリックテナンシーはデフォルトのテナンシーです。専用のテナンシーを持つインスタンスは、単一テナントのハードウェアで実行されます。

2.2.4.1. マシンセットの使用による専有インスタンス (Dedicated Instance) の作成

マシン API 統合を使用して、専有インスタンス (Dedicated Instance) によってサポートされるマシンを実行できます。マシンセット YAML ファイルの tenancy フィールドを設定し、AWS で専有インスタンス (Dedicated Instance) を起動します。

手順

providerSpec フィールドに専用テナンシーを指定します。
```
providerSpec:
  placement:
    tenancy: dedicated
```

2.2.5. マシンを Spot インスタンスとしてデプロイするマシンセット

マシンを保証されていない Spot インスタンスとしてデプロイする AWS で実行されるコンピュートマシンセットを作成して、コストを節約できます。Spot インスタンスは未使用の AWS EC2 容量を使用し、On-Demand インスタンスよりもコストが低くなります。Spot インスタンスは、バッチやステートレス、水平的に拡張可能なワークロードなどの割り込みを許容できるワークロードに使用することができます。

AWS EC2 は Spot インスタンスをいつでも終了できます。AWS は、中断の発生時にユーザーに警告を 2 分間表示します。OpenShift Container Platform は、AWS が終了についての警告を発行する際に影響を受けるインスタンスからワークロードを削除し始めます。

以下の理由により、Spot インスタンスを使用すると中断が生じる可能性があります。

インスタンス価格は最大価格を超えます。
Spot インスタンスの需要は増大します。
Spot インスタンスの供給は減少します。

AWS がインスタンスを終了すると、Spot インスタンスノードで実行される終了ハンドラーによりマシンリソースが削除されます。コンピュートマシンセットの replicas の量を満たすために、コンピュートマシンセットは Spot インスタンスを要求するマシンを作成します。

2.2.5.1. コンピュートマシンセットの使用による Spot インスタンスの作成

spotMarketOptions をコンピュートマシンセットの YAML ファイルに追加して、AWS で Spot インスタンスを起動できます。

手順

providerSpec フィールドの下に以下の行を追加します。
```
providerSpec:
  value:
    spotMarketOptions: {}
```
オプションで、Spot インスタンスのコストを制限するために、spotMarketOptions.maxPrice フィールドを設定できます。たとえば、maxPrice: '2.50' を設定できます。
maxPrice が設定されている場合、この値は毎時の最大 Spot 価格として使用されます。これを設定しないと、デフォルトで最大価格として On-Demand インスタンス価格までチャージされます。
注記
デフォルトの On-Demand 価格を maxPrice 値として使用し、Spot インスタンスの最大価格を設定しないことが強く推奨されます。

2.2.6. 既存の OpenShift Container Platform クラスターへの GPU ノードの追加

デフォルトのコンピュートマシンセット設定をコピーおよび変更して、AWS EC2 クラウドプロバイダー用の GPU 対応マシンセットとマシンを作成できます。

次の表は、検証済みのインスタンスタイプを示しています。

インスタンスタイプ	NVIDIA GPU アクセラレーター	GPU の最大数	アーキテクチャー
`p4d.24xlarge`	A100	8	x86
`g4dn.xlarge`	T4	1	x86

手順

次のコマンドを実行して、既存のノード、マシン、およびマシンセットを表示します。各ノードは、特定の AWS リージョンと OpenShift Container Platform ロールを持つマシン定義のインスタンスであることに注意してください。

$ oc get nodes

出力例

NAME                                        STATUS   ROLES                  AGE     VERSION
ip-10-0-52-50.us-east-2.compute.internal    Ready    worker                 3d17h   v1.25.4+86bd4ff
ip-10-0-58-24.us-east-2.compute.internal    Ready    control-plane,master   3d17h   v1.25.4+86bd4ff
ip-10-0-68-148.us-east-2.compute.internal   Ready    worker                 3d17h   v1.25.4+86bd4ff
ip-10-0-68-68.us-east-2.compute.internal    Ready    control-plane,master   3d17h   v1.25.4+86bd4ff
ip-10-0-72-170.us-east-2.compute.internal   Ready    control-plane,master   3d17h   v1.25.4+86bd4ff
ip-10-0-74-50.us-east-2.compute.internal    Ready    worker                 3d17h   v1.25.4+86bd4ff

以下のコマンドを実行して、openshift-machine-api 名前空間に存在するマシンおよびマシンセットを表示します。各コンピュートマシンセットは、AWS リージョン内の異なるアベイラビリティーゾーンに関連付けられています。インストーラーは、アベイラビリティゾーン全体でコンピュートマシンの負荷を自動的に分散します。
```
$ oc get machinesets -n openshift-machine-api
```
出力例
```
NAME                                        DESIRED   CURRENT   READY   AVAILABLE   AGE
preserve-dsoc12r4-ktjfc-worker-us-east-2a   1         1         1       1           3d11h
preserve-dsoc12r4-ktjfc-worker-us-east-2b   2         2         2       2           3d11h
```
以下のコマンドを実行して、openshift-machine-api 名前空間に存在するマシンを表示します。現時点では、マシンセットごとに 1 つのコンピュートマシンしかありませんが、特定のリージョンとゾーンにノードを追加するようにコンピュートマシンセットをスケーリングすることができます。
```
$ oc get machines -n openshift-machine-api | grep worker
```
出力例
```
preserve-dsoc12r4-ktjfc-worker-us-east-2a-dts8r      Running   m5.xlarge   us-east-2   us-east-2a   3d11h
preserve-dsoc12r4-ktjfc-worker-us-east-2b-dkv7w      Running   m5.xlarge   us-east-2   us-east-2b   3d11h
preserve-dsoc12r4-ktjfc-worker-us-east-2b-k58cw      Running   m5.xlarge   us-east-2   us-east-2b   3d11h
```
次のコマンドを実行して、既存のコンピュート MachineSet 定義のいずれかのコピーを作成し、結果を JSON ファイルに出力します。これは、GPU 対応のコンピュートマシンセット定義の基礎となります。
```
$ oc get machineset preserve-dsoc12r4-ktjfc-worker-us-east-2a -n openshift-machine-api -o json > <output_file.json>
```
JSON ファイルを編集し、新しい MachineSet 定義に次の変更を加えます。
- worker を gpu に置き換えます。これが新しいマシンセットの名前になります。
- 新しい MachineSet 定義のインスタンスタイプを、NVIDIA Tesla T4 GPU を含む g4dn に変更します。AWS g4dn インスタンスタイプの詳細については、Accelerated Computing を参照してください。
```
$ jq .spec.template.spec.providerSpec.value.instanceType preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a.json

"g4dn.xlarge"
```
  <output_file.json> ファイルは preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a.json として保存されます。
preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a.json の次のフィールドを更新します。
- .metadata.name を gpu を含む名前に変更します。
- .spec.selector.matchLabels["machine.openshift.io/cluster-api-machineset"] を新しい .metadata.name に一致させます。
- .spec.template.metadata.labels["machine.openshift.io/cluster-api-machineset"] を新しい .metadata.name に一致させます。
- .spec.template.spec.providerSpec.value.instanceType to g4dn.xlarge.

変更を確認するには、次のコマンドを実行して、元のコンピュート定義と新しい GPU 対応ノード定義の diff を実行します。

$ oc -n openshift-machine-api get preserve-dsoc12r4-ktjfc-worker-us-east-2a -o json | diff preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a.json -

出力例

10c10

< "name": "preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a",
---
> "name": "preserve-dsoc12r4-ktjfc-worker-us-east-2a",

21c21

< "machine.openshift.io/cluster-api-machineset": "preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a"
---
> "machine.openshift.io/cluster-api-machineset": "preserve-dsoc12r4-ktjfc-worker-us-east-2a"

31c31

< "machine.openshift.io/cluster-api-machineset": "preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a"
---
> "machine.openshift.io/cluster-api-machineset": "preserve-dsoc12r4-ktjfc-worker-us-east-2a"

60c60

< "instanceType": "g4dn.xlarge",
---
> "instanceType": "m5.xlarge",

次のコマンドを実行して、定義から GPU 対応のコンピュートマシンセットを作成します。

$ oc create -f preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a.json

出力例

machineset.machine.openshift.io/preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a created

検証

次のコマンドを実行して、作成したマシンセットを表示します。
```
$ oc -n openshift-machine-api get machinesets | grep gpu
```
MachineSet レプリカ数は 1 に設定されているため、新しい Machine オブジェクトが自動的に作成されます。
出力例
```
preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a   1         1         1       1           4m21s
```

次のコマンドを実行して、マシンセットが作成した Machine オブジェクトを表示します。

$ oc -n openshift-machine-api get machines | grep gpu

出力例

preserve-dsoc12r4-ktjfc-worker-gpu-us-east-2a    running    g4dn.xlarge   us-east-2   us-east-2a  4m36s

ノードの名前空間を指定する必要がないことに注意してください。ノード定義はクラスタースコープ指定されています。

2.2.7. Node Feature Discovery Operator のデプロイ

GPU 対応ノードを作成したら、スケジュールできるように GPU 対応ノードを検出する必要があります。これを行うには、Node Feature Discovery (NFD) Operator をインストールします。NFD Operator は、ノード内のハードウェアデバイス機能を識別します。OpenShift Container Platform で使用できるようにインフラストラクチャーノードのハードウェアリソースを識別してカタログ化するという一般的な問題を解決します。

手順

OpenShift Container Platform コンソールの OperatorHub から Node Feature Discovery Operator をインストールします。
NFD Operator を OperatorHub にインストールした後、インストールされた Operator リストから Node Feature Discovery を選択し、Create instance を選択します。これにより、nfd-master Pod および nfd-worker Pod (コンピュートノードごとに 1 つの nfd-worker Pod) が openshift-nfd 名前空間にインストールされます。

次のコマンドを実行して、Operator がインストールされ、実行されていることを確認します。

$ oc get pods -n openshift-nfd

出力例

NAME                                       READY    STATUS     RESTARTS   AGE

nfd-controller-manager-8646fcbb65-x5qgk    2/2      Running 7  (8h ago)   1d

コンソールでインストール済みの Operator へ移動し、Create Node Feature Discovery を選択します。
Create を選択して、NFD カスタムリソースをビルドします。これにより、openshift-nfd 名前空間に NFD Pod が作成され、ハードウェアリソース用に OpenShift Container Platform ノードをポーリングし、それらをカタログ化します。

検証

ビルドが成功したら、次のコマンドを実行して、各ノードで NFD Pod が実行されていることを確認します。

$ oc get pods -n openshift-nfd

出力例

NAME                                       READY   STATUS      RESTARTS        AGE
nfd-controller-manager-8646fcbb65-x5qgk    2/2     Running     7 (8h ago)      12d
nfd-master-769656c4cb-w9vrv                1/1     Running     0               12d
nfd-worker-qjxb2                           1/1     Running     3 (3d14h ago)   12d
nfd-worker-xtz9b                           1/1     Running     5 (3d14h ago)   12d

NFD Operator は、ベンダー PCI ID を使用してノード内のハードウェアを識別します。NVIDIA は PCI ID 10de を使用します。

次のコマンドを実行して、NFD Operator によって検出された NVIDIA GPU を表示します。
```
$ oc describe node ip-10-0-132-138.us-east-2.compute.internal | egrep 'Roles|pci'
```
出力例
```
Roles: worker

feature.node.kubernetes.io/pci-1013.present=true

feature.node.kubernetes.io/pci-10de.present=true

feature.node.kubernetes.io/pci-1d0f.present=true
```
GPU 対応ノードのノード機能リストに 10de が表示されます。これは、NFD Operator が GPU 対応の MachineSet からノードを正しく識別したことを意味します。

2.3. Azure でコンピュートマシンセットを作成

Microsoft Azure 上の OpenShift Container Platform クラスターで特定の目的を果たすように異なるコンピュートマシンセットを作成することができます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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

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: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role>-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <role> 8
        machine.openshift.io/cluster-api-machine-type: <role> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          machine.openshift.io/cluster-api-machineset: <machineset_name> 11
          node-role.kubernetes.io/<role>: "" 12
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image: 13
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> 14
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> 15
          managedIdentity: <infrastructure_id>-identity 16
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg 17
          sshPrivateKey: ""
          sshPublicKey: ""
          tags:
            - name: <custom_tag_name> 18
              value: <custom_tag_value> 19
          subnet: <infrastructure_id>-<role>-subnet 20 21
          userDataSecret:
            name: worker-user-data 22
          vmSize: Standard_D4s_v3
          vnet: <infrastructure_id>-vnet 23
          zone: "1" 24

1 5 7 16 17 20 23

$ 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 3 8 9 12 21 22

追加するノードラベルを指定します。

4 6 10

インフラストラクチャー ID、ノードラベル、およびリージョンを指定します。

オプション: 可用性セットの使用を有効にするためにコンピュートマシンセットの名前を指定します。この設定は、新規コンピュートマシンにのみ適用されます。

コンピュートマシンセットのイメージの詳細を指定します。Azure Marketplace イメージを使用する場合は、Azure Marketplace イメージの選択を参照してください。

インスタンスタイプと互換性のあるイメージを指定します。インストールプログラムによって作成された Hyper-V 世代の V2 イメージには接尾辞 -gen2 が付いていますが、V1 イメージには接尾辞のない同じ名前が付いています。

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

24

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

18 19

オプション: マシンセットでカスタムタグを指定します。<custom_tag_name> フィールドにタグ名を指定し、対応するタグ値を <custom_tag_value> フィールドに指定します。

2.3.2. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.3.3. Azure Marketplace イメージの選択

Azure Marketplace サービスを使用するマシンをデプロイする、Azure で実行するマシンセットを作成できます。このサービスを使用するには、まず Azure Marketplace イメージを取得する必要があります。イメージを取得するときは、次の点を考慮してください。

イメージは同じですが、Azure Marketplace のパブリシャーは地域によって異なります。北米にお住まいの場合は、redhat をパブリッシャーとして指定してください。EMEA にお住まいの場合は、redhat-limited をパブリッシャーとして指定してください。
このオファーには、rh-ocp-worker SKU と rh-ocp-worker-gen1 SKU が含まれています。rh-ocp-worker SKU は、Hyper-V 世代のバージョン 2 VM イメージを表します。OpenShift Container Platform で使用されるデフォルトのインスタンスタイプは、バージョン 2 と互換性があります。バージョン 1 のみと互換性のあるインスタンスタイプを使用する場合は、rh-ocp-worker-gen1 SKU に関連付けられたイメージを使用します。rh-ocp-worker-gen1 SKU は、Hyper-V バージョン 1 VM イメージを表します。

重要

Azure Marketplace を使用したイメージのインストールは、arm64 インスタンスを含むクラスターではサポートされていません。

前提条件

Azure CLI クライアント (az) をインストールしている。
お客様の Azure アカウントにはオファーのエンタイトルメントがあり、Azure CLI クライアントを使用してこのアカウントにログインしている。

手順

以下のいずれかのコマンドを実行して、利用可能なすべての OpenShift Container Platform イメージを表示します。

北米:

$  az vm image list --all --offer rh-ocp-worker --publisher redhat -o table

出力例

Offer          Publisher       Sku                 Urn                                                             Version
-------------  --------------  ------------------  --------------------------------------------------------------  --------------
rh-ocp-worker  RedHat          rh-ocp-worker       RedHat:rh-ocp-worker:rh-ocpworker:4.8.2021122100               4.8.2021122100
rh-ocp-worker  RedHat          rh-ocp-worker-gen1  RedHat:rh-ocp-worker:rh-ocp-worker-gen1:4.8.2021122100         4.8.2021122100

EMEA:

$  az vm image list --all --offer rh-ocp-worker --publisher redhat-limited -o table

出力例

Offer          Publisher       Sku                 Urn                                                             Version
-------------  --------------  ------------------  --------------------------------------------------------------  --------------
rh-ocp-worker  redhat-limited  rh-ocp-worker       redhat-limited:rh-ocp-worker:rh-ocp-worker:4.8.2021122100       4.8.2021122100
rh-ocp-worker  redhat-limited  rh-ocp-worker-gen1  redhat-limited:rh-ocp-worker:rh-ocp-worker-gen1:4.8.2021122100  4.8.2021122100

注記

インストールする OpenShift Container Platform のバージョンに関係なく、使用する Azure Marketplace イメージの正しいバージョンは 4.8 です。必要に応じて、VM はインストールプロセスの一部として自動的にアップグレードされます。

次のいずれかのコマンドを実行して、オファーのイメージを調べます。

北米:

$ az vm image show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>

EMEA:

$ az vm image show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>

次のコマンドのいずれかを実行して、オファーの条件を確認します。

北米:

$ az vm image terms show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>

EMEA:

$ az vm image terms show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>

次のコマンドのいずれかを実行して、オファリングの条件に同意します。

北米:

$ az vm image terms accept --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>

EMEA:

$ az vm image terms accept --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>

オファーのイメージの詳細 (具体的には publisher、offer、sku、および version の値) を記録します。
オファーのイメージの詳細を使用して、マシンセット YAML ファイルの providerSpec セクションに次のパラメーターを追加します。
Azure Marketplace マシンのサンプル providerSpec イメージ値
```
providerSpec:
  value:
    image:
      offer: rh-ocp-worker
      publisher: redhat
      resourceID: ""
      sku: rh-ocp-worker
      type: MarketplaceWithPlan
      version: 4.8.2021122100
```

2.3.4. Azure ブート診断の有効化

マシンセットが作成する Azure マシンで起動診断を有効にできます。

前提条件

既存の Microsoft Azure クラスターがある。

手順

ストレージタイプに適用可能な diagnostics 設定を、マシンセット YAML ファイルの providerSpec フィールドに追加します。
- Azure Managed ストレージアカウントの場合:
```
providerSpec:
  diagnostics:
    boot:
      storageAccountType: AzureManaged 1
```
  1
  Azure Managed ストレージアカウントを指定します。
- Azure Unmanaged ストレージアカウントの場合:
```
providerSpec:
  diagnostics:
    boot:
      storageAccountType: CustomerManaged 1
      customerManaged:
        storageAccountURI: https://<storage-account>.blob.core.windows.net 2
```
  1
  Azure Unmanaged ストレージアカウントを指定します。
  2
  <storage-account> をストレージアカウントの名前に置き換えます。
  注記
  Azure Blob Storage データサービスのみサポートされています。

検証

Microsoft Azure ポータルで、マシンセットによってデプロイされたマシンの 起動診断 ページを確認し、マシンのシリアルログが表示されることを確認します。

2.3.5. マシンを Spot 仮想マシンとしてデプロイするマシンセット

マシンを保証されていない Spot 仮想マシンとしてデプロイする Azure で実行されるコンピュートマシンセットを作成して、コストを節約できます。Spot 仮想マシンは未使用の Azure 容量を使用し、標準の仮想マシンよりもコストが低くなります。Spot 仮想マシンは、バッチやステートレス、水平的に拡張可能なワークロードなどの割り込みを許容できるワークロードに使用することができます。

Azure は Spot 仮想マシンをいつでも終了できます。Azure は、中断の発生時にユーザーに警告を 30 秒間表示します。OpenShift Container Platform は、Azure が終了についての警告を発行する際に影響を受けるインスタンスからワークロードを削除し始めます。

以下の理由により、Spot 仮想マシンを使用すると中断が生じる可能性があります。

インスタンス価格は最大価格を超えます。
Spot 仮想マシンの供給は減少します。
Azure は容量を戻す必要があります。

Azure がインスタンスを終了すると、Spot 仮想マシンノードで実行される終了ハンドラーによりマシンリソースが削除されます。コンピュートマシンセットの replicas の量を満たすために、コンピュートマシンセットは Spot VM を要求するマシンを作成します。

2.3.5.1. コンピュートマシンセットの使用による Spot VM の作成

spotVMOptions をコンピュータマシンセットの YAML ファイルに追加して、Azure で Spot 仮想マシンを起動できます。

手順

providerSpec フィールドの下に以下の行を追加します。
```
providerSpec:
  value:
    spotVMOptions: {}
```
オプションで、Spot 仮想マシンのコストを制限するために、spotVMOptions.maxPrice フィールドを設定できます。たとえば、maxPrice: '0.98765' を設定できます。maxPrice が設定されている場合、この値は毎時の最大 Spot 価格として使用されます。設定されていない場合、最大価格はデフォルトの -1 に設定され、標準の仮想マシン価格までチャージされます。
Azure は標準価格で Spot 仮想マシン価格を制限します。インスタンスがデフォルトの maxPrice で設定されている場合、Azure は価格設定によりインスタンスをエビクトしません。ただし、インスタンスは容量の制限によって依然としてエビクトできます。

注記

デフォルトの仮想マシンの標準価格を maxPrice 値として使用し、Spot 仮想マシンの最大価格を設定しないことが強く推奨されます。

2.3.6. マシンを一時 OS ディスクにデプロイするマシンセット

マシンを Ephemeral OS ディスクにデプロイする Azure で実行されるコンピュートマシンセットを作成できます。Azure Ephemeral OS ディスクは、リモートの Azure Storage ではなく、ローカルの VM 容量を使用します。したがって、この設定により、追加コストがなく、読み取り、書き込み、および再イメージ化のレイテンシーが短くなります。

関連情報

詳細は、Ephemeral OS disks for Azure VMs についての Microsoft Azure ドキュメントを参照してください。

2.3.6.1. コンピュートマシンセットを使用してエフェメラル OS ディスク上にマシンを作成する

コンピュートマシンセットの YAML ファイルを編集して、Azure の一時 OS ディスクでコンピュートマシンを起動できます。

前提条件

既存の Microsoft Azure クラスターがある。

手順

以下のコマンドを実行してカスタムリソース (CR) を編集します。
```
$ oc edit machineset <machine-set-name>
```
ここで、<machine-set-name> は、エフェメラル OS ディスクにマシンをプロビジョニングするコンピュートマシンセットです。
以下を providerSpec フィールドに追加します。
```
providerSpec:
  value:
    ...
    osDisk:
       ...
       diskSettings: 1
         ephemeralStorageLocation: Local 2
       cachingType: ReadOnly 3
       managedDisk:
         storageAccountType: Standard_LRS 4
       ...
```
1 2 3
これらの行では、Ephemeral OS ディスクを使用できます。
4
一時 OS ディスクは、標準の LRS ストレージのアカウントタイプを使用する仮想マシンまたはスケールセットインスタンスでのみサポートされます。
重要
OpenShift Container Platform での Ephemeral OS ディスクのサポートの実装は、CacheDisk 配置タイプのみをサポートします。placement 設定は変更しないでください。
更新された設定を使用してコンピュートマシンセットを作成します。
```
$ oc create -f <machine-set-config>.yaml
```

検証

Microsoft Azure ポータルで、コンピュートマシンセットによってデプロイされたマシンの Overview ページを確認し、Ephemeral OS ディスク フィールドが OS キャッシュ配置に設定されていることを確認します。

2.3.7. Machine sets that deploy machines with ultra disks as data disks

Ultra ディスクと共にマシンをデプロイする Azure で実行されるマシンセットを作成できます。Ultra ディスクは、最も要求の厳しいデータワークロードでの使用を目的とした高性能ストレージです。

Azure ウルトラディスクに支えられたストレージクラスに動的にバインドし、それらを Pod にマウントする永続ボリューム要求 (PVC) を作成することもできます。

注記

データディスクは、ディスクスループットまたはディスク IOPS を指定する機能をサポートしていません。これらのプロパティーは、PVC を使用して設定できます。

関連情報

2.3.7.1. マシンセットを使用した Ultra ディスクを持つマシンの作成

マシンセットの YAML ファイルを編集することで、Azure 上に Ultra ディスクと共にマシンをデプロイできます。

前提条件

既存の Microsoft Azure クラスターがある。

手順

次のコマンドを実行して、worker データシークレットを使用して openshift-machine-api namespace にカスタムシークレットを作成します。
```
$ oc -n openshift-machine-api \
get secret <role>-user-data \ 1
--template='{{index .data.userData | base64decode}}' | jq > userData.txt 2
```
1
<role> を worker に置き換えます。
2
新しいカスタムシークレットの名前として userData.txt を指定します。
テキストエディターで、userData.txt ファイルを開き、ファイル内の最後の } 文字を見つけます。
1. 直前の行に、, を追加します。
2. , の後に新しい行を作成し、以下の設定内容を追加します。
```
"storage": {
  "disks": [ 1
    {
      "device": "/dev/disk/azure/scsi1/lun0", 2
      "partitions": [ 3
        {
          "label": "lun0p1", 4
          "sizeMiB": 1024, 5
          "startMiB": 0
        }
      ]
    }
  ],
  "filesystems": [ 6
    {
      "device": "/dev/disk/by-partlabel/lun0p1",
      "format": "xfs",
      "path": "/var/lib/lun0p1"
    }
  ]
},
"systemd": {
  "units": [ 7
    {
      "contents": "[Unit]\nBefore=local-fs.target\n[Mount]\nWhere=/var/lib/lun0p1\nWhat=/dev/disk/by-partlabel/lun0p1\nOptions=defaults,pquota\n[Install]\nWantedBy=local-fs.target\n", 8
      "enabled": true,
      "name": "var-lib-lun0p1.mount"
    }
  ]
}
```
  1
  ウルトラディスクとしてノードに接続するディスクの設定の詳細。
  2
  使用しているマシンセットの dataDisks スタンザで定義されている lun 値を指定します。たとえば、マシンセットに lun:0 が含まれている場合は、lun0 を指定します。この設定ファイルで複数の "disks" エントリーを指定することにより、複数のデータディスクを初期化できます。複数の "disks" エントリーを指定する場合は、それぞれの lun 値がマシンセットの値と一致することを確認してください。
  3
  ディスク上の新しいパーティションの設定の詳細。
  4
  パーティションのラベルを指定します。lun0 の最初のパーティションに lun0p1 などの階層名を使用すると便利な場合があります。
  5
  パーティションの合計サイズを MiB で指定します。
  6
  パーティションをフォーマットするときに使用するファイルシステムを指定します。パーティションラベルを使用して、パーティションを指定します。
  7
  起動時にパーティションをマウントする systemd ユニットを指定します。パーティションラベルを使用して、パーティションを指定します。この設定ファイルで複数の "partitions" エントリーを指定することにより、複数のパーティションを作成できます。複数の "partitions" エントリーを指定する場合は、それぞれに systemd ユニットを指定する必要があります。
  8
  Where には、storage.filesystems.path の値を指定します。What には、storage.filesystems.device の値を指定します。
次のコマンドを実行して、無効化テンプレート値を disableTemplating.txt というファイルに抽出します。
```
$ oc -n openshift-machine-api get secret <role>-user-data \ 1
--template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt
```
1
<role> を worker に置き換えます。
次のコマンドを実行して、userData.txt ファイルと disableTemplating.txt ファイルを組み合わせてデータシークレットファイルを作成します。
```
$ oc -n openshift-machine-api create secret generic <role>-user-data-x5 \ 1
--from-file=userData=userData.txt \
--from-file=disableTemplating=disableTemplating.txt
```
1
<role>-user-data-x5 には、シークレットの名前を指定します。<role> を worker に置き換えます。
既存の Azure MachineSet カスタムリソース (CR) をコピーし、次のコマンドを実行して編集します。
```
$ oc edit machineset <machine-set-name>
```
ここで、<machine-set-name> は、Ultra ディスクと共にマシンをプロビジョニングするマシンセットです。

示された位置に次の行を追加します。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
spec:
  template:
    spec:
      metadata:
        labels:
          disk: ultrassd 1
      providerSpec:
        value:
          ultraSSDCapability: Enabled 2
          dataDisks: 3
          - nameSuffix: ultrassd
            lun: 0
            diskSizeGB: 4
            deletionPolicy: Delete
            cachingType: None
            managedDisk:
              storageAccountType: UltraSSD_LRS
          userDataSecret:
            name: <role>-user-data-x5 4

1: このマシンセットによって作成されるノードを選択するために使用するラベルを指定します。この手順では、この値に disk.ultrassd を使用します。
2 3: これらのラインにより、ウルトラディスクの使用が可能になります。dataDisk の場合、スタンザ全体を含めます。
4: 以前に作成したユーザーデータシークレットを指定します。<role> を worker に置き換えます。

次のコマンドを実行して、更新された設定を使用してマシンセットを作成します。
```
$ oc create -f <machine-set-name>.yaml
```

検証

次のコマンドを実行して、マシンが作成されていることを確認します。
```
$ oc get machines
```
マシンは Running 状態になっているはずです。
実行中でノードが接続されているマシンの場合、次のコマンドを実行してパーティションを検証します。
```
$ oc debug node/<node-name> -- chroot /host lsblk
```
このコマンドでは、oc debug node/<node-name> がノード <node-name> でデバッグシェルを開始し、-- を付けてコマンドを渡します。渡されたコマンド chroot /host は、基盤となるホスト OS バイナリーへのアクセスを提供し、lsblk は、ホスト OS マシンに接続されているブロックデバイスを表示します。

次のステップ

Pod 内から Ultra ディスクを使用するには、マウントポイントを使用するワークロードを作成します。次の例のような YAML ファイルを作成します。

apiVersion: v1
kind: Pod
metadata:
  name: ssd-benchmark1
spec:
  containers:
  - name: ssd-benchmark1
    image: nginx
    ports:
      - containerPort: 80
        name: "http-server"
    volumeMounts:
    - name: lun0p1
      mountPath: "/tmp"
  volumes:
    - name: lun0p1
      hostPath:
        path: /var/lib/lun0p1
        type: DirectoryOrCreate
  nodeSelector:
    disktype: ultrassd

2.3.7.2. Ultra ディスクを有効にするマシンセットのリソースに関するトラブルシューティング

このセクションの情報を使用して、発生する可能性のある問題を理解し、回復してください。

2.3.7.2.1. ウルトラディスク設定が正しくありません

マシンセットで ultraSSDCapability パラメーターの誤った設定が指定されている場合、マシンのプロビジョニングは失敗します。

たとえば、ultraSSDCapability パラメーターが Disabled に設定されているが、dataDisks パラメーターでウルトラディスクが指定されている場合、次のエラーメッセージが表示されます。

StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.

この問題を解決するには、マシンセットの設定が正しいことを確認してください。

2.3.7.2.2. サポートされていないディスクパラメーター

ウルトラディスクと互換性のないリージョン、アベイラビリティーゾーン、またはインスタンスサイズがマシンセットで指定されている場合、マシンのプロビジョニングは失敗します。ログで次のエラーメッセージを確認してください。

failed to create vm <machine_name>: failure sending request for machine <machine_name>: cannot create vm: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="Storage Account type 'UltraSSD_LRS' is not supported <more_information_about_why>."

この問題を解決するには、サポートされている環境でこの機能を使用していること、およびマシンセットの設定が正しいことを確認してください。

2.3.7.2.3. ディスクを削除できません

データディスクとしてのウルトラディスクの削除が期待どおりに機能しない場合、マシンが削除され、データディスクが孤立します。必要に応じて、孤立したディスクを手動で削除する必要があります。

2.3.8. マシンセットの顧客管理の暗号鍵の有効化

Azure に暗号化キーを指定して、停止中に管理ディスクのデータを暗号化できます。マシン API を使用して、顧客管理の鍵でサーバー側の暗号化を有効にすることができます。

お客様が管理する鍵を使用するために、Azure Key Vault、ディスク暗号化セット、および暗号化キーが必要です。ディスク暗号化セットは、Cloud Credential Operator (CCO) がアクセス許可を付与したリソースグループに存在する必要があります。これがない場合は、ディスク暗号化セットで追加のリーダーロールを指定する必要があります。

前提条件

手順

マシンセット YAML ファイルの providerSpec フィールドでディスクの暗号化キーを設定します。以下に例を示します。

providerSpec:
  value:
    osDisk:
      diskSizeGB: 128
      managedDisk:
        diskEncryptionSet:
          id: /subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Compute/diskEncryptionSets/<disk_encryption_set_name>
        storageAccountType: Premium_LRS

関連情報

カスタマーマネージドキーに関する Azure ドキュメント

2.3.9. Microsoft Azure 仮想マシンのネットワークアクセラレート

アクセラレートネットワークは、Single Root I/O Virtualization (SR-IOV) を使用して、スイッチへのより直接的なパスを持つ Microsoft Azure 仮想マシンを提供します。これにより、ネットワークパフォーマンスが向上します。この機能は、インストール時またはインストール後に有効にできます。

2.3.9.1. 制限事項

Accelerated Networking を使用するかどうかを決定する際には、以下の制限を考慮してください。

ネットワークのアクセラレートは、マシン API が機能しているクラスターでのみサポートされます。
Azure ワーカーノードの最小要件は 2 つの vCPU ですが、Accelerated Networking には 4 つ以上の vCPU を含む Azure 仮想マシンのサイズが必要です。この要件を満たすには、マシンセットの vmSize の値を変更します。Azure VM サイズの詳細は、Microsoft Azure のドキュメントを参照してください。

この機能が既存の Azure クラスターで有効にされている場合、新たにプロビジョニングされたノードのみが影響を受けます。現在実行中のノードは調整されていません。全ノードで機能を有効にするには、それぞれの既存マシンを置き換える必要があります。これは、各マシンに対して個別に行うか、レプリカをゼロにスケールダウンしてから、必要なレプリカ数にスケールアップして実行できます。

2.3.10. 既存の OpenShift Container Platform クラスターへの GPU ノードの追加

デフォルトのコンピュートマシンセット設定をコピーおよび変更して、Azure クラウドプロバイダー用の GPU 対応マシンセットとマシンを作成できます。

次の表は、検証済みのインスタンスタイプを示しています。

vmSize	NVIDIA GPU アクセラレーター	GPU の最大数	アーキテクチャー
`Standard_NC24s_v3`	V100	4	x86
`Standard_NC4as_T4_v3`	T4	1	x86
`ND A100 v4`	A100	8	x86

注記

デフォルトでは、Azure サブスクリプションには、GPU を使用する Azure インスタンスタイプのクォータがありません。お客様は、上記の Azure インスタンスファミリーのクォータの引き上げを要求する必要があります。

手順

以下のコマンドを実行して、openshift-machine-api 名前空間に存在するマシンおよびマシンセットを表示します。各コンピュートマシンセットは、Azure リージョン内の異なるアベイラビリティーゾーンに関連付けられています。インストーラーは、アベイラビリティゾーン全体でコンピュートマシンの負荷を自動的に分散します。
```
$ oc get machineset -n openshift-machine-api
```
出力例
```
NAME                              DESIRED   CURRENT   READY   AVAILABLE   AGE
myclustername-worker-centralus1   1         1         1       1           6h9m
myclustername-worker-centralus2   1         1         1       1           6h9m
myclustername-worker-centralus3   1         1         1       1           6h9m
```
次のコマンドを実行して、既存のコンピュート MachineSet 定義のいずれかのコピーを作成し、結果を YAML ファイルに出力します。これは、GPU 対応のコンピュートマシンセット定義の基礎となります。
```
$ oc get machineset -n openshift-machine-api myclustername-worker-centralus1 -o yaml > machineset-azure.yaml
```

マシンセットの内容を表示します。

$ cat machineset-azure.yaml

machineset-azure.yaml ファイルの例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  annotations:
    machine.openshift.io/GPU: "0"
    machine.openshift.io/memoryMb: "16384"
    machine.openshift.io/vCPU: "4"
  creationTimestamp: "2023-02-06T14:08:19Z"
  generation: 1
  labels:
    machine.openshift.io/cluster-api-cluster: myclustername
    machine.openshift.io/cluster-api-machine-role: worker
    machine.openshift.io/cluster-api-machine-type: worker
  name: myclustername-worker-centralus1
  namespace: openshift-machine-api
  resourceVersion: "23601"
  uid: acd56e0c-7612-473a-ae37-8704f34b80de
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: myclustername
      machine.openshift.io/cluster-api-machineset: myclustername-worker-centralus1
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: myclustername
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: myclustername-worker-centralus1
    spec:
      lifecycleHooks: {}
      metadata: {}
      providerSpec:
        value:
          acceleratedNetworking: true
          apiVersion: machine.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          diagnostics: {}
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/myclustername-rg/providers/Microsoft.Compute/galleries/gallery_myclustername_n6n4r/images/myclustername-gen2/versions/latest
            sku: ""
            version: ""
          kind: AzureMachineProviderSpec
          location: centralus
          managedIdentity: myclustername-identity
          metadata:
            creationTimestamp: null
          networkResourceGroup: myclustername-rg
          osDisk:
            diskSettings: {}
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: myclustername
          resourceGroup: myclustername-rg
          spotVMOptions: {}
          subnet: myclustername-worker-subnet
          userDataSecret:
            name: worker-user-data
          vmSize: Standard_D4s_v3
          vnet: myclustername-vnet
          zone: "1"
status:
  availableReplicas: 1
  fullyLabeledReplicas: 1
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1

次のコマンドを実行して、machineset-azure.yaml ファイルのコピーを作成します。
```
$ cp machineset-azure.yaml machineset-azure-gpu.yaml
```

machineset-azure-gpu.yaml の次のフィールドを更新します。

.metadata.name を gpu を含む名前に変更します。
.spec.selector.matchLabels["machine.openshift.io/cluster-api-machineset"] を変更して新しい .metadata.name に一致させます。
.spec.template.metadata.labels["machine.openshift.io/cluster-api-machineset"] を変更して新しい .metadata.name に一致させます。

.spec.template.spec.providerSpec.value.vmSize を Standard_NC4as_T4_v3 に変更します。

machineset-azure-gpu.yaml ファイルの例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  annotations:
    machine.openshift.io/GPU: "1"
    machine.openshift.io/memoryMb: "28672"
    machine.openshift.io/vCPU: "4"
  creationTimestamp: "2023-02-06T20:27:12Z"
  generation: 1
  labels:
    machine.openshift.io/cluster-api-cluster: myclustername
    machine.openshift.io/cluster-api-machine-role: worker
    machine.openshift.io/cluster-api-machine-type: worker
  name: myclustername-nc4ast4-gpu-worker-centralus1
  namespace: openshift-machine-api
  resourceVersion: "166285"
  uid: 4eedce7f-6a57-4abe-b529-031140f02ffa
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: myclustername
      machine.openshift.io/cluster-api-machineset: myclustername-nc4ast4-gpu-worker-centralus1
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: myclustername
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: myclustername-nc4ast4-gpu-worker-centralus1
    spec:
      lifecycleHooks: {}
      metadata: {}
      providerSpec:
        value:
          acceleratedNetworking: true
          apiVersion: machine.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          diagnostics: {}
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/myclustername-rg/providers/Microsoft.Compute/galleries/gallery_myclustername_n6n4r/images/myclustername-gen2/versions/latest
            sku: ""
            version: ""
          kind: AzureMachineProviderSpec
          location: centralus
          managedIdentity: myclustername-identity
          metadata:
            creationTimestamp: null
          networkResourceGroup: myclustername-rg
          osDisk:
            diskSettings: {}
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: myclustername
          resourceGroup: myclustername-rg
          spotVMOptions: {}
          subnet: myclustername-worker-subnet
          userDataSecret:
            name: worker-user-data
          vmSize: Standard_NC4as_T4_v3
          vnet: myclustername-vnet
          zone: "1"
status:
  availableReplicas: 1
  fullyLabeledReplicas: 1
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1

変更を確認するには、次のコマンドを実行して、元のコンピュート定義と新しい GPU 対応ノード定義の diff を実行します。

$ diff machineset-azure.yaml machineset-azure-gpu.yaml

出力例

14c14
<   name: myclustername-worker-centralus1
---
>   name: myclustername-nc4ast4-gpu-worker-centralus1
23c23
<       machine.openshift.io/cluster-api-machineset: myclustername-worker-centralus1
---
>       machine.openshift.io/cluster-api-machineset: myclustername-nc4ast4-gpu-worker-centralus1
30c30
<         machine.openshift.io/cluster-api-machineset: myclustername-worker-centralus1
---
>         machine.openshift.io/cluster-api-machineset: myclustername-nc4ast4-gpu-worker-centralus1
67c67
<           vmSize: Standard_D4s_v3
---
>           vmSize: Standard_NC4as_T4_v3

次のコマンドを実行して、定義ファイルから GPU 対応のコンピュートマシンセットを作成します。
```
$ oc create -f machineset-azure-gpu.yaml
```
出力例
```
machineset.machine.openshift.io/myclustername-nc4ast4-gpu-worker-centralus1 created
```

以下のコマンドを実行して、openshift-machine-api 名前空間に存在するマシンおよびマシンセットを表示します。各コンピュートマシンセットは、Azure リージョン内の異なるアベイラビリティーゾーンに関連付けられています。インストーラーは、アベイラビリティゾーン全体でコンピュートマシンの負荷を自動的に分散します。

$ oc get machineset -n openshift-machine-api

出力例

NAME                                               DESIRED   CURRENT   READY   AVAILABLE   AGE
clustername-n6n4r-nc4ast4-gpu-worker-centralus1    1         1         1       1           122m
clustername-n6n4r-worker-centralus1                1         1         1       1           8h
clustername-n6n4r-worker-centralus2                1         1         1       1           8h
clustername-n6n4r-worker-centralus3                1         1         1       1           8h

以下のコマンドを実行して、openshift-machine-api 名前空間に存在するマシンを表示します。セットごとに設定できるコンピュートマシンは 1 つだけですが、コンピュートマシンセットをスケーリングして、特定のリージョンとゾーンにノードを追加することはできます。

$ oc get machines -n openshift-machine-api

出力例

NAME                                                PHASE     TYPE                   REGION      ZONE   AGE
myclustername-master-0                              Running   Standard_D8s_v3        centralus   2      6h40m
myclustername-master-1                              Running   Standard_D8s_v3        centralus   1      6h40m
myclustername-master-2                              Running   Standard_D8s_v3        centralus   3      6h40m
myclustername-nc4ast4-gpu-worker-centralus1-w9bqn   Running      centralus   1      21m
myclustername-worker-centralus1-rbh6b               Running   Standard_D4s_v3        centralus   1      6h38m
myclustername-worker-centralus2-dbz7w               Running   Standard_D4s_v3        centralus   2      6h38m
myclustername-worker-centralus3-p9b8c               Running   Standard_D4s_v3        centralus   3      6h38m

次のコマンドを実行して、既存のノード、マシン、およびマシンセットを表示します。各ノードは、特定の Azure リージョンと OpenShift Container Platform ロールを持つマシン定義のインスタンスであることに注意してください。

$ oc get nodes

出力例

NAME                                                STATUS   ROLES                  AGE     VERSION
myclustername-master-0                              Ready    control-plane,master   6h39m   v1.25.4+a34b9e9
myclustername-master-1                              Ready    control-plane,master   6h41m   v1.25.4+a34b9e9
myclustername-master-2                              Ready    control-plane,master   6h39m   v1.25.4+a34b9e9
myclustername-nc4ast4-gpu-worker-centralus1-w9bqn   Ready    worker                 14m     v1.25.4+a34b9e9
myclustername-worker-centralus1-rbh6b               Ready    worker                 6h29m   v1.25.4+a34b9e9
myclustername-worker-centralus2-dbz7w               Ready    worker                 6h29m   v1.25.4+a34b9e9
myclustername-worker-centralus3-p9b8c               Ready    worker                 6h31m   v1.25.4+a34b9e9

コンピュートマシンセットのリストを表示します。

$ oc get machineset -n openshift-machine-api

出力例

NAME                                   DESIRED   CURRENT   READY   AVAILABLE   AGE
myclustername-worker-centralus1        1         1         1       1           8h
myclustername-worker-centralus2        1         1         1       1           8h
myclustername-worker-centralus3        1         1         1       1           8h

次のコマンドを実行して、定義ファイルから GPU 対応のコンピュートマシンセットを作成します。
```
$ oc create -f machineset-azure-gpu.yaml
```

コンピュートマシンセットのリストを表示します。

oc get machineset -n openshift-machine-api

出力例

NAME                                          DESIRED   CURRENT   READY   AVAILABLE   AGE
myclustername-nc4ast4-gpu-worker-centralus1   1         1         1       1           121m
myclustername-worker-centralus1               1         1         1       1           8h
myclustername-worker-centralus2               1         1         1       1           8h
myclustername-worker-centralus3               1         1         1       1           8h

検証

次のコマンドを実行して、作成したマシンセットを表示します。
```
$ oc get machineset -n openshift-machine-api | grep gpu
```
MachineSet レプリカ数は 1 に設定されているため、新しい Machine オブジェクトが自動的に作成されます。
出力例
```
myclustername-nc4ast4-gpu-worker-centralus1   1         1         1       1           121m
```

次のコマンドを実行して、マシンセットが作成した Machine オブジェクトを表示します。

$ oc -n openshift-machine-api get machines | grep gpu

出力例

myclustername-nc4ast4-gpu-worker-centralus1-w9bqn   Running   Standard_NC4as_T4_v3   centralus   1      21m

注記

ノードの namespace を指定する必要はありません。ノード定義はクラスタースコープ指定されています。

2.3.11. Node Feature Discovery Operator のデプロイ

手順

OpenShift Container Platform コンソールの OperatorHub から Node Feature Discovery Operator をインストールします。
NFD Operator を OperatorHub にインストールした後、インストールされた Operator リストから Node Feature Discovery を選択し、Create instance を選択します。これにより、nfd-master Pod および nfd-worker Pod (コンピュートノードごとに 1 つの nfd-worker Pod) が openshift-nfd 名前空間にインストールされます。

次のコマンドを実行して、Operator がインストールされ、実行されていることを確認します。

$ oc get pods -n openshift-nfd

出力例

NAME                                       READY    STATUS     RESTARTS   AGE

nfd-controller-manager-8646fcbb65-x5qgk    2/2      Running 7  (8h ago)   1d

コンソールでインストール済みの Operator へ移動し、Create Node Feature Discovery を選択します。
Create を選択して、NFD カスタムリソースをビルドします。これにより、openshift-nfd 名前空間に NFD Pod が作成され、ハードウェアリソース用に OpenShift Container Platform ノードをポーリングし、それらをカタログ化します。

検証

ビルドが成功したら、次のコマンドを実行して、各ノードで NFD Pod が実行されていることを確認します。

$ oc get pods -n openshift-nfd

出力例

NAME                                       READY   STATUS      RESTARTS        AGE
nfd-controller-manager-8646fcbb65-x5qgk    2/2     Running     7 (8h ago)      12d
nfd-master-769656c4cb-w9vrv                1/1     Running     0               12d
nfd-worker-qjxb2                           1/1     Running     3 (3d14h ago)   12d
nfd-worker-xtz9b                           1/1     Running     5 (3d14h ago)   12d

NFD Operator は、ベンダー PCI ID を使用してノード内のハードウェアを識別します。NVIDIA は PCI ID 10de を使用します。

次のコマンドを実行して、NFD Operator によって検出された NVIDIA GPU を表示します。
```
$ oc describe node ip-10-0-132-138.us-east-2.compute.internal | egrep 'Roles|pci'
```
出力例
```
Roles: worker

feature.node.kubernetes.io/pci-1013.present=true

feature.node.kubernetes.io/pci-10de.present=true

feature.node.kubernetes.io/pci-1d0f.present=true
```
GPU 対応ノードのノード機能リストに 10de が表示されます。これは、NFD Operator が GPU 対応の MachineSet からノードを正しく識別したことを意味します。

関連情報

インストール中の高速ネットワークの有効化

2.3.11.1. 既存の Microsoft Azure クラスターでの Accelerated Networking の有効化

Azure で Accelerated Networking を有効にするには、Networking を マシンセットの YAML ファイルに追加します。

前提条件

マシン API が機能している既存の Microsoft Azure クラスターがあること。

手順

以下を providerSpec フィールドに追加します。
```
providerSpec:
  value:
    acceleratedNetworking: true 1
    vmSize: <azure-vm-size> 2
```
1
この行は Accelerated Networking を有効にします。
2
4 つ以上の vCPU を含む Azure 仮想マシンのサイズを指定します。仮想マシンのサイズに関する情報は、Microsoft Azure のドキュメントを参照してください。

次のステップ

現在実行中のノードで機能を有効にするには、それぞれの既存マシンを置き換える必要があります。これは、各マシンに対して個別に行うか、レプリカをゼロにスケールダウンしてから、必要なレプリカ数にスケールアップして実行できます。

検証

Microsoft Azure ポータルで、マシンセットによってプロビジョニングされるマシンの Networking 設定ページを確認し、Accelerated networking フィールドが Enabled に設定されていることを確認します。

関連情報

コンピュートマシンセットの手動スケーリング

2.4. Azure Stack Hub でコンピュートマシンセットを作成

Microsoft Azure Stack Hub 上の OpenShift Container Platform クラスターで特定の目的を果たすように異なるコンピュートマシンセットを作成することができます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role>-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <role> 8
        machine.openshift.io/cluster-api-machine-type: <role> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/<role>: "" 11
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          availabilitySet: <availability_set> 12
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> 13
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> 14
          managedIdentity: <infrastructure_id>-identity 15
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg 16
          sshPrivateKey: ""
          sshPublicKey: ""
          subnet: <infrastructure_id>-<role>-subnet 17 18
          userDataSecret:
            name: worker-user-data 19
          vmSize: Standard_DS4_v2
          vnet: <infrastructure_id>-vnet 20
          zone: "1" 21

1 5 7 13 15 16 17 20

$ 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 3 8 9 11 18 19

追加するノードラベルを指定します。

4 6 10

インフラストラクチャー ID、ノードラベル、およびリージョンを指定します。

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

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

クラスターの可用性セットを指定します。

2.4.2. コンピュートマシンセットの作成

前提条件

OpenShift Container Platform クラスターをデプロイすること。
OpenShift CLI (oc) がインストールされている。
cluster-admin パーミッションを持つユーザーとして、oc にログインする。
Azure Stack Hub コンピュートマシンをデプロイする可用性セットを作成します。

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<availability Set>、<cluster ID>、および <role> パラメーター値を必ず設定してください。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.4.3. Azure ブート診断の有効化

マシンセットが作成する Azure マシンで起動診断を有効にできます。

前提条件

既存の Microsoft Azure Stack Hub クラスターがある。

手順

ストレージタイプに適用可能な diagnostics 設定を、マシンセット YAML ファイルの providerSpec フィールドに追加します。
- Azure Managed ストレージアカウントの場合:
```
providerSpec:
  diagnostics:
    boot:
      storageAccountType: AzureManaged 1
```
  1
  Azure Managed ストレージアカウントを指定します。
- Azure Unmanaged ストレージアカウントの場合:
```
providerSpec:
  diagnostics:
    boot:
      storageAccountType: CustomerManaged 1
      customerManaged:
        storageAccountURI: https://<storage-account>.blob.core.windows.net 2
```
  1
  Azure Unmanaged ストレージアカウントを指定します。
  2
  <storage-account> をストレージアカウントの名前に置き換えます。
  注記
  Azure Blob Storage データサービスのみサポートされています。

検証

Microsoft Azure ポータルで、マシンセットによってデプロイされたマシンの 起動診断 ページを確認し、マシンのシリアルログが表示されることを確認します。

2.4.4. マシンセットの顧客管理の暗号鍵の有効化

前提条件

手順

マシンセット YAML ファイルの providerSpec フィールドでディスクの暗号化キーを設定します。以下に例を示します。

providerSpec:
  value:
    osDisk:
      diskSizeGB: 128
      managedDisk:
        diskEncryptionSet:
          id: /subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Compute/diskEncryptionSets/<disk_encryption_set_name>
        storageAccountType: Premium_LRS

関連情報

カスタマーマネージドキーに関する Azure ドキュメント

2.5. GCP でコンピュートマシンセットを作成する

異なるコンピュートマシンセットを作成して、Google Cloud Platform (GCP) 上の OpenShift Container Platform クラスターで特定の目的で使用できます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  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: <role> 2
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: ""
      providerSpec:
        value:
          apiVersion: gcpprovider.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <path_to_image> 3
            labels: null
            sizeGb: 128
            type: pd-ssd
          gcpMetadata: 4
          - 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> 5
          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

1

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

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

2

<node> には、追加するノードラベルを指定します。

現在のコンピュートマシンセットで使用されるイメージへのパスを指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してイメージへのパスを取得できます。

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

GCP Marketplace イメージを使用するには、使用するオファーを指定します。

OpenShift Container Platform: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145
OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145
OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145

オプション: key:value のペアの形式でカスタムメタデータを指定します。ユースケースの例については、カスタムメタデータの設定について GCP のドキュメントを参照してください。

<project_name> には、クラスターに使用する GCP プロジェクトの名前を指定します。

2.5.2. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.5.3. コンピュートマシンセットを使用した永続ディスクタイプの設定

コンピュートマシンセットの YAML ファイルを編集することで、コンピュートマシンセットがマシンをデプロイする永続ディスクのタイプを設定できます。

永続ディスクの種類、互換性、地域の可用性、制限の詳細については、永続ディスクに関する GCPComputeEngine のドキュメントを参照してください。

手順

テキストエディターで、既存のコンピュートマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。
providerSpec フィールドの下で以下の行を編集します。
```
providerSpec:
  value:
    disks:
      type: <pd-disk-type> 1
```
1
ディスク永続タイプを指定します。有効な値は、pd-ssd、pd-standard、および pd-balanced です。デフォルト値は pd-standard です。

検証

Google Cloud コンソールで、コンピュートマシンセットによってデプロイされたマシンの詳細を確認し、Type フィールドが設定済みのディスクタイプと一致することを確認します。

2.5.4. マシンをプリエンプション可能な仮想マシンインスタンスとしてデプロイするマシンセット

マシンを保証されていないプリエンプション可能な仮想マシンインスタンスとしてデプロイする GCP で実行されるコンピュートマシンセットを作成して、コストを節約できます。プリエンプション可能な仮想マシンインスタンスは、追加の Compute Engine 容量を使用し、通常のインスタンスよりもコストが低くなります。プリエンプション可能な仮想マシンインスタンスは、バッチやステートレス、水平的に拡張可能なワークロードなどの割り込みを許容できるワークロードに使用することができます。

GCP Compute Engine は、プリエンプション可能な仮想マシンインスタンスをいつでも終了することができます。Compute Engine は、中断が 30 秒後に発生することを示すプリエンプションの通知をユーザーに送信します。OpenShift Container Platform は、Compute Engine がプリエンプションについての通知を発行する際に影響を受けるインスタンスからワークロードを削除し始めます。インスタンスが停止していない場合は、ACPI G3 Mechanical Off シグナルが 30 秒後にオペレーティングシステムに送信されます。プリエンプション可能な仮想マシンインスタンスは、Compute Engine によって TERMINATED 状態に移行されます。

以下の理由により、プリエンプション可能な仮想マシンインスタンスを使用すると中断が生じる可能性があります。

システムまたはメンテナンスイベントがある
プリエンプション可能な仮想マシンインスタンスの供給が減少する
インスタンスは、プリエンプション可能な仮想マシンインスタンスについて割り当てられている 24 時間後に終了します。

GCP がインスタンスを終了すると、プリエンプション可能な仮想マシンインスタンスで実行される終了ハンドラーによりマシンリソースが削除されます。コンピュートマシンセットの レプリカ 数を満たすために、ココンピュートマシンセットは、プリエンプティブル VM インスタンスを要求するマシンを作成します。

2.5.4.1. コンピュートマシンセットの使用によるプリエンプション可能な仮想マシンインスタンスの作成

preemptible をコンピュートマシンセットの YAML ファイルに追加し、GCP でプリエンプション可能な仮想マシンインスタンスを起動できます。

手順

providerSpec フィールドの下に以下の行を追加します。
```
providerSpec:
  value:
    preemptible: true
```
preemptible が true に設定される場合、インスタンスの起動後に、マシンに interruptable-instance というラベルが付けられます。

2.5.5. コンピュートマシンセットの顧客管理の暗号鍵の有効化

Google Cloud Platform (GCP) Compute Engine を使用すると、ユーザーは暗号鍵を指定してディスク上の停止状態のデータを暗号化することができます。この鍵は、顧客のデータの暗号化に使用されず、データ暗号化キーの暗号化に使用されます。デフォルトでは、Compute Engine は Compute Engine キーを使用してこのデータを暗号化します。

マシン API を使用して、顧客管理の鍵で暗号化を有効にすることができます。まず KMS キーを作成し、適切なパーミッションをサービスアカウントに割り当てる必要があります。サービスアカウントが鍵を使用できるようにするには、KMS キー名、キーリング名、および場所が必要です。

注記

KMS の暗号化に専用のサービスアカウントを使用しない場合は、代わりに Compute Engine のデフォルトのサービスアカウントが使用されます。専用のサービスアカウントを使用しない場合、デフォルトのサービスアカウントに、キーにアクセスするためのパーミッションを付与する必要があります。Compute Engine のデフォルトのサービスアカウント名は、service-<project_number>@compute-system.iam.gserviceaccount.com パターンをベースにしています。

手順

KMS キー名、キーリング名、および場所を指定して以下のコマンドを実行し、特定のサービスアカウントが KMS キーを使用し、サービスアカウントに正しい IAM ロールを付与できるようにします。

gcloud kms keys add-iam-policy-binding <key_name> \
  --keyring <key_ring_name> \
  --location <key_ring_location> \
  --member "serviceAccount:service-<project_number>@compute-system.iam.gserviceaccount.com” \
  --role roles/cloudkms.cryptoKeyEncrypterDecrypter

コンピュートマシンセット YAML ファイルの providerSpec フィールドで暗号化キーを設定します。以下に例を示します。
```
providerSpec:
  value:
    # ...
    disks:
    - type:
      # ...
      encryptionKey:
        kmsKey:
          name: machine-encryption-key 1
          keyRing: openshift-encrpytion-ring 2
          location: global 3
          projectID: openshift-gcp-project 4
        kmsKeyServiceAccount: openshift-service-account@openshift-gcp-project.iam.gserviceaccount.com 5
```
1
ディスク暗号化に使用される顧客管理の暗号鍵の名前。
2
KMS キーが属する KMS キーリングの名前。
3
KMS キーリングが存在する GCP の場所。
4
オプション: KMS キーリングが存在するプロジェクトの ID。プロジェクト ID が設定されていない場合は、計算マシンセットが作成された計算マシンセット projectID が使用されます。
5
オプション: 指定の KMS キーの暗号化要求に使用されるサービスアカウント。サービスアカウントが設定されていない場合、Compute Engine のデフォルトのサービスアカウントが使用されます。
更新された providerSpec オブジェクト設定を使用して新規マシンが作成された後に、ディスクの暗号化キーは KMS キーを使用して暗号化されます。

2.5.6. コンピュートマシンセットの GPU サポートの有効化

Google Cloud Platform (GCP) Compute Engine を使用すると、ユーザーは仮想マシンインスタンスに GPU を追加できます。GPU リソースにアクセスできるワークロードは、この機能を有効にしてコンピュートマシンでより優れたパフォーマンスが得られます。GCP 上の Open Shift Container Platform は、A2 および N1 マシンシリーズの NVIDIAGPU モデルをサポートします。

表2.1 サポートされている GPU 設定

モデル名	GPU タイプ	マシンタイプ ^[1]
NVIDIA A100	`nvidia-tesla-a100`	`a2-highgpu-1g` `a2-highgpu-2g` `a2-highgpu-4g` `a2-highgpu-8g` `a2-megagpu-16g`
NVIDIA K80	`nvidia-tesla-k80`	`n1-standard-1` `n1-standard-2` `n1-standard-4` `n1-standard-8` `n1-standard-16` `n1-standard-32` `n1-standard-64` `n1-standard-96` `n1-highmem-2` `n1-highmem-4` `n1-highmem-8` `n1-highmem-16` `n1-highmem-32` `n1-highmem-64` `n1-highmem-96` `n1-highcpu-2` `n1-highcpu-4` `n1-highcpu-8` `n1-highcpu-16` `n1-highcpu-32` `n1-highcpu-64` `n1-highcpu-96`
NVIDIA P100	`nvidia-tesla-p100`
NVIDIA P4	`nvidia-tesla-p4`
NVIDIA T4	`nvidia-tesla-t4`
NVIDIA V100	`nvidia-tesla-v100`

仕様、互換性、地域の可用性、制限など、マシンタイプの詳細については、 N1 マシンシリーズ、A2 マシンシリーズ、GPU リージョンとゾーンの可用性に関する GCP Compute Engine のドキュメントをご覧ください。

Machine API を使用して、インスタンスに使用するサポートされている GPU を定義できます。

N1 マシンシリーズのマシンを、サポートされている GPU タイプの 1 つでデプロイするように設定できます。A2 マシンシリーズのマシンには GPU が関連付けられており、ゲストアクセラレータを使用することはできません。

注記

グラフィックワークロード用の GPU はサポートされていません。

手順

テキストエディターで、既存のコンピュートマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。
コンピュートマシンセットの YAML ファイルの provider Spec フィールドで GPU 設定を指定します。有効な設定の次の例を参照してください。
A2 マシンシリーズの設定例:
```
  providerSpec:
    value:
      machineType: a2-highgpu-1g 1
      onHostMaintenance: Terminate 2
      restartPolicy: Always 3
```
1
マシンタイプを指定します。マシンタイプが A2 マシンシリーズに含まれていることを確認してください。
2
GPU サポートを使用する場合は、onHostMaintenance を Terminate に設定する必要があります。
3
コンピュートマシンセットによってデプロイされたマシンの再起動ポリシーを指定します。許可される値は、Always または Never です。
N1 マシンシリーズの設定例:
```
providerSpec:
  value:
    gpus:
    - count: 1 1
      type: nvidia-tesla-p100 2
    machineType: n1-standard-1 3
    onHostMaintenance: Terminate 4
    restartPolicy: Always 5
```
1
マシンに接続する GPU の数を指定します。
2
マシンに接続する GPU のタイプを指定します。マシンタイプと GPU タイプに互換性があることを確認してください。
3
マシンタイプを指定します。マシンタイプと GPU タイプに互換性があることを確認してください。
4
GPU サポートを使用する場合は、onHostMaintenance を Terminate に設定する必要があります。
5
コンピュートマシンセットによってデプロイされたマシンの再起動ポリシーを指定します。許可される値は、Always または Never です。

2.5.7. 既存の OpenShift Container Platform クラスターへの GPU ノードの追加

デフォルトのコンピュートマシンセット設定をコピーおよび変更して、GCP クラウドプロバイダー用の GPU 対応マシンセットとマシンを作成できます。

次の表は、検証済みのインスタンスタイプを示しています。

インスタンスタイプ	NVIDIA GPU アクセラレーター	GPU の最大数	アーキテクチャー
`a2-highgpu-1g`	A100	1	x86
`n1-standard-4`	T4	1	x86

手順

既存の MachineSet のコピーを作成します。
新しいコピーで、metadata.name と machine.openshift.io/cluster-api-machineset の両方のインスタンスで、マシンセットの name を変更します。

インスタンスタイプを変更して、新しくコピーした MachineSet に次の 2 行を追加します。

machineType: a2-highgpu-1g
onHostMaintenance: Terminate

a2-highgpu-1g.json ファイルの例

{
    "apiVersion": "machine.openshift.io/v1beta1",
    "kind": "MachineSet",
    "metadata": {
        "annotations": {
            "machine.openshift.io/GPU": "0",
            "machine.openshift.io/memoryMb": "16384",
            "machine.openshift.io/vCPU": "4"
        },
        "creationTimestamp": "2023-01-13T17:11:02Z",
        "generation": 1,
        "labels": {
            "machine.openshift.io/cluster-api-cluster": "myclustername-2pt9p"
        },
        "name": "myclustername-2pt9p-worker-gpu-a",
        "namespace": "openshift-machine-api",
        "resourceVersion": "20185",
        "uid": "2daf4712-733e-4399-b4b4-d43cb1ed32bd"
    },
    "spec": {
        "replicas": 1,
        "selector": {
            "matchLabels": {
                "machine.openshift.io/cluster-api-cluster": "myclustername-2pt9p",
                "machine.openshift.io/cluster-api-machineset": "myclustername-2pt9p-worker-gpu-a"
            }
        },
        "template": {
            "metadata": {
                "labels": {
                    "machine.openshift.io/cluster-api-cluster": "myclustername-2pt9p",
                    "machine.openshift.io/cluster-api-machine-role": "worker",
                    "machine.openshift.io/cluster-api-machine-type": "worker",
                    "machine.openshift.io/cluster-api-machineset": "myclustername-2pt9p-worker-gpu-a"
                }
            },
            "spec": {
                "lifecycleHooks": {},
                "metadata": {},
                "providerSpec": {
                    "value": {
                        "apiVersion": "machine.openshift.io/v1beta1",
                        "canIPForward": false,
                        "credentialsSecret": {
                            "name": "gcp-cloud-credentials"
                        },
                        "deletionProtection": false,
                        "disks": [
                            {
                                "autoDelete": true,
                                "boot": true,
                                "image": "projects/rhcos-cloud/global/images/rhcos-412-86-202212081411-0-gcp-x86-64",
                                "labels": null,
                                "sizeGb": 128,
                                "type": "pd-ssd"
                            }
                        ],
                        "kind": "GCPMachineProviderSpec",
                        "machineType": "a2-highgpu-1g",
                        "onHostMaintenance": "Terminate",
                        "metadata": {
                            "creationTimestamp": null
                        },
                        "networkInterfaces": [
                            {
                                "network": "myclustername-2pt9p-network",
                                "subnetwork": "myclustername-2pt9p-worker-subnet"
                            }
                        ],
                        "preemptible": true,
                        "projectID": "myteam",
                        "region": "us-central1",
                        "serviceAccounts": [
                            {
                                "email": "myclustername-2pt9p-w@myteam.iam.gserviceaccount.com",
                                "scopes": [
                                    "https://www.googleapis.com/auth/cloud-platform"
                                ]
                            }
                        ],
                        "tags": [
                            "myclustername-2pt9p-worker"
                        ],
                        "userDataSecret": {
                            "name": "worker-user-data"
                        },
                        "zone": "us-central1-a"
                    }
                }
            }
        }
    },
    "status": {
        "availableReplicas": 1,
        "fullyLabeledReplicas": 1,
        "observedGeneration": 1,
        "readyReplicas": 1,
        "replicas": 1
    }
}

次のコマンドを実行して、既存のノード、マシン、およびマシンセットを表示します。各ノードは、特定の GCP リージョンと OpenShift Container Platform ロールを持つマシン定義のインスタンスであることに注意してください。

$ oc get nodes

出力例

NAME                                                             STATUS     ROLES                  AGE     VERSION
myclustername-2pt9p-master-0.c.openshift-qe.internal             Ready      control-plane,master   8h      v1.25.4+77bec7a
myclustername-2pt9p-master-1.c.openshift-qe.internal             Ready      control-plane,master   8h      v1.25.4+77bec7a
myclustername-2pt9p-master-2.c.openshift-qe.internal             Ready      control-plane,master   8h      v1.25.4+77bec7a
myclustername-2pt9p-worker-a-mxtnz.c.openshift-qe.internal       Ready      worker                 8h      v1.25.4+77bec7a
myclustername-2pt9p-worker-b-9pzzn.c.openshift-qe.internal       Ready      worker                 8h      v1.25.4+77bec7a
myclustername-2pt9p-worker-c-6pbg6.c.openshift-qe.internal       Ready      worker                 8h      v1.25.4+77bec7a
myclustername-2pt9p-worker-gpu-a-wxcr6.c.openshift-qe.internal   Ready      worker                 4h35m   v1.25.4+77bec7a

以下のコマンドを実行して、openshift-machine-api 名前空間に存在するマシンおよびマシンセットを表示します。各コンピュートマシンセットは、GCP リージョン内の異なるアベイラビリティーゾーンに関連付けられています。インストーラーは、アベイラビリティゾーン全体でコンピュートマシンの負荷を自動的に分散します。
```
$ oc get machinesets -n openshift-machine-api
```
出力例
```
NAME                               DESIRED   CURRENT   READY   AVAILABLE   AGE
myclustername-2pt9p-worker-a       1         1         1       1           8h
myclustername-2pt9p-worker-b       1         1         1       1           8h
myclustername-2pt9p-worker-c       1         1                             8h
myclustername-2pt9p-worker-f       0         0                             8h
```
以下のコマンドを実行して、openshift-machine-api 名前空間に存在するマシンを表示します。セットごとに設定できるコンピュートマシンは 1 つだけですが、コンピュートマシンセットをスケーリングして、特定のリージョンとゾーンにノードを追加することはできます。
```
$ oc get machines -n openshift-machine-api | grep worker
```
出力例
```
myclustername-2pt9p-worker-a-mxtnz       Running   n2-standard-4   us-central1   us-central1-a   8h
myclustername-2pt9p-worker-b-9pzzn       Running   n2-standard-4   us-central1   us-central1-b   8h
myclustername-2pt9p-worker-c-6pbg6       Running   n2-standard-4   us-central1   us-central1-c   8h
```
次のコマンドを実行して、既存のコンピュート MachineSet 定義のいずれかのコピーを作成し、結果を JSON ファイルに出力します。これは、GPU 対応のコンピュートマシンセット定義の基礎となります。
```
$ oc get machineset myclustername-2pt9p-worker-a -n openshift-machine-api -o json  > <output_file.json>
```
JSON ファイルを編集し、新しい MachineSet 定義に次の変更を加えます。
- サブストリング gpu を metadata.name と machine.openshift.io/cluster-api-machineset の両方のインスタンスに挿入し、マシンセット name を変更します。
- 新しい MachineSet 定義の machineType を、NVIDIA A100 GPU を含む a2-highgpu-1g に変更します。
```
jq .spec.template.spec.providerSpec.value.machineType ocp_4.12_machineset-a2-highgpu-1g.json

"a2-highgpu-1g"
```
  <output_file.json> ファイルは ocp_4.12_machineset-a2-highgpu-1g.json として保存されます。
ocp_4.12_machineset-a2-highgpu-1g.json の次のフィールドを更新します。
- .metadata.name を gpu を含む名前に変更します。
- .spec.selector.matchLabels["machine.openshift.io/cluster-api-machineset"] を変更して新しい .metadata.name に一致させます。
- .spec.template.metadata.labels["machine.openshift.io/cluster-api-machineset"] を変更して新しい .metadata.name に一致させます。
- .spec.template.spec.providerSpec.value.MachineType を a2-highgpu-1g に変更します。
- machineType の下に次の行を追加します: `"onHostMaintenance": "Terminate"。以下に例を示します。
```
"machineType": "a2-highgpu-1g",
"onHostMaintenance": "Terminate",
```

変更を確認するには、次のコマンドを実行して、元のコンピュート定義と新しい GPU 対応ノード定義の diff を実行します。

$ oc get machineset/myclustername-2pt9p-worker-a -n openshift-machine-api -o json | diff ocp_4.12_machineset-a2-highgpu-1g.json -

出力例

15c15
<         "name": "myclustername-2pt9p-worker-gpu-a",
---
>         "name": "myclustername-2pt9p-worker-a",
25c25
<                 "machine.openshift.io/cluster-api-machineset": "myclustername-2pt9p-worker-gpu-a"
---
>                 "machine.openshift.io/cluster-api-machineset": "myclustername-2pt9p-worker-a"
34c34
<                     "machine.openshift.io/cluster-api-machineset": "myclustername-2pt9p-worker-gpu-a"
---
>                     "machine.openshift.io/cluster-api-machineset": "myclustername-2pt9p-worker-a"
59,60c59
<                         "machineType": "a2-highgpu-1g",
<                         "onHostMaintenance": "Terminate",
---
>                         "machineType": "n2-standard-4",

次のコマンドを実行して、定義ファイルから GPU 対応のコンピュートマシンセットを作成します。
```
$ oc create -f ocp_4.12_machineset-a2-highgpu-1g.json
```
出力例
```
machineset.machine.openshift.io/myclustername-2pt9p-worker-gpu-a created
```

検証

次のコマンドを実行して、作成したマシンセットを表示します。
```
$ oc -n openshift-machine-api get machinesets | grep gpu
```
MachineSet レプリカ数は 1 に設定されているため、新しい Machine オブジェクトが自動的に作成されます。
出力例
```
myclustername-2pt9p-worker-gpu-a   1         1         1       1           5h24m
```

次のコマンドを実行して、マシンセットが作成した Machine オブジェクトを表示します。

$ oc -n openshift-machine-api get machines | grep gpu

出力例

myclustername-2pt9p-worker-gpu-a-wxcr6   Running   a2-highgpu-1g   us-central1   us-central1-a   5h25m

注記

ノードの名前空間を指定する必要がないことに注意してください。ノード定義はクラスタースコープ指定されています。

2.5.8. Node Feature Discovery Operator のデプロイ

手順

OpenShift Container Platform コンソールの OperatorHub から Node Feature Discovery Operator をインストールします。
NFD Operator を OperatorHub にインストールした後、インストールされた Operator リストから Node Feature Discovery を選択し、Create instance を選択します。これにより、nfd-master Pod および nfd-worker Pod (コンピュートノードごとに 1 つの nfd-worker Pod) が openshift-nfd 名前空間にインストールされます。

次のコマンドを実行して、Operator がインストールされ、実行されていることを確認します。

$ oc get pods -n openshift-nfd

出力例

NAME                                       READY    STATUS     RESTARTS   AGE

nfd-controller-manager-8646fcbb65-x5qgk    2/2      Running 7  (8h ago)   1d

コンソールでインストール済みの Operator へ移動し、Create Node Feature Discovery を選択します。
Create を選択して、NFD カスタムリソースをビルドします。これにより、openshift-nfd 名前空間に NFD Pod が作成され、ハードウェアリソース用に OpenShift Container Platform ノードをポーリングし、それらをカタログ化します。

検証

ビルドが成功したら、次のコマンドを実行して、各ノードで NFD Pod が実行されていることを確認します。

$ oc get pods -n openshift-nfd

出力例

NAME                                       READY   STATUS      RESTARTS        AGE
nfd-controller-manager-8646fcbb65-x5qgk    2/2     Running     7 (8h ago)      12d
nfd-master-769656c4cb-w9vrv                1/1     Running     0               12d
nfd-worker-qjxb2                           1/1     Running     3 (3d14h ago)   12d
nfd-worker-xtz9b                           1/1     Running     5 (3d14h ago)   12d

NFD Operator は、ベンダー PCI ID を使用してノード内のハードウェアを識別します。NVIDIA は PCI ID 10de を使用します。

次のコマンドを実行して、NFD Operator によって検出された NVIDIA GPU を表示します。
```
$ oc describe node ip-10-0-132-138.us-east-2.compute.internal | egrep 'Roles|pci'
```
出力例
```
Roles: worker

feature.node.kubernetes.io/pci-1013.present=true

feature.node.kubernetes.io/pci-10de.present=true

feature.node.kubernetes.io/pci-1d0f.present=true
```
GPU 対応ノードのノード機能リストに 10de が表示されます。これは、NFD Operator が GPU 対応の MachineSet からノードを正しく識別したことを意味します。

2.6. IBM Cloud でコンピュートマシンセットを作成する

IBM Cloud 上の OpenShift Container Platform クラスターで特定の目的を果たす別のコンピューティングマシンセットを作成できます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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

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: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role>-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<region> 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <role> 8
        machine.openshift.io/cluster-api-machine-type: <role> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<region> 10
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: ""
      providerSpec:
        value:
          apiVersion: ibmcloudproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: ibmcloud-credentials
          image: <infrastructure_id>-rhcos 11
          kind: IBMCloudMachineProviderSpec
          primaryNetworkInterface:
              securityGroups:
              - <infrastructure_id>-sg-cluster-wide
              - <infrastructure_id>-sg-openshift-net
              subnet: <infrastructure_id>-subnet-compute-<zone> 12
          profile: <instance_profile> 13
          region: <region> 14
          resourceGroup: <resource_group> 15
          userDataSecret:
              name: <role>-user-data 16
          vpc: <vpc_name> 17
          zone: <zone> 18

1 5 7

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

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

2 3 8 9 16

追加するノードラベル。

4 6 10

インフラストラクチャー ID、ノードラベル、およびリージョン。

クラスターのインストールに使用されたカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。

マシンを配置するためのリージョン内のインフラストラクチャー ID とゾーン。リージョンがゾーンをサポートすることを確認してください。

IBM Cloud インスタンスプロファイルを指定します。

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

マシンリソースが配置されるリソースグループ。これは、インストール時に指定された既存のリソースグループ、またはインフラストラクチャー ID に基づいて名前が付けられたインストーラーによって作成されたリソースグループのいずれかです。

VPC 名。

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

2.6.2. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.7. Nutanix でコンピュートマシンセットを作成する

Nutanix 上の OpenShift Container Platform クラスターで特定の目的を果たす別のコンピューティングマシンセットを作成できます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

このサンプル YAML は、node-role.kubernetes.io/<role>: "" でラベル付けされたノードを作成する Nutanix コンピュートマシンセットを定義します。

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: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role>-<zone> 4
  namespace: openshift-machine-api
  annotations: 5
    machine.openshift.io/memoryMb: "16384"
    machine.openshift.io/vCPU: "4"
spec:
  replicas: 3
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 6
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 7
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 8
        machine.openshift.io/cluster-api-machine-role: <role> 9
        machine.openshift.io/cluster-api-machine-type: <role> 10
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone> 11
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          cluster:
            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-creds-secret
          image:
            name: <infrastructure_id>-rhcos 12
            type: name
          kind: NutanixMachineProviderConfig
          memorySize: 16Gi 13
          subnets:
          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi 14
          userDataSecret:
            name: <user_data_secret> 15
          vcpuSockets: 4 16
          vcpusPerSocket: 1 17

1 6 8

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

2 3 9 10

追加するノードラベルを指定します。

4 7 11

インフラストラクチャー ID、ノードラベル、およびゾーンを指定します。

クラスターオートスケーラーのアノテーション。

使用するイメージを指定します。クラスターに設定されている既存のコンピュートデフォルトマシンのイメージを使用します。

クラスターのメモリー量を Gi で指定します。

システムディスクのサイズを Gi で指定します。

vCPU ソケットの数を指定します。

ソケットあたりの vCPU の数を指定します。

2.7.2. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.8. OpenStack でコンピュートマシンセットを作成する

異なるコンピュートマシンセットを作成して、Red Hat OpenStack Platform (RHOSP) 上の OpenShift Container Platform クラスターで特定の目的で使用できます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

このサンプル YAML は、Red Hat OpenStack Platform (RHOSP) で実行され、node-role.kubernetes.io/<role>: "" というラベルが付けられたノードを作成するコンピュートマシンセットを定義します。

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: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role> 4
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas>
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <role> 8
        machine.openshift.io/cluster-api-machine-type: <role> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 10
    spec:
      providerSpec:
        value:
          apiVersion: openstackproviderconfig.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> 11
          kind: OpenstackProviderSpec
          networks: 12
          - filter: {}
            subnets:
            - filter:
                name: <subnet_name>
                tags: openshiftClusterID=<infrastructure_id> 13
          primarySubnet: <rhosp_subnet_UUID> 14
          securityGroups:
          - filter: {}
            name: <infrastructure_id>-worker 15
          serverMetadata:
            Name: <infrastructure_id>-worker 16
            openshiftClusterID: <infrastructure_id> 17
          tags:
          - openshiftClusterID=<infrastructure_id> 18
          trunk: true
          userDataSecret:
            name: worker-user-data 19
          availabilityZone: <optional_openstack_availability_zone>

1 5 7 13 15 16 17 18

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

2 3 8 9 19

追加するノードラベルを指定します。

4 6 10

インフラストラクチャー ID およびノードラベルを指定します。

MachineSet のサーバーグループポリシーを設定するには、サーバーグループの作成から返された値を入力します。ほとんどのデプロイメントでは、anti-affinity または soft-anti-affinity が推奨されます。

複数ネットワークへのデプロイメントに必要です。複数のネットワークを指定するには、ネットワークアレイに別のエントリーを追加します。また、primarySubnet の値として使用されるネットワークが含まれる必要があります。

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

2.8.2. RHOSP 上の SR-IOV を使用するコンピュートマシンセットのカスタムリソースのサンプル YAML

クラスターを SR-IOV (Single-root I/O Virtualization) 用に設定している場合に、その技術を使用するコンピュートマシンセットを作成できます。

このサンプル YAML は SR-IOV ネットワークを使用するコンピュートマシンセットを定義します。作成するノードには node-role.openshift.io/<node_role>: "" というラベルが付けられます。

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

この例では、radio と uplink という名前の 2 つの SR-IOV ネットワークを想定しています。これらのネットワークは、spec.template.spec.providerSpec.value.ports 一覧のポート定義で使用されます。

注記

この例では、SR-IOV デプロイメント固有のパラメーターのみを説明します。より一般的なサンプルを確認するには、RHOSP 上のコンピュートマシンセットのカスタムリソースのサンプル YAML を参照してください。

SR-IOV ネットワークを使用するコンピュートマシンセットの例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    machine.openshift.io/cluster-api-machine-role: <node_role>
    machine.openshift.io/cluster-api-machine-type: <node_role>
  name: <infrastructure_id>-<node_role>
  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>-<node_role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <node_role>
        machine.openshift.io/cluster-api-machine-type: <node_role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<node_role>
    spec:
      metadata:
      providerSpec:
        value:
          apiVersion: openstackproviderconfig.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:
            - subnets:
              - UUID: <machines_subnet_UUID>
          ports:
            - networkID: <radio_network_UUID> 1
              nameSuffix: radio
              fixedIPs:
                - subnetID: <radio_subnet_UUID> 2
              tags:
                - sriov
                - radio
              vnicType: direct 3
              portSecurity: false 4
            - networkID: <uplink_network_UUID> 5
              nameSuffix: uplink
              fixedIPs:
                - subnetID: <uplink_subnet_UUID> 6
              tags:
                - sriov
                - uplink
              vnicType: direct 7
              portSecurity: false 8
          primarySubnet: <machines_subnet_UUID>
          securityGroups:
          - filter: {}
            name: <infrastructure_id>-<node_role>
          serverMetadata:
            Name: <infrastructure_id>-<node_role>
            openshiftClusterID: <infrastructure_id>
          tags:
          - openshiftClusterID=<infrastructure_id>
          trunk: true
          userDataSecret:
            name: <node_role>-user-data
          availabilityZone: <optional_openstack_availability_zone>

1 5: 各ポートにネットワークの UUID を入力します。
2 6: 各ポートのサブネット UUID を入力します。
3 7: vnicType パラメーターの値は、各ポートに 直接 指定する必要があります。
4 8: portSecurity パラメーターの値は、各ポートで false である必要があります。
ポートセキュリティーが無効な場合は、ポートにセキュリティーグループと使用可能なアドレスペアを設定できません。インスタンスにセキュリティーグループを設定すると、グループが割り当てられているすべてのポートに適用されます。

重要

SR-IOV 対応のコンピュートマシンをデプロイしたら、そのようにラベルを付ける必要があります。たとえば、コマンドラインから次のように入力します。

$ oc label node <NODE_NAME> feature.node.kubernetes.io/network-sriov.capable="true"

注記

トランクは、ネットワークおよびサブネットの一覧のエントリーで作成されるポート向けに有効にされます。これらの一覧から作成されたポートの名前は、<machine_name>-<nameSuffix> パターンを使用します。nameSuffix フィールドは、ポート定義に必要です。

それぞれのポートにトランキングを有効にすることができます。

オプションで、タグを タグ 一覧の一部としてポートに追加できます。

関連情報

Preparing to install a cluster that uses SR-IOV or OVS-DPDK on OpenStack

2.8.3. ポートセキュリティーが無効にされている SR-IOV デプロイメントのサンプル YAML

ポートセキュリティーが無効にされたネットワークに single-root I/O Virtualization (SR-IOV) ポートを作成するには、spec.template.spec.providerSpec.value.ports 一覧の項目としてポートを含めてコンピュートマシンセットを定義します。標準の SR-IOV コンピュートマシンセットとのこの相違点は、ネットワークとサブネットインターフェイスを使用して作成されたポートに対して発生する自動セキュリティーグループと使用可能なアドレスペア設定によるものです。

マシンのサブネット用に定義するポートには、以下が必要です。

API および Ingress 仮想 IP ポート用に許可されるアドレスペア
コンピュートセキュリティーグループ
マシンネットワークおよびサブネットへの割り当て

注記

以下の例のように、ポートセキュリティーが無効になっている SR-IOV デプロイメント固有のパラメーターのみを説明します。より一般的なサンプルを確認するには、RHOSP 上の SR-IOV を使用するコンピュートマシンセットカスタムリソースのサンプル YAML について参照してください。

SR-IOV ネットワークを使用し、ポートセキュリティーが無効にされているコンピュートマシンセットの例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    machine.openshift.io/cluster-api-machine-role: <node_role>
    machine.openshift.io/cluster-api-machine-type: <node_role>
  name: <infrastructure_id>-<node_role>
  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>-<node_role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <node_role>
        machine.openshift.io/cluster-api-machine-type: <node_role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<node_role>
    spec:
      metadata: {}
      providerSpec:
        value:
          apiVersion: openstackproviderconfig.openshift.io/v1alpha1
          cloudName: openstack
          cloudsSecret:
            name: openstack-cloud-credentials
            namespace: openshift-machine-api
          flavor: <nova_flavor>
          image: <glance_image_name_or_location>
          kind: OpenstackProviderSpec
          ports:
            - allowedAddressPairs: 1
              - ipAddress: <API_VIP_port_IP>
              - ipAddress: <ingress_VIP_port_IP>
              fixedIPs:
                - subnetID: <machines_subnet_UUID> 2
              nameSuffix: nodes
              networkID: <machines_network_UUID> 3
              securityGroups:
                  - <compute_security_group_UUID> 4
            - networkID: <SRIOV_network_UUID>
              nameSuffix: sriov
              fixedIPs:
                - subnetID: <SRIOV_subnet_UUID>
              tags:
                - sriov
              vnicType: direct
              portSecurity: False
          primarySubnet: <machines_subnet_UUID>
          serverMetadata:
            Name: <infrastructure_ID>-<node_role>
            openshiftClusterID: <infrastructure_id>
          tags:
          - openshiftClusterID=<infrastructure_id>
          trunk: false
          userDataSecret:
            name: worker-user-data

1: API および Ingress ポート用に許可されるアドレスペアを指定します。
2 3: マシンネットワークおよびサブネットを指定します。
4: コンピュートマシンのセキュリティーグループを指定します。

注記

それぞれのポートにトランキングを有効にすることができます。

オプションで、タグを タグ 一覧の一部としてポートに追加できます。

クラスターで Kuryr を使用し、RHOSP SR-IOV ネットワークでポートセキュリティーが無効にされている場合に、コンピュートマシンのプライマリーポートには以下が必要になります。

spec.template.spec.providerSpec.value.networks.portSecurityEnabled パラメーターの値を false に設定します。
各サブネットについて、spec.template.spec.providerSpec.value.networks.subnets.portSecurityEnabled パラメーターの値を false に設定します。
spec.template.spec.providerSpec.value.securityGroups の値は、空: [] に指定します。

SR-IOV を使用し、ポートセキュリティーが無効な Kuryr にあるクラスターのコンピュートマシンセットのセクション例

...
          networks:
            - subnets:
              - uuid: <machines_subnet_UUID>
                portSecurityEnabled: false
              portSecurityEnabled: false
          securityGroups: []
...

今回の場合は、仮想マシンの作成後にコンピュートセキュリティーグループをプライマリー仮想マシンインターフェイスに適用できます。たとえば、コマンドラインでは、以下を実行します。

$ openstack port set --enable-port-security --security-group <infrastructure_id>-<node_role> <main_port_ID>

重要

$ oc label node <NODE_NAME> feature.node.kubernetes.io/network-sriov.capable="true"

2.8.4. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.9. RHV でコンピュートマシンセットを作成する

異なるコンピュートマシンセットを作成して、Red Hat Virtualization (RHV) 上の OpenShift Container Platform クラスターで特定の目的で使用できます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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

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: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role> 4
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas> 5
  Selector: 6
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 8
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 9
        machine.openshift.io/cluster-api-machine-role: <role> 10
        machine.openshift.io/cluster-api-machine-type: <role> 11
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 12
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 13
      providerSpec:
        value:
          apiVersion: ovirtproviderconfig.machine.openshift.io/v1beta1
          cluster_id: <ovirt_cluster_id> 14
          template_name: <ovirt_template_name> 15
          sparse: <boolean_value> 16
          format: <raw_or_cow> 17
          cpu: 18
            sockets: <number_of_sockets> 19
            cores: <number_of_cores> 20
            threads: <number_of_threads> 21
          memory_mb: <memory_size> 22
          guaranteed_memory_mb:  <memory_size> 23
          os_disk: 24
            size_gb: <disk_size> 25
            storage_domain_id: <storage_domain_UUID> 26
          network_interfaces: 27
            vnic_profile_id:  <vnic_profile_id> 28
          credentialsSecret:
            name: ovirt-credentials 29
          kind: OvirtMachineProviderSpec
          type: <workload_type> 30
          auto_pinning_policy: <auto_pinning_policy> 31
          hugepages: <hugepages> 32
          affinityGroupsNames:
            - compute 33
          userDataSecret:
            name: worker-user-data

1 7 9

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

2 3 10 11 13

追加するノードラベルを指定します。

4 8 12

インフラストラクチャー ID およびノードラベルを指定します。これら 2 つの文字列は 35 文字を超えることができません。

作成するマシンの数を指定します。

マシンのセレクター。

この仮想マシンインスタンスが属する RHV クラスターの UUID を指定します。

マシンの作成に使用する RHV 仮想マシンテンプレートを指定します。

このオプションを false に設定すると、ディスクの事前割り当てが有効になります。デフォルトは true です。format を raw に設定して sparse を true に設定することは、ブロックストレージドメインでは使用できません。raw 形式は、仮想ディスク全体を基盤となる物理ディスクに書き込みます。

cow または raw に設定できます。デフォルトは cow です。cow のフォーマットは仮想マシン用に最適化されています。

注記

ファイルストレージドメインにディスクを事前に割り当てると、ファイルにゼロが書き込まれます。基盤となるストレージによっては、実際にはディスクが事前に割り当てられない場合があります。

オプション: CPU フィールドには、ソケット、コア、スレッドを含む CPU の設定が含まれます。

オプション: 仮想マシンのソケット数を指定します。

20

オプション: ソケットあたりのコア数を指定します。

オプション: コアあたりのスレッド数を指定します。

オプション: 仮想マシンのメモリーサイズを MiB 単位で指定します。

23

オプション: 仮想マシンの保証されたメモリーのサイズを MiB で指定します。これは、バルーニングメカニズムによって排出されないことが保証されているメモリーの量です。詳細は、Memory Ballooning と Optimization Settings Explained を参照してください。

注記

RHV 4.4.8 より前のバージョンを使用している場合は、Red Hat Virtualization クラスターでの OpenShift の保証されたメモリー要件を参照してください。

24

オプション: ノードのルートディスク。

25

オプション: ブート可能なディスクのサイズを GiB 単位で指定します。

26

オプション: コンピュートノードのディスクのストレージドメインの UUID を指定します。何も指定されていない場合、コンピュートノードはコントロールノードと同じストレージドメインに作成されます。(デフォルト)

27

オプション: 仮想マシンのネットワークインターフェイスの一覧。このパラメーターを含めると、OpenShift Container Platform はテンプレートからすべてのネットワークインターフェイスを破棄し、新規ネットワークインターフェイスを作成します。

28

オプション: vNIC プロファイル ID を指定します。

29

RHV クレデンシャルを保持するシークレットオブジェクトの名前を指定します。

30

オプション: インスタンスが最適化されるワークロードタイプを指定します。この値は RHV VM パラメーターに影響します。サポートされる値: desktop、server (デフォルト)、high_performance です。high_performance は、VM のパフォーマンスを向上させます。制限があります。たとえば、グラフィカルコンソールで VM にアクセスすることはできません。詳細は、Virtual Machine Management Guideのハイパフォーマンス仮想マシン、テンプレート、およびプールの設定を参照してください。

31

オプション:AutoPinningPolicy は、このインスタンスのホストへのピニングを含む、CPU と NUMA 設定を自動的に設定するポリシーを定義します。サポートされる値は、none、resize_and_pin です。詳細は、Virtual Machine Management Guideの Setting NUMA Nodes を参照してください。

32

オプション:hugepages は、仮想マシンで hugepage を定義するためのサイズ (KiB) です。対応している値は 2048 および 1048576 です。詳細は、Virtual Machine Management Guideの Configuring Huge Pages を参照してください。

33

オプション: 仮想マシンに適用されるアフィニティーグループ名のリスト。アフィニティーグループは oVirt に存在している必要があります。

注記

RHV は仮想マシンの作成時にテンプレートを使用するため、任意のパラメーターの値を指定しない場合、RHV はテンプレートに指定されるパラメーターの値を使用します。

2.9.2. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

2.10. vSphere でコンピュートマシンセットを作成する

VMware vSphere 上の OpenShift Container Platform クラスターで特定の目的を果たすように異なるコンピュートマシンセットを作成することができます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-<role> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 4
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 8
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 120
          kind: VSphereMachineProviderSpec
          memoryMiB: 8192
          metadata:
            creationTimestamp: null
          network:
            devices:
            - networkName: "<vm_network_name>" 10
          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <vm_template_name> 11
          userDataSecret:
            name: worker-user-data
          workspace:
            datacenter: <vcenter_datacenter_name> 12
            datastore: <vcenter_datastore_name> 13
            folder: <vcenter_vm_folder_path> 14
            resourcepool: <vsphere_resource_pool> 15
            server: <vcenter_server_ip> 16

1 3 5

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

2 4 8

インフラストラクチャー ID およびノードラベルを指定します。

6 7 9

追加するノードラベルを指定します。

コンピュートマシンセットをデプロイする vSphere 仮想マシンネットワークを指定します。この仮想マシンネットワークは、他のコンピューティングマシンがクラスター内に存在する場所である必要があります。

user-5ddjd-rhcos などの使用する vSphere 仮想マシンテンプレートを指定します。

コンピュートマシンセットをデプロイする vCenter Datacenter を指定します。

コンピュートマシンセットをデプロイする vCenter Datastore を指定します。

/dc1/vm/user-inst-5ddjd などの vCenter の vSphere 仮想マシンフォルダーへのパスを指定します。

仮想マシンの vSphere リソースプールを指定します。

vCenter サーバーの IP または完全修飾ドメイン名を指定します。

2.10.2. コンピュートマシンセット管理に最低限必要な vCenter 権限

vCenter 上の OpenShift Container Platform クラスターでコンピュートマシンセットを管理するには、必要なリソースの読み取り、作成、および削除を行う権限を持つアカウントを使用する必要があります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。

グローバル管理者権限を持つアカウントを使用できない場合は、最低限必要な権限を付与するロールを作成する必要があります。次の表に、コンピュートマシンセットの作成、スケーリング、削除、および OpenShift Container Platform クラスター内のマシンの削除に必要な vCenter の最小のロールと特権を示します。

例2.1 コンピュートマシンセットの管理に必要な最小限の vCenter のロールと権限

ロールの vSphere オブジェクト	必要になる場合	必要な特権
vSphere vCenter	Always	`InventoryService.Tagging.AttachTag` `InventoryService.Tagging.CreateCategory` `InventoryService.Tagging.CreateTag` `InventoryService.Tagging.DeleteCategory` `InventoryService.Tagging.DeleteTag` `InventoryService.Tagging.EditCategory` `InventoryService.Tagging.EditTag` `Sessions.ValidateSession` `StorageProfile.Update`¹ `StorageProfile.View`¹
vSphere vCenter Cluster	Always	`Resource.AssignVMToPool`
vSphere Datastore	Always	`Datastore.AllocateSpace` `Datastore.Browse`
vSphere ポートグループ	Always	`Network.Assign`
仮想マシンフォルダー	Always	`VirtualMachine.Config.AddRemoveDevice` `VirtualMachine.Config.AdvancedConfig` `VirtualMachine.Config.Annotation` `VirtualMachine.Config.CPUCount` `VirtualMachine.Config.DiskExtend` `VirtualMachine.Config.Memory` `VirtualMachine.Config.Settings` `VirtualMachine.Interact.PowerOff` `VirtualMachine.Interact.PowerOn` `VirtualMachine.Inventory.CreateFromExisting` `VirtualMachine.Inventory.Delete` `VirtualMachine.Provisioning.Clone`
vSphere vCenter Datacenter	インストールプログラムが仮想マシンフォルダーを作成する場合	`Resource.AssignVMToPool` `VirtualMachine.Provisioning.DeployTemplate`
¹`StorageProfile.Update` および `StorageProfile.View` 権限は、Container Storage Interface (CSI) を使用するストレージバックエンドにのみ必要です。

次の表に、コンピュートマシンセットの管理に必要なパーミッションと伝播設定の詳細を示します。

例2.2 必要なパーミッションおよび伝播の設定

vSphere オブジェクト	フォルダータイプ	子への伝播	パーミッションが必要
vSphere vCenter	Always	必須ではありません。	必要な特権が一覧表示
vSphere vCenter Datacenter	既存のフォルダー	必須ではありません。	`ReadOnly` パーミッション
vSphere vCenter Datacenter	インストールプログラムがフォルダーを作成する	必須	必要な特権が一覧表示
vSphere vCenter Cluster	Always	必須	必要な特権が一覧表示
vSphere vCenter Datastore	Always	必須ではありません。	必要な特権が一覧表示
vSphere Switch	Always	必須ではありません。	`ReadOnly` パーミッション
vSphere ポートグループ	Always	必須ではありません。	必要な特権が一覧表示
vSphere vCenter 仮想マシンフォルダー	既存のフォルダー	必須	必要な特権が一覧表示

必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。

2.10.3. コンピュートマシンセットを使用するための、ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの要件

ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターでコンピュートマシンセットを使用するには、クラスター設定が Machine API の使用をサポートしていることを確認する必要があります。

インフラストラクチャー ID の取得

コンピュートマシンセットを作成するには、クラスターのインフラストラクチャー ID を指定できる必要があります。

手順

クラスターのインフラストラクチャー ID を取得するには、次のコマンドを実行します。
```
$ oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'
```

vSphere 認証情報の要件を満たす

コンピュートマシンセットを使用するには、マシン API が vCenter と対話できる必要があります。マシン API コンポーネントが vCenter と対話することを許可する認証情報は､openshift-machine-api 名前空間のシークレットに存在する必要があります。

手順

必要な認証情報が存在するかどうかを確認するには、次のコマンドを実行します。
```
$ oc get secret \
  -n openshift-machine-api vsphere-cloud-credentials \
  -o go-template='{{range $k,$v := .data}}{{printf "%s: " $k}}{{if not $v}}{{$v}}{{else}}{{$v | base64decode}}{{end}}{{"\n"}}{{end}}'
```
出力例
```
<vcenter-server>.password=<openshift-user-password>
<vcenter-server>.username=<openshift-user>
```
ここで、<vcenter-server> は vCenter サーバーの IP アドレスまたは完全修飾ドメイン名 (FQDN) であり、<openshift-user> および <openshift-user-password> は使用する OpenShift Container Platform 管理者の認証情報です。

シークレットが存在しない場合は、次のコマンドを実行して作成します。

$ oc create secret generic vsphere-cloud-credentials \
  -n openshift-machine-api \
  --from-literal=<vcenter-server>.username=<openshift-user> --from-literal=<vcenter-server>.password=<openshift-user-password>

Ignition 設定要件を満たす

仮想マシン (VM) のプロビジョニングには、有効な Ignition 設定が必要です。Ignition 設定には、machine-config-server アドレスと、Machine Config Operator からさらに Ignition 設定を取得するためのシステム信頼バンドルが含まれています。

デフォルトでは、この設定は machine-api-operator namespace の worker-user-data シークレットに保存されます。コンピュートマシンセットは、マシンの作成プロセス中にシークレットを参照します。

手順

必要なシークレットが存在するかどうかを判断するには、次のコマンドを実行します。

$ oc get secret \
  -n openshift-machine-api worker-user-data \
  -o go-template='{{range $k,$v := .data}}{{printf "%s: " $k}}{{if not $v}}{{$v}}{{else}}{{$v | base64decode}}{{end}}{{"\n"}}{{end}}'

出力例

disableTemplating: false
userData: 1
  {
    "ignition": {
      ...
      },
    ...
  }

1: ここでは完全な出力は省略しますが、この形式にする必要があります。

シークレットが存在しない場合は、次のコマンドを実行して作成します。
```
$ oc create secret generic worker-user-data \
  -n openshift-machine-api \
  --from-file=<installation_directory>/worker.ign
```
ここで <installation_directory>、クラスターのインストール中にインストール資産を保管するために使用されたディレクトリーです。

関連情報

2.10.4. コンピュートマシンセットの作成

注記

ユーザーがプロビジョニングしたインフラストラクチャーを使用してインストールされたクラスターには、インストールプログラムによってプロビジョニングされたインフラストラクチャーを使用したクラスターとは異なるネットワークスタックがあります。この違いの結果、自動ロードバランサー管理は、ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターではサポートされません。これらのクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

前提条件

OpenShift Container Platform クラスターをデプロイすること。
OpenShift CLI (oc) がインストールされている。
cluster-admin パーミッションを持つユーザーとして、oc にログインする。
vCenter インスタンスに仮想マシンをデプロイするのに必要なパーミッションがあり、指定されたデータストアへのアクセス権限が必要です。
クラスターがユーザーによってプロビジョニングされたインフラストラクチャーを使用している場合、その設定の特定のマシン API 要件を満たしています。

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスター用のコンピュートマシンセットを作成する場合は、次の重要な値に注意してください。

例: vSphere providerSpec 値

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
...
template:
  ...
  spec:
    providerSpec:
      value:
        apiVersion: machine.openshift.io/v1beta1
        credentialsSecret:
          name: vsphere-cloud-credentials 1
        diskGiB: 120
        kind: VSphereMachineProviderSpec
        memoryMiB: 16384
        network:
          devices:
            - networkName: "<vm_network_name>"
        numCPUs: 4
        numCoresPerSocket: 4
        snapshot: ""
        template: <vm_template_name> 2
        userDataSecret:
          name: worker-user-data 3
        workspace:
          datacenter: <vcenter_datacenter_name>
          datastore: <vcenter_datastore_name>
          folder: <vcenter_vm_folder_path>
          resourcepool: <vsphere_resource_pool>
          server: <vcenter_server_address> 4

1: 必要な vCenter 認証情報を含む openshift-machine-api 名前空間のシークレットの名前。
2: インストール中に作成されたクラスターの RHCOS VM テンプレートの名前。
3: 必要な Ignition 設定認証情報を含む openshift-machine-api namespace のシークレットの名前。
4: vCenter サーバーの IP アドレスまたは完全修飾ドメイン名 (FQDN)。

次のコマンドを実行して 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

2.11. ベアメタル上でのコンピュートマシンセットの作成

ベアメタル上の OpenShift Container Platform クラスターで、特定の目的を果たす別のコンピューティングマシンセットを作成できます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

2.11.1. ベアメタル上のコンピュートマシンセットカスタムリソースのサンプル YAML

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-<role> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 4
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: <role> 6
        machine.openshift.io/cluster-api-machine-type: <role> 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 8
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/<role>: "" 9
      providerSpec:
        value:
          apiVersion: baremetal.cluster.k8s.io/v1alpha1
          hostSelector: {}
          image:
            checksum: http:/172.22.0.3:6181/images/rhcos-<version>.<architecture>.qcow2.<md5sum> 10
            url: http://172.22.0.3:6181/images/rhcos-<version>.<architecture>.qcow2 11
          kind: BareMetalMachineProviderSpec
          metadata:
            creationTimestamp: null
          userData:
            name: worker-user-data

1 3 5

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

2 4 8

インフラストラクチャー ID およびノードラベルを指定します。

6 7 9

追加するノードラベルを指定します。

API VIP アドレスを使用するように checksum URL を編集します。

url URL を編集して API VIP アドレスを使用します。

2.11.2. コンピュートマシンセットの作成

前提条件

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

手順

コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。
<clusterID> および <role> パラメーターの値を設定していることを確認します。

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

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

$ 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

特定のコンピュートマシンセットカスタムリソース(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> 1
  name: <infrastructure_id>-<role> 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>-<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: 3
        ...

1: クラスターインフラストラクチャー ID。
2: デフォルトのノードラベル。
注記
ユーザーがプロビジョニングしたインフラストラクチャーを持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。
3: コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細については、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

次のコマンドを実行して 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

第3章コンピュートマシンセットの手動スケーリング

コンピュートマシンセットのマシンのインスタンスを追加または削除できます。

注記

スケーリング以外のコンピュートマシンセットの要素を変更する必要がある場合は、コンピュートマシンセットの変更を参照してください。

3.1. 前提条件

クラスター全体のプロキシーを有効にし、インストール設定から networking.machineNetwork[].cidr に含まれていないコンピュートマシンをスケールアップする場合、コンピュートマシンをプロキシーオブジェクトの noProxy フィールドに追加し、接続の問題を防ぐ必要があります。

重要

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

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

3.2. コンピュートマシンセットの手動スケーリング

コンピュートマシンセットのマシンのインスタンスを追加したり、削除したりする必要がある場合、コンピュートマシンセットを手動でスケーリングできます。

本書のガイダンスは、完全に自動化されたインストーラーでプロビジョニングされるインフラストラクチャーのインストールに関連します。ユーザーによってプロビジョニングされるインフラストラクチャーのカスタマイズされたインストールにはコンピュートマシンセットがありません。

前提条件

OpenShift Container Platform クラスターおよび oc コマンドラインをインストールすること。
cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

次のコマンドを実行して、クラスター内のコンピュートマシンセットを表示します。
```
$ oc get machinesets -n openshift-machine-api
```
コンピュートマシンセットは <clusterid>-worker-<aws-region-az> の形式で一覧表示されます。
次のコマンドを実行して、クラスター内のコンピュートマシンを表示します。
```
$ oc get machine -n openshift-machine-api
```
次のコマンドを実行して、削除するコンピュートマシンに注釈を設定します。
```
$ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"
```
次のいずれかのコマンドを実行して、コンピュートマシンセットをスケーリングします。
```
$ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
```
または、以下を実行します。
```
$ oc edit machineset <machineset> -n openshift-machine-api
```
ヒント
または、以下の YAML を適用してコンピュートマシンセットをスケーリングすることもできます。
```
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2
```
コンピュートマシンセットをスケールアップまたはスケールダウンできます。新規マシンが利用可能になるまで数分の時間がかかります。
重要
デフォルトでは、マシンコントローラーは、成功するまでマシンによってサポートされるノードをドレイン (解放) しようとします。Pod 中断バジェットの設定が間違っているなど、状況によっては、ドレイン操作が成功しない可能性があります。排水操作が失敗した場合、マシンコントローラーはマシンの取り外しを続行できません。
特定のマシンの machine.openshift.io/exclude-node-draining にアノテーションを付けると、ノードのドレイン (解放) を省略できます。

検証

次のコマンドを実行して、目的のマシンが削除されたことを確認します。
```
$ oc get machines
```

3.3. コンピュートマシンセットの削除ポリシー

Random、Newest、および Oldest は 3 つのサポートされる削除オプションです。デフォルトは Random です。これは、コンピュートマシンセットのスケールダウン時にランダムなマシンが選択され、削除されることを意味します。削除ポリシーは、特定のコンピュートマシンセットを変更し、ユースケースに基づいて設定できます。

spec:
  deletePolicy: <delete_policy>
  replicas: <desired_replica_count>

削除についての特定のマシンの優先順位は、削除ポリシーに関係なく、関連するマシンにアノテーション machine.openshift.io/delete-machine=true を追加して設定できます。

重要

デフォルトで、OpenShift Container Platform ルーター Pod はワーカーにデプロイされます。ルーターは Web コンソールなどの一部のクラスターリソースにアクセスすることが必要であるため、ルーター Pod をまず再配置しない限り、ワーカーのコンピュートマシンセットを 0 にスケーリングできません。

注記

カスタムのコンピュートマシンセットは、サービスを特定のノードサービスで実行し、それらのサービスがワーカーのコンピュートマシンセットのスケールダウン時にコントローラーによって無視されるようにする必要があるユースケースで使用できます。これにより、サービスの中断が回避されます。

3.4. 関連情報

マシン削除フェーズのライフサイクルフック

第4章コンピュートマシンセットの変更

ラベルの追加、インスタンスタイプの変更、ブロックストレージの変更など、コンピュートマシンセットに変更を加えることができます。

Red Hat Virtualization (RHV) では、コンピュートマシンセットを変更して新規ノードを別のストレージドメインにプロビジョニングすることもできます。

注記

他の変更なしにコンピュートマシンセットをスケーリングする必要がある場合は、コンピュートマシンセットの手動によるスケーリングを参照してください。

4.1. コンピュートマシンセットの変更

コンピュートマシンセットを変更するには、MachineSet YAML を編集します。次に、各マシンを削除するか、またはコンピュートマシンセットを 0 レプリカにスケールダウンしてコンピュートマシンセットに関連付けられたすべてのマシンを削除します。レプリカは必要な数にスケーリングします。コンピュートマシンセットへの変更は、既存のマシンに影響を与えません。

他の変更を加えずに、コンピュートマシンセットをスケーリングする必要がある場合、マシンを削除する必要はありません。

注記

デフォルトで、OpenShift Container Platform ルーター Pod はワーカーにデプロイされます。ルーターは Web コンソールなどの一部のクラスターリソースにアクセスすることが必要であるため、ルーター Pod をまず再配置しない限り、コンピュートマシンセットを 0 にスケーリングできません。

前提条件

OpenShift Container Platform クラスターおよび oc コマンドラインをインストールすること。
cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

次のコマンドを実行して、コンピュートマシンセットを編集します。
```
$ oc edit machineset <machineset> -n openshift-machine-api
```
次のいずれかのコマンドを実行して、コンピュートマシンセットを 0 にスケールダウンします。
```
$ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api
```
または、以下を実行します。
```
$ oc edit machineset <machineset> -n openshift-machine-api
```
ヒント
または、以下の YAML を適用してコンピュートマシンセットをスケーリングすることもできます。
```
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 0
```
マシンが削除されるまで待機します。
次のコマンドのいずれかを実行して、必要に応じてコンピュートマシンセットをスケールアップします。
```
$ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
```
または、以下を実行します。
```
$ oc edit machineset <machineset> -n openshift-machine-api
```
ヒント
または、以下の YAML を適用してコンピュートマシンセットをスケーリングすることもできます。
```
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2
```
マシンが起動するまで待ちます。新規マシンにはコンピュートマシンセットに加えられた変更が含まれます。

関連情報

マシン削除フェーズのライフサイクルフック

4.2. RHV 上の別のストレージドメインへのノードの移行

OpenShift Container Platform コントロールプレーンおよびコンピュートノードを Red Hat Virtualization (RHV) クラスターの別のストレージドメインに移行できます。

4.2.1. RHV 上の別のストレージドメインへのコンピュートノードの移行

前提条件

Manager にログインしている。
ターゲットとなるストレージドメインの名前を把握している。

手順

次のコマンドを実行して、仮想マシンテンプレートを特定します。

$ oc get -o jsonpath='{.items[0].spec.template.spec.providerSpec.value.template_name}{"\n"}' machineset -A

指定したテンプレートに基づいて、Manager で新規の仮想マシンを作成します。その他の設定はすべて変更しません。詳細は、Red Hat Virtualization Virtual Machine Management Guideの Creating a Virtual Machine Based on a Template を参照してください。
ヒント
新しい仮想マシンを起動する必要はありません。
新規仮想マシンから新規テンプレートを作成します。Target にターゲットストレージドメインを指定します。詳細は、Red Hat Virtualization Virtual Machine Management Guideの Creating a Template を参照してください。
新規テンプレートを使用して、新規コンピュートマシンセットを OpenShift Container Platform クラスターに追加します。
1. 次のコマンドを実行して、現在のコンピュートマシンセットの詳細を取得します。
```
$ oc get machineset -o yaml
```
2. これらの詳細を使用して、コンピュートマシンセットを作成します。詳細は、コンピュートマシンセットの作成 を参照してください。
  template_name フィールドに新規仮想マシンテンプレート名を入力します。Manager の New template ダイアログで使用したものと同じテンプレート名を使用します。
3. 古いマシンセットと新しいコンピュートマシンセットの名前の両方をメモします。後続の手順でこれらを参照する必要があります。
ワークロードを移行します。
1. 新規のコンピュートマシンセットをスケールアップします。コンピューティングマシンセットを手動でスケーリングする方法の詳細については、コンピュートマシンセットを手動でスケーリングするを参照してください。
  OpenShift Container Platform は、古いマシンが削除されると Pod を利用可能なワーカーに移動します。
2. 古いコンピュートマシンセットをスケールダウンします。
次のコマンドを実行して、古いコンピュートマシンセットを削除します。
```
$ oc delete machineset <machineset-name>
```

関連情報

4.2.2. RHV 上の別のストレージドメインへのコントロールプレーンノードの移行

OpenShift Container Platform はコントロールプレーンノードを管理しないため、コンピュートノードよりも移行が容易になります。Red Hat Virtualization (RHV) 上の他の仮想マシンと同様に移行することができます。

ノードごとに個別にこの手順を実行します。

前提条件

Manager にログインしている。
コントロールプレーンノードを特定している。Manager で master というラベルが付けられています。

手順

master というラベルが付けられた仮想マシンを選択します。
仮想マシンをシャットダウンします。
Disks タブをクリックします。
仮想マシンのディスクをクリックします。
More Actions をクリックし、Move を選択します。
ターゲットストレージドメインを選択し、移行プロセスが完了するまで待ちます。
仮想マシンを起動します。
OpenShift Container Platform クラスターが安定していることを確認します。
```
$ oc get nodes
```
出力には、ステータスが Ready のノードが表示されます。
コントロールプレーンノードごとに、この手順を繰り返します。

第5章マシンの削除

特定のマシンを削除できます。

5.1. 特定マシンの削除

特定のマシンを削除できます。

重要

クラスターがコントロールプレーンマシンセットを使用していない限り、コントロールプレーンマシンを削除しないでください。

前提条件

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

手順

次のコマンドを実行して、クラスター内のマシンを表示します。
```
$ oc get machine -n openshift-machine-api
```
コマンド出力には、<clusterid>-<role>-<cloud_region> 形式のマシンのリストが含まれます。
削除するマシンを特定します。
次のコマンドを実行してマシンを削除します。
```
$ oc delete machine <machine> -n openshift-machine-api
```
重要
デフォルトでは、マシンコントローラーは、成功するまでマシンによってサポートされるノードをドレイン (解放) しようとします。Pod 中断バジェットの設定が間違っているなど、状況によっては、ドレイン操作が成功しない可能性があります。排水操作が失敗した場合、マシンコントローラーはマシンの取り外しを続行できません。
特定のマシンの machine.openshift.io/exclude-node-draining にアノテーションを付けると、ノードのドレイン (解放) を省略できます。
削除するマシンがマシンセットに属している場合は、指定された数のレプリカを満たす新しいマシンがすぐに作成されます。

5.2. マシン削除フェーズのライフサイクルフック

マシンのライフサイクルフックは、通常のライフサイクルプロセスが中断できる、マシンの調整ライフサイクル内のポイントです。マシンの Deleting フェーズでは、これらの中断により、コンポーネントがマシンの削除プロセスを変更する機会が提供されます。

5.2.1. 用語と定義

マシンの削除フェーズのライフサイクルフックの動作を理解するには、次の概念を理解する必要があります。

調整

調整は、コントローラーがクラスターの実際の状態とクラスターを設定するオブジェクトをオブジェクト仕様の要件と一致させようとするプロセスです。

マシンコントローラー

マシンコントローラーは、マシンの調整ライフサイクルを管理します。クラウドプラットフォーム上のマシンの場合、マシンコントローラーは OpenShift Container Platform コントローラーとクラウドプロバイダーのプラットフォーム固有のアクチュエーターを組み合わせたものです。

マシンの削除のコンテキストでは、マシンコントローラーは次のアクションを実行します。

マシンによってバックアップされているノードをドレインします。
クラウドプロバイダーからマシンインスタンスを削除します。
Node オブジェクトを削除します。

ライフサイクルフック

ライフサイクルフックは、通常のライフサイクルプロセスを中断できる、オブジェクトの調整ライフサイクル内の定義されたポイントです。コンポーネントはライフサイクルフックを使用してプロセスに変更を注入し、望ましい結果を達成できます。

マシンの Deleting フェーズには 2 つのライフサイクルフックがあります。

preDrain ライフサイクルフックは、マシンによってサポートされているノードをドレインする前に解決する必要があります。
preTerminate ライフサイクルフックは、インスタンスをインフラストラクチャープロバイダーから削除する前に解決する必要があります。

フック実装コントローラー

フック実装コントローラーは、ライフサイクルフックと対話できる、マシンコントローラー以外のコントローラーです。フック実装コントローラーは、次の 1 つ以上のアクションを実行できます。

ライフサイクルフックを追加します。
ライフサイクルフックに応答します。
ライフサイクルフックを削除します。

各ライフサイクルフックには 1 つのフック実装コントローラーがありますが、フック実装コントローラーは 1 つ以上のフックを管理できます。

5.2.2. マシン削除処理順序

OpenShift Container Platform 4.12 には、マシン削除フェーズ用の 2 つのライフサイクルフック (preDrain と preTerminate) があります。特定のライフサイクルポイントのすべてのフックが削除されると、調整は通常どおり続行されます。

図5.1 マシン削除のフロー

マシンの Deleting フェーズは次の順序で続行されます。

既存のマシンは、次のいずれかの理由により削除される予定です。
- cluster-admin 権限を持つユーザーは、oc delete machine コマンドを使用します。
- マシンは machine.openshift.io/delete-machine アノテーションを取得します。
- マシンを管理するマシンセットは、調整の一環としてレプリカ数を減らすために、そのマシンに削除のマークを付けます。
- クラスターオートスケーラーは、クラスターのデプロイメントニーズを満たすために不必要なノードを特定します。
- マシンの健全性チェックは、異常なマシンを置き換えるように設定されています。
マシンは Deleting フェーズに入ります。このフェーズでは、マシンは削除対象としてマークされていますが、API にはまだ存在しています。
preDrain ライフサイクルフックが存在する場合、それを管理するフック実装コントローラーは指定されたアクションを実行します。
すべての preDrain ライフサイクルフックが満たされるまで、マシンのステータス条件 Drainable は False に設定されます。
未解決の preDrain ライフサイクルフックはなく、マシンのステータス条件 Drainable が True に設定されています。
マシンコントローラーは、マシンによってサポートされているノードをドレインしようとします。
- ドレインが失敗した場合、Drained は、False に設定され、マシンコントローラーはノードのドレインを再度試行します。
- ドレインに成功すると、Drained は True に設定されます。
マシンのステータス条件 Drained は True に設定されます。
preTerminate ライフサイクルフックが存在する場合、それを管理するフック実装コントローラーは指定されたアクションを実行します。
すべての preTerminate ライフサイクルフックが満たされるまで、マシンのステータス条件 Terminable は False に設定されます。
未解決の preTerminate ライフサイクルフックはなく、マシンのステータス条件 Terminable が True に設定されています。
マシンコントローラーは、インフラストラクチャープロバイダーからインスタンスを削除します。
マシンコントローラーは Node オブジェクトを削除します。

5.2.3. 削除ライフサイクルフック設定

次の YAML スニペットは、マシンセット内の削除ライフサイクルフック設定の形式と配置を示しています。

preDrain ライフサイクルフックを示す YAML スニペット

apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
spec:
  lifecycleHooks:
    preDrain:
    - name: <hook_name> 1
      owner: <hook_owner> 2
  ...

1: preDrain ライフサイクルフックの名前。
2: preDrain ライフサイクルフックを管理するフック実装コントローラー。

preTerminate ライフサイクルフックを示す YAML スニペット

apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
spec:
  lifecycleHooks:
    preTerminate:
    - name: <hook_name> 1
      owner: <hook_owner> 2
  ...

1: preTerminate ライフサイクルフックの名前。
2: preTerminate ライフサイクルフックを管理するフック実装コントローラー。

ライフサイクルフックの設定例

次の例は、マシンの削除プロセスを中断する複数の架空のライフサイクルフックの実装を示しています。

ライフサイクルフックの設定例

apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
spec:
  lifecycleHooks:
    preDrain: 1
    - name: MigrateImportantApp
      owner: my-app-migration-controller
    preTerminate: 2
    - name: BackupFileSystem
      owner: my-backup-controller
    - name: CloudProviderSpecialCase
      owner: my-custom-storage-detach-controller 3
    - name: WaitForStorageDetach
      owner: my-custom-storage-detach-controller
  ...

1: 単一のライフサイクルフックを含む preDrain ライフサイクルフックスタンザ。
2: 3 つのライフサイクルフックを含む preTerminate ライフサイクルフックスタンザ。
3: 2 つの preTerminate ライフサイクルフック CloudProviderSpecialCase と WaitForStorageDetach を管理するフック実装コントローラー。

5.2.4. Operator 開発者向けのマシン削除ライフサイクルフックの例

Operator は、マシン削除フェーズのライフサイクルフックを使用して、マシン削除プロセスを変更できます。次の例は、Operator がこの機能を使用できる方法を示しています。

`preDrain` ライフサイクルフックの使用例

積極的にマシンを入れ替える

Operator は、削除されたマシンのインスタンスを削除する前に、preDrain ライフサイクルフックを使用して、代替マシンが正常に作成され、クラスターに参加していることを確認できます。これにより、マシンの交換中の中断や、すぐに初期化されない交換用インスタンスの影響を軽減できます。

カスタムドレインロジックの実装

Operator は、preDrain ライフサイクルフックを使用して、マシンコントローラーのドレインロジックを別のドレインコントローラーに置き換えることができます。ドレインロジックを置き換えることにより、Operator は各ノードのワークロードのライフサイクルをより柔軟に制御できるようになります。

たとえば、マシンコントローラーのドレインライブラリーは順序付けをサポートしていませんが、カスタムドレインプロバイダーはこの機能を提供できます。カスタムドレインプロバイダーを使用することで、Operator はノードをドレインする前にミッションクリティカルなアプリケーションの移動を優先して、クラスターの容量が制限されている場合にサービスの中断を最小限に抑えることができます。

`preTerminate` ライフサイクルフックの使用例

ストレージの切り離しを確認する

Operator は、preTerminate ライフサイクルフックを使用して、マシンがインフラストラクチャープロバイダーから削除される前に、マシンに接続されているストレージが確実に切り離されるようにすることができます。

ログの信頼性の向上

ノードがドレインされた後、ログエクスポータデーモンがログを集中ログシステムに同期するのに時間がかかります。

ロギング Operator は、preTerminate ライフサイクルフックを使用して、ノードがドレインするときと、マシンがインフラストラクチャープロバイダーから削除されるときとの間に遅延を追加できます。この遅延により、Operator は主要なワークロードが削除され、ログバックログに追加されないようにする時間が確保されます。ログバックログに新しいデータが追加されていない場合、ログエクスポータは同期プロセスに追いつくことができるため、すべてのアプリケーションログが確実にキャプチャーされます。

5.2.5. マシンライフサイクルフックによるクォーラム保護

Machine API Operator を使用する OpenShift Container Platform クラスターの場合、etcd Operator はマシン削除フェーズのライフサイクルフックを使用して、クォーラム保護メカニズムを実装します。

preDrain ライフサイクルフックを使用することにより、etcd Operator は、コントロールプレーンマシン上の Pod がいつドレインされ、削除されるかを制御できます。etcd クォーラムを保護するために、etcd Operator は、etcd メンバーをクラスター内の新しいノードに移行するまで、そのメンバーの削除を防ぎます。

このメカニズムにより、etcd Operator は etcd クォーラムのメンバーを正確に制御できるようになり、マシン API Operator は etcd クラスターの特別な操作知識がなくても、コントロールプレーンマシンを安全に作成および削除できるようになります。

5.2.5.1. クォーラム保護処理順序によるコントロールプレーンの削除

コントロールプレーンマシンセットを使用するクラスター上でコントロールプレーンマシンが置き換えられると、クラスターには一時的に 4 つのコントロールプレーンマシンが存在します。4 番目のコントロールプレーンノードがクラスターに参加すると、etcd Operator は代替ノードで新しい etcd メンバーを開始します。etcd Operator は、古いコントロールプレーンマシンが削除対象としてマークされていることを確認すると、古いノード上の etcd メンバーを停止し、代替の etcd メンバーをクラスターのクォーラムに参加するように昇格させます。

コントロールプレーンマシンの Deleting フェーズは、以下の順序で続行されます。

コントロールプレーンマシンは削除される予定です。
コントロールプレーンマシンは Deleting フェーズに入ります。
preDrain ライフサイクルフックを満たすために、etcd Operator は次のアクションを実行します。
1. etcd Operator は、4 番目のコントロールプレーンマシンが etcd メンバーとしてクラスターに追加されるまで待機します。この新しい etcd メンバーの状態は Running ですが、etcd リーダーから完全なデータベース更新を受信するまでは ready ができていません。
2. 新しい etcd メンバーが完全なデータベース更新を受け取ると、etcd Operator は新しい etcd メンバーを投票メンバーに昇格させ、古い etcd メンバーをクラスターから削除します。
この移行が完了すると、古い etcd Pod とそのデータは安全に削除されるため、preDrain ライフサイクルフックが削除されます。
コントロールプレーンマシンのステータス条件 Drainable が True に設定されます。
マシンコントローラーは、コントロールプレーンマシンによってサポートされているノードをドレインしようとします。
- ドレインが失敗した場合、Drained は、False に設定され、マシンコントローラーはノードのドレインを再度試行します。
- ドレインに成功すると、Drained は True に設定されます。
コントロールプレーンマシンのステータス条件 Drained が True に設定されます。
他の Operator が preTerminate ライフサイクルフックを追加していない場合、コントロールプレーンのマシンステータス条件 Terminable は True に設定されます。
マシンコントローラーは、インフラストラクチャープロバイダーからインスタンスを削除します。
マシンコントローラーは Node オブジェクトを削除します。

etcd クォーラム保護の preDrain ライフサイクルフックを示す YAML スニペット

apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
spec:
  lifecycleHooks:
    preDrain:
    - name: EtcdQuorumOperator 1
      owner: clusteroperator/etcd 2
  ...

1: preDrain ライフサイクルフックの名前。
2: preDrain ライフサイクルフックを管理するフック実装コントローラー。

5.3. 関連情報

第6章 OpenShift Container Platform クラスターへの自動スケーリングの適用

自動スケーリングの OpenShift Container Platform クラスターへの適用には、クラスターへの Cluster Autoscaler のデプロイと各マシンタイプの Machine Autoscaler のデプロイが必要です。

重要

Cluster Autoscaler は、マシン API が機能しているクラスターでのみ設定できます。

6.1. Cluster Autoscaler について

Cluster Autoscaler は、現行のデプロイメントのニーズに合わせて OpenShift Container Platform クラスターのサイズを調整します。これは、Kubernetes 形式の宣言引数を使用して、特定のクラウドプロバイダーのオブジェクトに依存しないインフラストラクチャー管理を提供します。Cluster Autoscaler には cluster スコープがあり、特定の namespace には関連付けられていません。

Cluster Autoscaler は、リソース不足のために現在のワーカーノードのいずれにもスケジュールできない Pod がある場合や、デプロイメントのニーズを満たすために別のノードが必要な場合に、クラスターのサイズを拡大します。Cluster Autoscaler は、指定される制限を超えてクラスターリソースを拡大することはありません。

Cluster Autoscaler は、コントロールプレーンノードを管理しない場合でも、クラスター内のすべてのノードのメモリー、CPU、および GPU の合計を計算します。これらの値は、単一マシン指向ではありません。これらは、クラスター全体での全リソースの集約です。たとえば、最大メモリーリソースの制限を設定する場合、Cluster Autoscaler は現在のメモリー使用量を計算する際にクラスター内のすべてのノードを含めます。この計算は、Cluster Autoscaler にワーカーリソースを追加する容量があるかどうかを判別するために使用されます。

重要

作成する ClusterAutoscaler リソース定義の maxNodesTotal 値が、クラスター内のマシンの想定される合計数に対応するのに十分な大きさの値であることを確認します。この値は、コントロールプレーンマシンの数とスケーリングする可能性のあるコンピュートマシンの数に対応できる値である必要があります。

Cluster Autoscaler は 10 秒ごとに、クラスターで不要なノードをチェックし、それらを削除します。Cluster Autoscaler は、以下の条件が適用される場合に、ノードを削除すべきと考えます。

ノードの使用率はクラスターの ノード使用率レベル のしきい値よりも低くなります。ノード使用率レベルとは、要求されたリソースの合計をノードに割り当てられたリソースで除算したものです。ClusterAutoscaler カスタムリソースで値を指定しない場合、Cluster Autoscaler は 50% の使用率に対応するデフォルト値 0.5 を使用します。
Cluster Autoscaler がノードで実行されているすべての Pod を他のノードに移動できる。Kubernetes スケジューラーは、ノード上の Pod のスケジュールを担当します。
Cluster Autoscaler で、スケールダウンが無効にされたアノテーションがない。

以下のタイプの Pod がノードにある場合、Cluster Autoscaler はそのノードを削除しません。

制限のある Pod の Disruption Budget (停止状態の予算、PDB) を持つ Pod。
デフォルトでノードで実行されない Kube システム Pod。
PDB を持たないか、または制限が厳しい PDB を持つ Kuber システム Pod。
デプロイメント、レプリカセット、またはステートフルセットなどのコントローラーオブジェクトによってサポートされない Pod。
ローカルストレージを持つ Pod。
リソース不足、互換性のないノードセレクターまたはアフィニティー、一致する非アフィニティーなどにより他の場所に移動できない Pod。
それらに "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" アノテーションがない場合、"cluster-autoscaler.kubernetes.io/safe-to-evict": "false" アノテーションを持つ Pod。

たとえば、CPU の上限を 64 コアに設定し、それぞれ 8 コアを持つマシンのみを作成するように Cluster Autoscaler を設定したとします。クラスターが 30 コアで起動する場合、Cluster Autoscaler は最大で 4 つのノード (合計 32 コア) を追加できます。この場合、総計は 62 コアになります。

Cluster Autoscaler を設定する場合、使用に関する追加の制限が適用されます。

自動スケーリングされたノードグループにあるノードを直接変更しない。同じノードグループ内のすべてのノードには同じ容量およびラベルがあり、同じシステム Pod を実行します。
Pod の要求を指定します。
Pod がすぐに削除されるのを防ぐ必要がある場合、適切な PDB を設定します。
クラウドプロバイダーのクォータが、設定する最大のノードプールに対応できる十分な大きさであることを確認します。
クラウドプロバイダーで提供されるものなどの、追加のノードグループの Autoscaler を実行しない。

Horizontal Pod Autoscaler (HPA) および Cluster Autoscaler は複数の異なる方法でクラスターリソースを変更します。HPA は、現在の CPU 負荷に基づいてデプロイメント、またはレプリカセットのレプリカ数を変更します。負荷が増大すると、HPA はクラスターで利用できるリソース量に関係なく、新規レプリカを作成します。十分なリソースがない場合、Cluster Autoscaler はリソースを追加し、HPA で作成された Pod が実行できるようにします。負荷が減少する場合、HPA は一部のレプリカを停止します。この動作によって一部のノードの使用率が低くなるか、または完全に空になる場合、Cluster Autoscaler は不必要なノードを削除します。

Cluster Autoscaler は Pod の優先順位を考慮に入れます。Pod の優先順位とプリエンプション機能により、クラスターに十分なリソースがない場合に優先順位に基づいて Pod のスケジューリングを有効にできますが、Cluster Autoscaler はクラスターがすべての Pod を実行するのに必要なリソースを確保できます。これら両方の機能の意図を反映するべく、Cluster Autoscaler には優先順位のカットオフ機能が含まれています。このカットオフを使用して Best Effort の Pod をスケジュールできますが、これにより Cluster Autoscaler がリソースを増やすことはなく、余分なリソースがある場合にのみ実行されます。

カットオフ値よりも低い優先順位を持つ Pod は、クラスターをスケールアップせず、クラスターのスケールダウンを防ぐこともありません。これらの Pod を実行するために新規ノードは追加されず、これらの Pod を実行しているノードはリソースを解放するために削除される可能性があります。

クラスターの自動スケーリングは、マシン API が利用可能なプラットフォームでサポートされています。

6.2. Cluster Autoscaler の設定

まず Cluster Autoscaler をデプロイし、リソースの自動スケーリングを OpenShift Container Platform クラスターで管理します。

注記

Cluster Autoscaler のスコープはクラスター全体に設定されるため、クラスター用に 1 つの Cluster Autoscaler のみを作成できます。

6.2.1. ClusterAutoscaler リソース定義

この ClusterAutoscaler リソース定義は、Cluster Autoscaler のパラメーターおよびサンプル値を表示します。

apiVersion: "autoscaling.openshift.io/v1"
kind: "ClusterAutoscaler"
metadata:
  name: "default"
spec:
  podPriorityThreshold: -10 1
  resourceLimits:
    maxNodesTotal: 24 2
    cores:
      min: 8 3
      max: 128 4
    memory:
      min: 4 5
      max: 256 6
    gpus:
      - type: nvidia.com/gpu 7
        min: 0 8
        max: 16 9
      - type: amd.com/gpu
        min: 0
        max: 4
  logVerbosity: 4 10
  scaleDown: 11
    enabled: true 12
    delayAfterAdd: 10m 13
    delayAfterDelete: 5m 14
    delayAfterFailure: 30s 15
    unneededTime: 5m 16
    utilizationThreshold: "0.4" 17

1

Cluster Autoscaler に追加のノードをデプロイさせるために Pod が超えている必要のある優先順位を指定します。32 ビットの整数値を入力します。podPriorityThreshold 値は、各 Pod に割り当てる PriorityClass の値と比較されます。

2

デプロイするノードの最大数を指定します。この値は、Autoscaler が制御するマシンだけでなく、クラスターにデプロイされるマシンの合計数です。この値は、すべてのコントロールプレーンおよびコンピュートマシン、および MachineAutoscaler リソースに指定するレプリカの合計数に対応するのに十分な大きさの値であることを確認します。

クラスターにデプロイするコアの最小数を指定します。

クラスターにデプロイするコアの最大数を指定します。

クラスターのメモリーの最小量 (GiB 単位) を指定します。

クラスターのメモリーの最大量 (GiB 単位) を指定します。

7

オプション: デプロイする GPU ノードのタイプを指定します。nvidia.com/gpu および amd.com/gpu のみが有効なタイプです。

8

クラスターにデプロイする GPU の最小数を指定します。

9

クラスターにデプロイする GPU の最大数を指定します。

ロギングの詳細レベルを 0 から 10 の間で指定します。次のログレベルのしきい値は、ガイダンスとして提供されています。

1: (デフォルト) 変更に関する基本情報。
4: 一般的な問題をトラブルシューティングするためのデバッグレベルの詳細度。
9: 広範なプロトコルレベルのデバッグ情報。

値を指定しない場合は、デフォルト値の 1 が使用されます。

このセクションでは、有効な ParseDuration 期間 ( ns、us、ms、s、m、および h を含む) を使用して各アクションについて待機する期間を指定できます。

Cluster Autoscaler が不必要なノードを削除できるかどうかを指定します。

オプション: ノードが最後に追加されてからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 10m が使用されます。

オプション: ノードが最後に削除されてからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 0s が使用されます。

オプション: スケールダウンが失敗してからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 3m が使用されます。

オプション: 不要なノードが削除の対象となるまでの期間を指定します。値を指定しない場合は、デフォルト値の 10m が使用されます。<17> オプション: 不要なノードが削除の対象となる ノード使用率レベル を指定します。ノード使用率は、要求されたリソースをそのノードに割り当てられたリソースで割ったもので、"0" より大きく "1" より小さい値でなければなりません。値を指定しない場合、Cluster Autoscaler は 50% の使用率に対応するデフォルト値 "0.5" を使用します。この値は文字列として表現する必要があります。

注記

スケーリング操作の実行時に、Cluster Autoscaler は、デプロイするコアの最小および最大数、またはクラスター内のメモリー量などの ClusterAutoscaler リソース定義に設定された範囲内に残ります。ただし、Cluster Autoscaler はそれらの範囲内に留まるようクラスターの現在の値を修正しません。

Cluster Autoscaler がノードを管理しない場合でも、最小および最大の CPU、メモリー、および GPU の値は、クラスター内のすべてのノードのこれらのリソースを計算することによって決定されます。たとえば、Cluster Autoscaler がコントロールプレーンノードを管理しない場合でも、コントロールプレーンノードはクラスターのメモリーの合計に考慮されます。

6.2.2. Cluster Autoscaler のデプロイ

Cluster Autoscaler をデプロイするには、ClusterAutoscaler リソースのインスタンスを作成します。

手順

カスタマイズされたリソース定義を含む ClusterAutoscaler リソースの YAML ファイルを作成します。
クラスターにリソースを作成します。
```
$ oc create -f <filename>.yaml 1
```
1
<filename> は、カスタマイズしたリソースファイルの名前です。

6.3. 次のステップ

Cluster Autoscaler の設定後に、1 つ以上の Machine Autoscaler を設定する必要があります。

6.4. Machine Autoscaler について

Machine Autoscaler は、OpenShift Container Platform クラスターにデプロイするマシンセットのコンピュートマシン数を調整します。デフォルトの worker コンピュートマシンセットおよび作成する他のコンピュートマシンセットの両方をスケーリングできます。Machine Autoscaler は、追加のデプロイメントをサポートするのに十分なリソースがクラスターにない場合に追加のマシンを作成します。MachineAutoscaler リソースの値への変更 (例: インスタンスの最小または最大数) は、それらがターゲットとするコンピュートマシンセットに即時に適用されます。

重要

マシンをスケーリングするには、Cluster Autoscaler の Machine Autoscaler をデプロイする必要があります。Cluster Autoscaler は、スケーリングできるリソースを判別するために、Machine Autoscaler が設定するアノテーションをコンピュートマシンセットで使用します。Machine Autoscaler を定義せずにクラスター Autoscaler を定義する場合、クラスター Autoscaler はクラスターをスケーリングできません。

6.5. Machine Autoscaler の設定

Cluster Autoscaler の設定後に、クラスターのスケーリングに使用されるコンピュートマシンセットを参照する MachineAutoscaler リソースをデプロイします。

重要

ClusterAutoscaler リソースのデプロイ後に、1 つ以上の MachineAutoscaler リソースをデプロイする必要があります。

注記

各コンピュートマシンセットに対して別々のリソースを設定する必要があります。コンピュートマシンセットはそれぞれのリージョンごとに異なるため、複数のリージョンでマシンのスケーリングを有効にする必要があるかどうかを考慮してください。スケーリングするコンピュートマシンセットには 1 つ以上のマシンが必要です。

6.5.1. MachineAutoscaler リソース定義

この MachineAutoscaler リソース定義は、Machine Autoscaler のパラメーターおよびサンプル値を表示します。

apiVersion: "autoscaling.openshift.io/v1beta1"
kind: "MachineAutoscaler"
metadata:
  name: "worker-us-east-1a" 1
  namespace: "openshift-machine-api"
spec:
  minReplicas: 1 2
  maxReplicas: 12 3
  scaleTargetRef: 4
    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet 5
    name: worker-us-east-1a 6

1: Machine Autoscaler の名前を指定します。この Machine Autoscaler がスケーリングするコンピュートマシンセットを簡単に特定できるようにするには、スケーリングするコンピュートマシンセットの名前を指定するか、またはこれを組み込みます。コンピュートマシンセットの名前は、<clusterid>-<machineset>-<region> の形式を使用します。
2: Cluster Autoscaler がクラスターのスケーリングを開始した後に、指定されたゾーンに残っている必要のある指定されたタイプのマシンの最小数を指定します。AWS、GCP、Azure、RHOSP または vSphere で実行している場合は、この値は 0 に設定できます。他のプロバイダーの場合は、この値は 0 に設定しないでください。
特殊なワークロードに使用されるコストがかかり、用途が限られたハードウェアを稼働する場合などのユースケースにはこの値を 0 に設定するか、若干大きいマシンを使用してコンピュートマシンセットをスケーリングすることで、コストを節約できます。Cluster Autoscaler は、マシンが使用されていない場合にコンピュートマシンセットをゼロにスケールダウンします。
重要
インストーラーでプロビジョニングされるインフラストラクチャーの OpenShift Container Platform インストールプロセス時に作成される 3 つのコンピュートマシンセットについては、spec.minReplicas の値を 0 に設定しないでください。
3: Cluster Autoscaler がクラスタースケーリングの開始後に指定されたゾーンにデプロイできる指定されたタイプのマシンの最大数を指定します。ClusterAutoscaler リソース定義の maxNodesTotal 値が、Machine AutoScaler がこの数のマシンをデプロイするのに十分な大きさの値であることを確認します。
4: このセクションでは、スケーリングする既存のコンピュートマシンセットを記述する値を指定します。
5: kind パラメーターの値は常に MachineSet です。
6: name の値は、metadata.name パラメーター値に示されるように既存のコンピュートマシンセットの名前に一致する必要があります。

6.5.2. Machine Autoscaler のデプロイ

Machine Autoscaler をデプロイするには、 MachineAutoscaler リソースのインスタンスを作成します。

手順

カスタマイズされたリソース定義を含む MachineAutoscaler リソースの YAML ファイルを作成します。
クラスターにリソースを作成します。
```
$ oc create -f <filename>.yaml 1
```
1
<filename> は、カスタマイズしたリソースファイルの名前です。

6.6. 関連情報

Pod の優先順位についての詳細は、OpenShift Container Platform の Including pod priority in pod scheduling decisions を参照してください。

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

重要

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

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

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

実稼働デプロイメントでは、インフラストラクチャーコンポーネントを保持するために 3 つ以上のマシンセットをデプロイすることが推奨されます。OpenShift Logging と Red Hat OpenShift Service Mesh の両方が Elasticsearch をデプロイします。これには、3 つのインスタンスを異なるノードにインストールする必要があります。これらの各ノードは、高可用性のために異なるアベイラビリティーゾーンにデプロイできます。この設定には、可用性ゾーンごとに 1 つずつ、合計 3 つの異なるマシンセットが必要です。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。

7.1. OpenShift Container Platform インフラストラクチャーコンポーネント

以下のインフラストラクチャーワークロードでは、OpenShift Container Platform ワーカーのサブスクリプションは不要です。

マスターで実行される Kubernetes および OpenShift Container Platform コントロールプレーンサービス
デフォルトルーター
統合コンテナーイメージレジストリー
HAProxy ベースの Ingress Controller
ユーザー定義プロジェクトのモニタリング用のコンポーネントを含む、クラスターメトリクスの収集またはモニタリングサービス
クラスター集計ロギング
サービスブローカー
Red Hat Quay
Red Hat OpenShift Data Foundation
Red Hat Advanced Cluster Manager
Kubernetes 用 Red Hat Advanced Cluster Security
Red Hat OpenShift GitOps
Red Hat OpenShift Pipelines

他のコンテナー、Pod またはコンポーネントを実行するノードは、サブスクリプションが適用される必要のあるワーカーノードです。

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

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

7.2. 実稼働環境用のインフラストラクチャーマシンセットの作成

実稼働デプロイメントでは、インフラストラクチャーコンポーネントを保持するために 3 つ以上のコンピュートマシンセットをデプロイすることが推奨されます。OpenShift Logging と Red Hat OpenShift Service Mesh の両方が Elasticsearch をデプロイします。これには、3 つのインスタンスを異なるノードにインストールする必要があります。これらの各ノードは、高可用性のために異なるアベイラビリティーゾーンにデプロイできます。このような設定では、各アベイラビリティーゾーンに 1 つずつ、3 つの異なるコンピュートマシンセットが必要です。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。

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

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

7.2.1.1. Alibaba Cloud のコンピューティングマシンセットカスタムリソースのサンプル YAML

このサンプル YAML は、リージョン内の指定された Alibaba 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> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 3
  name: <infrastructure_id>-<infra>-<zone> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 10
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          credentialsSecret:
            name: alibabacloud-credentials
          imageId: <image_id> 11
          instanceType: <instance_type> 12
          kind: AlibabaCloudMachineProviderConfig
          ramRoleName: <infrastructure_id>-role-worker 13
          regionId: <region> 14
          resourceGroup: 15
            id: <resource_group_id>
            type: ID
          securityGroups:
          - tags: 16
            - Key: Name
              Value: <infrastructure_id>-sg-<role>
            type: Tags
          systemDisk: 17
            category: cloud_essd
            size: <disk_size>
          tag: 18
          - Key: kubernetes.io/cluster/<infrastructure_id>
            Value: owned
          userDataSecret:
            name: <user_data_secret> 19
          vSwitch:
            tags: 20
            - Key: Name
              Value: <infrastructure_id>-vswitch-<zone>
            type: Tags
          vpcId: ""
          zoneId: <zone> 21
      taints: 22
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

1 5 7

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

2 3 8 9

<infra> ノードラベルを指定します。

4 6 10

インフラストラクチャー ID、<infra> ノードラベル、およびゾーンを指定します。

使用するイメージを指定します。クラスターに設定されている既存のコンピュートデフォルトマシンのイメージを使用します。

コンピュートマシンセットに使用するインスタンスタイプを指定します。

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

16 18 20

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

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

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

Alibaba Cloud 使用統計のマシンセットパラメーター

次の YAML スニペットは、デフォルトのコンピュートマシンセットのどのタグがオプションでどれが必須かを示しています。

spec.template.spec.providerSpec.value.securityGroups のタグ

spec:
  template:
    spec:
      providerSpec:
        value:
          securityGroups:
          - tags:
            - Key: kubernetes.io/cluster/<infrastructure_id> 1
              Value: owned
            - Key: GISV
              Value: ocp
            - Key: sigs.k8s.io/cloud-provider-alibaba/origin 2
              Value: ocp
            - Key: Name
              Value: <infrastructure_id>-sg-<role> 3
            type: Tags

1 2

オプション: このタグは、コンピュートマシンセットで指定されていない場合でも適用されます。

必須。

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

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

spec.template.spec.providerSpec.value.tag のタグ

spec:
  template:
    spec:
      providerSpec:
        value:
          tag:
          - Key: kubernetes.io/cluster/<infrastructure_id> 1
            Value: owned
          - Key: GISV 2
            Value: ocp
          - Key: sigs.k8s.io/cloud-provider-alibaba/origin 3
            Value: ocp

2 3: オプション: このタグは、コンピュートマシンセットで指定されていない場合でも適用されます。
1: 必須。
<infrastructure_id> は、クラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID です。

spec.template.spec.providerSpec.value.vSwitch のタグ

spec:
  template:
    spec:
      providerSpec:
        value:
          vSwitch:
            tags:
            - Key: kubernetes.io/cluster/<infrastructure_id> 1
              Value: owned
            - Key: GISV 2
              Value: ocp
            - Key: sigs.k8s.io/cloud-provider-alibaba/origin 3
              Value: ocp
            - Key: Name
              Value: <infrastructure_id>-vswitch-<zone> 4
            type: Tags

1 2 3

オプション: このタグは、コンピュートマシンセットで指定されていない場合でも適用されます。

必須。

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

<infrastructure_id> は、クラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID です。
<zone> は、マシンを配置するリージョン内のゾーンです。

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

このサンプル YAML は us-east-1a Amazon Web Services (AWS) ゾーンで実行され、node-role.kubernetes.io/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> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone> 4
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: infra 6
        machine.openshift.io/cluster-api-machine-type: infra 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone> 8
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: "" 9
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 10
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile 11
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone> 12
            region: <region> 13
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-worker-sg 14
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructure_id>-private-<zone> 15
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id> 16
              value: owned
            - name: <custom_tag_name> 17
              value: <custom_tag_value> 18
          userDataSecret:
            name: worker-user-data
      taints: 19
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule

1 3 5 11 14 16

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

2 4 8

インフラストラクチャー ID、infra ロールノードラベル、およびゾーンを指定します。

6 7 9

infra ロールノードラベルを指定します。

$ oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \
    get machineset/<infrastructure_id>-<role>-<zone>

17 18

注記

ゾーン (例: us-east-1a) を指定します。

リージョン (例: us-east-1) を指定します。

インフラストラクチャー ID とゾーンを指定します。

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

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

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

このサンプル YAML は、リージョンの 1 Microsoft Azure ゾーンで実行され、node-role.kubernetes.io/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> 3
  name: <infrastructure_id>-infra-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          machine.openshift.io/cluster-api-machineset: <machineset_name> 11
          node-role.kubernetes.io/infra: "" 12
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image: 13
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> 14
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> 15
          managedIdentity: <infrastructure_id>-identity 16
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg 17
          sshPrivateKey: ""
          sshPublicKey: ""
          tags:
            - name: <custom_tag_name> 18
              value: <custom_tag_value> 19
          subnet: <infrastructure_id>-<role>-subnet 20 21
          userDataSecret:
            name: worker-user-data 22
          vmSize: Standard_D4s_v3
          vnet: <infrastructure_id>-vnet 23
          zone: "1" 24
      taints: 25
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

1 5 7 16 17 20 23

$ 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 3 8 9 12 21 22

<infra> ノードラベルを指定します。

4 6 10

インフラストラクチャー ID、<infra> ノードラベル、およびリージョンを指定します。

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

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

18 19

25

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

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

関連情報

Azure Marketplace イメージの選択

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

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> 3
  name: <infrastructure_id>-infra-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: "" 11
      taints: 12
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          availabilitySet: <availability_set> 13
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> 14
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> 15
          managedIdentity: <infrastructure_id>-identity 16
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg 17
          sshPrivateKey: ""
          sshPublicKey: ""
          subnet: <infrastructure_id>-<role>-subnet 18 19
          userDataSecret:
            name: worker-user-data 20
          vmSize: Standard_DS4_v2
          vnet: <infrastructure_id>-vnet 21
          zone: "1" 22

1 5 7 14 16 17 18 21

$ 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 3 8 9 11 19 20

<infra> ノードラベルを指定します。

4 6 10

インフラストラクチャー ID、<infra> ノードラベル、およびリージョンを指定します。

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

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

クラスターの可用性セットを指定します。

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

注記

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

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

このサンプル YAML は、リージョン内の指定された IBM Cloud ゾーンで実行され、node-role.kubernetes.io/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> 3
  name: <infrastructure_id>-<infra>-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region> 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region> 10
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: ibmcloudproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: ibmcloud-credentials
          image: <infrastructure_id>-rhcos 11
          kind: IBMCloudMachineProviderSpec
          primaryNetworkInterface:
              securityGroups:
              - <infrastructure_id>-sg-cluster-wide
              - <infrastructure_id>-sg-openshift-net
              subnet: <infrastructure_id>-subnet-compute-<zone> 12
          profile: <instance_profile> 13
          region: <region> 14
          resourceGroup: <resource_group> 15
          userDataSecret:
              name: <role>-user-data 16
          vpc: <vpc_name> 17
          zone: <zone> 18
        taints: 19
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule

1 5 7

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

2 3 8 9 16

<infra>ノードラベル。

4 6 10

インフラストラクチャー ID、 <infra>ノードラベル、およびリージョン。

クラスターのインストールに使用されたカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。

マシンを配置するためのリージョン内のインフラストラクチャー ID とゾーン。リージョンがゾーンをサポートすることを確認してください。

IBM Cloud インスタンスプロファイルを指定します。

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

VPC 名。

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

ユーザーのワークロードがインフラノードでスケジュールされないようにするための汚染。

注記

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  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> 2
        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: gcpprovider.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <path_to_image> 3
            labels: null
            sizeGb: 128
            type: pd-ssd
          gcpMetadata: 4
          - 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> 5
          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: 6
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

1

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

2

<infra> には、<infra> ノードラベルを指定します。

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

GCP Marketplace イメージを使用するには、使用するオファーを指定します。

OpenShift Container Platform: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145
OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145
OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145

<project_name> には、クラスターに使用する GCP プロジェクトの名前を指定します。

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

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

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

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

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> 3
  name: <infrastructure_id>-<infra>-<zone> 4
  namespace: openshift-machine-api
  annotations: 5
    machine.openshift.io/memoryMb: "16384"
    machine.openshift.io/vCPU: "4"
spec:
  replicas: 3
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 6
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 7
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 8
        machine.openshift.io/cluster-api-machine-role: <infra> 9
        machine.openshift.io/cluster-api-machine-type: <infra> 10
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 11
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          cluster:
            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-creds-secret
          image:
            name: <infrastructure_id>-rhcos 12
            type: name
          kind: NutanixMachineProviderConfig
          memorySize: 16Gi 13
          subnets:
          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi 14
          userDataSecret:
            name: <user_data_secret> 15
          vcpuSockets: 4 16
          vcpusPerSocket: 1 17
      taints: 18
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

1 6 8

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

2 3 9 10

<infra> ノードラベルを指定します。

4 7 11

インフラストラクチャー ID、<infra> ノードラベル、およびゾーンを指定します。

クラスターオートスケーラーのアノテーション。

使用するイメージを指定します。クラスターに設定されている既存のコンピュートデフォルトマシンのイメージを使用します。

クラスターのメモリー量を Gi で指定します。

システムディスクのサイズを Gi で指定します。

vCPU ソケットの数を指定します。

ソケットあたりの vCPU の数を指定します。

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

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

このサンプル YAML は、Red Hat OpenStack Platform (RHOSP) で実行され、node-role.kubernetes.io/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> 3
  name: <infrastructure_id>-infra 4
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas>
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
      taints: 11
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: openstackproviderconfig.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> 12
          kind: OpenstackProviderSpec
          networks: 13
          - filter: {}
            subnets:
            - filter:
                name: <subnet_name>
                tags: openshiftClusterID=<infrastructure_id> 14
          primarySubnet: <rhosp_subnet_UUID> 15
          securityGroups:
          - filter: {}
            name: <infrastructure_id>-worker 16
          serverMetadata:
            Name: <infrastructure_id>-worker 17
            openshiftClusterID: <infrastructure_id> 18
          tags:
          - openshiftClusterID=<infrastructure_id> 19
          trunk: true
          userDataSecret:
            name: worker-user-data 20
          availabilityZone: <optional_openstack_availability_zone>

1 5 7 14 16 17 18 19

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

2 3 8 9 20

<infra> ノードラベルを指定します。

4 6 10

インフラストラクチャー ID および <infra> ノードラベルを指定します。

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

複数ネットワークへのデプロイメントに必要です。複数ネットワークにデプロイする場合、この一覧には、primarySubnet が の値として使用されるネットワークが含まれる必要があります。

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

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: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role> 4
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas> 5
  Selector: 6
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 8
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 9
        machine.openshift.io/cluster-api-machine-role: <role> 10
        machine.openshift.io/cluster-api-machine-type: <role> 11
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 12
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 13
      providerSpec:
        value:
          apiVersion: ovirtproviderconfig.machine.openshift.io/v1beta1
          cluster_id: <ovirt_cluster_id> 14
          template_name: <ovirt_template_name> 15
          sparse: <boolean_value> 16
          format: <raw_or_cow> 17
          cpu: 18
            sockets: <number_of_sockets> 19
            cores: <number_of_cores> 20
            threads: <number_of_threads> 21
          memory_mb: <memory_size> 22
          guaranteed_memory_mb:  <memory_size> 23
          os_disk: 24
            size_gb: <disk_size> 25
            storage_domain_id: <storage_domain_UUID> 26
          network_interfaces: 27
            vnic_profile_id:  <vnic_profile_id> 28
          credentialsSecret:
            name: ovirt-credentials 29
          kind: OvirtMachineProviderSpec
          type: <workload_type> 30
          auto_pinning_policy: <auto_pinning_policy> 31
          hugepages: <hugepages> 32
          affinityGroupsNames:
            - compute 33
          userDataSecret:
            name: worker-user-data

1 7 9

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

2 3 10 11 13

追加するノードラベルを指定します。

4 8 12

インフラストラクチャー ID およびノードラベルを指定します。これら 2 つの文字列は 35 文字を超えることができません。

作成するマシンの数を指定します。

マシンのセレクター。

この仮想マシンインスタンスが属する RHV クラスターの UUID を指定します。

マシンの作成に使用する RHV 仮想マシンテンプレートを指定します。

cow または raw に設定できます。デフォルトは cow です。cow のフォーマットは仮想マシン用に最適化されています。

注記

オプション: CPU フィールドには、ソケット、コア、スレッドを含む CPU の設定が含まれます。

オプション: 仮想マシンのソケット数を指定します。

20

オプション: ソケットあたりのコア数を指定します。

オプション: コアあたりのスレッド数を指定します。

オプション: 仮想マシンのメモリーサイズを MiB 単位で指定します。

23

注記

RHV 4.4.8 より前のバージョンを使用している場合は、Red Hat Virtualization クラスターでの OpenShift の保証されたメモリー要件を参照してください。

24

オプション: ノードのルートディスク。

25

オプション: ブート可能なディスクのサイズを GiB 単位で指定します。

26

27

28

オプション: vNIC プロファイル ID を指定します。

29

RHV クレデンシャルを保持するシークレットオブジェクトの名前を指定します。

オプション: 仮想マシンに適用されるアフィニティーグループ名のリスト。アフィニティーグループは oVirt に存在している必要があります。

注記

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-infra 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 4
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: <infra> 6
        machine.openshift.io/cluster-api-machine-type: <infra> 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 8
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: "" 9
      taints: 10
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 120
          kind: VSphereMachineProviderSpec
          memoryMiB: 8192
          metadata:
            creationTimestamp: null
          network:
            devices:
            - networkName: "<vm_network_name>" 11
          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <vm_template_name> 12
          userDataSecret:
            name: worker-user-data
          workspace:
            datacenter: <vcenter_datacenter_name> 13
            datastore: <vcenter_datastore_name> 14
            folder: <vcenter_vm_folder_path> 15
            resourcepool: <vsphere_resource_pool> 16
            server: <vcenter_server_ip> 17

1 3 5

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

2 4 8

インフラストラクチャー ID および <infra> ノードラベルを指定します。

6 7 9

<infra> ノードラベルを指定します。

ユーザーのワークロードが infra ノードにスケジュールされないようにテイントを指定します。

注記

user-5ddjd-rhcos などの使用する vSphere 仮想マシンテンプレートを指定します。

コンピュートマシンセットをデプロイする vCenter Datacenter を指定します。

コンピュートマシンセットをデプロイする vCenter Datastore を指定します。

/dc1/vm/user-inst-5ddjd などの vCenter の vSphere 仮想マシンフォルダーへのパスを指定します。

仮想マシンの vSphere リソースプールを指定します。