Dieser Vorgang führt Sie schrittweise durch die Erstellung eines benutzerdefinierten Linux-Maschinen-Images, das beim Erstellen von Clustern 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.
Wie in den Verfahren angegeben, unterscheiden sich einige Schritte je nachdem, ob Sie ein Image für einen klassenbasierten oder planbasierten (Legacy-)Cluster erstellen.
Zur Erstellung eines benutzerdefinierten Linux-Maschinen-Images benötigen Sie Folgendes:
aws
-CLI (Command-Line Interface, Befehlszeilenschnittstelle)az
-CLIBevor Sie ein Image für klassenbasierte Cluster auf vSphere erstellen, müssen Sie die Betriebssystem-Image-Version abrufen, die mit der standardmäßigen Ubuntu-OVA für die Kubernetes-Version verbunden ist, die Sie für Ihr benutzerdefiniertes Image verwenden möchten. Sie weisen diese Betriebssystem-Image-Version Ihrem benutzerdefinierten Image im Schritt Erstellen eines Linux-Images weiter unten zu.
Zum Abrufen der Betriebssystem-Image-Version führen Sie je nach Anwendungsfall einen der folgenden Schritte aus:
Wenn Sie über einen ausgeführten Verwaltungscluster verfügen, der mit der Kubernetes-Standardversion für die aktuelle Tanzu Kubernetes Grid-Version erstellt wurde, können Sie die Betriebssystem-Image-Version aus dem Cluster abrufen:
Setzen Sie den kubectl
-Kontext auf den Verwaltungscluster.
Wählen Sie in der Liste der verfügbaren TKrs das Tanzu Kubernetes-Release (TKr) für die Kubernetes-Version aus, die Sie für das benutzerdefinierte Image verwenden möchten. Beispiel: v1.26.8---vmware.2-tkg.1
. Führen Sie zum Auflisten der verfügbaren TKrs folgenden Befehl aus:
kubectl get tkr
Öffnen Sie das TKr und notieren Sie sich die Eigenschaft osImages
. Diese Eigenschaft gibt die Namen von OSImage
-Objekten an, die dem TKr zugeordnet sind.
OSImage
-Objekte in Kubernetes auflisten:
kubectl get osimages
Suchen Sie in der Ausgabe die Objektliste OSImage
, die mit dem TKr osImages
-Namen für die Standard-Ubuntu-OVA übereinstimmt.
Notieren Sie sich die Eigenschaft NAME
der Liste OSImage
und ersetzen Sie die eingebetteten ---
-Zeichen durch ein +
-Zeichen. Beispiel: v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8
.
Wenn Sie nicht über einen ausgeführten Verwaltungscluster verfügen, der mit der Kubernetes-Standardversion für die aktuelle Tanzu Kubernetes Grid-Version erstellt wurde, können Sie die Betriebssystem-Image-Version direkt aus der Ubuntu-Standard-OVA (entweder lokal oder aus vSphere) abrufen:
So rufen Sie die Betriebssystem-Image-Version lokal ab:
.ofv
.Suchen Sie in der Datei .ofv
nach der OVA-Eigenschaft VERSION
und notieren Sie sich den entsprechenden Wert. Beispiel: v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8
. Die Eigenschaft ähnelt Folgendem:
<Property ovf:key="VERSION" ovf:type="string" ovf:userConfigurable="false" ovf:value="v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8"/>
Wenn Sie die Ubuntu-Standard-OVA für Ihre Kubernetes-Zielversion bereits auf vSphere hochgeladen haben, können Sie alternativ die Betriebssystem-Image-Version abrufen, indem Sie die Eigenschaften der OVA-VM auf der vSphere-Benutzeroberfläche überprüfen oder die govc
-CLI verwenden. Rufen Sie zur Verwendung dieser Methode die Betriebssystem-Image-Version ab, bevor Sie die OVA-VM in eine Vorlage konvertieren.
So rufen Sie die Betriebssystem-Image-Version aus der vSphere-Benutzeroberfläche ab:
v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8
.Zum Abrufen der Betriebssystem-Image-Version mithilfe der govc
-CLI führen Sie den Befehl govc vm.info
aus. Beispiel:
govc vm.info -json /dc0/vm/ubuntu-2004-kube-v1.26.8+vmware.1-tkg.1 | jq
Suchen Sie in der Ausgabe nach "Id": "VERSION"
und notieren Sie sich den Wert der Eigenschaft "DefaultValue"
. Beispiel:
{
"Key": 10,
"ClassId": "",
"InstanceId": "",
"Id": "VERSION",
"Category": "Cluster API Provider (CAPI)",
"Label": "VERSION",
"Type": "string",
"TypeReference": "",
"UserConfigurable": false,
"DefaultValue": "v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8",
"Value": "",
"Description": ""
}
Richten Sie die Authentifizierung für Ihre Infrastruktur ein:
vSphere: Erstellen Sie 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": ""
}
AWS: Melden Sie sich bei der aws
-CLI an Authentifizieren Sie sich und geben Sie Ihre Region an, wenn Sie dazu aufgefordert werden:
aws configure
Azure: Melden Sie sich bei der az
-CLI an Erstellen Sie dann eine JSON-Konfigurationsdatei azure-sig.json
und geben Sie die Azure-spezifischen Informationen ein. Ein Beispiel für eine solche Datei finden Sie hier.
Laden Sie den Linux-Ressourcenbündel-Container von projects.registry.vmware.com
herunter:
Stellen Sie sicher, dass Ihre Workstation auf die VMware-Image-Registrierung projects.registry.vmware.com
zugreifen kann.
Laden Sie den Container mit den Kubernetes-Linux-Binärdateien, die Image Builder zum Erstellen einer Linux-OVA benötigt, herunter und führen Sie ihn aus:
docker pull projects.registry.vmware.com/tkg/linux-resource-bundle:v1.26.8_vmware.1-tkg.1
docker run -d -p 3000:3000 projects.registry.vmware.com/tkg/linux-resource-bundle:v1.26.8_vmware.1-tkg.1
Laden Sie das Image Builder-Konfigurationsverzeichnis herunter:
Legen Sie die Version der Image Builder-Konfiguration fest, die als Grundlage für die Erstellung dienen soll.
TKG Image Builder
, um die verfügbaren Versionen aufzulisten.TKG-Image-Builder-for-Kubernetes-v1_26_8---vmware_1-tkg_v2_3_1.zip
ein Kubernetes v1.26.8-Image für Tanzu Kubernetes Grid v2.3.1.In den folgenden Schritten wird erläutert, wie Sie ein Kubernetes v1.26.8-Image für Tanzu Kubernetes Grid v2.3.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.
vSphere Erstellen Sie für vSphere eine Datei metadata.json
im Image Builder-Verzeichnis, die eine Versionszeichenfolge festlegt, die mit der Liste in Ihrem benutzerdefinierten TKr in den späteren Schritten übereinstimmt:
Klassenbasiert: Verwenden Sie den Wert, den Sie im Schritt Abrufen der Betriebssystem-Image-Version oben abgerufen haben, z. B.:
{
"VERSION": "v1.26.8+vmware.1-tkg.1-0edd4dafbefbdb503f64d5472e500cf8"
}
Planbasiert: Der Image-Builder gibt den von ihm erstellten OVAs eine Versionszeichenfolge, die mit den von VMware veröffentlichten OVAs identisch ist, wie v1.26.8+vmware.1-tkg.1
. Für benutzerdefinierte Images empfiehlt VMware, -tkg.1
durch eine für Ihre Organisation aussagekräftige Zeichenfolge zu ersetzen, z. B.:
{
"VERSION": "v1.26.8+vmware.1-myorg.0"
}
Bearbeiten Sie die tkg.json
-Datei, um die <IP>
und <PORT>
-Einstellungen und Anpassungen für containerd_url
und kubernetes_http_source
einzutragen, wobei:
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.Um die folgenden Optionen einzubinden, bearbeiten Sie die Datei tkg.json
weiter.
Photon: 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"
STIG- und CIS-Absicherung: So härten Sie Ihr benutzerdefiniertes Ubuntu-Image über die Standardwerte hinaus:
Fügen Sie eine Zeile hinzu, die ansible_user_vars
für einige oder alle der folgenden Variablen auf true
festlegt. Dies ist standardmäßig auf false
gesetzt:
STIG:
install_aide
– AIDE (Advanced Intrusion Detection Environment) aktiviereninstall_sshd_login_banner
– DoD-Anmelde-Banner installierenremove_existing_ca_certs
– DoD-PKI-Infrastruktur beibehalteninstall_audispd_plugins
– Ereignis-Multiplexor-Plug-Ins (audispd) installierenCIS:
install_aide
– AIDE (Advanced Intrusion Detection Environment) aktiviereninstall_clamav
– ClamAV AntiVirus aktiviereninstall_systemd_timesyncd
– timesyncd anstelle von chrony verwendeninstall_protect_kernel_defaults
– Upstream-Standardeinstellungen für Kernelschutz festlegenÄndern Sie die Einstellung custom_role_names
, indem Sie /home/imagebuilder/stig_ubuntu_2004
für STIG oder /home/imagebuilder/cis_ubuntu_2004
für CIS hinzufügen.
Beispiel für zusätzliche CIS-Absicherung:
"ansible_user_vars": "install_aide=true install_clamav=true install_systemd_timesyncd=true install_protect_kernel_defaults=true",
"custom_role_names": "/home/imagebuilder/tkg /home/imagebuilder/cis_ubuntu_2004",
HinweisBenutzerdefinierte Photon-Images werden für zusätzliche Absicherung über
ansible_user_vars
nicht unterstützt.
FIPS: Um ein FIPS-fähiges Image zu erstellen, entfernen Sie die folgende Einstellung, falls vorhanden:
"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 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 zu erstellen, fügen Sie Folgendes hinzu:
"vmx_version": "17"
Sie können zusätzliche Anpassungen zu tkg.json
hinzufügen oder sie in einer separaten Datei customizations.json
ablegen.
Erfassen Sie die folgenden Parameterzeichenfolgen, um sie im nächsten Schritt zum Befehl docker
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. Verwendung:
/PATH/TO/CREDENTIALS.json:/home/imagebuilder/vsphere.json
~/.aws:/home/imagebuilder/.aws
~/.azure:/home/imagebuilder/.azure
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:
/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.
TESTS
: Kopiert ein Testverzeichnis vom Typ goss
, das für die Zielinfrastruktur, das Betriebssystem und die Kubernetes-Version des Images entwickelt wurde:
goss
des Repositorys.amazon-ubuntu-1.26.8+vmware.1-goss-spec.yaml
CUSTOMIZATIONS
: Kopiert eine Anpassungsdatei im JSON-Format.
PACKER_VAR_FILES
: Eine durch Leerzeichen getrennte Liste der oben genannten JSON-Dateien, die Variablen für Packer enthalten.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.04build-ami-ubuntu-1804
: Ubuntu v18.04build-ami-amazon-2
: Amazon Linux 2build-node-ova-vsphere-ubuntu-2004
: GPU-fähige ClusterFü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.
Lassen Sie metadata.json
aus, wenn Sie kein Image für vSphere und env-file
wenn Sie kein Image für Azure erstellen:
export ROLES="... the value for roles you created above"
export SOURCES="... ..."
docker run -it --rm \
-v $AUTHENTICATION \
-v $SOURCES \
-v $ROLES \
-v /PATH/TO/goss/TESTS.yaml:/home/imagebuilder/goss/goss.yaml \
-v /PATH/TO/metadata.json:/home/imagebuilder/metadata.json \
-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
HinweisEs kann einige Minuten dauern, bis der Befehl abgeschlossen ist.
Beispiele
vSphere: Die Datei .ova
wird 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.26.8+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
GPU-fähige Cluster: Fügen Sie die in den obigen Schritten erstellte Datei customizations.json
, wenn Sie den Befehl zur Erstellung der OVA ausführen:
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.26.8+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.$(pwd)/isos/rhel-8.4-x86-64-dvd.iso
im obigen Beispiel als zusätzliches Volume zu.AWS: Erstellen Sie ein benutzerdefiniertes Image mit Ubuntu v20.04 und Kubernetes v1.26.8 für AWS, das aus dem Verzeichnis mit der Datei tkg.json
ausgeführt wird:
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.26.8+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
Laden Sie das Image auf Ihren Cloud-Anbieter hoch.
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.
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 hierzu beispielsweise einen Dateinamen wie tkr-bom-v1.26.8+vmware.1-tkg.1.yaml
für Kubernetes v1.26.8.
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).
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
.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.26.8+vmware.1-myorg.0
.HinweisDie
version
muss exakt mit derselbenVERSION
in der Dateimetadata.json
übereinstimmen.
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.
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.26.8+vmware.1-tkg.1
in v1.26.8+vmware.1-tkg.1-mycustomtkr
.
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.26.8---vmware.2-tkg.1-mycustomtkr.yaml
.
Codieren Sie den Dateiinhalt mithilfe von base64
in eine binäre Zeichenfolge, wie z. B.:
cat tkr-bom-v1.26.8---vmware.2-tkg.1-mycustomtkr.yaml | base64 -w 0
Erstellen Sie eine ConfigMap-YAML-Datei (beispielsweise configmap-v1.26.8---vmware.2-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.26.8---vmware.2-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.26.8---vmware.2-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.26.8---vmware.2-tkg.1-mycustomtkr
labels:
tanzuKubernetesRelease: v1.26.8---vmware.2-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.26.8---vmware.2-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:
Listen Sie Pods im Namespace tkr-system
auf:
kubectl get pod -n tkr-system
Rufen Sie den Namen des TKr-Controller-Pods ab, der folgendermaßen aussieht: tkr-controller-manager-f7bbb4bd4-d5lfd
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).
So erstellen Sie einen Verwaltungscluster, der das benutzerdefinierte Image als Basisbetriebssystem für die zugehörigen Knoten verwendet:
Weitere Informationen finden Sie unter Vorgehensweise zum Erzeugen von Auswahlen für Basisbetriebssystem-Images.
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:
Kopieren Sie die Konfigurationsdatei des Verwaltungsclusters und speichern Sie sie unter einem neuen Namen, indem Sie das Verfahren unter Konfigurationsdateien und Objektspezifikationen durchführen.
Ä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.
Stellen Sie einen Arbeitslastcluster gemäß der Beschreibung unter Erstellen von Arbeitslastclustern bereit.