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

12.4. コントロールプレーンマシンセットを使用したコントロールプレーンマシンの管理

コントロールプレーンマシンセットは、コントロールプレーン管理のいくつかの重要な側面を自動化します。

12.4.1. コントロールプレーンマシンの置き換え

コントロールプレーンマシンが設定されているクラスター内のコントロールプレーンマシンを置き換えるには、マシンを手動で削除します。コントロールプレーンマシンセットは、コントロールプレーンマシンセットのカスタムリソース (CR) の仕様を使用するマシンに削除されたマシンを置き換えます。

前提条件

  • クラスターが Red Hat OpenStack Platform (RHOSP) 上で実行されており、アップグレードなどのためにコンピューティングサーバーを退避する必要がある場合は、次のコマンドを実行して、マシンが実行している RHOSP コンピューティングノードを無効にする必要があります。 

    $ openstack compute service set <target_node_host_name> nova-compute --disable

    詳細は、RHOSP ドキュメントの 移行の準備 を参照してください。

手順

  1. 次のコマンドを実行して、クラスター内のコントロールプレーンマシンを一覧表示します。 

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

  2. 次のコマンドを実行して、コントロールプレーンマシンを削除します。 

    $ oc delete machine \
  -n openshift-machine-api \
  <control_plane_machine_name> 1
    1
    削除するコントロールプレーンマシンの名前を指定します。
    注記

    複数のコントロールプレーンマシンを削除すると、設定された更新戦略に従ってコントロールプレーンマシンセットがそれらを置き換えます。

    • デフォルトの RollingUpdate 更新戦略を使用するクラスターの場合、Operator は、各マシンが交換されるまで、一度に 1 台のマシンを交換します。
    • OnDelete 更新戦略を使用するように設定されたクラスターの場合、Operator は必要なすべての代替マシンを同時に作成します。

    どちらの戦略も、コントロールプレーンマシンの交換中に etcd の健全性を維持します。

12.4.2. コントロールプレーン設定の更新

コントロールプレーンマシンセットのカスタムリソース (CR) の仕様を更新することで、コントロールプレーンのマシンの設定を変更できます。

Control Plane Machine Set Operator は、コントロールプレーンマシンを監視し、それらの設定をコントロールプレーンマシンセット CR の仕様と比較します。CR の仕様とコントロールプレーンマシンの設定との間に不一致がある場合、オペレータはそのコントロールプレーンマシンに交換用のマークを付けます。

注記

CR のパラメーターの詳細は、「コントロールプレーンマシンセットの設定」を参照してください。

前提条件

  • クラスターには、アクティブ化され機能している Control Plane Machine Set Operator があります。

手順

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

    $ oc edit controlplanemachineset.machine.openshift.io cluster \
  -n openshift-machine-api
  2. クラスター設定で更新するフィールドの値を変更します。
  3. 変更を保存します。

次のステップ

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

12.4.2.1. コントロールプレーン設定の自動更新

RollingUpdate 更新戦略により、変更がコントロールプレーン設定に自動的に反映されます。この更新戦略は、コントロールプレーンマシンセットのデフォルト設定です。

RollingUpdate 更新戦略を使用するクラスターの場合、Operator は、CR で指定された設定を使用して、代替のコントロールプレーンマシンを作成します。交換用のコントロールプレーンマシンの準備ができたら、Operator は、交換用にマークされたコントロールプレーンマシンを削除します。次に、交換用のマシンがコントロールプレーンに参加します。

複数のコントロールプレーンマシンが交換対象としてマークされている場合、Operator は、各マシンを交換するまでこの交換プロセスを一度に 1 台のマシンずつ繰り返すことで、交換中の etcd の健全性を保護します。

12.4.2.2. コントロールプレーン設定の手動更新

OnDelete 更新ストラテジーを使用して、マシンを手動で交換することで、コントロールプレーン設定に変更を反映できます。マシンを手動で置き換えると、変更をより広範囲に適用する前に、単一のマシンで設定への変更をテストできます。

OnDelete 更新ストラテジーを使用するように設定されているクラスターの場合、既存のマシンを削除すると、Operator は代替のコントロールプレーンマシンを作成します。代替のコントロールプレーンマシンの準備ができたら、etcd Operator を使用して既存のマシンを削除できます。次に、交換用のマシンがコントロールプレーンに参加します。

複数のコントロールプレーンマシンが削除された場合、Operator は必要なすべての代替マシンを同時に作成します。Operator は、複数のマシンがコントロールプレーンから同時に削除されるのを防ぐことで etcd の健全性を維持します。

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

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

12.4.3.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 2
    この行を削除します。

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

検証

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

    • 配置グループフィールドには、マシンセットの placementGroupName パラメーターに指定した値が含まれます。
    • インターフェイスタイプフィールドは、EFA を使用することを示します。

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

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

注記

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

重要

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

12.4.3.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.4.3.5. マシンを専有インスタンス (Dedicated Instance) としてデプロイするマシンセット

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

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

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

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

手順

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

    providerSpec:
  placement:
    tenancy: dedicated

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

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

12.4.4.1. API サーバーをプライベートに制限する

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

前提条件

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

手順

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

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

      • Azure の場合、ロードバランサーの api-internal ルールを削除します。
    2. パブリックゾーンの api.$clustername.$yourdomain DNS エントリーを削除します。

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

    providerSpec:
  value:
    loadBalancers:
    - name: lk4pj-ext 1
      type: network 2
    - name: lk4pj-int
      type: network
    1 2
    この行を削除します。

12.4.4.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:413.92.2023101700            413.92.2023101700
rh-ocp-worker  RedHat          rh-ocp-worker-gen1  RedHat:rh-ocp-worker:rh-ocp-worker-gen1:413.92.2023101700       413.92.2023101700

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

    注記

    インストールする OpenShift Container Platform のバージョンに関係なく、使用する Azure Marketplace イメージの正しいバージョンは 4.13 です。必要に応じて、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.4.4.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.4.4.4. Machine sets that deploy machines with ultra disks as data disks

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

関連情報

12.4.4.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.4.4.4.2. Ultra ディスクを有効にするマシンセットのリソースに関するトラブルシューティング

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

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

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

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

StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
  • この問題を解決するには、マシンセットの設定が正しいことを確認してください。
12.4.4.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.4.4.4.2.3. ディスクを削除できません

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

12.4.4.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.4.4.6. マシンセットを使用した Azure 仮想マシンの信頼された起動の設定

重要

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

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

OpenShift Container Platform 4.14 は、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:
    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.4.4.7. マシンセットを使用した Azure 機密仮想マシンの設定

重要

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

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

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

注記

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

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

12.4.4.8.1. 制限

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

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

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

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

OpenShift Container Platform バージョン 4.18 以降では、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.4.4.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.4.5. コントロールプレーンマシンの Google Cloud Platform 機能を有効にする

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

12.4.5.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.4.5.2. マシンセットを使用した Confidential VM の設定

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

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

注記

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

重要

OpenShift Container Platform 4.14 は、AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP) を備えた Confidential 仮想マシンなど、一部の 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.4.5.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.4.5.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.4.6. RHOSP コントロールプレーンマシンの設定の更新

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

12.4.6.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. 変更を保存します。

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.