vSphere 上のクラスタ

以下のセクションでは、スタンドアローン管理クラスタで vSphere 固有の機能を使用するように Tanzu Kubernetes Grid (TKG) ワークロードクラスタを構成する方法について説明します。これらの機能は、クラスタのフラット構成ファイルまたは Kubernetes スタイルのオブジェクト仕様では完全には構成できません。

構成ファイルとオブジェクト仕様を使用して、vSphere でワークロードクラスタを構成する方法については、以下を参照してください。

カスタム OVA イメージを使用したクラスタの展開

Kubernetes の各バージョンに対して単一のカスタム OVA イメージを使用して 1 つのオペレーティングシステムにクラスタを展開する場合は、OVA を vSphere にインポートし、--tkr オプションを使用して tanzu cluster create に指定します。

ただし、同じ Kubernetes バージョンに複数のカスタム OVA イメージを使用している場合、--tkr 値が曖昧になります。これは、同じ Kubernetes バージョンの OVA が以下の場合に発生します。

オペレーティングシステムが異なる（たとえば make build-node-ova-vsphere-ubuntu-1804、make build-node-ova-vsphere-photon-3、および make build-node-ova-vsphere-rhel-7 によって作成されている場合）。
名前は同じで、異なる vCenter Server フォルダに存在する。

この曖昧な状態を解決するには、tanzu cluster create を実行する前に、VSPHERE_TEMPLATE オプションを目的の OVA イメージに設定します。

OVA テンプレートイメージ名が一意の場合は、VSPHERE_TEMPLATE をイメージ名のみに設定します。
複数のイメージが同じ名前を共有する場合は、VSPHERE_TEMPLATE を vCenter Server のイメージの完全なインベントリパスに設定します。このパスは、/MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE の形式に従います。ここで、
- MY-DC は、OVA テンプレートイメージを含むデータセンターです。
- MY-FOLDER-PATH は、vCenter Server の [仮想マシンおよびテンプレート (VMs and Templates)] ビューに示すように、データセンターからのイメージへのパスです。
- MY-IMAGE はイメージ名です。
例：
```
VSPHERE_TEMPLATE: "/TKG_DC/vm/TKG_IMAGES/ubuntu-2004-kube-v1.29.9-vmware.1"
```
イメージの完全な vCenter Server インベントリパスを手動で特定することも、govc CLI を使用することもできます。
1. govc をインストールします。インストールの手順については、GitHub の govmomi リポジトリを参照してください。
2. vCenter Server にアクセスするための govc の環境変数を設定します。
  - export GOVC_USERNAME=VCENTER-USERNAME
  - export GOVC_PASSWORD=VCENTER-PASSWORD
  - export GOVC_URL=VCENTER-URL
  - export GOVC_INSECURE=1
3. govc find / -type m を実行し、出力からイメージ名を見つけます。この出力には、完全なインベントリパス別にオブジェクトが一覧表示されます。

カスタム OVA イメージの詳細については、「マシンイメージのビルド」を参照してください。

CSI のリージョンタグとゾーンタグを使用したクラスタの展開

ワークロードクラスタのリージョンとゾーンを指定して、vSphere CSI（クラウドストレージインターフェイス）用に構成されたリージョンおよびゾーンタグと統合できます。複数のゾーンにまたがるクラスタの場合、ワーカーノードは、たとえば通信無線アクセスネットワーク (RAN) などストレージポッドのないゾーンで実行されている場合でも共有ストレージを検索して使用できます。

vSphere CSI を使用して共有ストレージを有効にするリージョンタグとゾーンタグを持つワークロードクラスタを展開するには：

vCenter Server でタグを作成します。
1. 「タグカテゴリの作成および編集」に従って vCenter Server にタグカテゴリを作成します。たとえば、k8s-region および k8s-zone などです。
2. 次の表に示すように、「vSphere タグの作成および編集」に従ってデータセンター内のリージョンカテゴリとゾーンカテゴリ内にタグを作成します。
  
  カテゴリ Tags
  
  k8s-zone zone-a
  zone-b
  zone-c
  
  k8s-region region-1

カテゴリ	Tags
`k8s-zone`	`zone-a` `zone-b` `zone-c`
`k8s-region`	`region-1`

次の表に示すように、「vSphere タグの割り当てまたは削除」に従ってクラスタおよびデータセンターに対応するタグを作成します。


vSphere オブジェクト	Tags
`datacenter`	`region-1`
`cluster1`	`zone-a`
`cluster2`	`zone-b`
`cluster3`	`zone-c`

vSphere ワークロードクラスタの CSI ドライバでカスタムリージョンとゾーンを有効にするには、クラスタ構成ファイルの変数 VSPHERE_REGION と VSPHERE_ZONE を上記のタグに設定します。例：
```
VSPHERE_REGION: region-1
VSPHERE_ZONE: zone-a
```
Tanzu CLI がこれらの変数セットを使用してワークロードクラスタを作成すると、各クラスタノードにトポロジキー failure-domain.beta.kubernetes.io/zone および failure-domain.beta.kubernetes.io/region のラベルが付けられます。
tanzu cluster create を実行して、「プランベースまたは TKC クラスタの作成」の説明に従ってワークロードクラスタを作成します。
クラスタを作成し、kubectl コンテキストをクラスタに設定した後、次のいずれかを実行して、リージョンラベルとゾーンラベルを確認できます。
- kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region を実行し、出力にクラスタノードが一覧表示されることを確認します。
- kubectl get csinodes -o jsonpath='{range .items\[\*\]}{.metadata.name} {.spec}{"\\n"}{end}' を実行し、リージョンとゾーンが vsphere-csi で有効になっていることを確認します。

vSphere CSI の構成の詳細については、「vSphere CSI ドライバ - トポロジを使用した展開」を参照してください。

異なる vSphere アカウント上のクラスタ

Tanzu Kubernetes Grid は、複数のターゲットプラットフォームアカウントでワークロードクラスタを実行できます。たとえば、クラウド使用量を複数のチームに分割したり、本番、ステージング、開発の各ワークロードに異なるセキュリティプロファイルを適用したりできます。

ワークロードクラスタを、管理クラスタの展開に使用されるアカウントとは異なる代替 vSphere アカウントに展開するには、次の手順を実行します。

kubectl のコンテキストを管理クラスタに設定します。
```
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
```
ここで、MY-MGMT-CLUSTER は管理クラスタの名前です。
次の内容で secret.yaml ファイルを作成します。
```
apiVersion: v1
kind: Secret
metadata:
  name: SECRET-NAME
  namespace: CAPV-MANAGER-NAMESPACE
stringData:
  username: VSPHERE-USERNAME
  password: VSPHERE-PASSWORD
```
ここで、
- SECRET-NAME は、クライアントシークレットに指定する名前です。
- CAPV-MANAGER-NAMESPACE は、capv-manager ポッドが実行されている名前空間です。デフォルト: capv-system。
- VSPHERE-USERNAME および VSPHERE-PASSWORD は、代替 vSphere アカウントへのアクセスを可能にするログイン認証情報です。
このファイルを使用して Secret オブジェクトを作成します。
```
kubectl apply -f secret.yaml
```
次の内容で identity.yaml ファイルを作成します。
```
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereClusterIdentity
metadata:
  name: EXAMPLE-IDENTITY
spec:
  secretName: SECRET-NAME
  allowedNamespaces:
    selector:
      matchLabels: {}
```
ここで、
- EXAMPLE-IDENTITY は、VSphereClusterIdentity オブジェクトに使用する名前です。
- SECRET-NAME は、前述のクライアントシークレットに指定した名前です。
このファイルを使用して VsphereClusterIdentity オブジェクトを作成します。
```
kubectl apply -f identity.yaml
```

これで、管理クラスタは代替アカウントにワークロードクラスタを展開できます。

ワークロードクラスタをアカウントに展開するには、次の手順を実行します。

tanzu cluster create --dry-run を実行して、クラスタマニフェストを作成します。

マニフェストで VSphereCluster 定義を編集して、VSphereClusterIdentity オブジェクトの spec.identityRef.name 値を前に作成した EXAMPLE-IDENTITY に設定します。

...
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
 name: new-workload-cluster
spec:
 identityRef:
   kind: VSphereClusterIdentity
   name: EXAMPLE-IDENTITY
...

kubectl apply -f my-cluster-manifest.yaml を実行してワークロードクラスタを作成します。

ワークロードクラスタを作成した後、代替アカウントの認証情報を使用して vSphere にログインすると、実行中であることが示されます。

詳細については、Cluster API プロバイダ vSphere リポジトリの「Identity Management」を参照してください。

データストアクラスタを使用するクラスタの展開

注
この機能は期待どおりに動作しません。1 つのデータストアクラスタ内の複数のデータストアにタグを付ける場合、ワークロードクラスタのストレージポリシーの基準として、ワークロードクラスタはデータストアの 1 つのみを使用します。

ワークロードクラスタが単一のデータストアではなくデータストアクラスタを使用できるようにするには、次のようにデータストアクラスタ内のすべてのデータストアをターゲットとするストレージポリシーを設定します。

タグを作成し、関連するデータストアに関連付けます。
1. 「vSphere タグ」の手順に従って、vCenter Server にタグカテゴリを作成します。カテゴリに関連付けが可能なオブジェクトタイプとして Datastore があることを確認します。
2. 「vSphere タグ」の残りの手順に従って、その前の手順で作成したカテゴリ内にタグを作成し、新しいタグをデータストアクラスタに属するすべてのデータストアに関連付けます。
「タグベースの配置用に仮想マシンストレージポリシーを作成」に従って、タグベースのストレージポリシーを作成します。
クラスタ構成ファイルで、次の手順を実行します。
- VSPHERE_STORAGE_POLICY_ID を前の手順で作成したストレージポリシーの名前に設定します。
- VSPHERE_DATASTORE が設定されていないことを確認します。VSPHERE_DATASTORE 設定は、ストレージポリシー設定をオーバーライドします。

マルチ OS ワークロードクラスタの展開

Windows ベースと Linux ベースの両方のワーカーノードを持つマルチ OS ワークロードクラスタを展開するには、カスタム Windows マシンイメージを作成し、Windows ワークロードクラスタを展開してから、Linux MachineDeploymentを追加して、Windows のみのワークロードクラスタをマルチ OS クラスタに変換します。

マルチ OS クラスタは、Windows ワークロードと Linux ワークロードの両方を、それらが属するワーカーノードで Linux ベースの TKG コンポーネントを実行しながらホストできます。

「Windows カスタムマシンイメージ」のすべての手順に従って、Windows マシンイメージを作成します。
管理クラスタに OSImage を追加するため、Windows マシンイメージを作成したときのテンプレートを参照する YAML ファイル（win-osimage.yaml など）を作成します。

次のサンプル YAML ファイルを使用できます。spec.image.ref.template 値を、作成した Windows テンプレートの場所に変更します。パスは、vSphere 環境に固有です。
```
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
 name: v1.25.7---vmware.2-tkg.1-windows
spec:
 image:
   ref:
     template: /dc0/vm/windows-2019-kube-v1.25.7+vmware.2-tkg.1
     version: v1.25.7+vmware.2-tkg.1-windows
   type: ova
 kubernetesVersion: v1.25.7+vmware.2
 os:
   arch: amd64
   name: windows
   type: windows
   version: "2019"
```
kubectl apply -f win-osimage.yaml を実行して OSImage を追加します。
TKR バージョンを spec.osImages に追加して、TKR の解決と Webhook の検証が正常に行われるようにします。次のコマンドを使用して、TKR バージョンを spec.osImages に追加します。
```
$ kubectl edit tkr v1.25.7---vmware.2-tkg.1
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
  name: v1.25.7---vmware.2-tkg.1
spec:
  bootstrapPackages:
  # Keep the other packages listed here.
  - name: tkg-windows.tanzu.vmware.com.0.29.0+vmware.1
  osImages:
  # Keep the other images listed here.
  - name: v1.25.7---vmware.2-tkg.1-windows
```
TKR で、spec.bootstrapPackages に新しいアイテムを追加して、tkg-windows パッケージを有効にします。このパッケージは、tanzu package available list tkg-windows.tanzu.vmware.com を使用して公式リポジトリで見つけられます。操作中の TKR の例は、次のとおりです。
次のコマンドを実行して、クラスベースのクラスタオブジェクト仕様を作成します。
```
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
```
ここで、 * WINDOWS-CLUSTER は Windows クラスタの名前です。* CLUSTER-CONFIG は構成ファイルの名前です。

新しい tkg-worker マシン展開クラスを、my-cluster-spec.yaml のクラスタオブジェクトに追加します。TKG が OSImage オブジェクトを検索できるように、注釈が正しいことを確認します。

次の例のように、新しい tkg-worker 仕様を spec.workers.machineDeployments に追加できます。

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: WINDOWS-CLUSTER
spec:
  workers:
    machineDeployments:
    - class: tkg-worker
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=photon
        name: md-0-l
        replicas: 1
    - class: tkg-worker-windows
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=windows
        name: md-0
        replicas: 1

次のコマンドを実行して、マルチ OS クラスタを展開します。

tanzu cluster create my-cluster -f my-cluster-spec.yaml

ノードには、「Well-Known Labels, Annotations and Taints」の OS 情報がラベル付けされ、テイントされます。

注
マルチ OS ワークロードクラスタのバックアップとリストアはサポートされていません。

Windows Antrea CNI の信頼性

HNS Network は、Windows では永続的ではありません。Windows ノードが再起動すると、antrea-agent が作成した HNS Network は削除され、Open vSwitch Extension がデフォルトで無効になります。そのため、Windows ノードが再起動したら、古い OVS ブリッジとポートは削除してください。ヘルプスクリプト Clean-AntreaNetwork.ps1 を使用すると、OVS ブリッジをクリーンアップできます。

次のいずれかの方法を使用して、ヘルプスクリプトをインストールします。

手動インストール
自動インストール

手動インストール

分離された各ワークロードノードにヘルプスクリプトを手動でインストールするには、次の手順を実行します。

Clean-AntreaNetwork.ps1 インストールスクリプトをこのコードサンプルからダウンロードします。ダウンロードしたインストールスクリプト snippet.ps1 は、Clean-AntreaNetwork.ps1 をインストールします。
ノードに SSH 接続し、次のコマンドを実行します。
```
powershell snippet.ps1
```

自動インストール

新しいワークロードノードごとに、ヘルプスクリプトを自動的にインストールするカスタムの ClusterClass を作成するには、次の手順を実行します。

「ClusterClass の作成」の手順に従って、カスタム ClusterClass オブジェクトを作成します。
YTT を使用してこのコードサンプルからパッチを適用し、管理クラスタに仕様を適用します。
```
ytt -f custom-cluster-class.yaml -f snippet.yaml | kubectl apply -f -
```

分散ポートグループのセキュリティに関する注意事項

Windows または MultiOS クラスタを展開する場合は、分散ポートグループで特定のセキュリティポリシーが Reject に設定されていることを確認する必要があります。たとえば、無作為検出モードが Accept に設定されている場合、ノードを Ready と NotReady 状態の間で切り替えることができます。

vSphere Client で、Windows ノードに使用するネットワークを選択し、[分散仮想スイッチ (virtual Distributed Switch)] > [分散ポートグループセキュリティポリシー (Distributed Portgroup Security Policy)] 設定に移動して、次のポリシーを Reject に設定します。

無差別モード
MAC アドレス変更
偽装転送