Arbeitslastcluster

In diesem Thema werden die verschiedenen von Tanzu Kubernetes Grid (TKG) erstellten Arbeitslastclustertypen und die Methode zum Erstellen und Konfigurieren dieser Cluster beschrieben.

Typen von Arbeitslastclustern: klassenbasiert, TKC und planbasiert

Tanzu Kubernetes Grid hostet drei verschiedene Typen von Arbeitslastclustern:

• Klassenbasierte Cluster
  • Sind Kubernetes-Objekte vom Typ Cluster
  • Sind ein neuer in vSphere with Tanzu 8 und TKG 2.x eingeführter Clustertyp
  • Für sie ist die grundlegende Topologie in einem spec.topology-Block definiert
    • Beispiel: Anzahl und Typ der Worker-Knoten und Knoten der Steuerungsebene
  • Übernehmen die Konfiguration vom Wert spec.topology.class
    • Bezieht sich auf ein ClusterClass-Objekt
    • Auf Supervisor ist class standardmäßig tanzukubernetescluster
    • Die Standard-class in einem eigenständigen Verwaltungscluster lautet tkg-INFRASTRUCTURE-default-VERSION, wie z. B. tkg-vsphere-default-v1.0.0.
  • Kann mithilfe eines Supervisors auf vSphere with Tanzu 8 oder mithilfe eines eigenständigen TKG v2.x-Verwaltungsclusters auf vSphere 6.7, 7 und 8 ohne Supervisor in AWS oder Azure erstellt werden
• TKC-basierte Cluster (Legacy)
  • Sind Kubernetes-Objekte vom Typ TanzuKubernetesCluster
  • Kann mithilfe eines Supervisor-Clusters in vSphere 7 oder mithilfe eines Supervisors auf vSphere 8 zu Legacy-Zwecken erstellt werden
• Planbasierte Cluster (Legacy)
  • Sind Kubernetes-Objekte vom Typ Cluster
  • Kann mithilfe eines eigenständigen TKG v2.x- oder v1.x-Verwaltungsclusters in vSphere 6.7, 7 und 8 ohne Supervisor in AWS oder Azure erstellt werden

Beachten Sie, dass klassenbasierte Cluster mit class: tanzukubernetescluster (alles in Kleinbuchstaben) sich von TKC-basierten Clustern unterscheiden, die den Objekttyp TanzuKubernetesCluster aufweisen.

Klassenbasierte Cluster wurden entwickelt, um die anderen beiden Clustertypen zu ersetzen, indem dieselbe API für beide Typen von Verwaltungsclustern bereitgestellt wird: Supervisors und eigenständige Verwaltungscluster.

Wichtig

Tanzu Kubernetes Grid v2.4.x ist die letzte Version von TKG, die die Erstellung von TKG-Arbeitslastclustern auf AWS und Azure unterstützt. Die Möglichkeit, TKG-Arbeitslastcluster auf AWS und Azure zu erstellen, wird in Tanzu Kubernetes Grid v2.5 entfernt. Weitere Informationen finden Sie unter Veraltete TKG-Verwaltungs- und -Arbeitslastcluster in AWS und Azure in den Versionshinweisen zu VMware Tanzu Kubernetes Grid v2.4.

Clustertypen und Cluster-API

Zum Erstellen und Verwalten von Arbeitslastclustern führen Verwaltungscluster die Cluster-API-Software aus:

• Cluster-API: Open-Source-Kubernetes-Software zum Erstellen und Verwalten von Kubernetes-Clustern.
• Cluster-API-Anbieter: Software, die auf bestimmten Cloud- oder physischen Infrastrukturen als Schnittstelle zur Unterstützung der Cluster-API ausgeführt wird.
  • Die meisten Cluster-API-Anbieter-Softwareprojekte sind Open Source, aber einige sind proprietär.

In der folgenden Tabelle werden die Verwaltungs- und Arbeitslastclustertypen den verwendeten Cluster-API-Anbietern zugeordnet:

TKG mit ...	verwendet Cluster-API-Anbieter...	in ...	zum Erstellen und Verwalten von Arbeitslastclustern vom Typ...	in Produktversionen...
Supervisor	CAPW (proprietär)	vSphere	Klassenbasierte Cluster-Objekte	TKG 2.x und vSphere with Tanzu 8
			TanzuKubernetesCluster-Objekte	vSphere with Tanzu 7 & 8
Eigenständiger Verwaltungscluster	CAPA (OSS)	AWS	Klassenbasierte Cluster-Objekte	TKG v2.x
			Planbasierte AWSCluster-Objekte	TKG v2.x und v1.x
	CAPZ (OSS)	Azure	Klassenbasierte Cluster-Objekte	TKG v2.x
			Planbasierte AzureCluster-Objekte	TKG v2.x und v1.x
	CAPV (OSS)	vSphere	Klassenbasierte Cluster-Objekte	TKG v2.x
			Planbasierte VSphereCluster-Objekte	TKG v2.x und v1.x

Kompatibilität von Clustertypen und Tanzu CLI

Mithilfe der verschiedenen Versionen der Tanzu CLI, die sich im Lieferumfang von Tanzu Kubernetes Grid befinden, können Sie verschiedene Clustertypen erstellen, je nachdem, ob Sie Supervisor auf vSphere 8, einen Supervisor-Cluster in vSphere 7 oder einen eigenständigen Verwaltungscluster in vSphere 6.7, 7 und 8 ohne Supervisor in AWS oder Azure verwenden.

CLI-Version	TKG-Version	Erstellen klassenbasierter Cluster mit ...			Erstellen planbasierter Cluster mit ...			Erstellen von TanzuKubernetesClusters mit ...
		Eigenständiger Verwaltungscluster	Supervisor auf vSphere 8	Supervisor-Cluster auf vSphere 7	Eigenständiger Verwaltungscluster	Supervisor auf vSphere 8	Supervisor-Cluster auf vSphere 7	Eigenständiger Verwaltungscluster	Supervisor auf vSphere 8	Supervisor-Cluster auf vSphere 7
v0.90.1*	2.3.0	✓	✓	x	✓	✓	x	x	✓	x
v0.29.0	2.2.0	✓	✓	x	✓	✓	x	x	✓	x
v0.28.1	2.1.1	✓	✓	x	✓	✓	x	x	✓	x
v0.25.4	1.6.1	x	✓	x	✓	✓	x	x	✓	✓
v0.25.0	1.6.0	x	✓	x	✓	✓	x	x	✓	✓
v0.11.x	1.5.x	x	x	x	✓	x	x	x	x	✓

* Eine vollständige Liste der CLI-Versionen, die mit Tanzu Kubernetes Grid v2.4 kompatibel sind, finden Sie unter Produkt-Interoperabilitätsmatrix.

Unterkomponenten von Arbeitslastclusterobjekten

Klassenbasierte Cluster weisen die folgende allgemeine Objekttypenhierarchie auf. Die KubeAdmControlPlane und MachineDeployment zugrunde liegenden Objekte haben dieselben Typen, sind in der Regel jedoch unterschiedliche Objekte:

• Cluster: Anzahl und Typ der Steuerungsebenen- und Worker-Knoten, die vom topology-Block in der Spezifikation festgelegt werden
  • KubeAdmControlPlane: definiert die Knoten der Steuerungsebene
    • IaaS-spezifisches Maschinenobjekt: z. B. vSphereMachine, AWSMachine, DockerMachine
    • Machine: generisches Objekt für Knoten-VM
    • KubeAdmConfig: Kubernetes-Konfiguration, einschließlich Kubernetes-Version, Image-Repository, Hooks vor und nach der Bereitstellung usw.
  • MachineDeployment: definiert den Worker-Knoten
    • IaaS-spezifisches Maschinenobjekt
    • Machine
    • KubeAdmConfig

Weitere Informationen finden Sie unter CustomResourceDefinitions-Beziehungen im Cluster-API-Handbuch.

Möglichkeiten zum Erstellen von Arbeitslastclustern

Je nach installierter Umgebung können Sie Tanzu Kubernetes Grid-Arbeitslastcluster mithilfe von Tanzu Mission Control, kubectl und der Tanzu CLI erstellen.

Das folgende Diagramm zeigt, wie Benutzer verschiedene Arten von Arbeitslastclustern in unterschiedlichen Infrastrukturen erstellen können:

Verwendung von ...	zum Erstellen von ...	übernimmt Konfigurationswerte aus...	und Konfigurationsvorlagen aus ...	Anleitung
Tanzu CLI: tanzu cluster create	Klassenbasierter Arbeitslastcluster (vSphere)	Cluster und zugrunde liegende Objektspezifikationen	Benutzer, wie z. B. classycluster.yaml	Erstellen eines klassenbasierten Clusters
	TanzuKubernetesCluster-Arbeitslastcluster (vSphere)	Clusterkonfigurationsdatei, lokale Umgebung, (erweitert) ytt Overlays	infrastructure-tkg-service-vsphere*	(Legacy) Erstellen eines planbasierten oder TKC-Clusters
	Planbasierter Arbeitslastcluster (vSphere, AWS, Azure)		infrastructure-vsphere, infrastructure-aws, infrastructure-azure*
Tanzu Mission Control (TMC)	TanzuKubernetesCluster oder planbasierter Arbeitslastcluster	TMC-Benutzeroberfläche	Registrierter Verwaltungscluster	Bereitstellen von Arbeitslastclustern
kubectl apply	Klassenbasierte oder TanzuKubernetesCluster-Arbeitslastcluster (vSphere)	Cluster und zugrunde liegende Objektspezifikationen	Benutzer, wie z. B. classycluster.yaml, tkc.yaml	Deklaratives Erstellen von Arbeitslastclustern

*Lokale Verzeichnisse unter .config/tanzu/tkg/providers/

Informationen zur Konfiguration von Legacy-TKC und planbasierten Clustern

Wenn die Tanzu CLI einen TKC-basierten Arbeitslastcluster erstellt, kombiniert sie Konfigurationswerte aus folgenden Optionen:

• Live-Eingabe bei Aufruf
  • CLI-Eingabe
• Umgebungsvariablen
• ~/.config/tanzu/tkg/cluster-config.yaml oder eine andere Datei, die an die CLI-Option --file übergeben wird
• YAML-Konfigurationsdateien des Clusterplans in ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere wie in Plankonfigurationsdateien unten beschrieben
• Andere, Nicht-Plan-YAML-Konfigurationsdateien unter ~/.config/tanzu/tkg/providers

Live-Eingabe wendet Konfigurationswerte an, die für jeden Aufruf eindeutig sind. Umgebungsvariablen behalten sie über eine Terminalsitzung bei, Konfigurationsdateien und Overlays behalten sie unbegrenzt bei. Sie können Cluster über jede dieser Quellen anpassen. Dabei gelten die im Folgenden beschriebenen Empfehlungen und Einschränkungen.

Unter Vorrang für Konfigurationswerte erfahren Sie, wie die tanzu-CLI spezifische Clusterkonfigurationswerte aus diesen verschiedenen Quellen ableitet, bei denen es zu Konflikten kommen kann.

Plankonfigurationsdateien

Das Verzeichnis ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere enthält Konfigurationsdateien für den TKC-Arbeitslastclusterplan mit dem Namen cluster-template-definition-PLAN.yaml. Die Konfigurationswerte für jeden Plan stammen aus diesen Dateien und den Dateien, die sie unter spec.paths auflisten:

• Konfigurationsdateien, die mit der tanzu-CLI bereitgestellt werden
• Benutzerdefinierte Dateien, die Benutzer erstellen und zur Liste spec.paths hinzufügen
• ytt-Overlays, die Benutzer erstellen oder bearbeiten, um Werte in anderen Konfigurationsdateien zu überschreiben

Zu bearbeitende Dateien – unverändert beibehaltene Dateien

Um Clusterpläne über YAML anzupassen, bearbeiten Sie Dateien unter ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere. Sie sollten jedoch keine anderen Dateien verändern.

Zu bearbeitende Dateien

Die Pfade der Konfigurationsdateien für den Arbeitslastclusterplan folgen dem Format ~/.config/tanzu/tkg/providers/infrastructure-infrastructure-tkg-service-vsphere/VERSION/cluster-template-definition-PLAN.yaml. Dabei gilt:

• VERSION ist die Version des Cluster-API-Anbietermoduls, die von der Konfiguration verwendet wird.
• PLAN ist dev, prod oder ein benutzerdefinierter Plan.

Jede Plankonfigurationsdatei verfügt über einen Abschnitt spec.paths, in dem die Quelldateien und die ytt-Verzeichnisse aufgelistet sind, die den Clusterplan konfigurieren. Beispiel:

apiVersion: providers.tanzu.vmware.com/v1alpha1
kind: TemplateDefinition
spec:
  paths:
    - path: providers/infrastructure-tkg-service-vsphere/v1.1.0/ytt
    - path: providers/ytt
    - path: bom
      filemark: text-plain
    - path: providers/config_default.yaml

Diese Dateien werden in der aufgeführten Reihenfolge verarbeitet. Wenn dasselbe Konfigurationsfeld in mehreren Dateien festgelegt ist, ist die zuletzt verarbeitete Einstellung diejenige, die von der tanzu-CLI verwendet wird.

Um Ihre Clusterkonfiguration anzupassen, haben Sie folgende Möglichkeiten:

• Erstellen Sie neue Konfigurationsdateien und fügen Sie sie zur Liste spec.paths hinzu.
  • Dies ist die einfachere Methode.
• Ändern Sie vorhandene ytt-Overlay-Dateien.
  • Dies ist die leistungsstärkere Methode für Anwender, die sich mit ytt auskennen.

Unverändert beibehaltene Dateien

VMware rät davon ab, die folgenden Dateien unter ~/.config/tanzu/tkg/providers zu ändern, außer wie angegeben:

• base-template.yaml-Dateien in ytt-Verzeichnissen

  • Diese Konfigurationsdateien verwenden Werte aus den Cluster-API-Anbieter-Repos unter Kubernetes-SIGs und anderen Upstream-Open-Source-Projekten, die vorzugsweise nicht bearbeitet werden sollten.
  • Erstellen Sie stattdessen neue Konfigurationsdateien oder informieren Sie sich unter Cluster und Clusterpläne in Erweiterte TKC-Konfiguration mit ytt, um Werte in der Datei overlay.yaml im selben ytt-Verzeichnis festzulegen.

• ~/.config/tanzu/tkg/providers/config_default.yaml – nur anhängen

  • Diese Datei enthält systemweite Standardeinstellungen für Tanzu Kubernetes Grid.
  • Ändern Sie keine vorhandenen Werte in dieser Datei. Sie können aber am Ende einen Abschnitt User Customizations anhängen.
  • Statt Werte in dieser Datei zu ändern, passen Sie Clusterkonfigurationen in Dateien an, die Sie an die Option --file von tanzu cluster create übergeben.

• ~/.config/tanzu/tkg/providers/config.yaml

  • Die tanzu-CLI verwendet diese Datei als Referenz für alle Anbieter im Verzeichnis /providers und deren Standardversionen.

Vorrang für Konfigurationswerte

Wenn die Tanzu CLI einen TKC-basierten Arbeitslastcluster erstellt, kombiniert sie Konfigurationswerte aus mehreren Quellen. Wenn diese Quellen in Konflikt stehen, werden Konflikte in der folgenden absteigenden Reihenfolge behoben:

Verarbeitung von Layern, sortiert in absteigender Reihenfolge	Quelle	Beispiele
1. In Ihrer lokalen Umgebung festgelegte Clusterkonfigurationsvariablen	In der Shell festgelegt.	export WORKER_VM_CLASS=best-effort-large
2. In der Tanzu CLI festgelegte Clusterkonfigurationsvariablen mit tanzu config set env.	In Shell festgelegt; in der globalen Tanzu CLI-Konfigurationsdatei ~/.config/tanzu/config.yaml gespeichert.	tanzu config set env.WORKER_VM_CLASS best-effort-large
3. In der Clusterkonfigurationsdatei festgelegte Clusterkonfigurationsvariablen	In der Datei festgelegt, die an die Option --file von tanzu cluster create übergeben wird. Standardmäßig lautet die Datei ~/.config/tanzu/tkg/cluster-config.yaml.	WORKER_VM_CLASS: best-effort-large
4. Werkseitige Standardkonfigurationswerte	In providers/config_default.yaml festgelegt, aber einige Felder sind ohne Standardwerte aufgeführt. Ändern Sie diese Datei nicht.	WORKER_VM_CLASS: