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

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

12.5.1. Amazon Web Services のコントロールプレーン設定オプション

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

12.5.1.1. Amazon Web Services クラスターを設定するサンプル YAML

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

12.5.1.1.1. サンプル AWS プロバイダー仕様

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

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

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

サンプル 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

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
コントロールプレーンのユーザーデータシークレットを指定します。この値は変更しないでください。
12.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
# ...

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

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

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

12.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
# ...
    1
    -ext で終わる外部ロードバランサーの name 値を削除します。
    2
    外部ロードバランサーの type 値を削除します。

関連情報

12.5.1.2.2. コントロールプレーンマシンセットを使用して Amazon Web Services インスタンスタイプを変更する

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

前提条件

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

手順

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

    providerSpec:
  value:
    ...
    instanceType: <compatible_aws_instance_type> 1
    1
    前の選択と同じベースで、より大きな AWS インスタンスタイプを指定します。たとえば、m6i.xlarge を m6i.2xlarge または m6i.4xlarge に変更できます。
  2. 変更を保存します。
12.5.1.2.3. マシンセットを使用した Elastic Fabric Adapter インスタンスの配置グループへのマシンの割り当て

既存の 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
# ...
    1
    EFA をサポートする インスタンスタイプを指定します。
    2
    EFA ネットワークインターフェイスのタイプを指定します。
    3
    ゾーン (例: us-east-1a) を指定します。
    4
    リージョン (例: us-east-1) を指定します。
    5
    マシンをデプロイする既存の AWS 配置グループの名前を指定します。
    6
    オプション: マシンをデプロイする既存の AWS 配置グループのパーティション番号を指定します。

検証

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

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

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

注記

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

重要

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

12.5.1.2.4.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 の両方が許可されます。
12.5.1.2.5. マシンを専有インスタンス (Dedicated Instance) としてデプロイするマシンセット

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

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

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

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

手順

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

    providerSpec:
  placement:
    tenancy: dedicated

12.5.2. Microsoft Azure のコントロールプレーン設定オプション

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

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

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

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

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

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 によって無視されます。

12.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
# ...

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

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

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

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

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

12.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
# ...
    1
    -ext で終わる外部ロードバランサーの name 値を削除します。
    2
    外部ロードバランサーの type 値を削除します。

関連情報

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

手順

  1. 以下のいずれかのコマンドを実行して、利用可能なすべての 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-ocp-worker:4.15.2024072409              4.15.2024072409
rh-ocp-worker  RedHat          rh-ocp-worker-gen1  RedHat:rh-ocp-worker:rh-ocp-worker-gen1:4.15.2024072409         4.15.2024072409

    • 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.15.2024072409              4.15.2024072409
rh-ocp-worker  redhat-limited  rh-ocp-worker-gen1  redhat-limited:rh-ocp-worker:rh-ocp-worker-gen1:4.15.2024072409         4.15.2024072409

    注記

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

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

    • 北米: 

      $ 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>

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

    • 北米: 

      $ 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>

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

    • 北米: 

      $ 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>
  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

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

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

前提条件

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

手順

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

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

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

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

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

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

検証

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

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

関連情報

12.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
    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"
    }
  ]
}
      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
    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
    1
    <role>-user-data-x5 には、シークレットの名前を指定します。<role> を master に置き換えます。

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

    $ oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster

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

  7. 変更を保存します。

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

検証

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

    $ oc get machines

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

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

    $ oc debug node/<node-name> -- chroot /host lsblk

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

次のステップ

  • コントロールプレーンで Ultra ディスクを使用するには、コントロールプレーンの Ultra ディスクマウントポイントを使用するようにワークロードを再設定します。
12.5.2.2.4.2. Ultra ディスクを有効にするマシンセットのリソースに関するトラブルシューティング

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

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

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

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

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

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

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

関連情報

12.5.2.2.6. マシンセットを使用した Azure 仮想マシンの信頼された起動の設定
重要

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

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

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

注記

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

表12.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
# ...

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

検証

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

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

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

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

注記

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

マシンセットの YAML ファイルを編集することにより、マシンセットがデプロイするマシンに使用する Confidential VM オプションを設定できます。たとえば、セキュアブートや専用の仮想 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
# ...

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

検証

  • Azure ポータルで、マシンセットによってデプロイされたマシンの詳細を確認し、Confidential VM オプションが設定した値に一致していることを確認します。
12.5.2.2.8. Microsoft Azure 仮想マシンのネットワークアクセラレート

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

12.5.2.2.8.1. 制限

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

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

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

12.5.2.2.9. マシンセットを使用した Capacity Reservation の設定

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

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

この Azure インスタンスタイプの制限事項や推奨される使用例などの詳細は、オンデマンド容量予約 に関する Microsoft Azure のドキュメントを参照してください。

注記

マシンセットの既存の 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
# ...

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

検証

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

    $ oc get machine \
  -n openshift-machine-api \
  -l machine.openshift.io/cluster-api-machine-role=master

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

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

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

前提条件

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

手順

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

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

検証

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

12.5.3. Google Cloud Platform のコントロールプレーン設定オプション

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

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

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

12.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
イメージパス

<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

サンプル 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

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 はそれを障害ドメインの値で上書きします。
12.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
# ...

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

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

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

12.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
    1
    コントロールプレーンノードは、pd-ssd ディスクタイプを使用する必要があります。

検証

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

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

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

注記

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

重要

OpenShift Container Platform 4.17 は、AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP) を備えた機密仮想マシンなど、一部の Confidential Compute 機能をサポートしていません。

手順

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

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

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
...
spec:
  template:
    spec:
      providerSpec:
        value:
          confidentialCompute: Enabled 1
          onHostMaintenance: Terminate 2
          machineType: n2d-standard-8 3
...
    1
    Confidential VM を有効にするかどうかを指定します。有効な値は Disabled または Enabled です。
    2
    ハードウェアやソフトウェアの更新など、ホストのメンテナンスイベント中の VM の動作を指定します。Confidential VM を使用するマシンの場合は、この値を Terminate に設定する必要があります。これにより、VM が停止します。Confidential VM はライブ VM 移行をサポートしていません。
    3
    Confidential VM をサポートするマシンタイプを指定します。Confidential VM は、N2D および C2D シリーズのマシンタイプをサポートしています。

検証

  • Google Cloud コンソールで、マシンセットによってデプロイされたマシンの詳細を確認し、Confidential VM オプションが設定した値に一致していることを確認します。
12.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
# ...
    1
    このセクションでは、必要な Shielded VM オプションを指定します。
    2
    整合性監視を有効にするかどうかを指定します。有効な値は Disabled または Enabled です。
    注記

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

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

検証

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

関連情報

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

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

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

12.5.4. Nutanix のコントロールプレーン設定オプション

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

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

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

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

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

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

OpenShift Container Platform 4.17 では、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
サブネット設定を指定します。この例では、サブネットタイプは uuid であるため、uuid スタンザがあります。
注記

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

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

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

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

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

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

関連情報

12.5.5. Red Hat OpenStack Platform のコントロールプレーン設定オプション

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

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

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

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

1
クラスターのシークレット名。この値は変更しないでください。
2
コントロールプレーンの RHOSP フレーバータイプ。
3
RHOSP クラウドプロバイダーのプラットフォームタイプ。この値は変更しないでください。
4
コントロールプレーンマシンのセキュリティーグループ。
12.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
# ...

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

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

12.5.5.2.1. コントロールプレーンマシンセットを使用した RHOSP コンピュートフレーバーの変更

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

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

前提条件

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

手順

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

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

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

12.5.6. VMware vSphere のコントロールプレーン設定オプション

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

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

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

12.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
            diskGiB: 120 2
            kind: VSphereMachineProviderSpec 3
            memoryMiB: 16384 4
            metadata:
              creationTimestamp: null
            network: 5
              devices:
              - networkName: <vm_network_name>
            numCPUs: 4 6
            numCoresPerSocket: 4 7
            snapshot: ""
            template: <vm_template_name> 8
            userDataSecret:
              name: master-user-data 9
            workspace: 10
              datacenter: <vcenter_data_center_name> 11
              datastore: <vcenter_datastore_name> 12
              folder: <path_to_vcenter_vm_folder> 13
              resourcePool: <vsphere_resource_pool> 14
              server: <vcenter_server_ip> 15

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

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

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

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

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

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

11
コントロールプレーンの vCenter データセンターを指定します。
12
コントロールプレーンの vCenter データストアを指定します。
13
/dc1/vm/user-inst-5ddjd などの vCenter の vSphere 仮想マシンフォルダーへのパスを指定します。
14
仮想マシンの vSphere リソースプールを指定します。
15
vCenter サーバーの IP または完全修飾ドメイン名を指定します。
12.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_name1>
        - name: <failure_domain_name2>
# ...

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

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

$ oc get infrastructure cluster -o=jsonpath={.spec.platformSpec.vsphere.failureDomains[0].name}

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

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

関連情報

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

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

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

      タグ ID の例

      urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL

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

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

    apiVersion: machine.openshift.io/v1
kind: ControlPlaneMachineSet
# ...
spec:
  template:
    spec:
      providerSpec:
        value:
          tagIDs: 1
          - <tag_id_value> 2
# ...
    1
    このマシンセットがプロビジョニングするマシンに追加する最大 10 個のタグのリストを指定します。
    2
    マシンに追加するタグの値を指定します。たとえば、urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL です。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.