This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

カスタム ClusterClass の作成

このトピックでは、Tanzu Kubernetes Grid (TKG) スタンドアローン管理クラスタに独自のカスタム ClusterClass リソースを作成し、それを使用してクラスベースのワークロード クラスタを作成し、カスタム ClusterClass に基づくクラスタと連携する方法について説明します。

カスタム ClusterClass をクラスタのベースにするには、その spec.topology.class をカスタム ClusterClass 名に設定します。

これらの手順は、vSphere with Tanzu スーパーバイザーを使用する TKG には適用されません。

注意

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

要件

カスタム ClusterClass を作成するには、ytt、imgpkg、Tanzu CLI、および kubectl がローカルにインストールされている必要があります。ytt と imgpkg のダウンロードおよびインストール方法については、「Carvel ツールのインストール」を参照してください。

オプション：テンプレートと新しいオブジェクト仕様

カスタム ClusterClass を作成するには、VMware は、「ベース ClusterClass マニフェスト」で説明されているように、既存のデフォルトの ClusterClass マニフェストまたは YTT テンプレートから開始することをお勧めします。新しいバージョンの TKG など、デフォルトの ClusterClass オブジェクトの新しいバージョンが公開されると、同じカスタマイズを実装するためにオーバーレイを新しいバージョンに適用できます。このトピックの手順では、カスタム ClusterClass オブジェクトを作成するこの方法について説明します。

既存のテンプレートを使用せずにまったく新しい ClusterClass オブジェクトをゼロから記述する場合は、Cluster API ドキュメントの「Writing a ClusterClass」の手順に従います。

ベース ClusterClass マニフェストの作成

デフォルトの ClusterClass マニフェストまたは Tanzu Kubernetes Grid が提供する YTT テンプレートに基づいて、ベース ClusterClass マニフェストを作成できます。作成するカスタム クラスタは、このベース ClusterClass マニフェストに基づいている必要があります。プロセスには次の 3 つの手順があります。

  1. ターゲット プラットフォームのデフォルトの ClusterClass マニフェストまたは YTT テンプレートを取得します。
  2. デフォルトの ClusterClass マニフェストまたは YTT テンプレートを使用して、インフラストラクチャに関する情報を含むカスタマイズされたベース ClusterClass マニフェストを生成します。
  3. このベース ClusterClass マニフェストを、カスタマイズしたクラスタの作成元となるテンプレートとして使用します。

クラスタのベース ClusterClass マニフェストを作成する方法は 3 つあります。

  • 方法 1：管理クラスタからベース マニフェストを直接取得します。これは最も簡単な方法です。管理クラスタを展開すると、デフォルトのベース マニフェストが自動的に生成されます。このベース マニフェストには、管理クラスタを展開したときに指定したインフラストラクチャ構成が含まれます。これは、ベース ClusterClass マニフェストとして直接使用できます。
  • 方法 2：Tanzu CLI から YTT テンプレートを取得します（上級）。Tanzu CLI をインストールすると、YTT テンプレートがマシンにインストールされます。これらの YTT テンプレートからベース マニフェストを作成するには、インフラストラクチャ構成を提供する YTT オーバーレイを作成する必要があります。
  • 方法 3：TKG イメージ レジストリから YTT テンプレートを取得します（上級）。TKG イメージ レジストリから YTT テンプレートを取得することもできます。これらの YTT テンプレートからベース マニフェストを作成するには、インフラストラクチャ構成を提供する YTT オーバーレイを作成する必要があります。
重要

方法 2 および 3 は、次のユースケースを満たす必要がある上級ユーザーを対象にしています。

  • スタンドアローン管理クラスタを展開せずに、CI システムのカスタム ClusterClass 定義を生成する。
  • ワークロード クラスタで、管理クラスタとは異なるインフラストラクチャを使用する。

方法 1：管理クラスタからベース マニフェストを直接取得する

Tanzu Kubernetes Grid 2.3.0 以降では、管理クラスタを展開した後、~/.config/tanzu/tkg/clusterclassconfigs フォルダにデフォルトの ClusterClass マニフェストを見つけることができます。

管理クラスタを展開したターゲット プラットフォームのマニフェストを表示するには、次のコマンドを実行します。

tree ~/.config/tanzu/tkg/clusterclassconfigs/

たとえば、管理クラスタを vSphere に展開した場合、次の YAML ファイルが表示されます。

.config/tanzu/tkg/clusterclassconfigs/
└── tkg-vsphere-default-v1.1.0.yaml
 
1 directory, 1 file

生成されたマニフェストには、管理クラスタの展開から抽出されたターゲット プラットフォームに関する情報が含まれています。これは、カスタム ClusterClass 作成のベース マニフェストとして直接使用できます。次の手順については、「ベース ClusterClass マニフェストのカスタマイズ」を参照してください。

方法 2：Tanzu CLI から YTT テンプレートを取得する

Tanzu CLI v1.0.0 以降をインストールした後、管理クラスタを展開する前に、デフォルトの ClusterClass の YTT テンプレートを ~/.config/tanzu/tkg/providers/infrastructure-<provider name>/<provider version>/cconly フォルダに見つけることができます。これらのテンプレートを使用して、カスタム ClusterClass 作成のベース マニフェストを作成できます。

  1. テンプレートを見つけるには、ターゲット プラットフォームに適したコマンドを実行します。

    vSphere 
    tree ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
    次の YAML ファイルが表示されます。 
    .config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
├── base.yaml
├── overlay-kube-apiserver-admission.yaml
└── overlay.yaml

1 directory, 3 files
    AWS 
    tree ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
    次の YAML ファイルが表示されます。 
    .config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
├── base.yaml
├── overlay-kube-apiserver-admission.yaml
└── overlay.yaml
    Azure 
    tree ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
    次の YAML ファイルが表示されます。 
    .config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
├── base.yaml
├── overlay-kube-apiserver-admission.yaml
└── overlay.yaml

  2. 次の内容を使用して、user_input.yaml という名前の YTT データ値ファイルを作成します。

    #@data/values

#@overlay/match-child-defaults missing_ok=True
---

  3. ターゲット プラットフォームに適した構成値を user_input.yaml に追加します。

    管理クラスタの展開時に使用した構成値を使用できます。たとえば、vSphere の user_input.yaml ファイルは次のようになります。

    #@data/values

#@overlay/match-child-defaults missing_ok=True
---
ENABLE_MHC: true
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
NODE_STARTUP_TIMEOUT: 20m
VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
VSPHERE_DATACENTER: /dc0
VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
VSPHERE_FOLDER: /dc0/vm
VSPHERE_NETWORK: /dc0/network/VM Network
VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
VSPHERE_SERVER: xxx.xxx.xxx.xxx
VSPHERE_USERNAME: [email protected]
VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
VSPHERE_WORKER_MEM_MIB: "8192"
VSPHERE_WORKER_NUM_CPUS: "4"
VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.0"       # change it to the version in TKG BOM
NAMESPACE: "tkg-system"                       # DO NOT change it

  4. ytt を使用して、ターゲット プラットフォームのベース ClusterClass マニフェストを生成します。

    vSphere 
    ytt -f ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
    AWS 
    ytt -f ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
    Azure 
    ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml

インフラストラクチャのベース マニフェストを生成したら、次の手順について「ベース ClusterClass マニフェストのカスタマイズ」を参照してください。

方法 3：TKG イメージ レジストリから YTT テンプレートを取得する

デフォルトの ClusterClass の YTT テンプレートは、TKG イメージ リポジトリからダウンロードすることもできます。これらのテンプレートを使用して、カスタム ClusterClass 作成のベース マニフェストを作成できます。

  1. 公式 TKG レジストリの providerTemplate イメージから YTT テンプレートをプルします。

    TKG v2.3.1 の場合、providerTemplate イメージのタグは v0.30.2 です。タグのバージョンは、providerTemplateImage を検索して TKG BOM ファイルで確認できます。

    imgpkg pull -i projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates:v0.30.2 -o providers

    次のような出力が表示されます。

    Pulling image 'projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates@sha256:b210d26c610800f5da4b3aa55bfbc8ffae9275fa2c4073a2b1332e2045a6e1da'
Extracting layer 'sha256:3ba336232c0e616b2b6c8f263593497c5a059a645f4c6137ea0eb658f4a8538a' (1/1)

Succeeded

    YAML テンプレート ファイルは、providers フォルダにダウンロードされます。

  2. 次の内容を使用して、user_input.yaml という名前の YTT データ値ファイルを作成します。

    #@data/values

#@overlay/match-child-defaults missing_ok=True
---

  3. ターゲット プラットフォームに適した構成値を user_input.yaml に追加します。

    管理クラスタの展開時に使用した構成値を使用できます。たとえば、vSphere の user_input.yaml ファイルは次のようになります。

    #@data/values

#@overlay/match-child-defaults missing_ok=True
---
ENABLE_MHC: true
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
NODE_STARTUP_TIMEOUT: 20m
VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
VSPHERE_DATACENTER: /dc0
VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
VSPHERE_FOLDER: /dc0/vm
VSPHERE_NETWORK: /dc0/network/VM Network
VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
VSPHERE_SERVER: xxx.xxx.xxx.xxx
VSPHERE_USERNAME: [email protected]
VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
VSPHERE_WORKER_MEM_MIB: "8192"
VSPHERE_WORKER_NUM_CPUS: "4"
VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.0"       # change it to the version in TKG BOM
NAMESPACE: "tkg-system"                       # DO NOT change it

  4. ytt を使用して、ターゲット プラットフォームのベース ClusterClass マニフェストを生成します。

    vSphere 
    ytt -f providers/infrastructure-vsphere/v1.7.0/cconly -f providers/config_default.yaml -f user_input.yaml
    AWS 
    ytt -f providers/infrastructure-aws/v2.1.3/cconly -f providers/config_default.yaml -f user_input.yaml
    Azure 
    ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml

インフラストラクチャのベース マニフェストを生成したら、次の手順について「ベース ClusterClass マニフェストのカスタマイズ」を参照してください。

ベース ClusterClass マニフェストのカスタマイズ

ClusterClass マニフェストをカスタマイズするには、マニフェストと一緒に ytt オーバーレイ ファイルを作成します。次の例は、ClusterClass 定義で Linux カーネル パラメータを変更する方法を示しています。

  1. 次のように、custom フォルダを作成します。

    tree custom
custom
|-- overlays
    |-- filter.yaml
    |-- kernels.yaml

  2. custom/overlays/kernels.yaml を編集します。

    たとえば、nfConntrackMax を変数として追加し、その値を制御プレーン ノードのカーネル パラメータ net.netfilter.nf_conntrack_max に追加するパッチを定義します。

    このオーバーレイは、preKubeadmCommands フィールドにコマンドを追加して、構成を sysctl.conf に書き込みます。この設定を有効にするには、コマンド sysctl -p を追加してこの変更を適用できます。デフォルトの ClusterClass 定義は変更できないため、このオーバーレイでは、-extended を追加することで、カスタム ClusterClass とそのすべてのテンプレートの名前も変更します。

    cat custom/overlays/kernels.yaml
#@ load("@ytt:overlay", "overlay")

#@overlay/match by=overlay.subset({"kind":"ClusterClass"})
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
  name: tkg-vsphere-default-v1.1.0-extended
spec:
  variables:
  - name: nfConntrackMax
    required: false
    schema:
      openAPIV3Schema:
        type: string
  patches:
  - name: nfConntrackMax
    enabledIf: '{{ not (empty .nfConntrackMax) }}'
    definitions:
      - selector:
          apiVersion: controlplane.cluster.x-k8s.io/v1beta1
          kind: KubeadmControlPlaneTemplate
          matchResources:
            controlPlane: true
        jsonPatches:
          - op: add
            path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
            valueFrom:
              template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
          - op: add
            path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
            value: sysctl -p

  3. 変更しないリソースを削除します。

    この例では、すべてのテンプレートはカスタムとデフォルトの ClusterClass 間で共有されることを目的としているため、すべて削除されます。同様に、デフォルト テンプレートに基づいてカスタム テンプレートを作成することもできます。その場合は、kind が除外されていないことを確認します。

    cat custom/overlays/filter.yaml
#@ load("@ytt:overlay", "overlay")

#@overlay/match by=overlay.not_op(overlay.subset({"kind": "ClusterClass"})),expects="0+"
---
#@overlay/remove

  4. デフォルトの ClusterClass マニフェストを使用して、ベース ClusterClass を生成します。

    ytt -f tkg-vsphere-default-v1.1.0.yaml -f custom/overlays/filter.yaml > default_cc.yaml

  5. カスタム ClusterClass を生成します。

    ytt -f tkg-vsphere-default-v1.1.0.yaml -f custom/ > custom_cc.yaml

  6. （オプション）デフォルト ClusterClass とカスタム ClusterClass の違いを確認して、変更が適用されていることを確認します。

    diff default_cc.yaml custom_cc.yaml

    次のような出力が表示されます。

    4c4
<   name: tkg-vsphere-default-v1.1.0
---
>   name: tkg-vsphere-default-v1.1.0-extended
638a639,643
>   - name: nfConntrackMax
>     required: false
>     schema:
>       openAPIV3Schema:
>         type: string
2607a2613,2628
>   - name: nfConntrackMax
>     enabledIf: '{{ not (empty .nfConntrackMax) }}'
>     definitions:
>     - selector:
>         apiVersion: controlplane.cluster.x-k8s.io/v1beta1
>         kind: KubeadmControlPlaneTemplate
>         matchResources:
>           controlPlane: true
>       jsonPatches:
>       - op: add
>         path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
>         valueFrom:
>           template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
>       - op: add
>         path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
>         value: sysctl -p

この例では、-extended がクラスタ名に追加されていることを確認できます。

管理クラスタへのカスタム ClusterClass のインストール

管理クラスタでカスタム ClusterClass を使用できるようにするには、新しいマニフェストを適用してインストールします。

  1. ClusterClass マニフェストを適用します。

    kubectl apply -f custom_cc.yaml

    次の出力が表示されます。

    clusterclass.cluster.x-k8s.io/tkg-vsphere-default-v1.1.0-extended created

  2. カスタム ClusterClass がデフォルトの名前空間に伝達されているかどうかを確認します。次に例を示します。

    kubectl get clusterclass

    次の出力が表示されます。

    NAME                                  AGE
tkg-vsphere-default-v1.1.0            2d23h
tkg-vsphere-default-v1.1.0-extended   11s

カスタム ワークロード クラスタ マニフェストの生成

カスタム ClusterClass を作成した後、これを使用してカスタマイズを含む新しいワークロード クラスタを作成できます。

  1. tanzu cluster create を --dry-run オプションを指定して実行し、標準のクラスタ構成ファイルからクラスタ マニフェストを生成します。

    tanzu cluster create --file workload-1.yaml --dry-run > default_cluster.yaml

  2. ytt オーバーレイを作成するか、クラスタ マニフェストを直接編集します。

    推奨されるオプションは、ytt オーバーレイ（cluster_overlay.yaml など）を作成して、次の操作を実行することです。

    • topology.class 値をカスタム ClusterClass の名前に置き換えます。
    • デフォルト値を使用して、カスタム変数を variables ブロックに追加します。

    ClusterClass オブジェクト仕様の変更と同様に、次のようにオーバーレイを使用すると、新しいアップストリーム クラスタ リリースが発生するたびに、変更を新しいオブジェクトに自動的に適用できます。

    #@ load("@ytt:overlay", "overlay")

#@overlay/match by=overlay.subset({"kind":"Cluster"})
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
spec:
  topology:
    class: tkg-vsphere-default-v1.1.0-extended
    variables:
    - name: nfConntrackMax
      value: "1048576

  3. custom_cluster.yaml マニフェストを生成します。

    ytt -f default_cluster.yaml -f cluster_overlay.yaml > custom_cluster.yaml

  4. （オプション）前述の ClusterClass と同様に、diff を実行して、カスタムクラス クラスタ マニフェストをデフォルトのクラスベースのクラスタと比較できます。次に例を示します。

    diff custom_cluster.yaml default_cluster.yaml

    次のような出力が表示されます。

    <     class: tkg-vsphere-default-v1.1.0
---
>     class: tkg-vsphere-default-v1.1.0-extended
142a143,144
>     - name: nfConntrackMax
>       value: "1048576"

カスタム クラスタの作成

前述の生成されたカスタム マニフェストに基づいて、次のようにカスタム ワークロード クラスタを作成します。

  1. クラスタを作成します。

    tanzu cluster create -f custom_cluster.yaml

  2. 作成されたオブジェクト プロパティを確認します。

    たとえば、前述のカーネル変更を行った場合は、KubeadmControlPlane オブジェクトを取得し、カーネル構成が設定されていることを確認します。

    kubectl get kcp workload-1-jgwd9 -o yaml

    次のような出力が表示されます。

    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
...
    preKubeadmCommands:
    - hostname "{{ ds.meta_data.hostname }}"
    - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
    - echo "127.0.0.1   localhost" >>/etc/hosts
    - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
    - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
    - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
    - sysctl -p
...

  3. 制御プレーン ノードにログインし、その sysctl.conf が変更されていることを確認します。

    capv@workload-1-jgwd9:~$ sudo cat /etc/sysctl.conf
...
net.ipv6.neigh.default.gc_thresh3=16384
fs.file-max=9223372036854775807
net.netfilter.nf_conntrack_max=1048576

カスタム クラスタのアップグレード

以前のリリースでカスタム クラスタを作成した場合は、最新の TKG リリースにアップグレードできます。

クラスタのアップグレードの準備

クラスタをアップグレードする前に、実行する準備手順があります。

  1. 管理クラスタをアップグレードする前に、以前のリリース用に作成したカスタム マニフェストのバージョンを使用してテスト クラスタを作成します。

    たとえば、test-upgrade という名前のカスタム クラスタを作成します。

  2. TKG 2.2 管理クラスタで使用可能な ClusterClass バージョンに関する情報を取得します。

    kubectl get clusterclass

    TKG v2.2.0 を使用してカスタム クラスタを作成した場合、ClusterClass のバージョンは 1.0.0 になります。例：

    NAME                                  AGE
tkg-vsphere-default-extended-v1.0.0   21m
tkg-vsphere-default-v1.0.0            10d

  3. test-upgrade クラスタで実行されている ClusterClass バージョンに関する情報を取得します。

    kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'

    出力は tkg-vsphere-default-extended-v1.0.0 のようになります。

  4. 「スタンドアローン管理クラスタのアップグレード」の手順に従って管理クラスタを TKG 2.3 にアップグレードします。

  5. 管理クラスタを v2.3 にアップグレードした後に使用可能な ClusterClass バージョンに関する情報を取得します。

    kubectl get cluster mgmt-cluster-name -n tkg-system -o jsonpath='{.spec.topology.class}'

    管理クラスタが vSphere で実行されている場合、出力は tkg-vsphere-default-v1.1.0 になります。

  6. 「ベース ClusterClass マニフェストの作成」と「ベース ClusterClass マニフェストのカスタマイズ」の手順に従って、新しいバージョンの ClusterClass マニフェストを作成します。
    • たとえば、新しいカスタム ClusterClass に tkg-vsphere-default-v1.1.0-extended という名前を指定し、古いバージョン tkg-vsphere-default-extended-v1.0.0 と同じカスタム変数を含めます。
    • 新しいオーバーレイに custom_cc.yaml という名前を付けます。

  7. 管理クラスタに新しいカスタム ClusterClass をインストールします。

    kubectl apply -f custom_cc.yaml

  8. 管理クラスタで使用可能になった ClusterClass バージョンに関する情報を取得します。

    kubectl get clusterclass

    古いバージョンと新しいバージョンの両方が表示されます。

    NAME                                  AGE
tkg-vsphere-default-extended-v1.0.0   61m
tkg-vsphere-default-v1.0.0            10d
tkg-vsphere-default-v1.1.0            25m
tkg-vsphere-default-v1.1.0-extended   15s

アップグレードの実行

準備手順を実行したら、本番クラスタをアップグレードする前に、テスト クラスタでアップグレードをテストできます。

  1. クラスタ test-upgrade を古いバージョンのカスタム ClusterClass から新しいバージョンにリベースします。

    kubectl patch cluster test-upgrade --type merge -p '{"spec": {"topology": {"class": "tkg-vsphere-default-v1.1.0-extended"}}}'

    出力は cluster.cluster.x-k8s.io/test-upgrade patched のようになります。

  2. test-upgrade クラスタで現在実行されている ClusterClass バージョンに関する情報を取得します。

    kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'

    出力は tkg-vsphere-default-v1.1.0-extended のようになります。以前は、tkg-vsphere-default-extended-v1.0.0 でした。

  3. 数分待ってから kubectl get cluster を実行し、UpdatesAvailable が true に更新されていることを確認します。

    kubectl get cluster test-upgrade -o yaml

    準備ができると、次のようなメッセージが出力に表示されます。

    ...
status:
  conditions:
...
  - lastTransitionTime: "2023-06-19T09:59:21Z"
    message: '[v1.25.9+vmware.1-tkg.1-20230609 v1.26.4+vmware.1-tkg.1-20230609]'
    status: "True"
    type: UpdatesAvailable
  controlPlaneReady: true
  infrastructureReady: true
  observedGeneration: 5
  phase: Provisioned

  4. test-upgrade クラスタをアップグレードします。

    tanzu cluster upgrade test-upgrade

  5. 作成されたオブジェクト プロパティを確認します。

    たとえば、上記の例で説明するようにカーネル変更を行った場合は、KubeadmControlPlane オブジェクトを取得し、カーネル構成が設定されていることを確認します。

    kubectl get kcp test-upgrade-nsc6d -o yaml

    次のような出力が表示されます。

    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
...
    preKubeadmCommands:
    - hostname "{{ ds.meta_data.hostname }}"
    - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
    - echo "127.0.0.1   localhost" >>/etc/hosts
    - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
    - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
    - sed -i 's|".*/pause|"projects-stg.registry.vmware.com/tkg/pause|' /etc/containerd/config.toml
    - systemctl restart containerd
    - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
    - sysctl -p

本番クラスタのアップグレード

テスト アップグレードが成功した場合は、本番クラスタで「アップグレードの実行」の手順を繰り返します。

注

アップグレード中にエラーが発生した場合は、カスタム ClusterClass の新しいバージョンから古いバージョンにクラスタをリベースすることでロールバックできます。

カスタム ClusterClass を使用するためのデフォルト クラスタのリベース

デフォルト ClusterClass を使用してクラスタを作成し、カスタム ClusterClass を使用するように更新する場合は、kubectl を使用してクラスタ オブジェクトを編集します。

  • spec.topology.class をカスタム ClassClass マニフェストの名前に変更します。
  • spec.topology.variables を変更して、カスタム変数を追加します。

デフォルト ClusterClass を使用するためのカスタム クラスタのリベース

デフォルト ClusterClass の新しいバージョンに戻す場合は、次の手順を実行します。

  • spec.topology.class をデフォルト ClusterClass の新しいバージョンに変更します。
  • spec.topology.variables を変更して、カスタム変数を削除します。デフォルト ClusterClass の新しいバージョンで定義されている新しい変数の追加が必要になる場合があります。
check-circle-line exclamation-circle-line close-line
Scroll to top icon