Benutzerdefinierte Linux-Maschinen-Images (Legacy)

Dieser Vorgang führt Sie schrittweise durch die Erstellung eines benutzerdefinierten Linux-Maschinen-Images, das beim Erstellen planbasierte Cluster (Legacy) auf AWS, Azure oder vSphere verwendet werden soll. Er ist in die folgenden Abschnitte unterteilt. Weitere Informationen zu Clustertypen in Tanzu Kubernetes Grid finden Sie unter Typen von Arbeitslastclustern.

Unter Voraussetzungen für Linux-Images wird aufgeführt, was Sie zum erfolgreichen Erstellen und Verwenden eines benutzerdefinierten Linux-Images benötigen.
Unter Erstellen eines Linux-Images erhalten Sie Informationen zur Verwendung von Kubernetes Image Builder und Docker zum Anpassen und Erstellen eines Images.
Unter Erstellen eines TKr für das Linux-Image erhalten Sie Informationen zum Konvertieren eines Linux-Images in ein Tanzu Kubernetes-Release (TKr). Auf diese Weise wird das Image zum Standard-Image für zukünftige Kubernetes-Versionen und bietet weitere Optionen zu seiner Verwendung und Verwaltung.
Unter Verwenden eines Linux-Images für einen Verwaltungscluster erhalten Sie Informationen zum Bereitstellen eines Verwaltungsclusters, der das benutzerdefinierte Image als Vorlage verwendet.
Unter Verwenden eines Linux-Images für einen Arbeitslastcluster erhalten Sie Informationen zum Bereitstellen eines Arbeitslastclusters, der das benutzerdefinierte Image als Vorlage verwendet.

Voraussetzungen für Linux-Images

Zur Erstellung eines benutzerdefinierten Linux-Maschinen-Images benötigen Sie Folgendes:

Ein Konto in der Zielinfrastruktur, AWS, Azure oder vSphere.
Eine macOS- oder Linux-Workstation, auf der Folgendes installiert ist:
- Docker Desktop
- Für AWS: Die aws-CLI (Command-Line Interface, Befehlszeilenschnittstelle)
- Für Azure: Die az-CLI
- Für vSphere: Zum Erstellen eines RHEL 8-Images benötigen Sie eine Linux-Workstation (keine macOS-Workstation).

Erstellen eines Linux-Images

Melden Sie sich unter AWS und Azure bei Ihrer Infrastruktur-CLI an. Authentifizieren Sie sich und geben Sie Ihre Region an, wenn Sie dazu aufgefordert werden:
- AWS: Führen Sie aws configure aus.
- Azure: Führen Sie az login aus.
Erstellen Sie unter Azure eine JSON-Konfigurationsdatei azure-sig.json und geben Sie die Azure-spezifischen Informationen ein. Ein Beispiel für eine solche Datei finden Sie hier.

Erstellen Sie in vSphere eine JSON-Datei mit Anmeldedaten und geben Sie die zugehörigen Werte ein:

{
"cluster": "",
"convert_to_template": "false",
"create_snapshot": "true",
"datacenter": "",
"datastore": "",
"folder": "",
"insecure_connection": "false",
"linked_clone": "true",
"network": "",
"password": "",
"resource_pool": "",
"template": "",
"username": "",
"vcenter_server": ""
}

Legen Sie die Version der Image Builder-Konfiguration fest, die als Grundlage für die Erstellung dienen soll.
- Durchsuchen Sie VMware {code} Sample Exchange nach TKG Image Builder, um die verfügbaren Versionen aufzulisten.
- Jede Image Builder-Version entspricht den kompatiblen Kubernetes- und Tanzu Kubernetes Grid-Versionen. Beispiel: TKG-Image-Builder-for-Kubernetes-v1.24.10-on-TKG-v2.1.1-master.zip erstellt ein Kubernetes v1.24.10-Image für Tanzu Kubernetes Grid v2.1.1.
- Wenn Sie bei der Erstinstallation von Tanzu Kubernetes Grid einen Verwaltungscluster erstellen müssen, wählen Sie die Kubernetes-Standardversion Ihrer Tanzu Kubernetes Grid-Version aus. In Tanzu Kubernetes Grid v2.1.1 ist die Kubernetes-Standardversion beispielsweise v1.24.10. Für Arbeitslastcluster können Sie zusätzlich zu v1.24.10 auch ein Kubernetes v1.23.16- oder v1.22.17-Image erstellen.
In den folgenden Schritten wird erläutert, wie Sie ein Kubernetes v1.24.10-Image für Tanzu Kubernetes Grid v2.1.1 erstellen.
Laden Sie die Zip-Datei des Konfigurationscodes herunter und entpacken Sie deren Inhalt.
cd in das Verzeichnis TKG-Image-Builder-, d. h., die Datei tkg.json befindet sich in Ihrem aktuellen Verzeichnis.
Stellen Sie sicher, dass Ihre Workstation auf die VMware-Image-Registrierung projects.registry.vmware.com zugreifen kann.

Laden Sie den gewünschten Artefakt-Container von projects.registry.vmware.com herunter und führen Sie ihn aus.

docker pull projects.registry.vmware.com/tkg/linux-resource-bundle:v1.24.10_vmware.1-tkg.2

docker run -d -p 3000:3000 projects.registry.vmware.com/tkg/linux-resource-bundle:v1.24.10_vmware.1-tkg.2

Bearbeiten Sie tkg.json, um <IP> und <PORT> aufzufüllen. Dabei gilt:
- IP entspricht der IP der Maschine, auf der der Docker-Container ausgeführt wird.
- PORT verknüpft einen nicht verwendeten Port auf dem Docker-Host mit Port 3000 auf dem Container, z. B. 3001:3000. Der Container legt die Artefakte über Port 3000 offen.
Wenn Sie eine Photon-3-OVA erstellen, bearbeiten Sie "extra_rpms" in tkg.json entsprechend für die zusätzlichen unterstützten benutzerdefinierten Pakete:
```
"extra_rpms": "sysstat nfs-utils ethtool apparmor-parser"
```
Um ein FIPS-fähiges Image zu erstellen, entfernen Sie die folgende Zeile in tkg.json:
```
"ansible_user_vars": "install_fips=no"
```
Auf das Internet beschränkt: Zum Erstellen von Images für eine auf das Internet beschränkte Umgebung, die über einen HTTP-Proxyserver auf das Internet zugreift, fügen Sie Folgendes zur Datei tkg.json hinzu:
```
{
  "http_proxy": "http://proxy.acme.com:80",
  "https_proxy": "http://proxy.acme.com:80",
  "no_proxy": "localhost, 127.0.0.1, acme.com, 10.0.0.0/8"
}
```
GPU-fähige Cluster: Um ein Image für einen GPU-fähigen Cluster für vSphere zu erstellen, erstellen Sie eine Datei mit dem Namen customizations.json und fügen Sie Folgendes hinzu:
```
{
"vmx_version": "17"
}
```
Speichern Sie die Datei customizations.json in demselben Verzeichnis wie tkg.json, die Sie im vorherigen Schritt bearbeitet haben.
Erfassen Sie die folgenden Parameterzeichenfolgen, um sie im nächsten Schritt zum Befehl hinzuzufügen. Viele dieser Zeichenfolgen geben Parameter vom Typ docker run -v an, die Ihre aktuellen Arbeitsverzeichnisse in das Verzeichnis /home/imagebuilder des Containers kopieren, der zum Erstellen des Images verwendet wird.
- AUTHENTICATION: Kopiert Ihr lokales CLI-Verzeichnis:
  - AWS: Verwenden Sie ~/.aws:/home/imagebuilder/.aws
  - Azure: Verwenden Sie ~/.azure:/home/imagebuilder/.azure
  - vSphere: /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
- SOURCES: Kopiert die Datei tkg.json des Repositorys, in dem Download-Quellen für versionierte Betriebssystem-, Kubernetes- und CNI-Images (Container Network Interface) aufgelistet werden:
  - Verwenden Sie /PATH/TO/tkg.json:/home/imagebuilder/tkg.json
- ROLES: Kopiert das Verzeichnis tkg des Repositorys, das für Image Builder benötigte Ansible-Rollen enthält.
  - Verwenden Sie /PATH/TO/tkg:/home/imagebuilder/tkg
  - Zum Hinzufügen benutzerdefinierter Ansible-Rollen bearbeiten Sie die Datei tkg.json und formatieren Sie die Einstellung custom_role_names mit in Escape-Zeichen gesetzten Anführungszeichen (\") neu, um eine Liste mit mehreren Rollen zu erstellen. Beispiel:
    "custom_role_names": "\"/home/imagebuilder/tkg /home/imagebuilder/mycustomrole\"",
- TESTS: Kopiert ein Testverzeichnis vom Typ goss, das für die Zielinfrastruktur, das Betriebssystem und die Kubernetes-Version des Images entwickelt wurde:
  - Verwenden Sie den Dateinamen einer Datei im Verzeichnis goss des Repositorys, wie z. B. amazon-ubuntu-1.24.10+vmware.1-goss-spec.yaml.
- CUSTOMIZATIONS: Kopiert eine Anpassungsdatei im JSON-Format. Weitere Informationen finden Sie unter Anpassung in der Image Builder-Dokumentation. Bevor Sie Änderungen vornehmen, wenden Sie sich an VMware Customer Reliability Engineering (CRE), um Best Practices und Empfehlungen zu erhalten.
- PACKER_VAR_FILES: Eine durch Leerzeichen getrennte Liste der oben genannten JSON-Dateien, die Variablen für Packer enthalten.
- (Azure) AZURE-CREDS: Pfad einer Datei mit Azure-Anmeldedaten, die in der Image Builder-Dokumentation beschrieben wird.
- COMMAND: Verwenden Sie auf Basis des benutzerdefinierten Image-Betriebssystems einen der folgenden Befehle. Für vSphere- und Azure-Images beginnen die Befehle mit build-node-ova- und build-azure-sig-:
  - build-ami-ubuntu-2004: Ubuntu v20.04
  - build-ami-ubuntu-1804: Ubuntu v18.04
  - build-ami-amazon-2: Amazon Linux 2
  - build-node-ova-vsphere-ubuntu-2004: GPU-fähige Cluster

Führen Sie mithilfe der obigen Zeichenfolgen den Image Builder in einem Docker-Container aus, der aus der VMware-Registrierung projects.registry.vmware.com abgerufen wurde:

docker run -it --rm \
    -v AUTHENTICATION \
    -v SOURCES \
    -v ROLES \
    -v /PATH/TO/goss/TESTS.yaml:/home/imagebuilder/goss/goss.yaml \
    -v /PATH/TO/CUSTOMIZATIONS.json:/home/imagebuilder/CUSTOMIZATIONS.json \
    --env PACKER_VAR_FILES="tkg.json CUSTOMIZATIONS.json" \
    --env-file AZURE-CREDS \
    --env IB_OVFTOOL=1 \
    projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
    COMMAND

Hinweis
Lassen Sie env-file aus, wenn Sie kein Image für Azure erstellen. Es kann einige Minuten dauern, bis der Befehl abgeschlossen ist.

Beispiel: Um ein benutzerdefiniertes Image mit Ubuntu v20.04 und Kubernetes v1.24.10 für AWS zu erstellen, führen Sie es über das Verzeichnis aus, das tkg.json enthält:

docker run -it --rm \
    -v ~/.aws:/home/imagebuilder/.aws \
    -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
    -v $(pwd)/tkg:/home/imagebuilder/tkg \
    -v $(pwd)/goss/amazon-ubuntu-1.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
    -v /PATH/TO/CUSTOMIZATIONS.json /home/imagebuilder/aws.json \
    --env PACKER_VAR_FILES="tkg.json aws.json" \
    --env IB_OVFTOOL=1 \
    projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
    build-ami-ubuntu-2004

Für vSphere müssen Sie das oben erstellte benutzerdefinierte Container-Image verwenden. Sie müssen auch eine Versionszeichenfolge festlegen, die damit übereinstimmt, was Sie in Ihrem benutzerdefinierten TKr in späteren Schritten übergeben. Während veröffentlichte VMware-OVAs über eine Versionszeichenfolge wie v1.24.10+vmware.1-tkg.1 verfügen, wird empfohlen, dass -tkg.1 durch eine für Ihre Organisation aussagekräftige Zeichenfolge ersetzt wird. Zum Festlegen dieser Versionszeichenfolge definieren Sie sie folgendermaßen in einer Datei vom Typ metadata.json:

{
  "VERSION": "v1.24.10+vmware.1-myorg.0"
}

Beim Erstellen von OVAs wird die Datei .ova im lokalen Dateisystem Ihrer Workstation gespeichert. Der Ordner, in dem diese OVAs gespeichert werden sollen, sollte auf /home/imagebuilder/output innerhalb des Containers gemountet werden. Erstellen Sie dann die OVA mithilfe des Container-Images:

docker run -it --rm \
  -v /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json \
  -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
  -v $(pwd)/tkg:/home/imagebuilder/tkg \
  -v $(pwd)/goss/vsphere-ubuntu-1.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

Für GPU-fähige Cluster müssen wir die in den Schritten oben erstellte Datei customizations.json bei Ausführung des Befehls zum Erstellen der OVA-Datei einschließen.

docker run -it --rm \
  -v /PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json \
  -v $(pwd)/tkg.json:/home/imagebuilder/tkg.json \
  -v $(pwd)/tkg:/home/imagebuilder/tkg \
  -v $(pwd)/goss/vsphere-ubuntu-1.24.10+vmware.1-goss-spec.yaml:/home/imagebuilder/goss/goss.yaml \
  -v $(pwd)/metadata.json:/home/imagebuilder/metadata.json \
  -v $(pwd)/customizations.json:/home/imagebuilder/customizations.json \
  -v /PATH/TO/OVA/DIR:/home/imagebuilder/output \
  --env PACKER_VAR_FILES="tkg.json vsphere.json customizations.json" \
  --env OVF_CUSTOM_PROPERTIES=/home/imagebuilder/metadata.json \
  --env IB_OVFTOOL=1 \
  projects.registry.vmware.com/tkg/image-builder:v0.1.13_vmware.2 \
  build-node-ova-vsphere-ubuntu-2004

RHEL: Zum Erstellen einer RHEL-OVA müssen Sie eine Linux-Maschine (nicht macOS) verwenden, da Docker die Option --network host auf macOS nicht unterstützt.
Sie müssen auch das Betriebssystem als lizenziert bei Red Hat registrieren und sich für Updates anmelden, indem Sie dem obigen Befehl docker run Folgendes hinzufügen:

  -v $(pwd)/isos/rhel-8.4-x86_64-dvd.iso:/rhel-8.4-x86_64-dvd.iso \
  --network host \
  --env RHSM_USER=USER --env RHSM_PASS=PASS

Dabei gilt:

RHSM_USER und RHSM_PASS sind der Benutzername und das Kennwort für Ihr Red Hat Subscription Manager-Konto.
Sie ordnen Ihren lokalen RHEL-ISO-Pfad in $(pwd)/isos/rhel-8.4-x86-64-dvd.iso im obigen Beispiel als zusätzliches Volume zu.

Erstellen eines TKr für das Linux-Image

Um Ihr Linux-Image als Standardeinstellung für zukünftige Kubernetes-Versionen zu verwenden, erstellen Sie ein darauf basierendes TKr. Fahren Sie andernfalls mit Verwenden eines Linux-Images für einen Arbeitslastcluster fort.

Das folgende Diagramm bietet einen allgemeinen Überblick über die Erstellung eines TKr für ein benutzerdefiniertes Linux-Image auf vSphere.

Erstellen eines TKr

So erstellen Sie ein TKr:

Öffnen Sie im Verzeichnis ~/.config/tanzu/tkg/bom/ die TKr-BoM, die der Kubernetes-Version des benutzerdefinierten Images entspricht. Verwenden Sie beispielsweise einen Dateinamen wie tkr-bom-v1.24.10+vmware.1-tkg.1.yaml für Kubernetes v1.24.10.

Wenn die benötigte TKr-BoM-Datei nicht im Verzeichnis vorhanden ist, können Sie sie hinzufügen, indem Sie einen Cluster mit der gewünschten Kubernetes-Version bereitstellen (siehe Beschreibung in Bereitstellen eines Clusters mit einer nicht standardmäßigen Kubernetes-Version).
1. Suchen Sie in der BoM-Datei nach den Image-Definitionsblöcken für Ihre Infrastruktur: ova für vSphere, ami für AWS und azure für Azure. Jeder Image-Definitionsblock enthält osinfo.name, osinfo.version und osinfo.arch. Dabei gilt:
  - osinfo.name ist der Name des Betriebssystems. Beispiel: ubuntu. Eine Liste der unterstützten Betriebssysteme finden Sie unter Zielbetriebssysteme.
  - osinfo.version ist die Version des Betriebssystems. Beispiel: 20.04. Eine Liste der unterstützten Versionen finden Sie unter Zielbetriebssysteme.
  - osinfo.arch ist die Betriebssystemarchitektur. Unterstützter Wert ist amd64.
2. Um einen Verweis auf Ihr neues Betriebssystem-Image hinzuzufügen, fügen Sie je nach Zielinfrastruktur einen Image-Definitionsblock unter ova, ami oder azure hinzu. Der Image-Definitionsblock muss osinfo.name, osinfo.version und osinfo.arch enthalten, wie oben beschrieben. Darüber hinaus gilt beim Hinzufügen eines Image-Definitionsblocks auf:
  - vSphere:
    - name: ist ein eindeutiger Name für Ihre OVA, der die Betriebssystemversion enthält, z. B. my-ova-ubuntu-2004.
    - version: Verwenden Sie die eindeutige VERSION, die in metadata.json zugewiesen wurde, als Sie die OVA erstellt haben, z. B. v1.24.10+vmware.1-myorg.0.
    Hinweis
    Die version muss exakt mit derselben VERSION in der Datei metadata.json übereinstimmen.
  - AWS: Folgen Sie für jede Region, in der Sie das benutzerdefinierte Image verwenden möchten, dem Format des vorhandenen id-Werts, verwenden Sie am Ende jedoch eine eindeutige Hex-Zeichenfolge, z. B.: ami-693a5e2348b25e428.
  Wenn Images in der BoM-Datei unter Regionen definiert sind, muss der benutzerdefinierte Image-Definitionsblock zuerst in der zugehörigen Region aufgelistet werden. Innerhalb jeder Region wird während der Clustererstellung das erste geeignete Image ausgewählt, das aufgelistet wird.
3. Legen Sie im Wert release.version eine benutzerdefinierte Version fest, indem Sie ein Suffix hinzufügen. Passen Sie die Version nicht an, indem Sie ein Präfix hinzufügen. Ändern Sie beispielsweise v1.24.10+vmware.1-tkg.1 in v1.24.10+vmware.1-tkg.1-mycustomtkr.
4. Speichern Sie die BoM-Datei mit demselben benutzerdefinierten Suffix, das Sie im vorherigen Schritt für release.version angegeben haben.
  
  Wenn der Dateiname ein Pluszeichen (+) enthält, ersetzen Sie + durch drei Gedankenstriche (---).
  
  Speichern Sie die BoM-Datei beispielsweise als tkr-bom-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml.
Codieren Sie den Dateiinhalt mithilfe von base64 in eine binäre Zeichenfolge, wie z. B.:
```
cat tkr-bom-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml | base64 -w 0
```
Erstellen Sie eine ConfigMap-YAML-Datei (beispielsweise configmap-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml) mit folgenden Werten:
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: CUSTOM-TKG-BOM
 labels:
   tanzuKubernetesRelease: CUSTOM-TKR
binaryData:
 bomContent: "BOM-BINARY-CONTENT"
```
Dabei gilt:
- CUSTOM-TKG-BOM ist der Name der ConfigMap, die den in der BoM-Datei angegebenen TKr-Wert release.version enthalten muss. Ersetzen Sie alle Plussymbole durch drei Gedankenstriche (–). Legen Sie beispielsweise v1.24.10---vmware.1-tkg.1-mycustomtkr fest.
- CUSTOM-TKR ist ein Name für Ihr TKr, der mit dem für CUSTOM-TKG-BOM angegebenen Wert übereinstimmen muss. Beispiel: v1.24.10---vmware.1-tkg.1-mycustomtkr.
- BOM-BINARY-CONTENT ist der base64-codierte Inhalt der angepassten BoM-Datei, den Sie im vorherigen Schritt erzeugt haben.
Beispiel:
```
apiVersion: v1
kind: ConfigMap
metadata:
 name: v1.24.10---vmware.1-tkg.1-mycustomtkr
 labels:
   tanzuKubernetesRelease: v1.24.10---vmware.1-tkg.1-mycustomtkr
binaryData:
 bomContent: "YXBpVmVyc2lvbjogcnVuLnRhbnp1...."
```
Speichern Sie die Datei ConfigMap, legen Sie den kubectl-Kontext auf einen Verwaltungscluster fest, dem Sie das TKr hinzufügen möchten, und wenden Sie die Datei auf den Cluster an, z. B.:
```
kubectl -n tkr-system apply -f configmap-v1.24.10---vmware.1-tkg.1-mycustomtkr.yaml
```
Der TKr-Controller gleicht das neue ConfigMap-Objekt durch Erstellen eines TanzuKubernetesRelease ab. Die Standardzeitraum für die Abstimmung beträgt 600 Sekunden. Sie können diese Verzögerung vermeiden, indem Sie den TKr-Controller-Pod löschen, wodurch der Pod sofort wiederhergestellt und abgestimmt wird:
1. Listen Sie Pods im Namespace tkr-system auf:
```
kubectl get pod -n tkr-system
```
2. Rufen Sie den Namen des TKr-Controller-Pods ab, der folgendermaßen aussieht: tkr-controller-manager-f7bbb4bd4-d5lfd
3. Löschen Sie den Pod:
```
kubectl delete pod -n tkr-system TKG-CONTROLLER
```
  Dabei gilt: TKG-CONTROLLER ist der Name des TKr-Controller-Pods.
Um sicherzustellen, dass das benutzerdefinierte TKr hinzugefügt wurde, führen Sie tanzu kubernetes-release get oder kubectl get tkr aus und suchen Sie nach dem in der obigen Ausgabe festgelegten Wert CUSTOM-TKR.

Sobald das benutzerdefinierte TKr von den kubectl- und tanzu-CLIs aufgelistet wird, können Sie mit ihm Verwaltungs- oder Arbeitslastcluster erstellen (siehe folgende Beschreibung).

Verwenden eines Linux-Images für einen Verwaltungscluster

So erstellen Sie einen Verwaltungscluster, der das benutzerdefinierte Image als Basisbetriebssystem für die zugehörigen Knoten verwendet:

Laden Sie das Image auf Ihren Cloud-Anbieter hoch.
Wenn Sie die Installationsprogramm-Schnittstelle ausführen, wählen Sie im Bereich OS-Image (OS Image) das benutzerdefinierte Image aus (siehe Beschreibung unter Auswählen des Basisbetriebssystem-Images).

Weitere Informationen finden Sie unter Vorgehensweise zum Erzeugen von Auswahlen für Basisbetriebssystem-Images.

Verwenden eines Linux-Images für einen Arbeitslastcluster

Die Vorgehensweise zum Erstellen eines Arbeitslastclusters anhand des Linux-Images unterscheidet sich je nachdem, ob Sie wie oben in Erstellen eines TKr für das Linux-Image angegeben ein TKr erstellt haben.

Wenn Sie ein TKr erstellt haben, übergeben Sie den TKr-Namen entsprechend der Angabe in tanzu kubernetes-release get an die Option --tkr von tanzu cluster create.
Wenn Sie kein TKr erstellt haben, führen Sie die folgenden Schritte aus:
1. Kopieren Sie die Konfigurationsdatei des Verwaltungsclusters und speichern Sie sie unter einem neuen Namen, indem Sie das Verfahren unter Konfigurationsdateien und Objektspezifikationen durchführen.
2. Ändern oder fügen Sie in der neuen Konfigurationsdatei Folgendes hinzu:
```
VSPHERE_TEMPLATE: LINUX-IMAGE
```
  Dabei gilt: LINUX-IMAGE ist der Name des Linux-Images, das Sie in Erstellen eines Linux-Images erstellt haben.
  
  Entfernen Sie gegebenenfalls CLUSTER_NAME und die zugehörige Einstellung.
3. Stellen Sie einen Arbeitslastcluster gemäß der Beschreibung unter Erstellen von Arbeitslastclustern bereit.