複数のアベイラビリティ ゾーンにまたがるクラスタの実行

このトピックでは、複数のアベイラビリティ ゾーン (AZ) で実行される新しいTanzu Kubernetes Grid (TKG) ワークロード クラスタをデプロイする方法、および複数または異なる AZ で実行するように既存の管理クラスタとワークロード クラスタを変更する方法について説明します。

インストーラ インターフェイスを使用して、複数の AZ にまたがって実行する新しいスタンドアローン管理クラスタを構成するには、「インストーラ インターフェイスを使用した管理クラスタの展開」の「vSphere リソースの構成」を参照してください。

注

このトピックは、スタンドアローン管理クラスタを使用する TKG に適用されます。複数のアベイラビリティ ゾーンにまたがるスーパーバイザーを使用して TKG を実行する場合は、vSphere 8.0 ドキュメントの「マルチゾーン スーパーバイザー デプロイ用の vSphere Zones の作成」を参照してください。

概要

Kubernetes オブジェクト：vSphere 上のクラスタで複数のアベイラビリティ ゾーンを有効にするために、クラスタ API プロバイダ vSphere (CAPV) は 2 つのカスタム リソース定義 (CRD) を使用します。

  • VSphereFailureDomain CRD は、リージョン/ゾーン固有のタグ付け情報と、vSphere データセンター、クラスタ、ホスト、データストアの情報を含むトポロジ定義をキャプチャします。
  • VSphereDeploymentZone CRD は、VSphereFailureDomain と Kubernetes ノードの配置制約情報との関連付けをキャプチャします。

Kubernetes と vSphere の関連付け：VSphereFailureDomain および VSphereDeploymentZone オブジェクト定義では、次の設定を使用してリージョンと AZ を定義します。

  • リージョン：spec.region
  • ゾーン/AZ：spec.zone

vSphere タグ k8s-region および k8s-zone は、Kubernetes のリージョンと AZ を vSphere の基盤となるオブジェクトに関連付けます。

AZ 範囲：次のように、VSPHERE オブジェクトに関連付けることで、vSphere のさまざまなレベルで AZ とリージョンの範囲を設定できます。

AZ スコープ ゾーン/AZ リージョン マルチ AZ の使用
クラスタ AZ vSphere クラスタ vSphere データセンター データセンター内の複数のクラスタにノードを分散
ホスト グループの AZ ホスト グループのvSphere vSphere クラスタ 単一クラスタ内の複数のホストにノードを分散

このトピックの構成では、オブジェクトが vSphere でどのようにタグ付けされ、Kubernetes の VSphereFailureDomain 定義と VSphereDeploymentZone 定義でどのように参照されるかに基づいて、TKG クラスタ制御プレーンとワーカー ノードを vSphere オブジェクト（vSphere データセンター、クラスタ、およびホスト）に分散します。

Cluster オブジェクト構成：Cluster オブジェクト仕様では、制御プレーンノードとワーカー ノードの AZ をさまざまな方法で構成し、AZ を定義する VSphereDeploymentZone オブジェクトのさまざまなプロパティと照合します。

ノード タイプ spec.topology のプロパティ VSphereDeploymentZone プロパティを照合するには 例
制御プレーン ノード variables.controlPlaneZoneMatchingLabels metadata.labels ペアのリスト {"environment": "staging", "region": "room1"}
ワーカー ノード machineDeployments.MD-INDEX.failureDomain （マシン展開ごと） metadata.name 値のリスト [rack1,rack2,rack3]

制御プレーン ノードはラベル一致に基づいて AZ に割り当てられるため、クラスタ制御プレーン ノードが使用する可能性のある AZ の各組み合わせを区別するラベルを作成する必要があります。

前提条件

複数の AZ または異なる AZ で実行するように TKG クラスタを展開または変更するための前提条件は次のとおりです。

  • ワークロード クラスタが vSphere で実行されている Tanzu Kubernetes Grid 管理クラスタ。
  • TKG 用に設定された vSphere アカウントに次の権限が追加されている。「vSphere アカウントに必要な権限」を参照してください：
    • [ホスト (Host)] > [インベントリ (Inventory)] > [クラスタの変更 (Modify cluster)]

複数の AZ 間でのワークロード クラスタの展開

ワークロード クラスタを展開して、次のセクションで説明するように、3 つの基本的な手順で制御プレーンまたはワーカー ノードを複数のアベイラビリティ ゾーン (AZ) で実行できます。

  1. vSphere でのリージョンと AZ の準備
  2. Kubernetes での FailureDomain および Deployment Zone オブジェクトの作成
  3. クラスタの展開

vSphere でのリージョンと AZ の準備

TKG でリージョンと AZ をサポートするための vSphere を準備するには、次の手順を実行します。

  1. TKG クラスタ ノードがホストされるリージョンと AZ のvSphere オブジェクトを特定または作成します。

    • ホスト グループの AZ (Host group AZs)：vSphere ホスト グループを AZ として使用している場合は、使用する AZ ごとに 1 つのホスト グループと対応する仮想マシン グループを作成する必要があります

      1. 次のいずれかの方法で、ホスト グループおよび仮想マシン グループ オブジェクトを作成します。

        • [vCenter Server] で、[構成 (Configure)] > [仮想マシン/ホスト グループ (VM/Host Groups)] > [追加 (Add)]… からホスト グループと仮想マシン グループを作成します

          • ホスト グループを作成するには、ダミーの仮想マシンを作成してグループ メンバーとして追加する必要がある場合があります。

        • govc CLI を使用して、次のような govc コマンドを実行します。たとえば、ホスト グループ rack1 および仮想マシン グループ rack1-vm-group を作成します。

          govc cluster.group.create -cluster=RegionA01-MGMT -name=rack1 -host esx-01a.corp.tanzu esx-02a.corp.tanzu

          govc cluster.group.create -cluster=RegionA01-MGMT -name=rack1-vm-group -vm

      2. 作成された仮想マシン グループとホスト グループの間にアフィニティ ルールを追加して、必ず作成されたホスト グループ内のホストで仮想マシン グループ内の仮想マシンが実行されるようにします。

        • [タイプ (Type)] を [仮想マシンからホスト (Virtual Machines to Hosts)] に設定し、[グループ内のホスト上で実行する必要があります (Must run on hosts in group)] ルールを含めます。

  2. クラスタ AZ またはホスト グループ AZ のどちらを構成しているかに応じて、vSphere オブジェクトvSphereタグ付けします。次の例では、govc CLI を使用しますが、vCenter Server の タグ & カスタム属性 ペインを使用することもできます。

    • クラスタ AZ：

      AZ ごとに、govc を使用して k8s-region カテゴリ タグを作成してデータセンターに適用し、k8s-zone カテゴリ タグを作成して各 vSphere クラスタに適用します。たとえば、データセンター dc0 をリージョン us-west-1 としてタグ付けし、そのクラスタ cluster1 などを AZ us-west-1a などとしてタグ付けするには、次のようにします。

      govc tags.category.create -t Datacenter k8s-region

govc tags.category.create -t ClusterComputeResource k8s-zone

govc tags.create -c k8s-region us-west-1

govc tags.create -c k8s-zone us-west-1a
govc tags.create -c k8s-zone us-west-1b
govc tags.create -c k8s-zone us-west-1c

govc tags.attach -c k8s-region us-west-1 /dc0

govc tags.attach -c k8s-zone us-west-1a /dc0/host/cluster1
govc tags.attach -c k8s-zone us-west-1b /dc0/host/cluster2
govc tags.attach -c k8s-zone us-west-1c /dc0/host/cluster3

    • ホスト グループの AZ (Host group AZs)：

      AZ ごとに、govc を使用して k8s-region カテゴリ タグを作成して vSphere クラスタに適用し、k8s-zoneカテゴリ タグを作成して各ホスト グループに適用します。たとえば、クラスタ /dc1/host/room1-mgmt をリージョン room1 としてタグ付けし、そのホスト グループ /dc1/host/room1-mgmt/esx-01a.corp.tanzu などを AZ rack1 などとしてタグ付けするには、次のようにします。

      govc tags.category.create -t ClusterComputeResource k8s-region
govc tags.category.create -t HostSystem k8s-zone

govc tags.create -c k8s-region room1

govc tags.create -c k8s-zone rack1
govc tags.create -c k8s-zone rack2
govc tags.create -c k8s-zone rack3

govc tags.attach -c k8s-region room1 /dc1/host/room1-mgmt

govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01a.corp.tanzu
govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01b.corp.tanzu
govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01c.corp.tanzu

Kubernetes での FailureDomain および Deployment Zone オブジェクトの作成

クラスタを複数のアベイラビリティ ゾーンに展開する前に、リージョンとゾーンを定義する Kubernetes オブジェクトFailureDomainおよび Deployment Zone を作成する必要があります。spec.region、spec.zone、および spec.topology のすべての設定が vCenter Server で構成されたオブジェクト パスおよびタグと一致する必要があります。

  • VSphereDeploymentZone オブジェクトの場合、spec.failuredomain の値は、VSphereFailureDomain 定義の metadata.name 値のいずれかと一致する必要があります。
  • VSphereDeploymentZone オブジェクトの spec.server 値は、インストーラ インターフェイスの [IaaS プロバイダ (IaaS Provider)] ペインの [VCENTER SERVER] に対して、または管理クラスタ構成ファイルの VSPHERE_SERVER 設定に対して入力された vCenter Server アドレス（IP アドレスまたは FQDN）と一致する必要があります。
  • metadata.name 値はすべて小文字にする必要があります。

vSphere クラスタ AZ またはホスト グループ AZ のどちらを構成しているかに応じて、次のように FailureDomain および Deployment Zone オブジェクトを作成します。

  • クラスタ AZ：

    データセンター内の複数の vSphere クラスタ ノードにワークロード クラスタを分散する方法の例として、次のコードは、us-west-1a us-west-1b および us-west-1c という 3 つの展開ゾーンに必要なオブジェクトを定義します。これらはそれぞれ独自のネットワークおよびストレージ パラメータを持つ vSphere クラスタです。

      ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
   name: us-west-1a
  spec:
   region:
     name: us-west-1
     type: Datacenter
     tagCategory: k8s-region
   zone:
     name: us-west-1a
     type: ComputeCluster
     tagCategory: k8s-zone
   topology:
     datacenter: dc0
     computeCluster: cluster1
     datastore: ds-c1
     networks:
     - net1
     - net2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
   name: us-west-1b
  spec:
   region:
     name: us-west-1
     type: Datacenter
     tagCategory: k8s-region
   zone:
     name: us-west-1b
     type: ComputeCluster
     tagCategory: k8s-zone
   topology:
     datacenter: dc0
     computeCluster: cluster2
     datastore: ds-c2
     networks:
     - net3
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
   name: us-west-1c
  spec:
   region:
     name: us-west-1
     type: Datacenter
     tagCategory: k8s-region
   zone:
     name: us-west-1c
     type: ComputeCluster
     tagCategory: k8s-zone
   topology:
     datacenter: dc0
     computeCluster: cluster3
     datastore: ds-c3
     networks:
     - net4
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: us-west-1a
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1a
   placementConstraint:
     resourcePool: pool1
     folder: foo
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: us-west-1b
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1b
   placementConstraint:
     resourcePool: pool2
     folder: bar
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: us-west-1c
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1c
   placementConstraint:
     resourcePool: pool3
     folder: baz

    ここで、VSPHERE_SERVER は、vCenter Server の IP アドレスまたは FQDN です。

    異なる vSphere クラスタに同じ名前のリソース プールがある場合は、VSphereDeploymentZone オブジェクトの spec.placementConstraint.resourcePool を単なる名前ではない完全なリソース パスに設定します。

  • ホスト グループの AZ (Host group AZs)：

    ワークロード クラスタ ノードを単一の vSphere クラスタ内の 3 つのホスト グループに分散する方法の例として、次のコードは、3 つの AZ (rack1rackrack2、および rack3) に必要なオブジェクトを定義します。これらはそれぞれリージョン room1 として定義される同じ vSphere クラスタ内のホストのラックを表しています。

      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
   name: rack1
  spec:
   region:
     name: room1
     type: ComputeCluster
     tagCategory: k8s-region
   zone:
     name: rack1
     type: HostGroup
     tagCategory: k8s-zone
   topology:
     datacenter: dc0
     computeCluster: cluster1
     hosts:
       vmGroupName: rack1-vm-group
       hostGroupName: rack1
     datastore: ds-r1
     networks:
     - net1
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
   name: rack2
  spec:
   region:
     name: room1
     type: ComputeCluster
     tagCategory: k8s-region
   zone:
     name: rack2
     type: HostGroup
     tagCategory: k8s-zone
   topology:
     datacenter: dc0
     computeCluster: cluster1
     hosts:
       vmGroupName: rack2-vm-group
       hostGroupName: rack2
     datastore: ds-r2
     networks:
     - net2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
   name: rack3
  spec:
   region:
     name: room1
     type: ComputeCluster
     tagCategory: k8s-region
   zone:
     name: rack3
     type: HostGroup
     tagCategory: k8s-zone
   topology:
     datacenter: dc0
     computeCluster: cluster1
     hosts:
       vmGroupName: rack3-vm-group
       hostGroupName: rack3
     datastore: ds-c3
     networks:
     - net3
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: rack1
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack1
   placementConstraint:
     resourcePool: pool1
     folder: foo
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: rack2
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack2
   placementConstraint:
     resourcePool: pool2
     folder: bar
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: rack3
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack3
   placementConstraint:
     resourcePool: pool3
   folder: baz

    ここで、VSPHERE_SERVER は、vCenter Server の IP アドレスまたは FQDN です。

クラスタを展開する次の手順については、「アベイラビリティ ゾーン全体に分散されたノードを含むワークロード クラスタの展開」を参照してください。

クラスタの展開

「vSphere でのリージョンおよび AZ の準備」および「Kubernetes での FailureDomain および Deployment Zone オブジェクトの作成」の手順を実行した後、ノードが複数の AZ に分散されたワークロード クラスタをデプロイできます。

次の手順では、vsphere-zones.yaml を FailureDomain および Deployment Zone オブジェクト定義を含むファイルとして使用します。

  1. 「スタンドアローン管理クラスタを使用する vSphere の構成ファイル」の説明に従って、展開するワークロード クラスタのクラスタ構成ファイルを作成します。

  2. 「複数のアベイラビリティ ゾーンの構成」の説明に従ってクラスタ構成ファイルを確認または変更し、AZ オブジェクト定義に一致するように、VSPHERE_REGION、VSPHERE_ZONE、VSPHERE_AZ_0、およびその他の構成変数を設定します。

    • AZ のクラスタ構成変数は、スタンドアローン管理クラスタとワークロード クラスタと同じように機能します。
    • ワークロード クラスタを vSphere に展開するときに指定する必要があるオプションの完全なリストについては、「構成ファイル変数リファレンス」を参照してください。

  3. （オプション）クラスタ作成プロセスで、構成で指定された vSphere ゾーンとリージョンがすべて存在し、一貫性があり、同じレベルで定義されていることを検証しないようにするには、ローカル環境で SKIP_MULTI_AZ_VERIFY を "true" に設定します。

    export SKIP_MULTI_AZ_VERIFY="true"

    クラスタ構成ファイルでこの変数を設定することはできません。

  4. tanzu cluster create を実行してワークロード クラスタを作成します。詳細については、「ワークロード クラスタの作成」を参照してください。

    • AZ オブジェクトをクラスタとは別に作成するには、tanzu login で管理クラスタにログインし、次のコマンドを実行してから tanzu cluster create を実行します。

      tanzu mc az set -f vsphere-zones.yaml

      または、kubectl apply -f vsphere-zones.yaml を実行できます。

    • フラット クラスタ構成ファイルで AZ オブジェクト定義を使用し、AZ オブジェクトとクラスタ オブジェクトを一緒に作成するには、vsphere-zones.yaml ファイルを tanzu cluster create の --az-file オプションに渡します。

      tanzu mc create --file cluster-config-file.yaml --az-file vsphere-zones.yaml

    • AZ オブジェクト定義をクラスタ マニフェストに組み合わせるには、「クラスベースのクラスタを作成する」で説明されている 2 段階のプロセスの手順 1 に従って、クラスタ マニフェストを作成し、vsphere-zones.yaml の内容をマニフェストに追加し、手順 2 の説明に従って tanzu cluster create を実行します。

    • クラスタの作成プロセス中に、その仮想マシンとその他のリソースが vCenter Server に表示されます。

    • 仮想マシン グループを作成するために vCenter Server でダミー仮想マシンを作成した場合は、クラスタの実行中に仮想マシン グループから仮想マシンを削除できます。

複数または異なるアベイラビリティ ゾーンを使用するための既存のクラスタの更新

展開済みの管理クラスタまたはワークロード クラスタを更新して、制御プレーンまたはワーカー ノードを複数のアベイラビリティ ゾーン (AZ) で実行したり、ノードが実行されている AZ を変更したりすることができます。

AZ をクラスタの制御プレーンまたはワーカー ノード全体に割り当てたり、基盤となるマシン展開に対して AZ を設定したりして、マシン展開セットの AZ とともに vSphere マシン設定をカスタマイズできます。

既存のワークロード クラスタの AZ を更新したら、「AZ の変更に対する CPI と CSI の更新」の説明に従って、コンテナ ストレージ インターフェイス (CSI) とクラウド プロバイダ インターフェイス (CPI) を更新して変更を反映する必要があります。

次のセクションでは、さまざまなシナリオで既存のクラスタ AZ 構成を更新する方法について説明します。

制御プレーン ノードの AZ の追加

制御プレーン ノードが単一の AZ で実行される既存のクラスタを拡張して、制御プレーンが複数の AZ で実行されるようにするには、次の手順を実行します。

  1. 新しい AZ ごとに VSphereFailureDomain および VSphereDeploymentZone オブジェクトを定義する構成ファイルを準備します。以下の例 vsphere-3-zones.yaml では、リージョン room1 の AZ rack1、rack2 および rack3 を定義します。

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind:VSphereFailureDomain
metadata:
 name:rack
spec:
 region:
 name: room1
 type: ComputeCluster
 tagCategory: k8s-region
 zone:
 name:rack
 type: HostGroup
 tagCategory: k8s-zone
 topology:
 datacenter: dc0
 computeCluster: cluster0
 hosts:
 vmGroupName:rack-vm-group
 hostGroupName:rack
 datastore: ds1
 networks:
 - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind:VSphereFailureDomain
metadata:
 name:rack
spec:
 region:
 name: room1
 type: ComputeCluster
 tagCategory: k8s-region
 zone:
 name: rack2
 type: HostGroup
 tagCategory: k8s-zone
 topology:
 datacenter: dc0
 computeCluster: cluster0
 hosts:
 vmGroupName: rack2-vm-group
 hostGroupName: rack2
 datastore: ds2
 networks:
 - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
 name: rack3
spec:
 region:
 name: room1
 type: ComputeCluster
 tagCategory: k8s-region
 zone:
 name: rack3:
 type: HostGroup
 tagCategory: k8s-zone
 topology:
 datacenter: dc0
 computeCluster: cluster0
 hosts:
 vmGroupName: rack3-vm-group
 hostGroupName: rack3
 datastore: ds3
 networks:
 - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack1
spec:
 server: VSPHERE_SERVER
 failureDomain: rack1
 placementConstraint:
 resourcePool: rp0
 folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack2
spec:
 server: VSPHERE_SERVER
 failureDomain: rack2
 placementConstraint:
 resourcePool: rp0
 folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack3
spec:
 server: VSPHERE_SERVER
 failureDomain: rack3
 placementConstraint:
 resourcePool: rp0
 folder: folder0

    ここで、VSPHERE_SERVER は、vCenter Server の IP アドレスまたは FQDN です。

    メモ：

    • vSphere 製品ドキュメントの「vSphere タグ」の説明に従って、タグが作成され、vCenter Server インベントリ内のリソースが適切にタグ付けされていることを確認します。
    • VSphereDeploymentZone で spec.placementConstraint.resourcePool を設定する必要があります。クラスタにユーザーが作成したリソース プールがない場合は、値をクラスタのデフォルトのリソース プール（パスは /dc0/host/cluster1/Resources）に設定します。
    • VSphereFailureDomain オブジェクトの場合、spec.region.autoConfigure および spec.zone.autoConfigure はサポートされなくなりました。

  2. vSphereFailureDomain および VSphereDeploymentZone オブジェクトを作成します。例：

    tanzu mc az set -f vsphere-3-zones.yaml

  3. ターゲット クラスタの KubeAdmControlPlane を取得します。この例では、ターゲットは管理クラスタ tkg-mgmt-vc ですが、ワークロード クラスタの場合もあります。

    kubectl get kcp --selector cluster.x-k8s.io/cluster-name=tkg-mgmt-vc -n tkg-system -o=name

kubeadmcontrolplane.controlplane.cluster.x-k8s.io/tkg-mgmt-vc-cpkxj

  4. クラスタ AZ セレクタを更新します。例：controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"}:

    kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq '.spec.topology.variables |= map(if .name == "controlPlaneZoneMatchingLabels" then .value = {"environment": "staging", "region": "room1"} else . end)'| kubectl apply -f -

cluster.cluster.x-k8s.io/tkg-mgmt-vc replaced

  5. クラスタの障害ドメインが想定どおりに更新されていることを確認します。

    kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq -r '.status.failureDomains | to_entries[].key'

  6. KubeAdmControlPlane に rolloutAfter のパッチを適用して、制御プレーン ノードの更新をトリガします。

    kubectl patch kcp tkg-mgmt-vc-cpkxj -n tkg-system --type merge -p "{\"spec\":{\"rolloutAfter\":\"$(date +'%Y-%m-%dT%TZ')\"}}"

  7. vCenter Server でノードのホストとデータストアを確認するか、次のような kubectl get node または govc vm.info コマンドを実行して、制御プレーン ノードが新しい AZ に移動したことを確認します。

    • kubectl get node NODE-NAME -o=jsonpath='{.metadata.labels.node.cluster.x-k8s.io/esxi-host}' --context tkg-mgmt-vc-admin@tkg-mgmt-vc
    • govc vm.info -json NODE-NAME | jq -r '.VirtualMachines[].Config.Hardware.Device[] | select(.DeviceInfo.Label == "Hard disk 1") | .Backing.FileName'

セレクタ ラベルを使用した新しい制御プレーンの AZ の指定

セレクタ ラベルを使用して AZ を選択するということは、VSphereDeploymentZone を、metadata.name ではなく、metadata.labels で指定することを意味します。これにより、たとえば、指定したリージョンおよび環境のすべての AZ で実行するようにクラスタの制御プレーン ノードを構成でき、AZ を個別に一覧表示する必要はありません。"region=us-west-1,environment=staging"。また、制御プレーン ノードの AZ 名を変更しなくても、クラスタ制御プレーンの AZ を更新できます。

セレクタ ラベルを使用して、既存のクラスタの制御プレーン ノードの新しい AZ を指定するには、次の手順を実行します。

  1. 新しい AZ ごとに VSphereFailureDomain および VSphereDeploymentZone オブジェクトを定義する構成ファイルを準備します。以下の例 vsphere-labeled-zones.yaml では、セレクタ ラベル メタデータを使用して AZ rack4 を定義します。

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
  name: rack4
spec:
  region:
   name: room1
   type: ComputeCluster
   tagCategory: k8s-region
  zone:
   name: rack4
   type: HostGroup
   tagCategory: k8s-zone
  topology:
   datacenter: dc0
   computeCluster: cluster0
   hosts:
     vmGroupName: rack4-vm-group
     hostGroupName: rack4
   datastore: vsanDatastore
   networks:
   - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack4
 labels:
   environment: staging
   region: room1
spec:
 server: VSPHERE_SERVER
 failureDomain: rack4
 placementConstraint:
   resourcePool: rp0
   folder: folder0

  2. VSphereFailureDomain および VSphereDeploymentZone オブジェクトを作成します。例：

    tanzu mc az set -f vsphere-labeled-zones.yaml

  3. AZ セレクタ ラベルを使用してクラスタを更新します。この例では、管理クラスタ tkg-mgmt-vc に対して AZ セレクタ controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"} を使用していますが、ワークロード クラスタの場合もあります。

    kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | \
jq '.spec.topology.variables |= \
map(if .name == "controlPlaneZoneMatchingLabels" \
then .value = {"environment": "staging", "region": "room1"} \
else . end)'| kubectl apply -f -

cluster.cluster.x-k8s.io/tkg-mgmt-vc replaced

  4. クラスタのステータスを確認して、障害ドメインが想定どおりに更新されていることを確認します。

    kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq -r '.status.failureDomains | to_entries[].key'

  5. KubeAdmControlPlane に rolloutAfter のパッチを適用して、制御プレーン ノードの更新をトリガします。

    kubectl patch kcp tkg-mgmt-vc-cpkxj -n tkg-system --type merge -p "{\"spec\":{\"rolloutAfter\":\"$(date +'%Y-%m-%dT%TZ')\"}}"

  6. vCenter Server でノードのホストとデータストアを確認するか、次のような kubectl get node または govc vm.info コマンドを実行して、制御プレーン ノードが controlPlaneZoneMatchingLabels のセレクタによって選択された新しい AZ に移動したことを確認します。この例では、新しい AZ は rack4 です。

    • kubectl get node NODE-NAME -o=jsonpath='{.metadata.labels.node.cluster.x-k8s.io/esxi-host}' --context tkg-mgmt-vc-admin@tkg-mgmt-vc
    • govc vm.info -json NODE-NAME | jq -r '.VirtualMachines[].Config.Hardware.Device[] | select(.DeviceInfo.Label == "Hard disk 1") | .Backing.FileName'

マシン展開の AZ の変更

既存のクラスタ内の AZ 構成を変更するには、そのノードの基盤となる MachineDeployment 構成に新しい AZ 値のパッチを適用します。

たとえば、クラスタ構成ファイルで VSPHERE_AZ_0 を rack1 に設定し、そのワーカー ノードを rack2 に移動する場合は、次の手順を実行します。

  1. クラスタに使用されている現在の AZ をクエリします。この例では、ワークロード クラスタ tkg-wc を使用しますが、管理クラスタにすることもできます。

    kubectl get cluster tkg-wc -o json \| jq -r '.spec.topology.workers.machineDeployments\[0\].failureDomain'

  2. 使用可能なすべての AZ を一覧表示します。

    kubectl get vspheredeploymentzones -o=jsonpath='{range .items[?(@.status.ready == true)]}{.metadata.name}{"\n"}{end}'

rack1
rack2

  3. tkg-wc クラスタの spec.toplogy.workers.machineDeployments 構成にパッチを適用し、そのゾーン VSphereFailureDomain を rack2 に設定します。この例では、tkg-wc が単一ノードの dev プラン クラスタであると想定しています。prod プラン クラスタの場合は、クラスタ内の 3 つの MachineDeployment オブジェクト構成すべてにパッチを適用する必要があります。

    kubectl patch cluster tkg-wc --type=json -p='[{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/failureDomain", "value": "rack2"}]'

cluster.cluster.x-k8s.io/tkg-wc patched

  4. クラスタが VSphereFailureDomain rack2 で更新されていることを確認します。

    kubectl get cluster tkg-wc -o=jsonpath='{.spec.topology.workers.machineDeployments[?(@.name=="md-0")].failureDomain}'

rack2

  5. ワーカー ノードが VSphereFailureDomain rack2 に展開されていることを確認します。

マシン展開用の AZ の追加

TKG クラスタで使用する新しい AZ を構成して既存のクラスタで使用するには、次の手順を実行します。

  1. 新しい AZ ごとに VSphereFailureDomain および VSphereDeploymentZone オブジェクトを定義する構成ファイルを準備します。上記の「制御プレーン ノードの AZ の追加」の vsphere-3-zones.yaml の例を使用して、リージョン room1 の AZ rack1、rack2 および rack3 を定義します。

  2. VSphereFailureDomain および VSphereDeploymentZone オブジェクトを作成します。

    tanzu mc az set -f vsphere-3-zones.yaml

    または、kubectl apply -f vsphere-3-zones.yaml を実行できます。

  3. クラスタ tkg-wc に VSphereFailureDomain rack1、rack2 および rack3 のパッチを適用します。この例では、tkg-wc は、3 つの MachineDeployment 構成を持つ prod プランのクラスタ プランです。dev プラン クラスタでは、クラスタの spec.toplogy.workers.machineDeployments で 1 つの MachineDeployment のみを更新する必要があります。

    kubectl patch cluster tkg-wc --type=json -p='[  \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/failureDomain", "value": "rack1"}, \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/1/failureDomain", "value": "rack2"}, \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/2/failureDomain", "value": "rack3"}]'

  4. クラスタが新しい AZ を使用して更新されていることを確認します。

    kubectl get cluster tkg-wc -o=jsonpath='{range .spec.topology.workers.machineDeployments[*]}{"Name: "}{.name}{"\tFailure Domain: "}{.failureDomain}{"\n"}{end}'

  5. ワーカー ノードが VSphereFailureDomain rack1、rack2 および rack3 に展開されていることを確認します。

AZ と新しいマシン展開の追加

TKG クラスタで使用する新しい AZ と新しい MachineDeployment オブジェクトの両方を構成して既存のクラスタで使用するには、次の手順を実行します。

  1. 新しい AZ ごとに VSphereFailureDomain および VSphereDeploymentZone オブジェクトを定義する構成ファイルを準備します。以下の例 vsphere-1-zone.yaml では、リージョン room1 の新しい AZ rack2 を定義します。

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
 name: rack2
spec:
 region:
   name: room1
   type: ComputeCluster
   tagCategory: k8s-region
 zone:
   name: rack2
   type: HostGroup
   tagCategory: k8s-zone
 topology:
   datacenter: dc0
   computeCluster: cluster0
   hosts:
     vmGroupName: rack2-vm-grou
     hostGroupName: rack2
     datastore: ds-r2
   networks:
   - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack2
spec:
 server: VSPHERE_SERVER
 failureDomain: rack2
 placementConstraint:
   resourcePool: rp0
   folder: folder0

  2. VSphereFailureDomain および VSphereDeploymentZone オブジェクトを作成します。

    tanzu mc az set -f vsphere-zones.yaml

    または、kubectl apply -f vsphere-1-zone.yaml を実行できます。

  3. 新しいマシン展開の構成ファイルを準備します。以下の例 md-1.yaml では、az プロパティが rack2 に設定された新しいマシン展開 md-1 を定義します。

    name: md-1
replicas: 1
az: rack2
nodeMachineType: t3.large
workerClass: tkg-worker
tkrResolver: os-name=ubuntu,os-arch=amd64

  4. Tanzu CLI を使用して新しいノード プールを作成します。この例では、ワークロード クラスタ tkg-wc を使用しますが、管理クラスタにすることもできます。

    tanzu cluster node-pool set wl-antrea -f md-1.yaml

Cluster update for node pool 'md-1' completed successfully

  5. 新しく作成されたノード プール内のマシン展開名を取得します。

    kubectl get machinedeployments -l
topology.cluster.x-k8s.io/deployment-name=md-1
-o=jsonpath='{.items[*].metadata.name}'

wl-antrea-md-1-pd9vj

  6. マシン展開が VSphereFailureDomain rack2 で更新されていることを確認します。

    kubectl get machinedeployments wl-antrea-md-1-pd9vj -o json | \
jq -r '.spec.template.spec.failureDomain'

rack2

  7. md-1 のワーカー ノードが rack2 に展開されていることを確認します。

AZ の変更に対する CPI と CSI の更新

上記のセクションの説明に従ってワークロード クラスタの AZ 構成を変更した後、CPI および CSI アドオン構成を更新し、変更を反映するようにアドオンを再作成する必要があります。以下の手順では、これを行う方法を説明します。

制限事項：

  • 既存のクラスタに対して複数の AZ を有効にする、またはそのワーカー ノードまたは制御プレーン ノードを既存のクラスタの別の AZ に移動する前に、新しいクラスタ ノードがクラスタの元のパーシステント ボリューム (PV) にアクセスできることを確認する必要があります。
  • VsphereFailureDomain のさまざまなリージョンおよびゾーンのすべての tagCategory 設定が一致する必要があります。
  • vSphere CSI に対して複数の AZ を有効にする前に、マルチ AZ の kcp/worker を有効にする必要があります。

AZ 変更後の CPI の更新

クラスタの CPI アドオン構成を更新して AZ の変更を反映し、対応するパッケージ インストーラを削除して、変更を含むアドオンを再作成するには、次の手順を実行します。

  1. cb リファレンスを使用して、クラスタの vsphereCPIConfig の名前を取得します。たとえば、wl という名前のワークロード クラスタの場合は次のようになります。

    kubectl -n default get cb wl -o json \| jq -r '.spec.cpi.valuesFrom.providerRef.name'

  2. クラスタの vsphereCPIConfig 仕様を編集して、その region と zone を、vSphere および vsphereFailuredomain 仕様で AZ のリージョンとゾーンに設定した tagCategory フィールドに設定します。例：

    apiVersion: cpi.tanzu.vmware.com/v1alpha1
kind: VSphereCPIConfig
metadata:
  name: wl
  namespace: default
spec:
  vsphereCPI:
  mode: vsphereCPI
  region: k8s-zone
  tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  vmNetwork:
    excludeExternalSubnetCidr: 10.215.10.79/32
    excludeInternalSubnetCidr: 10.215.10.79/32
  zone: k8s-zone

  3. 変更を適用し、Reconcile succeeded を待機します。

  4. CPI パッケージ インストーラ (pkgi) が再インストールされていることを確認します。

    kubectl -n tkg-system get wl-vsphere-cpi pkgi --context wl-admin@wl

AZ 変更後の CSI の更新

クラスタの CSI アドオン構成を更新して AZ の変更を反映し、csinodetopology および対応するパッケージ インストーラを削除して、変更を含むアドオンを再作成するには、次の手順を実行します。

  1. cb リファレンスを使用して、クラスタの vsphereCPIConfig の名前を取得します。たとえば、wl という名前のワークロード クラスタの場合は次のようになります。

    kubectl -n default get cb wl  -o json  |jq  -r '.spec.csi.valuesFrom.providerRef.name')

  2. クラスタの vsphereCSIConfig 仕様を編集して、その region と zone を、vSphere および vsphereFailuredomain 仕様で AZ のリージョンとゾーンに設定した tagCategory フィールドに設定します。例：

    apiVersion: csi.tanzu.vmware.com/v1alpha1
kind: VSphereCSIConfig
metadata:
  name: wl
  namespace: default
spec:
  vsphereCSI:
    config:
      datacenter: /dc0
      httpProxy: ""
      httpsProxy: ""
      insecureFlag: true
      noProxy: ""
  region: k8s-region
  tlsThumbprint: ""
  useTopologyCategories: true
  zone: k8s-zone
  mode: vsphereCSI

  3. 変更を適用します。

  4. csinode および csiNodeTopology オブジェクトを削除して、再作成します。csinodetopology は自動的に更新されません。

    kubectl -n delete csinode --all --context wl-admin@wl
kubectl -n delete csinodetopology --all --context wl-admin@wl

  5. クラスタの vsphere-csi パッケージ インストーラを削除し、Reconcile succeeded を待機します。

    kubectl delete pkgi -n tkg-system wl-vsphere-csi --context wl-admin@wl

  6. 次のように、すべての csinodes オブジェクトに topologyKeys パラメータが含まれることを確認します。

    kubectl get csinodes -o jsonpath='{range .items[*]}{.metadata.name} {.spec}{"\n"}{end}'

k8s-control-1 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-1","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-control-2 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-2","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-control-3 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-3","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-1 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-1","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-2 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-2","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-3 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-3","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-4 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-4","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-5 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-5","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-6 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-6","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}

  7. 次のように、すべてのノードのトポロジ ラベルに正しい AZ リージョンとゾーンが反映されていることを確認します。

    kubectl get nodes --show-labels
NAME            STATUS   ROLES                  AGE  VERSION   LABELS
k8s-control-1   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-A
k8s-control-2   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-control-3   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-C
k8s-node-1      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-A
k8s-node-2      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-node-3      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-node-4      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-C
k8s-node-5      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-2,topology.csi.vmware.com/k8s-zone=zone-D
k8s-node-6      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-2,topology.csi.vmware.com/k8s-zone=zone-D

アベイラビリティ ゾーンの一覧表示

tanzu mc az list コマンドを使用して、スタンドアローン管理クラスタで定義されているか、ワークロード クラスタによって使用されている AZ を一覧表示します。

  • 管理クラスタとそのワークロード クラスタで現在使用されているアベイラビリティ ゾーンを一覧表示するには、次のコマンドを実行します。

    tanzu management-cluster available-zone list

  • 管理クラスタで定義され、ワークロード クラスタ ノードで使用可能なすべてのアベイラビリティ ゾーンを一覧表示するには、次の手順を実行します。

    tanzu management-cluster available-zone list -a

  • ワークロード クラスタ CLUSTER-NAME によって現在使用されているアベイラビリティ ゾーンに対して：

    tanzu management-cluster available-zone list -c CLUSTER-NAME:

tanzu mc az コマンドは、tanzu management-cluster available-zone からエイリアス化されています。

出力例：

AZNAME   ZONENAME  ZONETYPE    REGIONNAME REGIONTYPE DATASTORE   NETWORK   OWNERCLUSTER STATUS  
us-west-1a us-west-1a ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready  
us-west-1b us-west-1b ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready  
us-west-1c us-west-1c ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready

出力により次が表示されます。

  • AZNAME、ZONENAME：AZ の名前
  • ZONETYPE：AZ （ComputeCluster または HostGroup）の範囲の vSphere オブジェクト タイプ
  • REGIONNAME：AZ を含んでいるリージョンの名前
  • REGIONTYPE：リージョン（Datacenter または ComputeCluster）の範囲の vSphere オブジェクト タイプ
  • DATASTORE：リージョン内の仮想マシンをホストするデータストア
  • NETWORK：リージョン内の仮想マシンにサービスを提供するネットワーク
  • OWNERCLUSTER：AZ で実行される 1 つ以上の TKG クラスタ
  • STATUS：現在の AZ ステータス

tanzu mc az コマンド グループは、tanzu management-cluster available-zone からエイリアス化されています。

アベイラビリティ ゾーンの削除

tanzu mc az delete コマンドを使用して、次のように使用されていない AZ を削除します。

tanzu mc az delete AZNAME

ここで、AZNAME は、tanzu mc az list で一覧表示される AZ の名前です。

tanzu mc az list で AZ のOWNERCLUSTER が一覧表示されないことが示されているように、AZ を削除できるのは、AZ が現在 TKG クラスタ ノードをホストしていない場合のみです。

check-circle-line exclamation-circle-line close-line
Scroll to top icon