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

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

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

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

手順

  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 の健全性を維持します。

13.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 更新戦略を使用するように設定されているクラスターの場合、コントロールプレーンマシンを手動で置き換える必要があります。

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

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

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

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

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

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

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

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

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

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

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

13.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.xlargem6i.2xlarge または m6i.4xlarge に変更できます。
  2. 変更を保存します。

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

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

注記

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

重要

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

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

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

前提条件

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

手順

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

    providerSpec:
      value:
        metadataServiceOptions:
          authentication: Required 1
    1
    IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。

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

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

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

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

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

手順

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

    providerSpec:
      placement:
        tenancy: dedicated

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

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

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

13.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-ocpworker:4.8.2021122100               4.8.2021122100
      rh-ocp-worker  RedHat          rh-ocp-worker-gen1  RedHat:rh-ocp-worker:rh-ocp-worker-gen1:4.8.2021122100         4.8.2021122100

    • EMEA:

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

      出力例

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

    注記

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

  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. オファーのイメージの詳細 (具体的には publisheroffersku、および version の値) を記録します。
  6. オファーのイメージの詳細を使用して、マシンセット YAML ファイルの providerSpec セクションに次のパラメーターを追加します。

    Azure Marketplace マシンのサンプル providerSpec イメージ値

    providerSpec:
      value:
        image:
          offer: rh-ocp-worker
          publisher: redhat
          resourceID: ""
          sku: rh-ocp-worker
          type: MarketplaceWithPlan
          version: 4.8.2021122100

13.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 ポータルで、マシンセットによってデプロイされたマシンの 起動診断 ページを確認し、マシンのシリアルログが表示されることを確認します。

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

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

13.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 ディスクマウントポイントを使用するようにワークロードを再設定します。
13.4.4.4.2. Ultra ディスクを有効にするマシンセットのリソースに関するトラブルシューティング

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

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

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

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

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

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

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

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

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

手順

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

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

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

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

13.4.4.6.1. 制限事項

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

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

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

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

前提条件

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

手順

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

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

検証

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