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

10.5. コントロールプレーンマシンの設定オプション

10.5.1. Amazon Web Services のコントロールプレーン設定オプション
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、Amazon Web Services (AWS) コントロールプレーンマシンの設定を変更し、機能を有効にすることができます。コントロールプレーンマシンセットへの更新を保存すると、設定された 更新ストラテジー に従って Control Plane Machine Set Operator がコントロールプレーンマシンを更新します。

10.5.1.1. Amazon Web Services クラスターを設定するサンプル YAML
リンクのコピー

次の YAML スニペットの例は、AWS クラスターのプロバイダーの仕様と障害ドメインの設定を示しています。

10.5.1.1.1. AWS プロバイダーの仕様例
リンクのコピー

既存のクラスター用のコントロールプレーンマシンセットを作成する場合、プロバイダーの仕様が、インストールプログラムによって作成されるコントロールプレーンマシンのカスタムリソース (CR) の providerSpec 設定と一致する必要があります。CR の障害ドメインセクションに設定されているフィールドは省略できます。

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

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
Copy to Clipboard Toggle word wrap

AWS providerSpec の値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            ami:
              id: ami-<ami_id_string>
1 

            apiVersion: machine.openshift.io/v1beta1
            blockDevices:
            - ebs:
2 

                encrypted: true
                iops: 0
                kmsKey:
                  arn: ""
                volumeSize: 120
                volumeType: gp3
            credentialsSecret:
              name: aws-cloud-credentials
3 

            deviceIndex: 0
            iamInstanceProfile:
              id: <cluster_id>-master-profile
4 

            instanceType: m6i.xlarge
5 

            kind: AWSMachineProviderConfig
6 

            loadBalancers:
7 

            - name: <cluster_id>-int
              type: network
            - name: <cluster_id>-ext
              type: network
            metadata:
              creationTimestamp: null
            metadataServiceOptions: {}
            placement:
8 

              region: <region>
9 

              availabilityZone: ""
10 

              tenancy:
11 

            securityGroups:
            - filters:
              - name: tag:Name
                values:
                - <cluster_id>-master-sg
12 

            subnet: {}
13 

            userDataSecret:
              name: master-user-data
14
Copy to Clipboard Toggle word wrap

1
クラスターの Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) ID を指定します。AMI はクラスターと同じリージョンに属する必要があります。AWS Marketplace イメージを使用する場合は、AWS Marketplace から OpenShift Container Platform サブスクリプションを完了して、リージョンの AMI ID を取得する必要があります。
2
暗号化された EBS ボリュームの設定を指定します。
3
クラスターのシークレット名を指定します。この値は変更しないでください。
4
AWS Identity and Access Management (IAM) インスタンスプロファイルを指定します。この値は変更しないでください。
5
コントロールプレーンの AWS インスタンスタイプを指定します。
6
クラウドプロバイダープラットフォームのタイプを指定します。この値は変更しないでください。
7
クラスターの内部 (int) および外部 (ext) ロードバランサーを指定します。
注記

プライベート OpenShift Container Platform クラスターでは、外部 (ext) ロードバランサーパラメーターを省略できます。

8
AWS でコントロールプレーンインスタンスを作成する場所を指定します。
9
クラスターの AWS リージョンを指定します。
10
このパラメーターは障害ドメインで設定されます。ここでは空の値が表示されています。このパラメーターに指定された値が障害ドメインの値と異なる場合、Control Plane Machine Set Operator がその値を障害ドメインの値で上書きします。
11
コントロールプレーンの AWS Dedicated Instance 設定を指定します。詳細は、Dedicated Instance に関する AWS ドキュメントを参照してください。次の値が有効です。
  • default: Dedicated Instance は共有ハードウェア上で実行されます。
  • dedicated: Dedicated Instance はシングルテナントのハードウェア上で実行されます。
  • host: Dedicated Instance は Dedicated Host (設定を制御できる分離されたサーバー) 上で実行されます。
12
コントロールプレーンマシンのセキュリティーグループを指定します。
13
このパラメーターは障害ドメインで設定されます。ここでは空の値が表示されています。このパラメーターに指定された値が障害ドメインの値と異なる場合、Control Plane Machine Set Operator がその値を障害ドメインの値で上書きします。
注記

障害ドメイン設定で値が指定されていない場合、プロバイダー仕様の値が使用されます。障害ドメインでサブネットを設定すると、プロバイダー仕様のサブネット値が上書きされます。

14
コントロールプレーンのユーザーデータシークレットを指定します。この値は変更しないでください。
10.5.1.1.2. AWS 障害ドメインの設定例
リンクのコピー

障害ドメインのコントロールプレーンマシンセットの概念は、既存の AWS の アベイラビリティゾーン (AZ) の概念に似ています。ControlPlaneMachineSet CR は、可能な場合、コントロールプレーンマシンを複数の障害ドメインに分散します。

コントロールプレーンマシンセットで AWS 障害ドメインを設定するときは、使用するアベイラビリティゾーン名とサブネットを指定する必要があります。

AWS 障害ドメインの値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    machines_v1beta1_machine_openshift_io:
      failureDomains:
        aws:
        - placement:
            availabilityZone: <aws_zone_a>
1 

          subnet:
2 

            filters:
            - name: tag:Name
              values:
              - <cluster_id>-private-<aws_zone_a>
3 

            type: Filters
4 

        - placement:
            availabilityZone: <aws_zone_b>
5 

          subnet:
            filters:
            - name: tag:Name
              values:
              - <cluster_id>-private-<aws_zone_b>
6 

            type: Filters
        platform: AWS
7 

# ...
Copy to Clipboard Toggle word wrap

1
最初の障害ドメインの AWS アベイラビリティゾーンを指定します。
2
サブネット設定を指定します。この例では、サブネットタイプが Filters であるため、filters スタンザがあります。
3
インフラストラクチャー ID と AWS アベイラビリティゾーンを使用して、最初の障害ドメインのサブネット名を指定します。
4
サブネットタイプを指定します。許可される値は、ARN、Filters、および ID です。デフォルト値は Filters です。
5
インフラストラクチャー ID と AWS アベイラビリティゾーンを使用して、追加の障害ドメインのサブネット名を指定します。
6
クラスターのインフラストラクチャー ID と、追加の障害ドメインの AWS アベイラビリティゾーンを指定します。
7
クラウドプロバイダーのプラットフォーム名を指定します。この値は変更しないでください。

10.5.1.2. コントロールプレーンマシンの Amazon Web Services 機能を有効にする
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、機能を有効にします。

10.5.1.2.1. API サーバーをプライベートに制限する
リンクのコピー

クラスターを Amazon Web Services (AWS) にデプロイした後に、プライベートゾーンのみを使用するように API サーバーを再設定することができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとして Web コンソールにアクセスできること。

手順

  1. クラウドプロバイダーの Web ポータルまたはコンソールで、次の操作を行います。

    1. 適切なロードバランサーコンポーネントを見つけて削除します。

      • AWS の場合は、外部ロードバランサーを削除します。プライベートゾーンの API DNS エントリーは、同一の設定を使用する内部ロードバランサーをすでに参照するため、内部ロードバランサーを変更する必要はありません。
    2. パブリックゾーンの api.$clustername.$yourdomain DNS エントリーを削除します。

  2. コントロールプレーンマシンセットのカスタムリソースで次の行を削除して、外部ロードバランサーを削除します。 

    # ...
providerSpec:
  value:
# ...
    loadBalancers:
    - name: lk4pj-ext
    1 
    
      type: network
    2 
    
    - name: lk4pj-int
      type: network
# ...
    Copy to Clipboard Toggle word wrap
    1
    -ext で終わる外部ロードバランサーの name 値を削除します。
    2
    外部ロードバランサーの type 値を削除します。

コントロールプレーンマシンセットのカスタムリソース (CR) の仕様を更新することで、コントロールプレーンマシンが使用する Amazon Web Services (AWS) インスタンスタイプを変更できます。

前提条件

  • AWS クラスターは、コントロールプレーンマシンセットを使用します。

手順

  1. providerSpec フィールドの下で以下の行を編集します。 

    providerSpec:
  value:
    ...
    instanceType: <compatible_aws_instance_type>
    1
    Copy to Clipboard Toggle word wrap
    1
    前の選択と同じベースで、より大きな AWS インスタンスタイプを指定します。たとえば、m6i.xlarge を m6i.2xlarge または m6i.4xlarge に変更できます。
  2. 変更を保存します。

既存の AWS プレースメントグループ内の Elastic Fabric Adapter (EFA) インスタンスにマシンをデプロイするようにマシンセットを設定できます。

EFA インスタンスにはプレースメントグループは必要なく、EFA の設定以外の目的にもプレースメントグループを使用できます。この例では、両方を使用して、指定されたプレースメントグループ内のマシンのネットワークパフォーマンスを向上できる設定を示します。

前提条件

  • AWS コンソールでプレースメントグループを作成しました。

    注記

    作成するプレースメントグループのタイプの ルールと制限 が、意図した使用例と互換性があることを確認してください。可能な場合、コントロールプレーンマシンセットは、コントロールプレーンマシンを複数の障害ドメインに分散します。コントロールプレーンにプレースメントグループを使用するには、複数のアベイラビリティゾーンにまたがることができるプレースメントグループタイプを使用する必要があります。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下に次の行を編集します。 

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    spec:
      providerSpec:
        value:
          instanceType: <supported_instance_type>
    1 
    
          networkInterfaceType: EFA
    2 
    
          placement:
            availabilityZone: <zone>
    3 
    
            region: <region>
    4 
    
          placementGroupName: <placement_group>
    5 
    
          placementGroupPartition: <placement_group_partition_number>
    6 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    EFA をサポートする インスタンスタイプを指定します。
    2
    EFA ネットワークインターフェイスのタイプを指定します。
    3
    ゾーン (例: us-east-1a) を指定します。
    4
    リージョン (例: us-east-1) を指定します。
    5
    マシンをデプロイする既存の AWS プレースメントグループの名前を指定します。
    6
    オプション: マシンをデプロイする既存の AWS プレースメントグループのパーティション番号を指定します。

検証

  • AWS コンソールで、マシンセットが作成したマシンを見つけて、マシンのプロパティーで次のことを確認します。

    • プレースメントグループフィールドには、マシンセットの placementGroupName パラメーターに指定した値が含まれます。
    • パーティション番号フィールドには、マシンセットの placementGroupPartition パラメーターに指定した値が設定されます。
    • インターフェイスタイプフィールドは、EFA を使用することを示します。
10.5.1.2.4. Amazon EC2 インスタンスメタデータサービスのマシンセットオプション
リンクのコピー

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

注記

OpenShift Container Platform バージョン 4.6 以前で作成された AWS クラスターで IMDSv2 を使用するには、ブートイメージを更新する必要があります。詳細は、「ブートイメージ更新」を参照してください。

重要

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

10.5.1.2.4.1. マシンセットを使用した IMDS の設定
リンクのコピー

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

前提条件

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

手順

  • providerSpec フィールドの下に次の行を追加または編集します。 

    providerSpec:
  value:
    metadataServiceOptions:
      authentication: Required
    1
    Copy to Clipboard Toggle word wrap
    1
    IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
10.5.1.2.5. マシンを専有インスタンス (Dedicated Instance) としてデプロイするマシンセット
リンクのコピー

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

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

10.5.1.2.5.1. マシンセットの使用による専有インスタンスの作成
リンクのコピー

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

手順

  • providerSpec フィールドに専用テナンシーを指定します。 

    providerSpec:
  placement:
    tenancy: dedicated
    Copy to Clipboard Toggle word wrap
10.5.1.2.6. マシンセットを使用した Capacity Reservation の設定
リンクのコピー

OpenShift Container Platform バージョン 4.19 以降では、On-Demand Capacity Reservation および Capacity Blocks for ML を含む Amazon Web Services クラスターでの Capacity Reservation がサポートされます。

定義した容量要求のパラメーターに一致する利用可能なリソースにマシンをデプロイするようにマシンセットを設定できます。これらのパラメーターは、予約するインスタンスのタイプ、リージョン、およびインスタンスの数を指定します。Capacity Reservation が容量要求に対応できる場合、デプロイメントは成功します。

この AWS オファリングの制限事項や推奨されるユースケースなどの詳細は、AWS ドキュメントの On-Demand Capacity Reservations and Capacity Blocks for ML を参照してください。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • On-Demand Capacity Reservation または Capacity Block for ML を購入している。詳細は、AWS ドキュメントの On-Demand Capacity Reservations and Capacity Blocks for ML を参照してください。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下の次のセクションを編集します。

    設定例

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    machines_v1beta1_machine_openshift_io:
      spec:
        providerSpec:
          value:
            capacityReservationId: <capacity_reservation>
    1 
    
            marketType: <market_type>
    2 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    マシンセットでマシンをデプロイする対象となる、Capacity Block for ML または On-Demand Capacity Reservation の ID を指定します。
    2
    使用するマーケットタイプを指定します。次の値が有効です。
    CapacityBlock
    このマーケットタイプは、Capacity Blocks for ML とともに使用します。
    OnDemand
    このマーケットタイプは、On-Demand Capacity Reservation で使用します。

検証

  • マシンのデプロイメントを確認するには、次のコマンドを実行して、マシンセットが作成したマシンをリスト表示します。 

    $ oc get machine \
  -n openshift-machine-api \
  -l machine.openshift.io/cluster-api-machine-role=master
    Copy to Clipboard Toggle word wrap

    出力で、リストされたマシンの特性が Capacity Reservation のパラメーターと一致していることを確認します。

10.5.2. Microsoft Azure のコントロールプレーン設定オプション
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、Microsoft Azure コントロールプレーンマシンの設定を変更し、機能を有効にすることができます。コントロールプレーンマシンセットへの更新を保存すると、設定された 更新ストラテジー に従って Control Plane Machine Set Operator がコントロールプレーンマシンを更新します。

10.5.2.1. Microsoft Azure クラスターを設定するためのサンプル YAML
リンクのコピー

次の YAML スニペットの例は、Azure クラスターのプロバイダーの仕様と障害ドメインの設定を示しています。

10.5.2.1.1. Azure プロバイダーの仕様例
リンクのコピー

既存クラスター用のコントロールプレーンマシンセットを作成する場合、プロバイダーの仕様は、インストールプログラムによって作成されるコントロールプレーン machine CR の providerSpec 設定と一致する必要があります。CR の障害ドメインセクションに設定されているフィールドは省略できます。

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

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
Copy to Clipboard Toggle word wrap

Azure providerSpec の値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            acceleratedNetworking: true
            apiVersion: machine.openshift.io/v1beta1
            credentialsSecret:
              name: azure-cloud-credentials
1 

              namespace: openshift-machine-api
            diagnostics: {}
            image:
2 

              offer: ""
              publisher: ""
              resourceID: /resourceGroups/<cluster_id>-rg/providers/Microsoft.Compute/galleries/gallery_<cluster_id>/images/<cluster_id>-gen2/versions/412.86.20220930
3 

              sku: ""
              version: ""
            internalLoadBalancer: <cluster_id>-internal
4 

            kind: AzureMachineProviderSpec
5 

            location: <region>
6 

            managedIdentity: <cluster_id>-identity
            metadata:
              creationTimestamp: null
              name: <cluster_id>
            networkResourceGroup: <cluster_id>-rg
            osDisk:
7 

              diskSettings: {}
              diskSizeGB: 1024
              managedDisk:
                storageAccountType: Premium_LRS
              osType: Linux
            publicIP: false
            publicLoadBalancer: <cluster_id>
8 

            resourceGroup: <cluster_id>-rg
            subnet: <cluster_id>-master-subnet
9 

            userDataSecret:
              name: master-user-data
10 

            vmSize: Standard_D8s_v3
            vnet: <cluster_id>-vnet
            zone: "1"
11
Copy to Clipboard Toggle word wrap

1
クラスターのシークレット名を指定します。この値は変更しないでください。
2
コントロールプレーンマシンセットのイメージの詳細を指定します。
3
インスタンスタイプと互換性のあるイメージを指定します。インストールプログラムによって作成された Hyper-V 世代の V2 イメージには接尾辞 -gen2 が付いていますが、V1 イメージには接尾辞のない同じ名前が付いています。
4
コントロールプレーンの内部ロードバランサーを指定します。このフィールドは事前入力されていない可能性がありますが、ControlPlaneMachineSet とコントロールプレーン Machin CR の両方で必要です。
5
クラウドプロバイダープラットフォームのタイプを指定します。この値は変更しないでください。
6
コントロールプレーンマシンを配置するリージョンを指定します。
7
コントロールプレーンのディスク設定を指定します。
8
コントロールプレーンのパブリックロードバランサーを指定します。
注記

ユーザー定義のアウトバウンドルーティングを持つプライベート OpenShift Container Platform クラスターでは、publicLoadBalancer パラメーターを省略できます。

9
コントロールプレーンのサブネットを指定します。
10
コントロールプレーンのユーザーデータシークレットを指定します。この値は変更しないでください。
11
すべての障害ドメインに対して単一のゾーンを使用するクラスターのゾーン設定を指定します。
注記

クラスターが障害ドメインごとに異なるゾーンを使用するように設定されている場合、このパラメーターは障害ドメインで設定されます。各障害ドメインに異なるゾーンを使用する場合にプロバイダー仕様でこの値を指定しても、その値は Control Plane Machine Set Operator によって無視されます。

10.5.2.1.2. Azure 障害ドメイン設定のサンプル
リンクのコピー

障害ドメインのコントロールプレーンマシンセットの概念は、Azure 可用性ゾーン の既存の Azure 概念に似ています。ControlPlaneMachineSet CR は、可能な場合、コントロールプレーンマシンを複数の障害ドメインに分散します。

コントロールプレーンマシンセットで Azure 障害ドメインを設定するときは、可用性ゾーン名を指定する必要があります。Azure クラスターは、複数のゾーンにまたがる単一のサブネットを使用します。

Azure 障害ドメインの値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    machines_v1beta1_machine_openshift_io:
      failureDomains:
        azure:
        - zone: "1"
1 

        - zone: "2"
        - zone: "3"
        platform: Azure
2 

# ...
Copy to Clipboard Toggle word wrap

1
zone の各インスタンスは、障害ドメインの Azure アベイラビリティーゾーンを指定します。
注記

すべての障害ドメインに対して単一のゾーンを使用するようにクラスターが設定されている場合、zone パラメーターは、障害ドメイン設定ではなくプロバイダー仕様で設定されます。

2
クラウドプロバイダーのプラットフォーム名を指定します。この値は変更しないでください。

10.5.2.2. コントロールプレーンマシンの Microsoft Azure 機能を有効にする
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、機能を有効にします。

10.5.2.2.1. API サーバーをプライベートに制限する
リンクのコピー

クラスターを Amazon Web Services (AWS) にデプロイした後に、プライベートゾーンのみを使用するように API サーバーを再設定することができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとして Web コンソールにアクセスできること。

手順

  1. クラウドプロバイダーの Web ポータルまたはコンソールで、次の操作を行います。

    1. 適切なロードバランサーコンポーネントを見つけて削除します。
    2. パブリックゾーンの api.$clustername.$yourdomain DNS エントリーを削除します。

  2. コントロールプレーンマシンセットのカスタムリソースで次の行を削除して、外部ロードバランサーを削除します。 

    # ...
providerSpec:
  value:
# ...
    loadBalancers:
    - name: lk4pj-ext
    1 
    
      type: network
    2 
    
    - name: lk4pj-int
      type: network
# ...
    Copy to Clipboard Toggle word wrap
    1
    -ext で終わる外部ロードバランサーの name 値を削除します。
    2
    外部ロードバランサーの type 値を削除します。
10.5.2.2.2. 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 マーケットプレイスを使用したイメージのインストールは、64 ビット ARM インスタンスを備えたクラスターではサポートされていません。

Azure Marketplace イメージを使用するには、コンピュートマシンの RHCOS イメージのみを変更する必要があります。コントロールプレーンマシンおよびインフラストラクチャーノードに OpenShift Container Platform サブスクリプションは必要なく、デフォルトでパブリック RHCOS デフォルトイメージが使用されるため、Azure 請求書にサブスクリプションコストは発生しません。したがって、クラスターのデフォルトのブートイメージやコントロールプレーンのブートイメージは変更しないでください。Azure Marketplace イメージを適用すると追加のライセンスコストが発生し、これは修正できません。

前提条件

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

手順

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

    • 北米: 

      $  az vm image list --all --offer rh-ocp-worker --publisher redhat -o table
      Copy to Clipboard Toggle word wrap

      出力例

      Offer          Publisher       Sku                 Urn                                                             Version
-------------  --------------  ------------------  --------------------------------------------------------------  -----------------
rh-ocp-worker  RedHat          rh-ocp-worker       RedHat:rh-ocp-worker:rh-ocp-worker:4.17.2024100419              4.17.2024100419
rh-ocp-worker  RedHat          rh-ocp-worker-gen1  RedHat:rh-ocp-worker:rh-ocp-worker-gen1:4.17.2024100419         4.17.2024100419
      Copy to Clipboard Toggle word wrap

    • EMEA: 

      $  az vm image list --all --offer rh-ocp-worker --publisher redhat-limited -o table
      Copy to Clipboard Toggle word wrap

      出力例

      Offer          Publisher       Sku                 Urn                                                                     Version
-------------  --------------  ------------------  --------------------------------------------------------------          -----------------
rh-ocp-worker  redhat-limited  rh-ocp-worker       redhat-limited:rh-ocp-worker:rh-ocp-worker:4.17.2024100419              4.17.2024100419
rh-ocp-worker  redhat-limited  rh-ocp-worker-gen1  redhat-limited:rh-ocp-worker:rh-ocp-worker-gen1:4.17.2024100419         4.17.2024100419
      Copy to Clipboard Toggle word wrap

    注記

    コンピュートおよびコントロールプレーンノードで利用可能な最新のイメージを使用します。必要に応じて、VM はインストールプロセスの一部として自動的にアップグレードされます。

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

    • 北米: 

      $ az vm image show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
      Copy to Clipboard Toggle word wrap

    • EMEA: 

      $ az vm image show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
      Copy to Clipboard Toggle word wrap

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

    • 北米: 

      $ az vm image terms show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
      Copy to Clipboard Toggle word wrap

    • EMEA: 

      $ az vm image terms show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
      Copy to Clipboard Toggle word wrap

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

    • 北米: 

      $ az vm image terms accept --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
      Copy to Clipboard Toggle word wrap

    • EMEA: 

      $ az vm image terms accept --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
      Copy to Clipboard Toggle word wrap
  5. オファーのイメージの詳細 (具体的には publisher、offer、sku、および version の値) を記録します。

  6. オファーのイメージの詳細を使用して、マシンセット YAML ファイルの providerSpec セクションに次のパラメーターを追加します。

    Azure Marketplace マシンの providerSpec イメージの値の例

    providerSpec:
  value:
    image:
      offer: rh-ocp-worker
      publisher: redhat
      resourceID: ""
      sku: rh-ocp-worker
      type: MarketplaceWithPlan
      version: 413.92.2023101700
    Copy to Clipboard Toggle word wrap

10.5.2.2.3. Azure ブート診断の有効化
リンクのコピー

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

前提条件

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

手順

  • ストレージタイプに適用可能な diagnostics 設定を、マシンセット YAML ファイルの providerSpec フィールドに追加します。

    • Azure Managed ストレージアカウントの場合: 

      providerSpec:
  diagnostics:
    boot:
      storageAccountType: AzureManaged
      1
      Copy to Clipboard Toggle word wrap
      1
      Azure Managed ストレージアカウントを指定します。

    • Azure Unmanaged ストレージアカウントの場合: 

      providerSpec:
  diagnostics:
    boot:
      storageAccountType: CustomerManaged
      1 
      
      customerManaged:
        storageAccountURI: https://<storage-account>.blob.core.windows.net
      2
      Copy to Clipboard Toggle word wrap
      1
      Azure Unmanaged ストレージアカウントを指定します。
      2
      <storage-account> をストレージアカウントの名前に置き換えます。
      注記

      Azure Blob Storage データサービスのみサポートされています。

検証

  • Microsoft Azure ポータルで、マシンセットによってデプロイされたマシンの 起動診断 ページを確認し、マシンのシリアルログが表示されることを確認します。
10.5.2.2.4. Machine sets that deploy machines with ultra disks as data disks
リンクのコピー

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

10.5.2.2.4.1. マシンセットを使用した Ultra ディスクを持つマシンの作成
リンクのコピー

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

前提条件

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

手順

  1. 次のコマンドを実行して、master データシークレットを使用して openshift-machine-api namespace にカスタムシークレットを作成します。 

    $ oc -n openshift-machine-api \
get secret <role>-user-data \
    1 
    
--template='{{index .data.userData | base64decode}}' | jq > userData.txt
    2
    Copy to Clipboard Toggle word wrap
    1
    <role> を master に置き換えます。
    2
    新しいカスタムシークレットの名前として userData.txt を指定します。

  2. テキストエディターで、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"
    }
  ]
}
      Copy to Clipboard Toggle word wrap
      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 の値を指定します。

  3. 次のコマンドを実行して、無効化テンプレート値を disableTemplating.txt というファイルに抽出します。 

    $ oc -n openshift-machine-api get secret <role>-user-data \
    1 
    
--template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt
    Copy to Clipboard Toggle word wrap
    1
    <role> を master に置き換えます。

  4. 次のコマンドを実行して、userData.txt ファイルと disableTemplating.txt ファイルを組み合わせてデータシークレットファイルを作成します。 

    $ oc -n openshift-machine-api create secret generic <role>-user-data-x5 \
    1 
    
--from-file=userData=userData.txt \
--from-file=disableTemplating=disableTemplating.txt
    Copy to Clipboard Toggle word wrap
    1
    <role>-user-data-x5 には、シークレットの名前を指定します。<role> を master に置き換えます。

  5. 次のコマンドを実行して、コントロールプレーンマシンセットの CR を編集します。 

    $ oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster
    Copy to Clipboard Toggle word wrap

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

    apiVersion: machine.openshift.io/v1beta1
kind: ControlPlaneMachineSet
spec:
  template:
    spec:
      metadata:
        labels:
          disk: ultrassd
    1 
    
      providerSpec:
        value:
          ultraSSDCapability: Enabled
    2 
    
          dataDisks:
    3 
    
          - nameSuffix: ultrassd
            lun: 0
            diskSizeGB: 4
            deletionPolicy: Delete
            cachingType: None
            managedDisk:
              storageAccountType: UltraSSD_LRS
          userDataSecret:
            name: <role>-user-data-x5
    4
    Copy to Clipboard Toggle word wrap
    1
    このマシンセットによって作成されるノードを選択するために使用するラベルを指定します。この手順では、この値に disk.ultrassd を使用します。
    2 3
    これらの行により、Ultra ディスクの使用が可能になります。dataDisks には、スタンザ全体を含めます。
    4
    以前に作成したユーザーデータシークレットを指定します。<role> を master に置き換えます。

  7. 変更を保存します。

    • デフォルトの RollingUpdate 更新戦略を使用するクラスターの場合、Operator は自動的に変更をコントロールプレーン設定に伝達します。
    • OnDelete 更新戦略を使用するように設定されているクラスターの場合、コントロールプレーンマシンを手動で置き換える必要があります。

検証

  1. 次のコマンドを実行して、マシンが作成されていることを確認します。 

    $ oc get machines
    Copy to Clipboard Toggle word wrap

    マシンは Running 状態になっているはずです。

  2. 実行中でノードが接続されているマシンの場合、次のコマンドを実行してパーティションを検証します。 

    $ oc debug node/<node_name> -- chroot /host lsblk
    Copy to Clipboard Toggle word wrap

    このコマンドでは、oc debug node/<node_name> によりノード <node_name> 上でデバッグシェルを起動し、-- を指定してコマンドを渡します。渡されたコマンド chroot /host は、基盤となるホスト OS バイナリーへのアクセスを提供し、lsblk は、ホスト OS マシンに接続されているブロックデバイスを表示します。

次のステップ

  • コントロールプレーンで Ultra ディスクを使用するには、コントロールプレーンの Ultra ディスクマウントポイントを使用するようにワークロードを再設定します。

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

10.5.2.2.4.2.1. ウルトラディスク設定が正しくありません
リンクのコピー

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

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

StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
Copy to Clipboard Toggle word wrap
  • この問題を解決するには、マシンセットの設定が正しいことを確認してください。
10.5.2.2.4.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>."
Copy to Clipboard Toggle word wrap
  • この問題を解決するには、サポートされている環境でこの機能を使用していること、およびマシンセットの設定が正しいことを確認してください。
10.5.2.2.4.2.3. ディスクを削除できません
リンクのコピー

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

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

Azure に暗号化キーを指定して、停止中に管理ディスクのデータを暗号化できます。Machine 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
    Copy to Clipboard Toggle word wrap
10.5.2.2.6. マシンセットを使用した Azure 仮想マシンの信頼された起動の設定
リンクのコピー

OpenShift Container Platform 4.19 は、Azure 仮想マシンの信頼された起動をサポートします。マシンセットの YAML ファイルを編集することで、マシンセットがデプロイメントするマシンに使用する信頼できる起動オプションを設定できます。たとえば、セキュアブートや専用の仮想 Trusted Platform Module (vTPM) インスタンスなどの UEFI セキュリティー機能を使用するようにこれらのマシンを設定できます。

注記

一部の機能の組み合わせでは、無効な設定が発生します。

Expand
表10.2 UEFI 機能の組み合わせの互換性
Secure Boot[1]vTPM[2]有効な設定

Enabled

Enabled

はい

Enabled

無効

はい

Enabled

省略

はい

無効

Enabled

はい

省略

Enabled

はい

無効

無効

いいえ

省略

無効

いいえ

省略

省略

いいえ

  1. secureBoot フィールドの使用。
  2. virtualizedTrustedPlatformModule フィールドの使用。

関連する機能の詳細は、Azure 仮想マシンの信頼された起動 に関する Microsoft Azure のドキュメントを参照してください。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下の次のセクションを編集して、有効な設定を指定します。

    UEFI セキュアブートと vTPM が有効になっている有効な設定例

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    machines_v1beta1_machine_openshift_io:
      spec:
        providerSpec:
          value:
            securityProfile:
              settings:
                securityType: TrustedLaunch
    1 
    
                trustedLaunch:
                  uefiSettings:
    2 
    
                    secureBoot: Enabled
    3 
    
                    virtualizedTrustedPlatformModule: Enabled
    4 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    Azure 仮想マシンの信頼された起動の使用を有効にします。この値は、すべての有効な設定に必要です。
    2
    使用する UEFI セキュリティー機能を指定します。このセクションは、すべての有効な設定に必要です。
    3
    UEFI セキュアブートを有効にします。
    4
    vTPM の使用を有効にします。

検証

  • Azure ポータルで、マシンセットによってデプロイされたマシンの詳細を確認し、信頼された起動オプションが設定した値と一致することを確認します。
10.5.2.2.7. マシンセットを使用した Azure 機密仮想マシンの設定
リンクのコピー

OpenShift Container Platform 4.19 は、Azure 機密仮想マシンをサポートします。

注記

現在、Confidential 仮想マシンは 64 ビット ARM アーキテクチャーではサポートされていません。

マシンセットの YAML ファイルを編集することにより、マシンセットがデプロイするマシンに使用する機密仮想マシンオプションを設定できます。たとえば、セキュアブートや専用の仮想 Trusted Platform Module (vTPM) インスタンスなどの UEFI セキュリティー機能を使用するようにこれらのマシンを設定できます。

警告

すべてのインスタンスタイプが機密仮想マシンをサポートしているわけではありません。機密仮想マシンを使用するように設定されているコントロールプレーンマシンセットのインスタンスタイプを、互換性のないタイプに変更しないでください。互換性のないインスタンスタイプを使用すると、クラスターが不安定になる可能性があります。

関連する機能の詳細は、機密仮想マシン に関する Microsoft Azure のドキュメントを参照してください。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下の次のセクションを編集します。

    設定例

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    spec:
      providerSpec:
        value:
          osDisk:
            # ...
            managedDisk:
              securityProfile:
    1 
    
                securityEncryptionType: VMGuestStateOnly
    2 
    
            # ...
          securityProfile:
    3 
    
            settings:
                securityType: ConfidentialVM
    4 
    
                confidentialVM:
                  uefiSettings:
    5 
    
                    secureBoot: Disabled
    6 
    
                    virtualizedTrustedPlatformModule: Enabled
    7 
    
          vmSize: Standard_DC16ads_v5
    8 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    機密仮想マシンを使用する場合のマネージドディスクのセキュリティープロファイル設定を指定します。
    2
    Azure 仮想マシンゲスト状態 (VMGS) ブロブの暗号化を有効にします。この設定には vTPM の使用が必要です。
    3
    機密仮想マシンのセキュリティープロファイル設定を指定します。
    4
    機密仮想マシンの使用を有効にします。この値は、すべての有効な設定に必要です。
    5
    使用する UEFI セキュリティー機能を指定します。このセクションは、すべての有効な設定に必要です。
    6
    UEFI セキュアブートを無効にします。
    7
    vTPM の使用を有効にします。
    8
    機密仮想マシンをサポートするインスタンスタイプを指定します。

検証

  • Azure ポータルで、マシンセットによってデプロイされたマシンの詳細を確認し、機密仮想マシンオプションが設定した値に一致していることを確認します。
10.5.2.2.8. マシンセットを使用した Capacity Reservation の設定
リンクのコピー

OpenShift Container Platform バージョン 4.19 以降では、Microsoft Azure クラスター上の Capacity Reservation グループを使用したオンデマンド Capacity Reservation がサポートされます。

定義した容量要求のパラメーターに一致する利用可能なリソースにマシンをデプロイするようにマシンセットを設定できます。これらのパラメーターは、予約する仮想マシンのサイズ、リージョン、インスタンスの数を指定します。Azure サブスクリプションのクォータが容量要求に対応できる場合は、デプロイメントが成功します。

この Azure オファリングの制限事項や推奨されるユースケースなどの詳細は、Microsoft Azure ドキュメントの On-demand Capacity Reservation を参照してください。

注記

マシンセットの既存の Capacity Reservation 設定は変更できません。別の Capacity Reservation グループを使用するには、マシンセットと、以前のマシンセットがデプロイしたマシンを置き換える必要があります。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • Capacity Reservation 予約グループを作成している。詳細は、Microsoft Azure のドキュメント Create a Capacity Reservation を参照してください。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下の次のセクションを編集します。

    設定例

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    machines_v1beta1_machine_openshift_io:
      spec:
        providerSpec:
          value:
            capacityReservationGroupID: <capacity_reservation_group>
    1 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    マシンをデプロイするマシンセットの Capacity Reservation グループの ID を指定します。

検証

  • マシンのデプロイメントを確認するには、次のコマンドを実行して、マシンセットが作成したマシンをリスト表示します。 

    $ oc get machine \
  -n openshift-machine-api \
  -l machine.openshift.io/cluster-api-machine-role=master
    Copy to Clipboard Toggle word wrap

    出力で、リストされたマシンの特性が Capacity Reservation のパラメーターと一致していることを確認します。

10.5.2.2.9. Microsoft Azure 仮想マシンのネットワークアクセラレート
リンクのコピー

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

10.5.2.2.9.1. 制限事項
リンクのコピー

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

  • Accelerated Networking は、Machine API が動作しているクラスターでのみサポートされます。

  • 高速ネットワークには、少なくとも 4 つの vCPU を含む Azure VM サイズが必要です。この要件を満たすには、マシンセットの vmSize の値を変更します。Azure VM サイズの詳細は、Microsoft Azure のドキュメント を参照してください。

10.5.2.2.9.2. 既存の Microsoft Azure クラスターでの Accelerated Networking の有効化
リンクのコピー

マシンセット YAML ファイルに acceleratedNetworking を追加することで、Azure で Accelerated Networking を有効にすることができます。

前提条件

  • Machine API が動作している既存の Microsoft Azure クラスターがある。

手順

  • 以下を providerSpec フィールドに追加します。 

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

検証

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

10.5.3. Google Cloud Platform のコントロールプレーン設定オプション
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、Google Cloud Platform (GCP) コントロールプレーンマシンの設定を変更し、機能を有効にすることができます。コントロールプレーンマシンセットへの更新を保存すると、設定された 更新ストラテジー に従って Control Plane Machine Set Operator がコントロールプレーンマシンを更新します。

10.5.3.1. Google Cloud Platform クラスターを設定するためのサンプル YAML
リンクのコピー

次の YAML スニペットの例は、GCP クラスターのプロバイダーの仕様と障害ドメインの設定を示しています。

10.5.3.1.1. GCP プロバイダーの仕様例
リンクのコピー

既存のクラスター用のコントロールプレーンマシンセットを作成する場合、プロバイダーの仕様が、インストールプログラムによって作成されるコントロールプレーンマシンのカスタムリソース (CR) の providerSpec 設定と一致する必要があります。CR の障害ドメインセクションに設定されているフィールドは省略できます。

OpenShift CLI を使用して取得した値

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

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

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

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

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

$ oc -n openshift-machine-api \
  -o jsonpath='{.spec.template.machines_v1beta1_machine_openshift_io.spec.providerSpec.value.disks[0].image}{"\n"}' \
  get ControlPlaneMachineSet/cluster
Copy to Clipboard Toggle word wrap

GCP providerSpec の値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            apiVersion: machine.openshift.io/v1beta1
            canIPForward: false
            credentialsSecret:
              name: gcp-cloud-credentials
1 

            deletionProtection: false
            disks:
            - autoDelete: true
              boot: true
              image: <path_to_image>
2 

              labels: null
              sizeGb: 200
              type: pd-ssd
            kind: GCPMachineProviderSpec
3 

            machineType: e2-standard-4
            metadata:
              creationTimestamp: null
            metadataServiceOptions: {}
            networkInterfaces:
            - network: <cluster_id>-network
              subnetwork: <cluster_id>-master-subnet
            projectID: <project_name>
4 

            region: <region>
5 

            serviceAccounts:
6 

            - email: <cluster_id>-m@<project_name>.iam.gserviceaccount.com
              scopes:
              - https://www.googleapis.com/auth/cloud-platform
            shieldedInstanceConfig: {}
            tags:
            - <cluster_id>-master
            targetPools:
            - <cluster_id>-api
            userDataSecret:
              name: master-user-data
7 

            zone: ""
8
Copy to Clipboard Toggle word wrap

1
クラスターのシークレット名を指定します。この値は変更しないでください。
2
ディスクの作成に使用されたイメージへのパスを指定します。

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

  • OpenShift Container Platform: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-413-x86-64-202305021736
  • OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-413-x86-64-202305021736
  • OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-413-x86-64-202305021736
3
クラウドプロバイダープラットフォームのタイプを指定します。この値は変更しないでください。
4
クラスターに使用する GCP プロジェクトの名前を指定します。
5
クラスターの GCP リージョンを指定します。
6
単一のサービスアカウントを指定します。複数のサービスアカウントはサポートされていません。
7
コントロールプレーンのユーザーデータシークレットを指定します。この値は変更しないでください。
8
このパラメーターは障害ドメインで設定され、ここでは空の値で表示されます。このパラメーターに指定された値が障害ドメインの値と異なる場合、Operator はそれを障害ドメインの値で上書きします。
10.5.3.1.2. GCP 障害ドメインの設定例
リンクのコピー

障害ドメインのコントロールプレーンマシンセットの概念は、既存の GCP の ゾーン の概念に似ています。ControlPlaneMachineSet CR は、可能な場合、コントロールプレーンマシンを複数の障害ドメインに分散します。

コントロールプレーンマシンセットで GCP 障害ドメインを設定する場合は、使用するゾーン名を指定する必要があります。

GCP 障害ドメインの値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    machines_v1beta1_machine_openshift_io:
      failureDomains:
        gcp:
        - zone: <gcp_zone_a>
1 

        - zone: <gcp_zone_b>
2 

        - zone: <gcp_zone_c>
        - zone: <gcp_zone_d>
        platform: GCP
3 

# ...
Copy to Clipboard Toggle word wrap

1
最初の障害ドメインの GCP ゾーンを指定します。
2
追加の障害ドメインを指定します。さらに障害ドメインが同じ方法で追加されます。
3
クラウドプロバイダーのプラットフォーム名を指定します。この値は変更しないでください。

10.5.3.2. コントロールプレーンマシンの Google Cloud Platform 機能を有効にする
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、機能を有効にします。

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

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

永続ディスクのタイプ、互換性、リージョン別の可用性、制限事項の詳細は、永続ディスク に関する GCP Compute Engine のドキュメントを参照してください。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下で以下の行を編集します。 

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
...
spec:
  template:
    spec:
      providerSpec:
        value:
          disks:
            type: pd-ssd
    1
    Copy to Clipboard Toggle word wrap
    1
    コントロールプレーンノードは、pd-ssd ディスクタイプを使用する必要があります。

検証

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

マシンセットの YAML ファイルを編集することにより、マシンセットがデプロイするマシンに使用する Confidential VM オプションを設定できます。

Confidential VM の機能、互換性の詳細は、Confidential VM に関する GCP Compute Engine のドキュメントを参照してください。

注記

現在、Confidential 仮想マシンは 64 ビット ARM アーキテクチャーではサポートされていません。Confidential VM を使用する場合は、サポートされているリージョンを選択する必要があります。サポートされているリージョンと設定の詳細は、サポートされているゾーン に関する GCP Compute Engine のドキュメントを参照してください。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下の次のセクションを編集します。 

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
    machines_v1beta1_machine_openshift_io:
      spec:
        providerSpec:
          value:
            confidentialCompute: Enabled
    1 
    
            onHostMaintenance: Terminate
    2 
    
            machineType: n2d-standard-8
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    Confidential VM を有効にするかどうかを指定します。次の値が有効です。
    有効
    Confidential VM テクノロジーのデフォルトの選択を使用して Confidential VM を有効にします。デフォルトの選択は、AMD Secure Encrypted Virtualization (AMD SEV) です。
    無効
    Confidential VM を無効化します。
    AMDEncryptedVirtualization
    AMD SEV を使用して Confidential VM を有効化します。AMD SEV は c2d、n2d、c3d マシンをサポートします。
    AMDEncryptedVirtualizationNestedPaging
    AMD Secure Encrypted Virtualization Secure Nested Paging (AMD SEV-SNP) を使用して Confidential VM を有効化します。AMD SEV-SNP は n2d マシンをサポートします。
    IntelTrustedDomainExtensions
    Intel Trusted Domain Extensions (Intel TDX) を使用して Confidential VM を有効化します。Intel TDX は n2d マシンをサポートします。
    2
    ハードウェアやソフトウェアの更新など、ホストのメンテナンスイベント中の VM の動作を指定します。Confidential 仮想マシンを使用するマシンの場合は、この値を Terminate に設定する必要があります。これにより、VM が停止します。Confidential VM はライブ VM 移行をサポートしていません。
    3
    confidentialCompute フィールドで指定した Confidential VM オプションをサポートするマシンタイプを指定します。

検証

  • Google Cloud コンソールで、マシンセットによってデプロイされたマシンの詳細を確認し、Confidential VM オプションが設定した値に一致していることを確認します。
10.5.3.2.3. マシンセットを使用した Shielded VM オプションの設定
リンクのコピー

マシンセットの YAML ファイルを編集することで、マシンセットがデプロイメントするマシンに使用する Shielded VM オプションを設定できます。

Shielded VM の特徴と機能の詳細は、Shielded VM に関する GCP Compute Engine のドキュメントを参照してください。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下の次のセクションを編集します。 

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    spec:
      providerSpec:
        value:
          shieldedInstanceConfig:
    1 
    
            integrityMonitoring: Enabled
    2 
    
            secureBoot: Disabled
    3 
    
            virtualizedTrustedPlatformModule: Enabled
    4 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    このセクションでは、必要な Shielded VM オプションを指定します。
    2
    整合性監視を有効にするかどうかを指定します。有効な値は Disabled または Enabled です。
    注記

    整合性監視が有効になっている場合、仮想トラステッドプラットフォームモジュール (vTPM) を無効にしないでください。

    3
    UEFI セキュアブートを有効にするかどうかを指定します。有効な値は Disabled または Enabled です。
    4
    vTPM を有効にするかどうかを指定します。有効な値は Disabled または Enabled です。

検証

  • Google Cloud コンソールを使用して、マシンセットによってデプロイされたマシンの詳細を確認し、Shielded VM オプションが設定した値に一致していることを確認します。
10.5.3.2.4. マシンセットの顧客管理の暗号鍵の有効化
リンクのコピー

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

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

注記

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

手順

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

    $ 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
    Copy to Clipboard Toggle word wrap

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

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
...
spec:
  template:
    spec:
      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
    Copy to Clipboard Toggle word wrap
    1
    ディスク暗号化に使用される顧客管理の暗号鍵の名前。
    2
    KMS キーが属する KMS キーリングの名前。
    3
    KMS キーリングが存在する GCP の場所。
    4
    オプション: KMS キーリングが存在するプロジェクトの ID。プロジェクト ID が設定されていない場合、マシンセットが作成されたマシンセットの projectID が使用されます。
    5
    オプション: 指定の KMS キーの暗号化要求に使用されるサービスアカウント。サービスアカウントが設定されていない場合、Compute Engine のデフォルトのサービスアカウントが使用されます。

    更新された providerSpec オブジェクト設定を使用して新しいマシンが作成されると、ディスク暗号化キーが KMS キーで暗号化されます。

10.5.4. Nutanix のコントロールプレーン設定オプション
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、Nutanix コントロールプレーンマシンの設定を変更できます。コントロールプレーンマシンセットへの更新を保存すると、設定された 更新ストラテジー に従って Control Plane Machine Set Operator がコントロールプレーンマシンを更新します。

10.5.4.1. Nutanix クラスターを設定するためのサンプル YAML
リンクのコピー

次の YAML スニペットの例は、Nutanix クラスターのプロバイダー仕様の設定を示しています。

10.5.4.1.1. Nutanix プロバイダーの仕様例
リンクのコピー

既存のクラスター用のコントロールプレーンマシンセットを作成する場合、プロバイダーの仕様が、インストールプログラムによって作成されるコントロールプレーンマシンのカスタムリソース (CR) の providerSpec 設定と一致する必要があります。

OpenShift CLI を使用して取得した値

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

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

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

$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
Copy to Clipboard Toggle word wrap

Nutanix providerSpec の値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            apiVersion: machine.openshift.io/v1
            bootType: ""
1 

            categories:
2 

            - key: <category_name>
              value: <category_value>
            cluster:
3 

              type: uuid
              uuid: <cluster_uuid>
            credentialsSecret:
              name: nutanix-credentials
4 

            image:
5 

              name: <cluster_id>-rhcos
              type: name
            kind: NutanixMachineProviderConfig
6 

            memorySize: 16Gi
7 

            metadata:
              creationTimestamp: null
            project:
8 

              type: name
              name: <project_name>
            subnets:
9 

            - type: uuid
              uuid: <subnet_uuid>
            systemDiskSize: 120Gi
10 

            userDataSecret:
              name: master-user-data
11 

            vcpuSockets: 8
12 

            vcpusPerSocket: 1
13
Copy to Clipboard Toggle word wrap

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

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

2
コントロールプレーンマシンに適用する 1 つ以上の Nutanix Prism カテゴリーを指定します。このスタンザには、Prism Central に存在するカテゴリーのキーと値のペアの key および value パラメーターが必要です。カテゴリーの詳細は、カテゴリー管理 を参照してください。
3
Nutanix Prism Element のクラスター設定を指定します。この例のクラスタータイプは uuid であるため、uuid スタンザがあります。
注記

OpenShift Container Platform バージョン 4.15 以降を使用するクラスターは、障害ドメイン設定を使用できます。

クラスターが障害ドメインを使用する場合は、障害ドメインでこのパラメーターを設定します。障害ドメインを使用する場合にプロバイダー仕様でこの値を指定しても、その値は Control Plane Machine Set Operator によって無視されます。

4
クラスターのシークレット名を指定します。この値は変更しないでください。
5
ディスクの作成に使用されたイメージを指定します。
6
クラウドプロバイダープラットフォームのタイプを指定します。この値は変更しないでください。
7
コントロールプレーンマシンに割り当てられるメモリーを指定します。
8
クラスターに使用する Nutanix プロジェクトを指定します。この例のプロジェクトタイプは name であるため、name スタンザがあります。
9
1 つ以上の Prism Element サブネットオブジェクトを指定します。この例では、サブネットタイプは uuid であるため、uuid スタンザがあります。クラスター内の Prism Element 障害ドメインごとに最大 32 個のサブネットがサポートされます。
重要

OpenShift Container Platform バージョン 4.18 には、次の既知の問題があります。これらの問題は、コントロールプレーンマシンセットを使用して既存の Nutanix クラスターに複数のサブネットを設定する場合に発生します。

  • subnets スタンザ内の既存サブネットの上にサブネットを追加すると、コントロールプレーンノードが Deleting 状態のままになります。回避策として、subnets スタンザ内の既存のサブネット配下にのみサブネットを追加します。
  • サブネットを追加した後、更新されたコントロールプレーンマシンが Nutanix コンソールに表示されても、OpenShift Container Platform クラスターにアクセスできないことがあります。この問題に対する回避策はありません。

これらの問題は、サブネットが障害ドメインまたはプロバイダー仕様で指定されているかどうかに関係なく、サブネットを設定するためにコントロールプレーンマシンセットを使用するクラスターで発生します。詳細は、OCPBUGS-50904 を参照してください。

指定したサブネットのいずれかの CIDR IP アドレス接頭辞に、OpenShift Container Platform クラスターが使用する仮想 IP アドレスが含まれている必要があります。すべてのサブネット UUID 値が一意である必要があります。

注記

OpenShift Container Platform バージョン 4.15 以降を使用するクラスターは、障害ドメイン設定を使用できます。

クラスターが障害ドメインを使用する場合は、障害ドメインでこのパラメーターを設定します。障害ドメインを使用する場合にプロバイダー仕様でこの値を指定しても、その値は Control Plane Machine Set Operator によって無視されます。

10
コントロールプレーンマシンの VM ディスクサイズを指定します。
11
コントロールプレーンのユーザーデータシークレットを指定します。この値は変更しないでください。
12
コントロールプレーンマシンに割り当てられる vCPU ソケットの数を指定します。
13
各コントロールプレーン vCPU ソケットの vCPU の数を指定します。
10.5.4.1.2. Nutanix クラスターの障害ドメイン
リンクのコピー

Nutanix クラスターの障害ドメイン設定を追加または更新するには、整合性のある変更を複数のリソースに加える必要があります。次の操作が必要です。

  1. クラスターインフラストラクチャーのカスタムリソース (CR) を変更します。
  2. クラスターコントロールプレーンマシンセットの CR を変更します。
  3. コンピュートマシンセットの CR を変更または置き換えます。

詳細は、インストール後の設定 コンテンツの「既存の Nutanix クラスターへの障害ドメインの追加」を参照してください。

10.5.5. Red Hat OpenStack Platform のコントロールプレーン設定オプション
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、Red Hat OpenStack Platform (RHOSP) コントロールプレーンマシンの設定を変更し、機能を有効にすることができます。コントロールプレーンマシンセットへの更新を保存すると、設定された 更新ストラテジー に従って Control Plane Machine Set Operator がコントロールプレーンマシンを更新します。

10.5.5.1. Red Hat OpenStack Platform (RHOSP) クラスターを設定するためのサンプル YAML
リンクのコピー

次の YAML スニペットの例は、RHOSP クラスターのプロバイダーの仕様と障害ドメインの設定を示しています。

10.5.5.1.1. RHOSP プロバイダーの仕様例
リンクのコピー

既存のクラスター用のコントロールプレーンマシンセットを作成する場合、プロバイダーの仕様が、インストールプログラムによって作成されるコントロールプレーンマシンのカスタムリソース (CR) の providerSpec 設定と一致する必要があります。

OpenStack providerSpec の値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            apiVersion: machine.openshift.io/v1alpha1
            cloudName: openstack
            cloudsSecret:
              name: openstack-cloud-credentials
1 

              namespace: openshift-machine-api
            flavor: m1.xlarge
2 

            image: ocp1-2g2xs-rhcos
            kind: OpenstackProviderSpec
3 

            metadata:
              creationTimestamp: null
            networks:
            - filter: {}
              subnets:
              - filter:
                  name: ocp1-2g2xs-nodes
                  tags: openshiftClusterID=ocp1-2g2xs
            securityGroups:
            - filter: {}
              name: ocp1-2g2xs-master
4 

            serverGroupName: ocp1-2g2xs-master
            serverMetadata:
              Name: ocp1-2g2xs-master
              openshiftClusterID: ocp1-2g2xs
            tags:
            - openshiftClusterID=ocp1-2g2xs
            trunk: true
            userDataSecret:
              name: master-user-data
Copy to Clipboard Toggle word wrap

1
クラスターのシークレット名。この値は変更しないでください。
2
コントロールプレーンの RHOSP フレーバータイプ。
3
RHOSP クラウドプロバイダーのプラットフォームタイプ。この値は変更しないでください。
4
コントロールプレーンマシンのセキュリティーグループ。
10.5.5.1.2. RHOSP 障害ドメイン設定のサンプル
リンクのコピー

障害ドメインのコントロールプレーンマシンセットの概念は、既存の Red Hat OpenStack Platform (RHOSP) の アベイラビリティーゾーン の概念に似ています。ControlPlaneMachineSet CR は、可能な場合、コントロールプレーンマシンを複数の障害ドメインに分散します。

次の例は、複数の Nova アベイラビリティーゾーンと Cinder アベイラビリティーゾーンの使用を示しています。

OpenStack 障害ドメインの値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    machines_v1beta1_machine_openshift_io:
      failureDomains:
        platform: OpenStack
        openstack:
        - availabilityZone: nova-az0
          rootVolume:
            availabilityZone: cinder-az0
        - availabilityZone: nova-az1
          rootVolume:
            availabilityZone: cinder-az1
        - availabilityZone: nova-az2
          rootVolume:
            availabilityZone: cinder-az2
# ...
Copy to Clipboard Toggle word wrap

10.5.5.2. コントロールプレーンマシンの Red Hat OpenStack Platform (RHOSP) 機能の有効化
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、機能を有効にします。

コントロールプレーンマシンセットのカスタムリソースの仕様を更新することで、コントロールプレーンマシンが使用する Red Hat OpenStack Platform (RHOSP) コンピュートサービス (Nova) フレーバーを変更できます。

RHOSP では、フレーバーはコンピューティングインスタンスのコンピュート、メモリー、およびストレージ容量を定義します。フレーバーのサイズを増減することで、コントロールプレーンを垂直方向にスケールできます。

前提条件

  • RHOSP クラスターはコントロールプレーンマシンセットを使用します。

手順

  1. providerSpec フィールドの下で以下の行を編集します。 

    providerSpec:
  value:
# ...
    flavor: m1.xlarge
    1
    Copy to Clipboard Toggle word wrap
    1
    既存の選択と同じベースを持つ RHOSP フレーバータイプを指定します。たとえば、m6i.xlarge を m6i.2xlarge または m6i.4xlarge に変更できます。垂直方向のスケーリングのニーズに応じて、より大きいフレーバーまたはより小さいフレーバーを選択できます。
  2. 変更を保存します。

変更を保存すると、マシンは選択したフレーバーを使用するマシンに置き換えられます。

10.5.6. VMware vSphere のコントロールプレーン設定オプション
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、VMware vSphere コントロールプレーンマシンの設定を変更できます。コントロールプレーンマシンセットへの更新を保存すると、設定された 更新ストラテジー に従って Control Plane Machine Set Operator がコントロールプレーンマシンを更新します。

10.5.6.1. VMware vSphere クラスターを設定するためのサンプル YAML
リンクのコピー

次の YAML スニペットの例は、vSphere クラスターのプロバイダーの仕様と障害ドメインの設定を示しています。

10.5.6.1.1. VMware vSphere プロバイダーの仕様例
リンクのコピー

既存のクラスター用のコントロールプレーンマシンセットを作成する場合、プロバイダーの仕様が、インストールプログラムによって作成されるコントロールプレーンマシンのカスタムリソース (CR) の providerSpec 設定と一致する必要があります。

vSphere providerSpec の値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
      spec:
        providerSpec:
          value:
            apiVersion: machine.openshift.io/v1beta1
            credentialsSecret:
              name: vsphere-cloud-credentials
1 

            dataDisks:
2 

            - name: "<disk_name>"
              provisioningMode: "<mode>"
              sizeGiB: 20
            diskGiB: 120
3 

            kind: VSphereMachineProviderSpec
4 

            memoryMiB: 16384
5 

            metadata:
              creationTimestamp: null
            network:
6 

              devices:
              - networkName: <vm_network_name>
            numCPUs: 4
7 

            numCoresPerSocket: 4
8 

            snapshot: ""
            template: <vm_template_name>
9 

            userDataSecret:
              name: master-user-data
10 

            workspace:
11 

              datacenter: <vcenter_data_center_name>
12 

              datastore: <vcenter_datastore_name>
13 

              folder: <path_to_vcenter_vm_folder>
14 

              resourcePool: <vsphere_resource_pool>
15 

              server: <vcenter_server_ip>
16
Copy to Clipboard Toggle word wrap

1
クラスターのシークレット名を指定します。この値は変更しないでください。
2
1 つ以上のデータディスク定義を指定します。詳細は、「マシンセットを使用してデータディスクを設定する」を参照してください。
3
コントロールプレーンマシンの VM ディスクサイズを指定します。
4
クラウドプロバイダープラットフォームのタイプを指定します。この値は変更しないでください。
5
コントロールプレーンマシンに割り当てられるメモリーを指定します。
6
コントロールプレーンがデプロイされるネットワークを指定します。
注記

クラスターが障害ドメインを使用するように設定されている場合、このパラメーターは障害ドメインで設定されます。障害ドメインを使用する場合にプロバイダー仕様でこの値を指定しても、その値は Control Plane Machine Set Operator によって無視されます。

7
コントロールプレーンマシンに割り当てられる CPU の数を指定します。
8
各コントロールプレーン CPU のコア数を指定します。
9
user-5ddjd-rhcos など、使用する vSphere VM テンプレートを指定します。
注記

クラスターが障害ドメインを使用するように設定されている場合、このパラメーターは障害ドメインで設定されます。障害ドメインを使用する場合にプロバイダー仕様でこの値を指定しても、その値は Control Plane Machine Set Operator によって無視されます。

10
コントロールプレーンのユーザーデータシークレットを指定します。この値は変更しないでください。
11
コントロールプレーンのワークスペースの詳細を指定します。
注記

クラスターが障害ドメインを使用するように設定されている場合、これらのパラメーターは障害ドメインで設定されます。障害ドメインを使用する場合にプロバイダー仕様でこれらの値を指定しても、それらの値は Control Plane Machine Set Operator によって無視されます。

12
コントロールプレーンの vCenter データセンターを指定します。
13
コントロールプレーンの vCenter データストアを指定します。
14
/dc1/vm/user-inst-5ddjd などの vCenter の vSphere 仮想マシンフォルダーへのパスを指定します。
15
仮想マシンの vSphere リソースプールを指定します。
16
vCenter サーバーの IP または完全修飾ドメイン名を指定します。
10.5.6.1.2. VMware vSphere 障害ドメインの設定例
リンクのコピー

VMware vSphere インフラストラクチャーでは、クラスター全体のインフラストラクチャーのカスタムリソース定義 (CRD) である infrastructures.config.openshift.io によってクラスターの障害ドメインが定義されます。ControlPlaneMachineSet カスタムリソース (CR) の providerSpec は、コントロールプレーンマシンセットがコントロールプレーンノードが適切な障害ドメインにデプロイされるようにするために使用する障害ドメインの名前を指定します。障害ドメインは、コントロールプレーンマシンセット、vCenter データセンター、vCenter データストア、およびネットワークで構成されるインフラストラクチャーリソースです。

障害ドメインリソースを使用すると、コントロールプレーンマシンセットを使用して、コントロールプレーンマシンを別のクラスターまたはデータセンターにデプロイできます。また、コントロールプレーンマシンセットは、定義された障害ドメイン全体でコントロールプレーンマシンのバランスをとり、インフラストラクチャーにフォールトトレランス機能を提供します。

注記

ControlPlaneMachineSet CR の ProviderSpec 設定を変更すると、コントロールプレーンマシンセットによって、プライマリーインフラストラクチャーと各障害ドメインインフラストラクチャーにデプロイされているすべてのコントロールプレーンマシンが更新されます。

VMware vSphere 障害ドメインの値の例

apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
metadata:
  name: cluster
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    machines_v1beta1_machine_openshift_io:
      failureDomains:
1 

        platform: VSphere
        vsphere:
2 

        - name: <failure_domain_name_1>
        - name: <failure_domain_name_2>
# ...
Copy to Clipboard Toggle word wrap

1
OpenShift Container Platform クラスターノードの vCenter の場所を指定します。
2
コントロールプレーンマシンセットの障害ドメインを名前で指定します。
重要

このセクションの各 name フィールドの値は、クラスター全体のインフラストラクチャー CRD の failureDomains.name フィールドの対応する値と一致する必要があります。次のコマンドを実行すると、failureDomains.name フィールドの値を見つけることができます。 

$ oc get infrastructure cluster -o=jsonpath={.spec.platformSpec.vsphere.failureDomains[0].name}
Copy to Clipboard Toggle word wrap

name フィールドは、ControlPlaneMachineSet CR で指定できる、サポートされている唯一の障害ドメインフィールドです。

各障害ドメインのリソースを定義するクラスター全体のインフラストラクチャー CRD の例は、「vSphere 上のクラスターに複数のリージョンとゾーンを指定する」を参照してください。

10.5.6.2. コントロールプレーンマシンの VMware vSphere 機能を有効にする
リンクのコピー

コントロールプレーンマシンセットの値を更新することで、機能を有効にします。

10.5.6.2.1. マシンセットの使用によるマシンへのタグの追加
リンクのコピー

OpenShift Container Platform は、作成する各仮想マシンにクラスター固有のタグを追加します。インストールプログラムはこれらのタグを使用して、クラスターをアンインストールするときに削除する仮想マシンを選択します。

仮想マシンに割り当てられたクラスター固有のタグのほかに、プロビジョニングする仮想マシンに最大 10 個の vSphere タグを追加するようにマシンセットを設定できます。

前提条件

  • cluster-admin 権限を持つアカウントを使用して、vSphere にインストールされた OpenShift Container Platform クラスターにアクセスできる。
  • クラスターに関連付けられた VMware vCenter コンソールにアクセスできる。
  • vCenter コンソールにタグを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. vCenter コンソールを使用して、マシンに追加するタグのタグ ID を検索します。

    1. vCenter コンソールにログインします。
    2. Home メニューから、Tags & Custom Attributes をクリックします。
    3. マシンに追加するタグを選択します。

    4. 選択したタグのブラウザー URL を使用して、タグ ID を特定します。

      タグ URL の例

      https://vcenter.example.com/ui/app/tags/tag/urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL/permissions
      Copy to Clipboard Toggle word wrap

      タグ ID の例

      urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL
      Copy to Clipboard Toggle word wrap

  2. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  3. providerSpec フィールドの下に次の行を編集します。 

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    spec:
      providerSpec:
        value:
          tagIDs:
    1 
    
          - <tag_id_value>
    2 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    このマシンセットがプロビジョニングするマシンに追加する最大 10 個のタグのリストを指定します。
    2
    マシンに追加するタグの値を指定します。たとえば、urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL です。
10.5.6.2.2. マシンセットを使用してデータディスクを設定する
リンクのコピー

VMware vSphere 上の OpenShift Container Platform クラスターは、仮想マシン (VM) コントローラーに最大 29 個のディスクを追加することをサポートします。

重要

vSphere データディスクの設定は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

データディスクを設定すると、ディスクを仮想マシンにアタッチし、etcd、コンテナーイメージなどの用途でデータを保存できます。データを分離すると、プライマリーディスクがいっぱいになるのを防ぎ、アップグレードなどの重要なアクティビティーに必要なリソースを確保できます。

注記

データディスクを追加すると、それらは仮想マシンにアタッチされ、RHCOS が指定する場所にマウントされます。

前提条件

  • vSphere 上の OpenShift Container Platform クラスターの OpenShift CLI (oc) に対する管理者アクセス権がある。

手順

  1. テキストエディターで、既存のマシンセットの YAML ファイルを開くか、新しいマシンセットを作成します。

  2. providerSpec フィールドの下に次の行を編集します。 

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    machines_v1beta1_machine_openshift_io:
      spec:
        providerSpec:
          value:
            dataDisks:
    1 
    
            - name: "<disk_name>"
    2 
    
              provisioningMode: "<mode>"
    3 
    
              sizeGiB: 20
    4 
    
            - name: "<disk_name>"
              provisioningMode: "<mode>"
              sizeGiB: 20
# ...
    Copy to Clipboard Toggle word wrap
    1
    1 - 29 個のデータディスク定義のコレクションを指定します。このサンプル設定は、2 つのデータディスク定義を含めるフォーマットを示しています。
    2
    データディスクの名前を指定します。名前は次の要件を満たしている必要があります。
    • 英数字で開始および終了する必要があります。
    • 英数字、ハイフン (-)、アンダースコア (_) のみで構成します。
    • 最大長は 80 文字です。
    3
    データディスクのプロビジョニング方法を指定します。この値が設定されていない場合、デフォルトで vSphere のデフォルトのストレージポリシーに設定されます。有効な値は、Thin、Thick、EagerlyZeroed です。
    4
    データディスクのサイズを GiB 単位で指定します。最大サイズは 16384 GiB です。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat