Erstellen einer benutzerdefinierten ClusterClass

In diesem Thema wird beschrieben, wie Sie Ihre eigene benutzerdefinierte ClusterClass-Ressource für einen eigenständigen Tanzu Kubernetes Grid-Verwaltungscluster (TKG) erstellen, sie verwenden, um klassenbasierte Arbeitslastcluster zu erstellen, und mit Clustern arbeiten, die auf der benutzerdefinierten ClusterClass basieren.

Um einen Cluster auf eine benutzerdefinierte ClusterClass zu stützen, legen Sie dessen spec.topology.class auf den Namen der benutzerdefinierten ClusterClass fest.

Diese Verfahren gelten nicht für TKG mit einem vSphere with Tanzu Supervisor.

Vorsicht

Die benutzerdefinierte ClusterClass ist eine experimentelle Kubernetes-Funktion gemäß der Dokumentation zur Upstream-Cluster-API. Aufgrund der im Zusammenhang mit der benutzerdefinierten ClusterClass verfügbaren Bandbreite an Anpassungen kann VMware nicht alle möglichen Anpassungen testen oder validieren. Die Kunden sind für das Testen, Validieren und Beheben von Fehlern ihrer benutzerdefinierten ClusterClass-Cluster verantwortlich. Sie können Support-Tickets für ihre benutzerdefinierten ClusterClass-Cluster öffnen. VMware Support beschränkt sich jedoch auf eine Unterstützung nach bestem Wissen und kann nicht garantieren, dass alle Probleme behoben werden, die bei benutzerdefinierten ClusterClass-Clustern auftreten. Die Kunden sollten sich diese Risiken bewusst machen, bevor sie benutzerdefinierte ClusterClass-Cluster in Produktionsumgebungen bereitstellen. Zum Erstellen von Arbeitslastclustern mithilfe der Standardressource ClusterClass führen Sie die Verfahren in Schritte für die Clusterbereitstellung durch.

Anforderungen

Um eine benutzerdefinierte ClusterClass zu erstellen, müssen ytt, imgpkg, die Tanzu CLI und kubectl lokal installiert sein. Informationen zum Herunterladen und Installieren von ytt und imgpkg finden Sie unter Installieren der Carvel-Tools.

Optionen: Vorlagen im Vergleich zu neuer Objektspezifikation

Um eine benutzerdefinierte ClusterClass zu erstellen, empfiehlt VMware, mit dem vorhandenen Standard-ClusterClass-Manifest oder den YTT-Vorlagen zu beginnen. Siehe Erstellen eines Basis-ClusterClass-Manifests. Wenn eine neue Version des Standard-ClusterClass-Objekts veröffentlicht wird, zum Beispiel mit einer neuen Version von TKG, können Sie das Overlay auf die neue Version anwenden, um dieselben Anpassungen vorzunehmen. Die Verfahren in diesem Thema beschreiben diese Methode zum Erstellen eines benutzerdefinierten ClusterClass-Objekts.

Um ein völlig neues ClusterClass-Objekt ohne Verwendung einer vorhandenen Vorlage zu schreiben, befolgen Sie die Anleitung zum Schreiben einer ClusterClass in der Dokumentation zur Cluster-API.

Erstellen eines ClusterClass-Basismanifests

Sie können ein ClusterClass-Basismanifest basierend auf dem standardmäßigen ClusterClass-Manifest oder auf YTT-Vorlagen erstellen, die Tanzu Kubernetes Grid bereitstellt. Alle benutzerdefinierten Cluster, die Sie erstellen, sollten auf diesem ClusterClass-Basismanifest basieren. Der Prozess besteht aus 3 Schritten:

1. Beziehen Sie das Standard-ClusterClass-Manifest oder die YTT-Vorlagen für Ihre Zielplattform.
2. Verwenden Sie die standardmäßigen ClusterClass-Manifest- oder YTT-Vorlagen, um ein angepasstes ClusterClass-Basismanifest zu generieren, das Informationen zu Ihrer Infrastruktur enthält.
3. Verwenden Sie dieses ClusterClass-Basismanifest als Vorlage, anhand derer Sie Ihre angepassten Cluster erstellen können.

Es gibt drei Methoden, mit denen Sie ein ClusterClass-Basismanifest für Ihre Cluster erstellen können.

• Methode 1: Abrufen des Basismanifests direkt von einem Verwaltungscluster. Dies ist die einfachste Methode. Wenn Sie einen Verwaltungscluster bereitstellen, wird automatisch ein Standard-Basismanifest generiert. Dieses Basismanifest enthält die Infrastrukturkonfiguration, die Sie bei der Bereitstellung des Verwaltungsclusters angegeben haben. Sie können diese direkt als ClusterClass-Basismanifest verwenden.
• Methode 2: Abrufen der YTT-Vorlagen über die Tanzu CLI (Fortgeschritten). Wenn Sie die Tanzu CLI installieren, werden YTT-Vorlagen auf Ihrem Computer installiert. Um ein Basismanifest aus diesen YTT-Vorlagen zu erstellen, müssen Sie ein YTT-Overlay erstellen, das Ihre Infrastrukturkonfiguration bereitstellt.
• Methode 3: Abrufen der YTT-Vorlagen aus der TKG Image-Registrierung (Fortgeschritten). Sie können die YTT-Vorlagen auch aus der TKG-Image-Registrierung abrufen. Um ein Basismanifest aus diesen YTT-Vorlagen zu erstellen, müssen Sie ein YTT-Overlay erstellen, das Ihre Infrastrukturkonfiguration bereitstellt.

Wichtig

Die Methoden 2 und 3 sind für fortgeschrittene Benutzer bestimmt, die folgende Anwendungsfälle erfüllen müssen:

• Sie möchten benutzerdefinierte ClusterClass-Definitionen für Ihr CI-System generieren, ohne einen eigenständigen Verwaltungscluster bereitzustellen.
• Sie möchten, dass Arbeitslastcluster eine andere Infrastruktur als Verwaltungscluster verwenden.

Methode 1: Abrufen des Basismanifests direkt von einem Verwaltungscluster

In Tanzu Kubernetes Grid v2.3.0 und höher finden Sie nach der Bereitstellung eines Verwaltungsclusters das standardmäßige ClusterClass-Manifest im Ordner ~/.config/tanzu/tkg/clusterclassconfigs.

Zum Anzeigen des Manifests für die Zielplattformen, auf denen Sie einen Verwaltungscluster bereitgestellt haben, führen Sie den folgenden Befehl aus:

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

Wenn Sie beispielsweise einen Verwaltungscluster auf vSphere bereitgestellt haben, wird die folgende YAML-Datei angezeigt.

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

Das generierte Manifest enthält Informationen über Ihre Zielplattform, die aus der Bereitstellung Ihres Verwaltungsclusters extrahiert wurden. Sie können dies als Basismanifest für die benutzerdefinierte ClusterClass-Erstellung direkt verwenden. Die nächsten Schritte finden Sie unter Anpassen des Basis-ClusterClass-Manifests.

Methode 2: Abrufen von YTT-Vorlagen über die Tanzu CLI

Nach der Installation von Tanzu CLI v1.0.0 oder höher, aber vor der Bereitstellung eines Verwaltungsclusters, finden Sie die YTT-Vorlagen für die Standard-ClusterClass im Ordner ~/.config/tanzu/tkg/providers/infrastructure-<provider name>/<provider version>/cconly. Sie können diese Vorlagen verwenden, um ein Basismanifest für die benutzerdefinierte ClusterClass-Erstellung zu erstellen.

1. Sie finden die Vorlagen, indem Sie den entsprechenden Befehl für Ihre Zielplattform ausführen.

   vSphere

   tree ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
   

   Die folgenden YAML-Dateien werden angezeigt.

   .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
   

   Die folgenden YAML-Dateien werden angezeigt.

   .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/
   

   Die folgenden YAML-Dateien werden angezeigt.

   .config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   

2. Erstellen Sie eine YTT-Datenwertdatei namens user_input.yaml mit dem folgenden Inhalt.

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

3. Fügen Sie user_input.yaml geeignete Konfigurationswerte für Ihre Zielplattform hinzu.

   Sie können die Konfigurationswerte verwenden, die Sie bei der Bereitstellung eines Verwaltungsclusters verwendet haben. Beispiel: Eine user_input.yaml-Datei für vSphere sieht zum Beispiel wie folgt aus:

   #@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. Verwenden Sie ytt, um das ClusterClass-Basismanifest für Ihre Zielplattform zu generieren.

   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
   

Nachdem Sie nun ein Basismanifest für Ihre Infrastruktur generiert haben, finden Sie die nächsten Schritte unter Anpassen des Basis-ClusterClass-Manifests.

Methode 3: Abrufen von YTT-Vorlagen aus der TKG-Image-Registrierung

Die YTT-Vorlagen für die standardmäßige ClusterClass können auch aus dem TKG-Image-Repository heruntergeladen werden. Sie können diese Vorlagen verwenden, um ein Basismanifest für die benutzerdefinierte ClusterClass-Erstellung zu erstellen.

1. Rufen Sie die YTT-Vorlagen aus dem providerTemplate-Image in der offiziellen TKG-Registrierung ab.

   Für TKG v2.3.1 ist das providerTemplate-Image-Tag v0.30.2. Sie finden die Tag-Version in der TKG-BOM-Datei, indem Sie nach providerTemplateImage suchen.

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

   Eine Ausgabe ähnlich der folgenden wird angezeigt:

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

   Die YAML-Vorlagendateien werden in einen Ordner providers heruntergeladen.

2. Erstellen Sie eine YTT-Datenwertdatei namens user_input.yaml mit dem folgenden Inhalt.

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

3. Fügen Sie user_input.yaml geeignete Konfigurationswerte für Ihre Zielplattform hinzu.

   Sie können die Konfigurationswerte verwenden, die Sie bei der Bereitstellung eines Verwaltungsclusters verwendet haben. Beispiel: Eine user_input.yaml-Datei für vSphere sieht zum Beispiel wie folgt aus:

   #@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. Verwenden Sie ytt, um das ClusterClass-Basismanifest für Ihre Zielplattform zu generieren.

   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
   

Nachdem Sie nun ein Basismanifest für Ihre Infrastruktur generiert haben, finden Sie die nächsten Schritte unter Anpassen des Basis-ClusterClass-Manifests.

Anpassen eines ClusterClass-Basismanifests

Um das ClusterClass-Manifest anzupassen, erstellen Sie zusammen mit dem Manifest ytt-Overlaydateien. Das folgende Beispiel zeigt, wie Sie einen Linux-Kernelparameter in der ClusterClass-Definition ändern.

1. Erstellen Sie wie folgt einen custom-Ordner:

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

2. Bearbeiten Sie custom/overlays/kernels.yaml.

   Fügen Sie z. B. nfConntrackMax als Variable hinzu und definieren Sie einen Patch dafür, der seinen Wert dem Kernel-Parameter net.netfilter.nf_conntrack_max für Steuerungsebenen-Knoten hinzufügt.

   Dieses Overlay hängt einen Befehl an das Feld preKubeadmCommands an, um die Konfiguration in sysctl.conf zu schreiben. Damit die Einstellung wirksam wird, können Sie den Befehl sysctl -p anhängen, um diese Änderung zu übernehmen. Standard-ClusterClass-Definitionen sind unveränderlich, sodass dieses Overlay auch den Namen Ihrer benutzerdefinierten ClusterClass und alle ihre Vorlagen ändert, indem Sie -extended hinzufügen.

   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. Entfernen Sie Ressourcen, die Sie nicht ändern möchten.

   In diesem Beispiel sollen alle Vorlagen von der benutzerdefinierten und der Standard-ClusterClass gemeinsam genutzt werden, weshalb sie alle entfernt werden. Sie können auch eine benutzerdefinierte Vorlage basierend auf der Standardvorlage auf dieselbe Weise erstellen. Stellen Sie in diesem Fall sicher, dass kind nicht ausgeschlossen wird.

   cat custom/overlays/filter.yaml
   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.not_op(overlay.subset({"kind": "ClusterClass"})),expects="0+"
   ---
   #@overlay/remove
   

4. Verwenden Sie das standardmäßige ClusterClass-Manifest, um die Basis-ClusterClass zu generieren.

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

5. Generieren Sie die benutzerdefinierte ClusterClass.

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

6. (Optional) Sehen Sie sich den Unterschied zwischen der standardmäßigen ClusterClass und Ihrer benutzerdefinierten Klasse an, um zu prüfen, ob die Änderungen übernommen wurden.

   diff default_cc.yaml custom_cc.yaml
   

   Eine Ausgabe wie die folgende sollte angezeigt werden:

   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
   

In diesem Beispiel können Sie sehen, dass -extended zum Clusternamen hinzugefügt wurde.

Installieren der benutzerdefinierten ClusterClass im Verwaltungscluster

Damit Ihr Verwaltungscluster Ihre benutzerdefinierte ClusterClass verwenden kann, installieren Sie sie, indem Sie das neue Manifest anwenden.

1. Wenden Sie das ClusterClass-Manifest an.

   kubectl apply -f custom_cc.yaml
   

   Die folgende Ausgabe sollte angezeigt werden.

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

2. Überprüfen Sie, ob die benutzerdefinierte ClusterClass an den Standard-Namespace propagiert wurde, z. B.:

   kubectl get clusterclass
   

   Die folgende Ausgabe sollte angezeigt werden.

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

Generieren des benutzerdefinierten Arbeitslastcluster-Manifests

Nachdem Sie Ihre benutzerdefinierte ClusterClass erstellt haben, können Sie sie verwenden, um einen neuen Arbeitslastcluster zu erstellen, der Ihre Anpassung enthält.

1. Führen Sie tanzu cluster create mit der Option --dry-run aus, um ein Clustermanifest aus einer Standard-Clusterkonfigurationsdatei zu erzeugen.

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

2. Erstellen Sie ein ytt-Overlay oder bearbeiten Sie das Cluster-Manifest direkt.

   Es wird empfohlen, ein ytt-Overlay zu erstellen, z. B. cluster_overlay.yaml, um Folgendes auszuführen:

   • Ersetzen Sie den Wert topology.class durch den Namen der benutzerdefinierten ClusterClass.
   • Fügen Sie die benutzerdefinierten Variablen mit einem Standardwert zum Block variables hinzu.

   Wie beim Ändern von ClusterClass-Objektspezifikationen können Sie mithilfe eines Overlays wie folgt die Änderungen automatisch auf neue Objekte anwenden, wenn eine neue Upstream-Clusterversion vorhanden ist.

   #@ 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. Generieren Sie das custom_cluster.yaml-Manifest:

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

4. (Optional) Wie bei der obigen ClusterClass können Sie diff ausführen, um das Manifest des Clusters mit benutzerdefinierter Klasse mit einem klassenbasierten Standardcluster zu vergleichen, z. B.:

   diff custom_cluster.yaml default_cluster.yaml
   

   Eine Ausgabe wie die folgende sollte angezeigt werden:

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

Erstellen eines benutzerdefinierten Clusters

Erstellen Sie einen benutzerdefinierten Arbeitslastcluster wie folgt basierend auf dem oben erzeugten benutzerdefinierten Manifest.

1. Erstellen Sie den Cluster.

   tanzu cluster create -f custom_cluster.yaml
   

2. Überprüfen Sie die Eigenschaften des erstellten Objekts.

   Rufen Sie beispielsweise mit der obigen Kernel-Änderung das Objekt KubeadmControlPlane ab und bestätigen Sie, dass die Kernel-Konfiguration festgelegt ist:

   kubectl get kcp workload-1-jgwd9 -o yaml
   

   Eine Ausgabe wie die folgende sollte angezeigt werden:

   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. Melden Sie sich bei Knoten der Steuerungsebene an und prüfen Sie, ob die sysctl.conf geändert wurde:

   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
   

Upgrade von benutzerdefinierten Clustern

Wenn Sie benutzerdefinierte Cluster mit einer früheren Version erstellt haben, können Sie sie auf die neueste TKG-Version aktualisieren.

Vorbereitungen für das Upgrade von Clustern

Bevor Sie ein Upgrade von Clustern durchführen, müssen Sie einige vorbereitende Schritte ausführen.

1. Bevor Sie ein Upgrade des Verwaltungsclusters durchführen, erstellen Sie Testcluster mit der Version des benutzerdefinierten Manifests, die Sie für die vorherige Version erstellt haben.

   Erstellen Sie beispielsweise einen benutzerdefinierten Cluster mit dem Namen test-upgrade.

2. Rufen Sie Informationen zu den mit Ihrem TKG 2.2-Verwaltungscluster verfügbaren ClusterClass-Versionen ab.

   kubectl get clusterclass
   

   Wenn Sie die benutzerdefinierten Cluster mit TKG v2.2.0 erstellt haben, sollte die ClusterClass-Version 1.0.0 sein. Beispiel:

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

3. Rufen Sie die Informationen zu den ClusterClass-Versionen ab, die in Ihrem test-upgrade-Cluster ausgeführt werden.

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

   Die Ausgabe sollte tkg-vsphere-default-extended-v1.0.0 sein.

4. Befolgen Sie die Anweisungen unter Upgrade eigenständiger Verwaltungscluster, um ein Upgrade des Verwaltungsclusters auf TKG 2.3 durchzuführen.

5. Rufen Sie Informationen zur ClusterClass-Version ab, die nach dem Upgrade des Verwaltungsclusters auf v.2.3 verfügbar ist.

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

   Die Ausgabe sollte tkg-vsphere-default-v1.1.0 sein, wenn der Verwaltungscluster auf vSphere ausgeführt wird.

6. Befolgen Sie die Verfahren unter Erstellen eines ClusterClass-Basismanifest und Anpassen eines ClusterClass-Basismanifests, um eine neue Version Ihres ClusterClass-Manifests zu erstellen.
   • Nennen Sie beispielsweise die neue benutzerdefinierte ClusterClass tkg-vsphere-default-v1.1.0-extended und fügen Sie dieselben benutzerdefinierten Variablen wie in der alten Version tkg-vsphere-default-extended-v1.0.0 ein.
   • Benennen Sie das neue Overlay custom_cc.yaml.

7. Installieren Sie die neue benutzerdefinierte ClusterClass im Verwaltungscluster.

   kubectl apply -f custom_cc.yaml
   

8. Rufen Sie Informationen zu den ClusterClass-Versionen ab, die jetzt mit Ihrem Verwaltungscluster verfügbar sind.

   kubectl get clusterclass
   

   Sowohl die älteren als auch die neueren Versionen sollten angezeigt werden.

   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
   

Durchführen des Upgrades

Nachdem Sie die vorbereitenden Schritte durchgeführt haben, können Sie das Upgrade auf dem Testcluster testen, bevor Sie das Upgrade Ihrer Produktionscluster durchführen.

1. Führen Sie ein Rebase des test-upgrade des Clusters von der alten Version der benutzerdefinierten ClusterClass auf die neue Version durch.

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

   Die Ausgabe sollte cluster.cluster.x-k8s.io/test-upgrade patched sein.

2. Rufen Sie die Informationen über die ClusterClass-Version ab, die jetzt in Ihrem test-upgrade-Cluster ausgeführt wird.

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

   Die Ausgabe sollte tkg-vsphere-default-v1.1.0-extended sein. Zuvor war es tkg-vsphere-default-extended-v1.0.0.

3. Warten Sie einige Minuten und führen Sie kubectl get cluster aus, bis angezeigt wird, dass UpdatesAvailable auf true aktualisiert wurde.

   kubectl get cluster test-upgrade -o yaml
   

   Anschließend sollte eine Meldung ähnlich der folgenden in der Ausgabe angezeigt werden:

   ...
   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. Aktualisieren Sie den test-upgrade-Cluster.

   tanzu cluster upgrade test-upgrade    
   

5. Überprüfen Sie die Eigenschaften des erstellten Objekts.

   Rufen Sie z. B. mit der im obigen Beispiel beschriebenen Kerneländerung das KubeadmControlPlane-Objekt ab und bestätigen Sie, dass die Kernelkonfiguration festgelegt ist:

   kubectl get kcp test-upgrade-nsc6d -o yaml
   

   Eine Ausgabe wie die folgende sollte angezeigt werden:

   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  
   

Upgrade von Produktionsclustern

Wenn das Test-Upgrade erfolgreich war, wiederholen Sie die Schritte von Durchführen des Upgrades auf Ihren Produktionsclustern.

Hinweis

Wenn Sie während des Upgrades auf Fehler stoßen, können Sie ein Rollback durchführen, indem Sie ein Rebase des Clusters von der neuen Version der benutzerdefinierten ClusterClass auf die alte Version vornehmen.

Rebase eines benutzerdefinierten Clusters zur Verwendung einer Standard-ClusterClass

Wenn Sie Cluster mit der Standard-ClusterClass erstellt haben und sie aktualisieren möchten, um eine benutzerdefinierte ClusterClass zu verwenden, verwenden Sie kubectl für die Bearbeitung des Cluster-Objekts:

• Ändern Sie spec.topology.class in den Namen Ihres benutzerdefinierten ClassClass-Manifests.
• Ändern Sie spec.topology.variables, um Ihre benutzerdefinierten Variablen anzuhängen.

Rebase eines Standardclusters zur Verwendung einer benutzerdefinierten ClusterClass

Wenn Sie zu einer neuen Version der Standard-ClusterClass zurückkehren möchten:

• Ändern Sie spec.topology.class in die neue Version der Standard-ClusterClass.
• Ändern Sie spec.topology.variables, um die benutzerdefinierten Variablen zu entfernen. Möglicherweise müssen Sie neue Variablen hinzufügen, die in der neuen Version der Standard-ClusterClass definiert sind.