Nachdem eine Tanzu Kubernetes-Clusterspezifikation automatisch in das v1alpha2-API-Format konvertiert wurde, müssen Sie möglicherweise einige Vorverarbeitungsschritte der Clusterspezifikation durchführen, um ein paralleles Update des Tanzu Kubernetes-Clusters durchzuführen, das in der Regel durch Ändern der Tanzu Kubernetes-Version erfolgt. Auf diese Weise werden Fehler vermieden.

Automatische Konvertierung von Cluster-Spezifikationen

Um Ihre vSphere with Tanzu-Umgebung auf die Tanzu Kubernetes Grid-Dienst-v1alpha2-API zu aktualisieren, aktualisieren Sie den Supervisor-Cluster, auf dem der Dienst ausgeführt wird.

Sobald der Tanzu Kubernetes Grid-Dienst die v1alpha2-API ausführt, konvertiert das System automatisch alle vorhandenen Tanzu Kubernetes-Clusterspezifikationen vom v1alpha1-Format in das v1alpha2-Format. Während des automatischen Konvertierungsprozesses erstellt das System die erwarteten Felder für jedes Clustermanifest und füllt diese auf. Veraltete und hinzugefügte APIs listet die Felder der Clusterspezifikation in der v1alpha2-API auf, die neu bzw. veraltet sind.

Zum Aktualisieren der Tanzu Kubernetes-Version für einen Cluster, dessen Manifest automatisch in das v1alpha2-Format konvertiert wurde, müssen Sie eine manuelle Vorverarbeitung durchführen, um Fehler zu vermeiden. Cluster-Update-Beispiele listet diverse Optionen auf.

Veraltete und hinzugefügte APIs

In der Tabelle werden die Einstellungen der Clusterspezifikation aufgeführt, die in der v1alpha2-API veraltet sind und durch neue Einstellungen ersetzt werden.
Veraltete Einstellungen Neue Einstellungen Anmerkungen

spec.distribution.version

spec.distribution.fullVersion

spec.topology.controlPlane.tkr.refernece.name

spec.topology.nodePools[*].tkr.reference.name

Muss das Format TKR-NAME verwenden. Sehen Sie sich die Beispiele an.

spec.topology.workers

spec.topology.nodePools[*]

 Bei einem konvertierten Cluster wird der Block spec.topology.workers zu spec.topology.nodePools[0].

Der erste Eintrag in der nodePools-Liste lautet name: workers.

spec.topology.controlPlane.count

spec.topology.workers.count

spec.topology.controlPlane.replicas

spec.topology.nodePools[*].replicas

 count wird durch replicas ersetzt

spec.topology.controlPlane.class

spec.topology.workers.class

spec.topology.controlPlane.vmClass

spec.topology.nodePools[*].vmClass

 class wird durch vmClass ersetzt

Nicht verfügbar

spec.topology.nodePools[*].labels

Optionale Schlüssel-Wert-Paare zum Organisieren und Kategorisieren von Objekten; Beschriftungen werden an die erstellten Knoten weitergegeben

Nicht verfügbar

spec.topology.nodePools[*].taints

Optionale Taints, mit denen die Knoten registriert werden; benutzerdefinierte Taints werden an die erstellten Knoten weitergegeben.

Format TKR-NAME ist erforderlich

Neben den veralteten spec.distribution.version-Feldern wird das Format VERTEILUNG für die Angabe der Tanzu Kubernetes-Version nicht unterstützt. Dies bedeutet, dass Sie die folgenden Zeichenfolgenformate nicht zum Referenzieren der Zielversion verwenden können: 1.21.2+vmware.1-tkg.1.ee25d55, 1.21.2 und 1.21.

Wenn Sie die Tanzu Kubernetes-Version in einer v1alpha2-API-Clusterspezifikation referenzieren, müssen Sie das Format TKR-NAME verwenden anstelle des veralteten Formats VERTEILUNG. Obwohl das veraltete Format in der Spalte VERFÜGBARE UPDATES angezeigt wird, ist das einzige unterstützte Format das in der Spalte TKR-NAME aufgeführte. 
kubectl get tanzukubernetescluster
NAMESPACE        NAME            CONTROL PLANE   WORKER   TKR NAME                             AGE    READY   TKR COMPATIBLE   UPDATES AVAILABLE
tkgs-cluster-1   test-cluster    3               3        v1.21.2---vmware.1-tkg.1.ee25d55     38h    True    True             [1.21.2+vmware.1-tkg.1.ee25d55]

Verwenden von „kubectl edit“ zum Aktualisieren einer Clusterspezifikation

Wenn Sie eine Clusterspezifikation bearbeiten müssen, damit sie mit der TKGS-v1alpha2-API übereinstimmt, verwenden Sie die kubectl edit-Methode. Versuchen Sie nicht, die kubectl patch-Methode für diesen Aktualisierungstyp zu verwenden. Weitere Informationen finden Sie unter Methoden zum Bearbeiten des Clustermanifests. Informationen zur Konfiguration von kubectl mit einem Editor finden Sie unter Angeben eines Standardtexteditors für Kubectl.

Cluster-Update-Beispiele

Die spec.distribution.version zu ändern ist die gängigste Möglichkeit, ein rollierendes Update des Clusters auszulösen (siehe Update von Tanzu Kubernetes-Clustern), und dieses Feld ist in der v1alpha2-API veraltet. Daher sind bestimmte Überlegungen und Empfehlungen vor der Verarbeitung zu beachten, um potenzielle Probleme beim Cluster-Update zu vermeiden.

Die folgenden Beispiele veranschaulichen, wie die Version eines Tanzu Kubernetes-Clusters, der mithilfe der v1alpha1-API bereitgestellt wurde, auf ein System aktualisiert wird, auf dem die v1alpha2-API ausgeführt wird.

Cluster-Upgrade, Beispiel 1: Verwenden einer einzelnen TKR-NAME-Referenz in der Steuerungsebene.

Empfohlen wird der Ansatz, alle nodePools[*].tkr.reference.name-Blöcke aus der konvertierten Spezifikation zu entfernen und den controlPlane.tkr.reference.name mit dem TKR-NAMEN der Zielversion zu aktualisieren. In diesem Fall wird die gleiche Tanzu Kubernetes-Version an alle nodePools[*]-Knoten weitergegeben.

Zukünftig können die Tanzu Kubernetes-Versionen über controlPlane und nodePools[*] hinweg verschieden sein. Derzeit müssen jedoch alle Versionen in einem Cluster übereinstimmen, sodass das Einfügen einer einzigen TKR-NAME-Referenz in controlPlane ausreicht.

Beispiel: 
apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example1
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium

Cluster-Upgrade, Beispiel 2: Verwenden einer TKR-NAME-Referenz für jeden Knotenpool

Im zweiten Beispiel wird der TKR-NAME in den tkr.reference.name-Block für die beiden Topologien controlPlane und nodePools[*] eingefügt.

Dieser Ansatz hat den Vorteil, dass er für zukünftige Versionen bereit ist, wenn die Tanzu Kubernetes-Version über Knotenpools hinweg verschieden sein kann. Aktuell müssen sie übereinstimmen.

Beispiel: 
apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example2
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55

Cluster-Upgrade, Beispiel 3: Verwenden veralteter Verteilungsfelder

Die letzte Option besteht darin, die veralteten Felder spec.distribution.fullVersion und spec.distribution.version zu verwenden und alle tkr.reference.name-Blöcke manuell zu entfernen. Sie müssen beide Felder einschließen. Dabei muss ein Feld das TKR-NAME-Format verwenden und das andere ausgenullt sein. Versionsverknüpfungen wie v1.21.2 und v1.21 werden nicht unterstützt.
Hinweis: Für die Tanzu Kubernetes-Version unter Ubuntu wird die Verwendung von spec.distribution.version nicht unterstützt.
Das folgende Beispiel verwendet die fullVersion mit dem TKR-NAMEN und einem Nullwert (leer) im Feld version. Alle tkr.reference.name-Einträge werden entfernt. 
apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3a
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: v1.21.2---vmware.1-tkg.1.ee25d55
    version: ""
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
Alternativ können Sie das Feld version mit dem TKR-NAMEN und einem Nullwert (leer) im Feld fullVersion verwenden. Auch wenn Sie das Feld version verwenden, werden Versionskürzel nicht unterstützt. Alle tkr.reference.name-Einträge werden entfernt. 
apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3b
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: ""
    version: v1.21.2---vmware.1-tkg.1.ee25d55
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium