OpenShift Container Platform

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

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

マシンセットに使用する 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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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 クラスターの特定の目的を果たすように異なるマシンセットを作成することができます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

$ 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>:"" というラベルが付けられたノードを作成するマシンセットを定義します。

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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
          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) AMI を指定します。AWS Marketplace イメージを使用する場合は、AWS Marketplace から OpenShift Container Platform サブスクリプションを完了して、リージョンの AMI ID を取得する必要があります。

ゾーン (例: 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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.3. Amazon EC2 インスタンスメタデータサービスのマシンセットオプション

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

注記

IMDSv2 の使用は、OpenShift Container Platform バージョン 4.7 以降で作成された AWS クラスターでのみサポートされます。

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

コントロールプレーンマシンの IMDS 設定は、クラスターのインストール時に設定されます。コントロールプレーンマシンの IMDS 設定を変更するには、AWS CLI を使用する必要があります。詳細は、既存のインスタンスのインスタンスメタデータオプションを変更する方法に関する AWS のドキュメントを参照してください。

重要

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

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

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

前提条件

IMDSv2 を使用するには、AWS クラスターが OpenShift Container Platform バージョン 4.7 以降で作成されている必要があります。

手順

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.3. Azure でのマシンセットの作成

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

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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>
          node-role.kubernetes.io/<role>: "" 11
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image: 12
            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: ""
          tags:
            - name: <custom_tag_name> 17
              value: <custom_tag_value> 18
          subnet: <infrastructure_id>-<role>-subnet 19 20
          userDataSecret:
            name: worker-user-data 21
          vmSize: Standard_D4s_v3
          vnet: <infrastructure_id>-vnet 22
          zone: "1" 23

1 5 7 15 16 19 22

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

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

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

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

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

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

2 3 8 9 11 20 21

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

4 6 10

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

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

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

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

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

17 18

オプション: マシンセットでカスタムタグを指定します。<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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.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 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.x です。必要に応じて、インストールプロセスの一環として、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. マシンを Spot 仮想マシンとしてデプロイするマシンセット

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

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

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

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

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

2.3.4.1. マシンセットの使用による Spot 仮想マシンの作成

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.5. マシンを一時 OS ディスクにデプロイするマシンセット

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

関連情報

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

2.3.5.1. マシンセットの使用による一時 OS ディスクでのマシンの作成

マシンセット YAML ファイルを編集して、Azure で Ephemeral 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.6. Machine sets that deploy machines with ultra disks as data disks

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

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

注記

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

関連情報

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

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

前提条件

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

手順

次のコマンドを実行して、ワーカーデータシークレットを使用して openshift-machine-api namespace にカスタムシークレットを作成します。
```
$ oc -n openshift-machine-api \
get secret worker-user-data \
--template='{{index .data.userData | base64decode}}' | jq > userData.txt
```
ここで、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 worker-user-data \
--template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt

次のコマンドを実行して、userData.txt ファイルと disableTemplating.txt ファイルを組み合わせてデータシークレットファイルを作成します。
```
$ oc -n openshift-machine-api create secret generic worker-user-data-x5 \
--from-file=userData=userData.txt \
--from-file=disableTemplating=disableTemplating.txt
```
ここで、worker-user-data-x5 はシークレットの名前です。
既存の 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: worker-user-data-x5 4
             ...

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

次のコマンドを実行して、更新された設定を使用してマシンセットを作成します。
```
$ 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.6.2. Ultra ディスクを有効にするマシンセットのリソースに関するトラブルシューティング

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

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

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

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

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

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

2.3.6.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.6.2.3. ディスクを削除できません

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

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

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.8. Microsoft Azure 仮想マシンのネットワークアクセラレート

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

2.3.8.1. 制限事項

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

ネットワークのアクセラレートは、マシン API が機能しているクラスターでのみサポートされます。
Azure ワーカーノードの最小要件は 2 つの vCPU ですが、Accelerated Networking には 4 つ以上の vCPU を含む Azure 仮想マシンのサイズが必要です。この要件を満たすには、マシンセットの vmSize の値を変更します。Azure VM サイズの詳細は、Microsoft Azure のドキュメントを参照してください。
この機能が既存の Azure クラスターで有効にされている場合、新たにプロビジョニングされたノードのみが影響を受けます。現在実行中のノードは調整されていません。全ノードで機能を有効にするには、それぞれの既存マシンを置き換える必要があります。これは、各マシンに対して個別に行うか、レプリカをゼロにスケールダウンしてから、必要なレプリカ数にスケールアップして実行できます。

関連情報

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

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

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

前提条件

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

手順

以下のコマンドを実行して、クラスター内のマシンセットをリスト表示します。

$ oc get machinesets -n openshift-machine-api

マシンセットは <cluster-id>-worker-<region> の形式で一覧表示されます。

出力例

NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
jmywbfb-8zqpx-worker-centralus1     1         1         1       1           15m
jmywbfb-8zqpx-worker-centralus2     1         1         1       1           15m
jmywbfb-8zqpx-worker-centralus3     1         1         1       1           15m

それぞれのマシンセットについて以下を実行します。
1. 以下のコマンドを実行してカスタムリソース (CR) を編集します。
```
$ oc edit machineset <machine-set-name>
```
2. 以下を 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 クラスターで特定の目的を果たすように異なるマシンセットを作成することができます。たとえば、インフラストラクチャーマシンセットおよび関連マシンを作成して、サポートするワークロードを新しいマシンに移動できます。

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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:
          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

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

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

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

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

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

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

2 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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.4.3. マシンセットの顧客管理の暗号鍵の有効化

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.5. GCP でのマシンセットの作成

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

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.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 がインスタンスを終了すると、プリエンプション可能な仮想マシンインスタンスで実行される終了ハンドラーによりマシンリソースが削除されます。マシンセットの replicas の量を満たすために、マシンセットはプリエンプション可能な仮想マシンインスタンスを要求するマシンを作成します。

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.6. IBMCloud でのマシンセットの作成

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

重要

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

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

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

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

2.6.1. IBMCloud 上のマシンセットカスタムリソースのサンプル YAML

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.7. Nutanix でマシンセットを作成する

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

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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>-<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-credentials
          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

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

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

2 3 9 10

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

4 7 11

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

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

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

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

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

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

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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.8. OpenStack でのマシンセットの作成

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

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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

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

$ 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: コンピュートマシンのセキュリティーグループを指定します。

注記

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

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

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

クラスターで 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>

重要

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

$ 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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.9. RHV でのマシンセットの作成

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

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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

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

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

2 3 10 11 13

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

4 8 12

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

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

6

マシンのセレクター。

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

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

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

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

注記

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

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

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

20

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

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

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

オプション: 仮想マシンの保証されたメモリーのサイズを 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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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.10. vSphere でのマシンセットの作成

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

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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

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

$ 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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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

新規のマシンセットが利用可能な場合、 DESIRED および CURRENT の値は一致します。マシンセットが利用可能でない場合、数分待機してからコマンドを再度実行します。

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

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

重要

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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

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

$ 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: デフォルトのノードラベル。
注記
user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは 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 の値は一致します。マシンセットが利用可能でない場合、数分待機してからコマンドを再度実行します。

第3章マシンセットの手動によるスケーリング

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

注記

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

3.1. 前提条件

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

重要

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

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

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

$ 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/cluster-api-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/cluster-api-delete-machine=true を追加して設定できます。

重要

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

注記

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

3.4. 関連情報

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

第4章マシンセットの変更

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

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

注記

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

4.1. CLI を使用したマシンセットの変更

マシンセットを変更する場合、変更は更新された MachineSet カスタムリソース(CR)を保存した後に作成されるマシンにのみ適用されます。この変更は既存のマシンには影響しません。コンピュートマシンセットをスケーリングすることで、既存のマシンを、更新された設定を反映した新しいマシンに置き換えることができます。

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

注記

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

前提条件

OpenShift Container Platform クラスターは、Machine API を使用する。
OpenShift CLI (oc) を使用して、管理者としてクラスターにログインしている。

手順

マシンセットを編集します。

$ oc edit machineset <machine_set_name> -n openshift-machine-api

変更を適用するためにマシンセットをスケーリングする際に必要になるため、spec.replicas フィールドの値を書き留めます。
```
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machine_set_name>
  namespace: openshift-machine-api
spec:
  replicas: 2 1
# ...
```
1
この手順例では、replicas 値が 2 のコンピュートマシンセットを示しています。
必要な設定オプションを使用してコンピュートマシンセット CR を更新し、変更を保存します。

次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。

$ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name>

出力例

NAME                        PHASE     TYPE         REGION      ZONE         AGE
<machine_name_original_1>   Running   m6i.xlarge   us-west-1   us-west-1a   4h
<machine_name_original_2>   Running   m6i.xlarge   us-west-1   us-west-1a   4h

次のコマンドを実行して、更新されたコンピュートマシンセットで管理されるマシンごとに delete アノテーションを設定します。
```
$ oc annotate machine/<machine_name_original_1> \
  -n openshift-machine-api \
  machine.openshift.io/delete-machine="true"
```
次のコマンドを実行して、コンピュートマシンセットをレプリカ数の 2 倍にスケーリングします。
```
$ oc scale --replicas=4 \1
  machineset <machine_set_name> \
  -n openshift-machine-api
```
1
元の例の値 2 は 2 倍の 4 になります。

次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。

$ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name>

出力例

NAME                        PHASE          TYPE         REGION      ZONE         AGE
<machine_name_original_1>   Running        m6i.xlarge   us-west-1   us-west-1a   4h
<machine_name_original_2>   Running        m6i.xlarge   us-west-1   us-west-1a   4h
<machine_name_updated_1>    Provisioned    m6i.xlarge   us-west-1   us-west-1a   55s
<machine_name_updated_2>    Provisioning   m6i.xlarge   us-west-1   us-west-1a   55s

新しいマシンが Running フェーズにある場合、コンピュートマシンセットを元のレプリカ数にスケーリングできます。

次のコマンドを実行して、コンピュートマシンセットのレプリカ数を元の数にスケーリングします。
```
$ oc scale --replicas=2 \1
  machineset <machine_set_name> \
  -n openshift-machine-api
```
1
元の例の値は 2 です。

検証

設定が更新されていないコンピュートマシンが削除されたことを確認するには、次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。

$ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name>

削除中の出力例

NAME                        PHASE           TYPE         REGION      ZONE         AGE
<machine_name_original_1>   Deleting        m6i.xlarge   us-west-1   us-west-1a   4h
<machine_name_original_2>   Deleting        m6i.xlarge   us-west-1   us-west-1a   4h
<machine_name_updated_1>    Running         m6i.xlarge   us-west-1   us-west-1a   5m41s
<machine_name_updated_2>    Running         m6i.xlarge   us-west-1   us-west-1a   5m41s

削除完了時の出力例

NAME                        PHASE           TYPE         REGION      ZONE         AGE
<machine_name_updated_1>    Running         m6i.xlarge   us-west-1   us-west-1a   6m30s
<machine_name_updated_2>    Running         m6i.xlarge   us-west-1   us-west-1a   6m30s

更新されたマシンセットによって作成されたマシンの設定が正しいことを確認するには、次のコマンドを実行して、新しいマシンの 1 つで CR の関連フィールドを調べます。
```
$ oc describe machine <machine_name_updated_1> -n openshift-machine-api
```

関連情報

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

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章マシンのフェーズとライフサイクル

マシンには ライフサイクル があり、ライフサイクルにはいくつかの定義されたフェーズがあります。マシンのライフサイクルとそのフェーズを理解すると、手順が完了したかどうかを確認したり、望ましくない動作をトラブルシューティングしたりするのに役立ちます。OpenShift Container Platform では、マシンのライフサイクルがサポート対象の全クラウドプロバイダーで一貫しています。

5.1. マシンのフェーズ

マシンのライフサイクルが進むにつれ、フェーズが変化します。各フェーズは、マシンの状態を表すための基本です。

Provisioning: 新しいマシンのプロビジョニング要求があります。マシンはまだ存在せず、インスタンス、プロバイダー ID、アドレスはありません。
Provisioned: マシンが存在し、プロバイダー ID かアドレスがあります。クラウドプロバイダーがマシンのインスタンスを作成しました。マシンはまだノードになっておらず、マシンオブジェクトの status.nodeRef セクションにデータはありません。
Running: マシンが存在し、プロバイダー ID またはアドレスがあります。Ignition が正常に実行され、クラスターマシンの承認者は証明書署名要求 (CSR) を承認しました。マシンはノードになり、マシンオブジェクトの status.nodeRef セクションにノードの詳細が格納されました。
Deleting: マシンの削除要求があります。マシンオブジェクトには、削除要求の時刻を示す DeletionTimestamp フィールドがあります。
Failed: マシンに回復不可能な問題があります。これは、クラウドプロバイダーがマシンのインスタンスを削除した場合などに発生する可能性があります。

5.2. マシンのライフサイクル

ライフサイクルは、マシンのプロビジョニング要求から始まり、マシンが存在しなくなるまで継続します。

マシンのライフサイクルは次の順序で進行します。エラーやライフサイクルフックによる中断は、この概要には含まれていません。

次のいずれかの理由で、新しいマシンをプロビジョニング要求が発生します。
- クラスター管理者がマシンセットをスケーリングするため、追加のマシンが必要になる。
- 自動スケーリングポリシーによりマシンセットがスケーリングされるため、追加のマシンが必要になる。
- マシンセットが管理するマシンで障害が発生した、またはマシンセットが管理するマシンが削除され、必要なマシン数を満たすためにマシンセットが代替マシンを作成する。
マシンは Provisioning フェーズに入ります。
インフラストラクチャープロバイダーは、マシンのインスタンスを作成します。
マシンにはプロバイダー ID またはアドレスがあり、Provisioned フェーズに入ります。
Ignition 設定ファイルが処理されます。
kubelet は証明書署名要求 (CSR) を発行します。
クラスターマシンの承認者が CSR を承認します。
マシンはノードになり、Running フェーズに入ります。
既存のマシンは、次のいずれかの理由により削除される予定です。
- cluster-admin 権限を持つユーザーは、oc delete machine コマンドを使用します。
- マシンは machine.openshift.io/delete-machine アノテーションを取得します。
- マシンを管理するマシンセットは、調整の一環としてレプリカ数を減らすために、そのマシンに削除のマークを付けます。
- クラスターオートスケーラーは、クラスターのデプロイメントニーズを満たすために不必要なノードを特定します。
- マシンの健全性チェックは、異常なマシンを置き換えるように設定されています。
マシンは Deleting フェーズに入ります。このフェーズでは、マシンは削除対象としてマークされていますが、API にはまだ存在しています。
マシンコントローラーは、インフラストラクチャープロバイダーからインスタンスを削除します。
マシンコントローラーは Node オブジェクトを削除します。

5.3. マシンのフェーズを確認する

マシンのフェーズは、OpenShift CLI (oc) または Web コンソールを使用して確認できます。この情報を使用して、手順が完了したかどうかを確認したり、望ましくない動作のトラブルシューティングを行うことができます。

5.3.1. CLI を使用してマシンのフェーズを確認する

マシンのフェーズは、OpenShift CLI (oc) を使用して確認できます。

前提条件

cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
oc CLI がインストールされている。

手順

次のコマンドを実行して、クラスター上のマシンをリスト表示します。

$ oc get machine -n openshift-machine-api

出力例

NAME                                      PHASE     TYPE         REGION      ZONE         AGE
mycluster-5kbsp-master-0                  Running   m6i.xlarge   us-west-1   us-west-1a   4h55m
mycluster-5kbsp-master-1                  Running   m6i.xlarge   us-west-1   us-west-1b   4h55m
mycluster-5kbsp-master-2                  Running   m6i.xlarge   us-west-1   us-west-1a   4h55m
mycluster-5kbsp-worker-us-west-1a-fmx8t   Running   m6i.xlarge   us-west-1   us-west-1a   4h51m
mycluster-5kbsp-worker-us-west-1a-m889l   Running   m6i.xlarge   us-west-1   us-west-1a   4h51m
mycluster-5kbsp-worker-us-west-1b-c8qzm   Running   m6i.xlarge   us-west-1   us-west-1b   4h51m

出力の PHASE 列には、各マシンのフェーズが含まれます。

5.3.2. Web コンソールを使用してマシンのフェーズを確認する

OpenShift Container Platform Web コンソールを使用して、マシンのフェーズを確認できます。

前提条件

cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

cluster-admin ロールを持つユーザーとして、Web コンソールにログインします。
Compute → Machines に移動します。
Machine ページで、フェーズを確認するマシンの名前を選択します。
Machine details ページで YAML タブを選択します。
YAML ブロックで、status.phase フィールドの値を確認します。
YAML スニペットの例
```
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  name: mycluster-5kbsp-worker-us-west-1a-fmx8t
# ...
status:
  phase: Running 1
```
1
この例のフェーズは Running です。

5.4. 関連情報

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

第6章マシンの削除

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

6.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 にアノテーションを付けると、ノードのドレイン (解放) を省略できます。
削除するマシンがマシンセットに属している場合は、指定された数のレプリカを満たす新しいマシンがすぐに作成されます。

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

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

6.2.1. 用語と定義

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

調整

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

マシンコントローラー

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

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

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

ライフサイクルフック

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

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

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

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

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

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

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

6.2.2. マシン削除処理順序

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

図6.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 オブジェクトを削除します。

6.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 を管理するフック実装コントローラー。

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

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

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

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

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

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

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

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

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

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

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

ログの信頼性の向上

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

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

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

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

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

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

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

OpenShift Container Platform 4.11 以降のクラスター上でコントロールプレーンマシンが置き換えられると、クラスターには一時的に 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 ライフサイクルフックを管理するフック実装コントローラー。

6.3. 関連情報

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

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

重要

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

7.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 が利用可能なプラットフォームでサポートされています。

7.2. Cluster Autoscaler の設定

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

注記

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

7.2.1. Cluster Autoscaler リソース定義

この 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
  scaleDown: 10
    enabled: true 11
    delayAfterAdd: 10m 12
    delayAfterDelete: 5m 13
    delayAfterFailure: 30s 14
    unneededTime: 5m 15
    utilizationThreshold: "0.4" 16

1: Cluster Autoscaler に追加のノードをデプロイさせるために Pod が超えている必要のある優先順位を指定します。32 ビットの整数値を入力します。podPriorityThreshold 値は、各 Pod に割り当てる PriorityClass の値と比較されます。
2: デプロイするノードの最大数を指定します。この値は、Autoscaler が制御するマシンだけでなく、クラスターにデプロイされるマシンの合計数です。この値は、すべてのコントロールプレーンおよびコンピュートマシン、および MachineAutoscaler リソースに指定するレプリカの合計数に対応するのに十分な大きさの値であることを確認します。
3: クラスターにデプロイするコアの最小数を指定します。
4: クラスターにデプロイするコアの最大数を指定します。
5: クラスターのメモリーの最小量 (GiB 単位) を指定します。
6: クラスターのメモリーの最大量 (GiB 単位) を指定します。
7: オプション: デプロイする GPU ノードのタイプを指定します。nvidia.com/gpu および amd.com/gpu のみが有効なタイプです。
8: クラスターにデプロイする GPU の最小数を指定します。
9: クラスターにデプロイする GPU の最大数を指定します。
10: このセクションでは、有効な ParseDuration 期間 ( ns、us、ms、s、m、および h を含む) を使用して各アクションについて待機する期間を指定できます。
11: Cluster Autoscaler が不必要なノードを削除できるかどうかを指定します。
12: オプション: ノードが最後に追加されてからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 10m が使用されます。
13: オプション: ノードが最後に削除されてからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 0s が使用されます。
14: オプション: スケールダウンが失敗してからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 3m が使用されます。
15: オプション: 不要なノードが削除の対象となるまでの期間を指定します。値を指定しない場合、デフォルト値の 10m が使用されます。
16: オプション: ノード使用率レベルを指定します。ノードの使用率がこの値を下回ると、不要なノードが削除の対象となります。ノード使用率は、要求されたリソースをそのノードに割り当てられたリソースで割ったもので、"0" より大きく "1" より小さい値でなければなりません。値を指定しない場合、Cluster Autoscaler は 50% の使用率に対応するデフォルト値 "0.5" を使用します。この値は文字列として表現する必要があります。

注記

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

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

7.2.2. Cluster Autoscaler のデプロイ

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

手順

カスタムリソース定義を含む ClusterAutoscaler リソースの YAML ファイルを作成します。
以下のコマンドを実行して、クラスター内にカスタムリソースを作成します。
```
$ oc create -f <filename>.yaml 1
```
1
<filename> はカスタムリソースファイルの名前です。

次のステップ

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

7.3. Machine Autoscaler について

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

重要

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

7.4. Machine Autoscaler の設定

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

重要

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

注記

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

7.4.1. Machine Autoscaler リソース定義

この 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 パラメーター値に示されるように既存のマシンセットの名前に一致する必要があります。

7.4.2. Machine Autoscaler のデプロイ

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

手順

カスタムリソース定義を含む MachineAutoscaler リソースの YAML ファイルを作成します。
以下のコマンドを実行して、クラスター内にカスタムリソースを作成します。
```
$ oc create -f <filename>.yaml 1
```
1
<filename> はカスタムリソースファイルの名前です。

7.5. 自動スケーリングの無効化

クラスター内の個々の Machine Autoscaler を無効にすることも、クラスター全体で自動スケーリングを無効にすることもできます。

7.5.1. Machine Autoscaler の無効化

Machine Autoscaler を無効にするには、対応する MachineAutoscaler カスタムリソース (CR) を削除します。

注記

Machine Autoscaler を無効にしても、Cluster Autoscaler は無効になりません。Cluster Autoscaler を無効にするには、「Cluster Autoscaler の無効化」に記載されている手順に従ってください。

手順

次のコマンドを実行して、クラスターの MachineAutoscaler CR をリスト表示します。

$ oc get MachineAutoscaler -n openshift-machine-api

出力例

NAME                 REF KIND     REF NAME             MIN   MAX   AGE
compute-us-east-1a   MachineSet   compute-us-east-1a   1     12    39m
compute-us-west-1a   MachineSet   compute-us-west-1a   2     4     37m

オプション: 次のコマンドを実行して、MachineAutoscaler CR の YAML ファイルバックアップを作成します。
```
$ oc get MachineAutoscaler/<machine_autoscaler_name> \1
  -n openshift-machine-api \
  -o yaml> <machine_autoscaler_name_backup>.yaml 2
```
1
<machine_autoscaler_name> は、削除する CR の名前です。
2
<machine_autoscaler_name_backup> は、CR のバックアップの名前です。

次のコマンドを実行して、MachineAutoscaler CR を削除します。

$ oc delete MachineAutoscaler/<machine_autoscaler_name> -n openshift-machine-api

出力例

machineautoscaler.autoscaling.openshift.io "compute-us-east-1a" deleted

検証

Machine Autoscaler が無効になっていることを確認するには、次のコマンドを実行します。
```
$ oc get MachineAutoscaler -n openshift-machine-api
```
無効化された Machine Autoscaler は、Machine Autoscaler リストに表示されません。

次のステップ

Machine Autoscaler を再度有効にする必要がある場合は、<machine_autoscaler_name_backup>.yaml バックアップファイルを使用し、「Machine Autoscaler のデプロイ」に記載されている手順に従います。

関連情報

7.5.2. Cluster Autoscaler の無効化

Cluster Autoscaler を無効にするには、対応する ClusterAutoscaler リソースを削除します。

注記

クラスターに既存の Machine Autoscaler がある場合も、Cluster Autoscaler を無効にするとクラスター上の自動スケーリングが無効になります。

手順

次のコマンドを実行して、クラスターの ClusterAutoscaler リソースを一覧表示します。
```
$ oc get ClusterAutoscaler
```
出力例
```
NAME      AGE
default   42m
```
オプション: 次のコマンドを実行して、ClusterAutoscaler CR の YAML ファイルバックアップを作成します。
```
$ oc get ClusterAutoscaler/default \1
  -o yaml> <cluster_autoscaler_backup_name>.yaml 2
```
1
default は、ClusterAutoscaler CR の名前です。
2
<cluster_autoscaler_backup_name> は、CR のバックアップの名前です。

次のコマンドを実行して、ClusterAutoscaler CR を削除します。

$ oc delete ClusterAutoscaler/default

出力例

clusterautoscaler.autoscaling.openshift.io "default" deleted

検証

Cluster Autoscaler が無効になっていることを確認するには、次のコマンドを実行します。
```
$ oc get ClusterAutoscaler
```
予想される出力
```
No resources found
```

次のステップ

ClusterAutoscaler CR を削除して Cluster Autoscaler を無効にすると、クラスターは自動スケーリングできなくなりますが、クラスター上の既存の Machine Autoscaler は削除されません。不要な Machine Autoscaler をクリーンアップするには、「Machine Autoscaler の無効化」を参照してください。
Cluster Autoscaler を再度有効にする必要がある場合は、<cluster_autoscaler_name_backup>.yaml バックアップファイルを使用し、「Cluster Autoscaler のデプロイ」に記載された手順に従います。

関連情報

7.6. 関連情報

OpenShift Container Platform における Pod スケジューリングに関する決定に Pod の優先順位を含める

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

重要

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

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

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

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

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

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

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

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

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

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

8.2.1. 異なるクラウドのマシンセットの作成

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

8.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

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

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

2 3 8 9

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

4 6 10

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

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

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

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

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

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

16 18 20

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

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

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

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

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

注記

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

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> は、マシンを配置するリージョン内のゾーンです。

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-infra-<zone> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 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
      taints: 10
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 11
          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 12
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone> 13
            region: <region> 14
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-worker-sg 15
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructure_id>-private-<zone> 16
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id> 17
              value: owned
          userDataSecret:
            name: worker-user-data

1 3 5 12 15 17

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

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

2 4 8

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

6 7 9

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

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

注記

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

OpenShift Container Platform ノードの AWS ゾーンに有効な Red Hat Enterprise Linux CoreOS (RHCOS) 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>-worker-<zone>

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

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

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

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

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 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>
          node-role.kubernetes.io/infra: "" 11
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image: 12
            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: ""
          tags:
            - name: <custom_tag_name> 17
              value: <custom_tag_value> 18
          subnet: <infrastructure_id>-<role>-subnet 19 20
          userDataSecret:
            name: worker-user-data 21
          vmSize: Standard_D4s_v3
          vnet: <infrastructure_id>-vnet 22
          zone: "1" 23
      taints: 24
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

1 5 7 15 16 19 22

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

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

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

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

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

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

2 3 8 9 11 20 21

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

4 6 10

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

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

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

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

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

17 18

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

24

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

注記

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

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

関連情報

Azure Marketplace イメージの選択

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 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

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

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

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

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

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

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

2 3 8 9 11 19 20

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

4 6 10

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

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

注記

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

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

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

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

注記

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

8.2.1.5. IBMCloud 上のマシンセットカスタムリソースのサンプル YAML

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 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

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

$ 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 インスタンスプロファイルを指定します。

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

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

VPC 名。

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

ユーザーのワークロードがインフラノードでスケジュールされないようにするためのテイント。

注記

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

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-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

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

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

2

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

現在のマシンセットで使用されるイメージへのパスを指定します。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 プロジェクトの名前を指定します。

6

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

注記

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

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

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

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

このサンプルでは、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
  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-credentials
          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

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

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

2 3 9 10

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

4 7 11

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

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

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

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

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

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

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

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

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

注記

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

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

このサンプル YAML は、Red Hat OpenStack Platform (RHOSP) で実行され、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 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

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

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

2 3 8 9 20

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

4 6 10

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

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

注記

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

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

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

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

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

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

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<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

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

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

2 3 10 11 13

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

4 8 12

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

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

6

マシンのセレクター。

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

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

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

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

注記

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

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

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

20

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

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

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

オプション: 仮想マシンの保証されたメモリーのサイズを 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 はテンプレートに指定されるパラメーターの値を使用します。

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

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

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

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 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

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

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

2 4 8

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

6 7 9

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

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

注記

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

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

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

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

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

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

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