v1beta1 の例：カスタム ClusterClass に基づくクラスタ（vSphere 8 U2 以降のワークフロー）

カスタム ClusterClass に基づいて TKG クラスタをプロビジョニングするには、次の手順を参照してください。これらの手順は、vSphere 8 U2 以降の環境に固有であることに注意してください。

前提条件

カスタム ClusterClass に基づいて TKG クラスタをプロビジョニングする手順は、vSphere 8 U2 リリースで更新されています。

次の前提条件を満たす必要があります。

• vSphere 8 U2 以降の環境
• ワークロード管理が有効
• スーパーバイザー 構成済み
• vSphere 向け Kubernetes CLI Tools がインストールされている Ubuntu クライアント

注目: カスタム ClusterClass は、アップストリーム クラスタ API の ドキュメントに基づく Kubernetes の試験的な機能です。カスタム ClusterClass で使用可能なカスタマイズの範囲により、VMwareは可能なすべてのカスタマイズをテストまたは検証できません。ユーザーは、カスタム ClusterClass クラスタのテスト、検証、およびトラブルシューティングを行う必要があります。カスタム ClusterClass クラスタに関するサポート チケットを発行できますが、VMwareサポートはベスト エフォートベースにのみ制限され、カスタム ClusterClass クラスタに対して発行されたすべての問題の解決を保証することはできません。本番環境にカスタム ClusterClass クラスタを展開する前に、これらのリスクを認識しておく必要があります。

ワークフローの概要

ワークフローの概要は次のとおりです。

次のワークフローは、開始する必要があるすべてです。

手順	タスク	方法
1	デフォルトの ClusterClass のクローンを作成して、カスタム ClusterClass を作成します。	1: カスタム ClusterClass の作成
2	カスタム ClusterClass に基づいて新しい TKG クラスタをプロビジョニングし、すべてのクラスタ ノードが適切に起動していることを確認します。	2: カスタム ClusterClass に基づく TKG クラスタの作成

カスタム ClusterClass に変更を加え、カスタム ClusterClass クラスタ ノードのローリング アップデートを開始するには、次のワークフローを参照してください。

注： 次のワークフローで示す操作は、カスタム ClusterClass に対して実行できる操作の例です。ユースケースは異なる場合がありますが、一般的なワークフローを適用する必要があります。

手順	タスク	方法
3	ワーカー ノードの 1 つに SSH 接続して、更新するパッケージがあることを確認します。	3: パッケージ更新の有無の確認
4	更新を実行する新しいコマンドを使用して、カスタム ClusterClass を更新します。	4: カスタム ClusterClass の更新
5	更新がすでに実行されている新しいノードのロールアウトを確認します。	5: クラスタ ノードのローリング アップデートの確認

1: カスタム ClusterClass の作成

最初のパートでは、 tanzukubernetescluster という名前のデフォルトの ClusterClass のクローンを作成することで、 ccc（ customclusterclass の省略形）という名前のカスタム ClusterClass を作成します。

注： カスタム ClusterClass 名はユーザー定義です。別の名前を使用する場合は、指示を適宜調整します。

1. ccc-ns という名前の vSphere 名前空間 を作成します。

   権限、ストレージ、コンテンツ ライブラリ、および仮想マシン クラスを構成します。必要に応じて、ドキュメントを参照してください。

   注： vSphere 名前空間 名はユーザー定義です。別の名前を使用する場合は、指示を適宜調整します。
2. スーパーバイザー にログインします。

   kubectl vsphere login --server=IP-ADDRESS --vsphere-username [email protected]

3. デフォルトの ClusterClass の出力を ccc.yaml という名前のファイルに書き込みます。

   kubectl -n ccc-ns get clusterclass tanzukubernetescluster -o yaml > ccc.yaml

   または、ショートカット バージョン:

   kubectl -n ccc-ns get cc tanzukubernetescluster -o yaml > ccc.yaml

4. クローン作成された ClusterClass ファイルを編集するために を開きます。

   vim ccc.yaml

5. ccc.yaml ファイルを編集します。
   • metadata.creationTimestamp という行を削除します。
   • metadata.generation という行を削除します。
   • metadata.resourceVersion という行を削除します。
   • metadata.uid という行を削除します。
   • metadata.name の値を tanzukubernetescluster から ccc に変更します。
   • metadata.namespace の値は ccc-ns のままにします
   • run.tanzu.vmware.com/resolve-tkr: "" の値は metadata.annotations のままにします。この注釈は TKR データ/解決に必要です。
6. 変更を保存して確認します。

   apiVersion: cluster.x-k8s.io/v1beta1
   kind: ClusterClass
   metadata:
     annotations:
       run.tanzu.vmware.com/resolve-tkr: ""
     name: ccc
     namespace: ccc-ns
   spec:
   ...

7. カスタム ClusterClass オブジェクトを作成します。

   kubectl apply -f ccc.yaml -n ccc-ns

   予期される結果：

   clusterclass.cluster.x-k8s.io/ccc created

8. カスタム ClusterClass を一覧表示します。

   kubectl get cc -n ccc-ns

   予期される結果：

   NAME                     AGE
   ccc                      3m14s
   tanzukubernetescluster   29m
   

2: カスタム ClusterClass に基づく TKG クラスタの作成

クラスタ v1beta1 API を使用して、ClusterClass に基づくクラスタを作成します。

1. ccc-cluster.yaml マニフェストを作成してクラスタをプロビジョニングします。

   #ccc-cluster.yaml
   apiVersion: cluster.x-k8s.io/v1beta1
   kind: Cluster
   metadata:
     name: ccc-cluster
   spec:
     clusterNetwork:
       pods:
         cidrBlocks:
         - 192.0.2.0/16
       services:
         cidrBlocks:
         - 198.51.100.0/12
       serviceDomain: cluster.local
     topology:
       class: ccc
       version: v1.26.5---vmware.2-fips.1-tkg.1
       controlPlane:
         replicas: 1
       workers:
         machineDeployments:
           - class: node-pool
             name: tkgs-node-pool-1
             replicas: 1
       variables:
       - name: vmClass
         value: guaranteed-small
       - name: storageClass
         value: tkg-storage-profile

   ここで、

   • metadata.name の値はクラスタの名前です：ccc-cluster
   • spec.topology.class の値はカスタム ClusterClass の名前です：ccc
   • spec.topology.version の値は TKR バージョンです
   • spec.topology.variables.storageClass の値はパーシステント ストレージ クラスの名前です

   注： テスト目的で、制御プレーンとワーカー ノード プールには 1 つのレプリカで十分です。本番環境では、制御プレーンに 3 つのレプリカを使用し、ワーカー ノード プールごとに少なくとも 3 つのレプリカを使用します。
2. カスタム ClusterClass に基づいて TKG クラスタを作成します。

   kubectl apply -f ccc-cluster.yaml -n ccc-ns

   予期される結果：

   cluster.cluster.x-k8s.io/ccc-cluster created

3. クラスタのプロビジョニングを確認します。
   次のコマンドを実行します。すべてのクラスタ ノードが正常に起動するまで待機します。

   kubectl -n ccc-ns get cc,clusters,vsphereclusters,kcp,machinedeployment,machineset,machine,vspheremachine,virtualmachineservice

   注： 手順 5 でローリング アップデートの進行状況を監視できるように、このコマンドを別のセッションで実行すると役立ちます。

3: パッケージ更新の有無の確認

ワーカー ノードの 1 つに SSH 接続して、更新するパッケージがあることを確認します。

注： この手順の目的は、実際に更新するパッケージではなく、更新するパッケージがあることを確認することです。新しいクラスタ ノードがロールアウトされると、カスタム ClusterClass によって更新されます(このノードに続く手順)。この手順とその後に続く手順は、カスタム ClusterClass に対して実行できる操作の例を示します。

1. 次のコマンドを実行して、SSH シークレットを取得します。

   export CC=ccc-cluster && kubectl get secret -n ccc-ns ${CC}-ssh -o jsonpath={.data.ssh-privatekey} | base64 -d > ${CC}-ssh && chomd 4000 ${CC}-ssh

2. 次のコマンドを実行して、ワーカー ノード仮想マシンの IP アドレスを取得します。

   kubectl -n ccc-ns get vm -o wide

   注： 複数のワーカー ノードを展開した場合は、1 つを選択します。制御プレーン ノードは使用しないでください。
3. 次のコマンドを実行して、ワーカー ノード仮想マシンに SSH 接続します。

   ssh -i ${CC}-ssh vmware-system-user@IP-ADDRESS-OF-WORKER-NODE

   例：

   ssh -i ${CC}-ssh [email protected]

   注： 接続を続行するには、「yes」と入力します。
   予期される結果：ホストに SSH 接続すると、次のメッセージが表示されます。

   tdnf update info not availble yet!

4. 次のコマンドを実行し、更新を確認します。

   sudo -i

   tdnf update

5. プロンプトで、いいえ(更新しない)に「N」と入力します。
   予期される結果：

   Operation aborted

   注： ここでの目的は、更新を開始するのではなく、更新の存在を確認するだけです。次のセクションでカスタム ClusterClass にコマンドを追加して、更新を開始します。
6. 「exit」と入力して SSH セッションからログアウトし、もう一度「exit」と入力します。

4: カスタム ClusterClass の更新

tdnf 更新を実行する新しいコマンドを使用して、カスタム ClusterClass を更新します。

1. ccc という名前のカスタム ClusterClass を編集用に開きます。

   kubectl edit cc ccc -n ccc-ns

2. postKubeadmCommands を使用して、次のセクションまで下にスクロールします。

     - definitions:
       - jsonPatches:
         - op: add
           path: /spec/template/spec/kubeadmConfigSpec/postKubeadmCommands
           valueFrom:
             template: |
               - touch /root/kubeadm-complete
               - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
               - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
         selector:
           apiVersion: controlplane.cluster.x-k8s.io/v1beta1
           kind: KubeadmControlPlaneTemplate
           matchResources:
             controlPlane: true
       - jsonPatches:
         - op: add
           path: /spec/template/spec/postKubeadmCommands
           valueFrom:
             template: |
               - touch /root/kubeadm-complete
               - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
               - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
         selector:
           apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
           kind: KubeadmConfigTemplate
           matchResources:
             machineDeploymentClass:
               names:
               - node-pool
       name: controlPlanePostKubeadmCommandsSuccess
   

   次のコマンドを両方の valueFrom.template フィールドに追加します。

   - tdnf update -y

   例：

     - definitions:
       - jsonPatches:
         - op: add
           path: /spec/template/spec/kubeadmConfigSpec/postKubeadmCommands
           valueFrom:
             template: |
               - touch /root/kubeadm-complete
               - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
               - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
               - tdnf update -y
         selector:
           apiVersion: controlplane.cluster.x-k8s.io/v1beta1
           kind: KubeadmControlPlaneTemplate
           matchResources:
             controlPlane: true
       - jsonPatches:
         - op: add
           path: /spec/template/spec/postKubeadmCommands
           valueFrom:
             template: |
               - touch /root/kubeadm-complete
               - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
               - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
               - tdnf update -y
         selector:
           apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
           kind: KubeadmConfigTemplate
           matchResources:
             machineDeploymentClass:
               names:
               - node-pool
       name: controlPlanePostKubeadmCommandsSuccess
   

3. カスタム ClusterClass への変更を保存し、エディタを閉じます。

   wq

   予期される結果：

   clusterclass.cluster.x-k8s/ccc edited

5: クラスタ ノードのローリング アップデートの確認

カスタム ClusterClass を更新すると、その ClusterClass に基づいてプロビジョニングされたクラスタに対して、クラスタ ノードのローリング アップデートがトリガされます。新しいノードには、上記のコマンドが適用されています。

1. 次のコマンドを実行して、クラスタがプロビジョニングされていることを確認します。
   すべてのクラスタ ノードが正常に起動するまで待機します。

   kubectl -n ccc-ns get cc,clusters,vsphereclusters,kcp,machinedeployment,machineset,machine,vspheremachine,virtualmachineservice

2. 新しい UUID を持つ新しいノードがデプロイされたことがわかります。
3. 次のコマンドを実行して、ワーカー ノード仮想マシンに SSH 接続します。

   ssh -i ${CC}-ssh vmware-system-user@IP-ADDRESS-OF-WORKER-NODE

   予期される結果：ホストに SSH 接続すると、次のメッセージが表示されます。

   tdnf update info not availble yet!

4. 次のコマンドを実行します。

   sudo -i

   tdnf update

   予期される結果：更新が必要なパッケージが少なくなります。

5. プロンプトで、いいえ(更新しない)に「N」と入力します。
   予期される結果：

   Operation aborted

6. 次のコマンドを実行して、tdnf が実行されたことを確認します。

   cat /var/log/cloud-init-output.log | grep -i tdnf

7. 「exit」と入力して SSH セッションからログアウトし、もう一度「exit」と入力します。

カスタム ClusterClass のメンテナンス

TKG サービス を新しいバージョンにアップグレードした後、以前の TKG サービス バージョンのデフォルトの ClusterClass から派生したカスタム ClusterClass が、新しい TKG サービス バージョンに付属するデフォルトの ClusterClass に対する変更を使用して更新されていることを確認する必要があります。

次のワークフローを使用して、カスタム ClusterClass をシステム提供の ClusterClass と同期させます。これらの手順では、ここに記載されているように、最初のカスタム ClusterClass が作成されていることが前提となります。

1. TKG サービス バージョンをアップグレードします。

   たとえば、TKG サービス v3.0 から v3.1 にアップグレードします。

   TKG サービスのインストールとアップグレードを参照してください。

2. ここに記載されている手順に従って、新しいカスタム ClusterClass を作成します。

   新しいカスタム ClusterClass の名前に TKG サービス のバージョン（ccc-3.1 など）を追加して、バージョンを手動で管理します。

3. 以前のカスタム ClusterClass のカスタム パッチと変数を新しいカスタム ClusterClass に追加します。

   この操作を行うには、cat ccc.yaml を実行し、その中のカスタム パッチと変数を ccc-3.1.yaml にコピーします。

4. 新しいカスタム ClusterClass を適用し、調整が成功するまで待機します。
5. クラスタ オブジェクトの spec.topology.class フィールドを編集して、以前のカスタム ClusterClass を使用して TKG クラスタを新しいカスタム ClusterClass に更新します。

管理対象外の ClusterClass

vSphere 8 U2 以降では、TKG コントローラでカスタム ClusterClass を管理しない場合、そのカスタム ClusterClass に注釈を追加できます。この注釈を追加する場合は、基盤となるすべての Kubernetes オブジェクト（証明書、シークレットなど）を手動で作成する必要があることに注意してください。その方法については、vSphere 8 U1 カスタム ClusterClass のドキュメントを参照してください。

注釈は次のとおりです。

注釈キー	値
run.tanzu.vmware.com/unmanaged-clusterclass	" "

ccc という名前のカスタム ClusterClass に注釈を追加する方法の例を次に示します。

apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
  annotations:
    run.tanzu.vmware.com/resolve-tkr: ""
    run.tanzu.vmware.com/unmanaged-clusterclass: ""
  name: ccc
  namespace: ccc-ns
spec:
...