Mithilfe der Tipps in diesem Thema können Sie Fehler in Bereitstellungen eigenständiger Verwaltungscluster beheben.
Weitere Informationen zur Fehlerbehebung in Arbeitslastclustern finden Sie unter Fehlerbehebung bei Problemen mit dem Arbeitslastcluster. Weitere Problemumgehungen für bekannte Probleme in dieser Version finden Sie in den Versionshinweisen oder in VMware KnowledgeBase-Artikeln.
In einigen der folgenden Verfahren wird die kind
-CLI verwendet. Informationen zum Installieren von kind
finden Sie unter Installation in der Dokumentation zu kind
.
087bf3b4 (RNs-Updates für Ghost (#1178))
Sie können SSH verwenden, um eine Verbindung zu einzelnen Knoten eigenständiger Verwaltungs- oder Arbeitslastcluster herzustellen. Hierzu muss das bei der Bereitstellung des Verwaltungsclusters erstellte SSH-Schlüsselpaar auf der Maschine verfügbar sein, auf der Sie den SSH-Befehl ausführen. Folglich müssen Sie ssh
-Befehle auf der Maschine ausführen, auf der Sie tanzu
-Befehle ausführen.
Die SSH-Schlüssel, die Sie beim Verwaltungscluster registrieren und die von allen über den Verwaltungscluster bereitgestellten Arbeitslastclustern verwendet werden, sind mit den folgenden Benutzerkonten verknüpft:
capv
ubuntu
ubuntu
ec2-user
capi
Zum Herstellen einer Verbindung zu einem Knoten mithilfe von SSH führen Sie einen der folgenden Befehle auf der Maschine aus, die Sie als Bootstrap-Maschine verwenden:
ssh capv@node-address
ssh ubuntu@node-address
ssh ec2-user@node-address
ssh capi@node-address
Da der SSH-Schlüssel auf dem System vorhanden ist, auf dem Sie den ssh
-Befehl ausführen, ist kein Kennwort erforderlich.
kubectl
So bereinigen Sie den Zustand von kubectl
, indem Sie bestimmte oder alle Benutzer, Kontexte und Cluster löschen:
Öffnen Sie die Datei ~/.kube-tkg/config
.
Führen Sie für die zu löschenden user
-Objekte Folgendes aus:
kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
Dabei fungiert USERNAME
als die Eigenschaft name
jedes user
-Objekts auf oberster Ebene, das in der Datei config
angegeben wird.
Führen Sie für die zu löschenden context
-Objekte Folgendes aus:
kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
Dabei fungiert CONTEXT-NAME
als die Eigenschaft name
jedes context
-Objekts auf oberster Ebene, das in der Datei config
üblicherweise im Format contexts.mycontext-admin@mycontext
angegeben wird.
Führen Sie für die zu löschenden cluster
-Objekte Folgendes aus:
kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
Dabei fungiert CLUSTER-NAME
als die Eigenschaft name
jedes cluster
-Objekts auf oberster Ebene, das in der Datei config
angegeben wird.
Wenn die config
-Dateien den aktuellen Kontext als einen von Ihnen gelöschten Cluster auflisten, setzen Sie den Kontext zurück:
kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
Wenn Sie von der tanzu
-CLI nachverfolgte Verwaltungscluster gelöscht haben, löschen Sie sie aus dem Status der tanzu
-CLI, indem Sie tanzu context delete
ausführen (siehe Beschreibung unter Löschen von Verwaltungsclustern aus der Konfiguration der Tanzu CLI).
nfs-utils
auf Photon OS-KnotenProblem
nfs-utils
ist in Tanzu Kubernetes Grid v1.1.2 und höher standardmäßig aktiviert. Wenn Sie nfs-utils
nicht benötigen, können Sie es aus Clusterknoten-VMs entfernen.
Lösung
Zum Deaktivieren von nfs-utils
auf Clustern, die Sie mit Tanzu Kubernetes Grid v1.1.2 oder höher bereitstellen, verwenden Sie SSH für die Anmeldung bei den Clusterknoten-VMs und führen Sie folgenden Befehl aus:
tdnf erase nfs-utils
Problem
Aufgrund eines Ressourcen-Tagging-Problems im Upstream-Cluster-API-Anbieter AWS (Cluster API Provider AWS, CAPA) können Offline-Bereitstellungen nicht auf die API ResourceTagging
zugreifen. Dies führt zu Abstimmungsfehlern bei der Erstellung oder dem Upgrade eines Verwaltungsclusters.
Lösung
Legen Sie in einer Offline-AWS-Umgebung EXP_EXTERNAL_RESOURCE_GC=false
in Ihrer lokalen Umgebung oder in der Verwaltungscluster-Konfigurationsdatei fest, bevor Sie tanzu mc create
oder tanzu mc upgrade
ausführen.
Problem
Die Ausführung von tanzu management-cluster create
oder tanzu mc create
schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:
Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain
Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request
Lösung
Tanzu Kubernetes Grid verwendet die standardmäßige Anbieterkette für AWS-Anmeldedaten. Bevor Sie einen Verwaltungs- oder Arbeitslastcluster auf AWS erstellen, müssen Sie die Anmeldedaten für Ihr AWS-Konto gemäß der Beschreibung unter Konfigurieren der AWS-Anmeldedaten konfigurieren.
Problem
Bevor Sie einen eigenständigen Verwaltungs- oder Arbeitslastcluster in Azure erstellen, müssen Sie die rechtlichen Bedingungen akzeptieren, die für das von Clusterknoten verwendete VM-Image gelten. Wenn Sie die Lizenz nicht akzeptiert haben, schlägt das Ausführen von tanzu mc create
oder tanzu cluster create
mit einem Fehler ähnlich dem folgenden fehl:
User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.
Lösung
Akzeptieren Sie in diesem Fall die rechtlichen Bedingungen und versuchen Sie es erneut:
Problem
Aufgrund eines erfolglosen Versuchs, einen eigenständigen Verwaltungscluster bereitzustellen, verbleiben verwaiste Objekte in Ihrer Cloud-Infrastruktur und auf Ihrer Bootstrap-Maschine.
Lösung
tanzu mc create
-Befehlsausgabe entweder im Terminal oder auf der Benutzeroberfläche des Tanzu Kubernetes Grid-Installationsprogramms. Wenn der Befehl fehlschlägt, wird eine Hilfemeldung mit folgendem Inhalt ausgegeben: Fehler beim Bereitstellen des Verwaltungsclusters… Zum Bereinigen der vom Verwaltungscluster: tkg erstellten Ressourcen löschen Sie mc… (Failure while deploying management cluster. To clean up the resources created by the management cluster: tkg delete mc).tanzu mc delete YOUR-CLUSTER-NAME
aus. Mit diesem Befehl werden die Objekte entfernt, die in Ihrer Infrastruktur und lokal erstellt wurden.Sie können auch die im Folgenden beschriebenen alternativen Methoden verwenden:
Bereinigung der Bootstrap-Maschine:
Verwenden Sie zum Entfernen eines kind
-Clusters die kind
-CLI. Beispiel:
kind get clusters
kind delete cluster --name tkg-kind-example1234567abcdef
Verwenden Sie zum Entfernen von Docker-Objekten die docker
-CLI. Beispiel: docker rm
, docker rmi
und docker system prune -a --volumes
.
Vorsicht Wenn Sie Docker-Prozesse ausführen, die sich nicht auf Tanzu Kubernetes Grid auf Ihrem System beziehen, entfernen Sie nicht benötigte Docker-Objekte einzeln.
Bereinigung der Zielplattform:
AZURE_RESOURCE_GROUP
. Verwenden Sie die Kontrollkästchen, um die von Tanzu Kubernetes Grid erstellten Ressourcen, deren Namen einen Zeitstempel enthalten, auszuwählen und zu löschen.Problem
Nach dem Ausführen von tanzu mc delete
in AWS werden mit tanzu mc get
und anderen Tanzu CLI-Befehlen keine gelöschten Verwaltungscluster mehr aufgelistet, sondern:
cluster infrastructure is still being provisioned: VpcReconciliationFailed
angezeigtLösung
Dieses Verhalten tritt auf, wenn TKG abgelaufene oder anderweitig ungültige AWS-Kontoanmeldedaten verwendet. So verhindern oder bereinigen Sie diese Situation:
Verhindern (Prevent): Aktualisieren Sie die Anmeldedaten für das AWS-Konto gemäß der Beschreibung unter Konfigurieren von AWS-Kontoanmeldedaten, indem Sie entweder AWS-Anmeldedatenprofile oder lokale statische Umgebungsvariablen verwenden.
Wiederherstellen (Recover) mithilfe des EC2-Dashboards: Löschen Sie die Knoten des Verwaltungsclusters manuell aus dem EC2-Dashboard
Wiederherstellen (Recover) mithilfe der CLI:
Korrigieren Sie folgenden geheimen Schlüssel für die AWS-Anmeldedaten im kind
-Cluster, der auf der Bootstrap-Maschine verbleibt, weil der Verwaltungscluster nicht gelöscht werden konnte:
kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
Bearbeiten Sie den geheimen Schlüssel, um die AWS-Anmeldedaten hinzuzufügen:
[default]
aws_access_key_id = <key id>
aws_secret_access_key = <access_key>
region = <region>
Führen Sie tanzu mc delete
erneut aus.
Problem
Durch Ausführen von tanzu mc delete
wird der Verwaltungscluster zwar entfernt, der lokale kind
-Cluster aber nicht von der Bootstrap-Maschine gelöscht.
Lösung
Listen Sie alle ausgeführten kind
-Cluster auf und entfernen Sie den Cluster, der tkg-kind-unique_ID
entspricht:
kind delete cluster --name tkg-kind-unique_ID
Listen Sie alle ausgeführten Cluster auf und geben Sie den kind
-Cluster an.
docker ps -a
Kopieren Sie die Container-ID des kind
-Clusters und entfernen Sie sie.
docker kill container-ID
Problem
Der eigenständige Verwaltungscluster kann nicht bereitgestellt werden, da Maschinen nicht mehr reagieren und auf die Standardisierung warten.
Lösung
Ein Verwaltungscluster, den Sie mit dem dev
-Plan bereitgestellt haben und der nur über einen Steuerungsebenenknoten verfügt, muss erneut bereitgestellt werden. Für Verwaltungscluster mit mehr als einem Steuerungsebenenknoten können Sie die nicht reaktionsfähigen Maschinen angeben und löschen.
Rufen Sie den Status des Verwaltungsclusters ab. Beispiel:
kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
Suchen Sie nach den Namen der nicht reaktionsfähigen Maschinen in der Ausgabe des vorherigen Schritts. Eine nicht reaktionsfähige Maschine ist folgendermaßen gekennzeichnet: WaitingForRemediation
. Beispiel: Der Name der nicht reaktionsfähigen Maschine lautet my-mgmt-cluster-zpc7t
in der folgenden Ausgabe:
status:
conditions:
- lastTransitionTime: "2021-08-25T15:44:23Z"
message: KCP can't remediate if current replicas are less or equal then 1
reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
severity: Warning
status: "False"
type: Ready
Erhöhen Sie für die Steuerungsebenenknoten die Zeitüberschreitungswerte für die Integritätsprüfung der Maschine auf einen Wert, der größer ist als der Standardwert 5m
. Beispiel:
tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
Weitere Informationen zum Aktualisieren eines MachineHealthCheck
-Objekts finden Sie unter Erstellen oder Aktualisieren eines MachineHealthCheck
-Objekts in Konfigurieren von Maschinenintegritätsprüfungen für Arbeitslastcluster.
Legen Sie kubectl
auf den Kontext des Verwaltungsclusters fest. Beispiel:
kubectl config use-context mgmt-cluster-admin@mgmt-cluster
Löschen Sie die nicht reaktionsfähigen Maschinen.
kubectl delete machine MACHINE-NAME
Dabei ist MACHINE-NAME
der Name der Maschine, die Sie in einem früheren Schritt ermittelt haben.
Warten Sie, bis der KubeadmControlPlane
-Controller die Maschine erneut bereitgestellt hat.
~/.config/tanzu
Problem
Das Verzeichnis ~/.config/tanzu
auf der Bootstrap-Maschine wurde versehentlich gelöscht oder beschädigt. Die Tanzu CLI erstellt und verwendet dieses Verzeichnis. Ohne dieses Verzeichnis funktioniert die CLI nicht.
Lösung
So stellen Sie die Inhalte des Verzeichnisses ~/.config/tanzu
wieder her:
Zur Angabe vorhandener Tanzu Kubernetes Grid-Verwaltungscluster führen Sie folgenden Befehl aus:
kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
In der Befehlsausgabe werden Namen und Kontexte aller Verwaltungscluster aufgelistet, die von der Tanzu CLI erstellt oder hinzugefügt wurden.
Stellen Sie für jeden in der Ausgabe aufgeführten Verwaltungscluster das Verzeichnis ~/.config/tanzu
und die CLI wieder her, indem Sie folgenden Befehl ausführen:
tanzu context create --management-cluster --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
tanzu management-cluster
create auf macOS hat einen kubectl-Versionsfehler zur FolgeProblem
Wenn Sie den Befehl tanzu management-cluster create
oder tanzu mc create
auf macOS mit der aktuellen stabilen Version von Docker Desktop ausführen, schlägt dies mit einer Fehlermeldung ähnlich der folgenden fehl:
Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.27.5
Dies geschieht, weil Docker Desktop eine ältere Version von kubectl
mithilfe symbolischer Links mit dem Pfad verknüpft.
Lösung
Platzieren Sie eine neuere unterstützte Version von kubectl
im Pfad vor der Docker-Version.
Wenn Sie die Anmeldedaten für einen eigenständigen Verwaltungscluster verloren haben, wie z. B. durch versehentliches Löschen der Datei .kube-tkg/config
auf dem System, auf dem Sie tanzu
-Befehle ausführen, können Sie die Anmeldedaten über den Steuerungsebenenknoten des Verwaltungsclusters wiederherstellen.
tanzu mc create
aus, um die Datei .kube-tkg/config
neu zu erstellen.Verwenden Sie SSH, um sich beim Steuerungsebenenknoten des Verwaltungsclusters anzumelden.
Die Anmeldedaten für alle Zielplattformen finden Sie weiter oben unter Herstellen einer Verbindung zu Clusterknoten mit SSH.
Greifen Sie auf die Datei admin.conf
für den Verwaltungscluster zu.
sudo vi /etc/kubernetes/admin.conf
Die Datei admin.conf
enthält den Namen und den Benutzernamen des Clusters, den Clusterkontext sowie die Daten für das Clientzertifikat.
.kube-tkg/config
auf dem System, auf dem Sie tanzu
-Befehle ausführen.VSPHERE_CONTROL_PLANE_ENDPOINT
Problem
Für die Integration eines externen Identitätsanbieters in eine vorhandene TKG-Bereitstellung muss möglicherweise ein Dummy-Wert für VSPHERE_CONTROL_PLANE_ENDPOINT
in der Verwaltungscluster-Konfigurationsdatei festgelegt werden, die zum Erstellen des geheimen Add-on-Schlüssels verwendet wird, wie unter Generieren des geheimen Pinniped-Add-on-Schlüssels für den Verwaltungscluster beschrieben.
Secret
auf Legacy-Clustern manuell gelöscht werden.Problem
Wenn Sie die externe Identitätsverwaltung auf einem Verwaltungscluster deaktivieren, bleibt das nicht verwendete Pinniped-Objekt Secret
auf Legacy-Arbeitslastclustern erhalten.
Wenn ein Benutzer dann versucht, mit einer alten kubeconfig
auf den Cluster zuzugreifen, wird ein Anmelde-Popup angezeigt und der Vorgang schlägt fehl.
Problemumgehung:
Löschen Sie das Pinniped-Secret
des Legacy-Clusters manuell, wie unter Deaktivieren der Identitätsverwaltung beschrieben.
Problem
Beim Upgrade auf Tanzu Kubernetes Grid v2.4 wird eine Fehlermeldung ähnlich der folgenden zurückgegeben:
Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again
Lösung
Dieser Fehler kann auftreten, wenn der Pinniped-Auftrag nach der Bereitstellung mit dem Upgrade-Vorgang einer Komponente kollidiert. Führen Sie die folgenden Schritte aus, um den Auftrag zu löschen und erneut bereitzustellen.
Löschen Sie den Pinniped-Auftrag nach der Bereitstellung.
kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
Warten Sie etwa 5 Minuten, bis kapp-controller
den Auftrag nach der Bereitstellung erneut bereitstellt.
Überprüfen Sie den Status der Pinniped-App.
kubectl get app -n tkg-system pinniped
NAME DESCRIPTION SINCE-DEPLOY AGE
pinniped Reconcile succeeded 5s 49m
Wenn in der DESCRIPTION
der Wert Reconciling
angezeigt wird, warten Sie einige Minuten und führen Sie zu einem späteren Zeitpunkt eine erneute Überprüfung durch. Fahren Sie mit dem nächsten Schritt fort, sobald Reconcile succeeded
angezeigt wird.
Überprüfen Sie den Status des Pinniped-Auftrags nach der Bereitstellung.
kubectl get jobs -n pinniped-supervisor
NAME COMPLETIONS DURATION AGE
pinniped-post-deploy-job-ver-1 1/1 9s 62s
Problem
Sie haben kürzlich den Verwaltungscluster aktualisiert. Wenn Sie sich bei einem mit diesem Verwaltungscluster verknüpften Arbeitslastcluster authentifizieren, erhalten Sie eine Fehlermeldung ähnlich der folgenden:
Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority
Lösung
Dies geschieht, weil die Kopie des vom Arbeitslastcluster verwendeten CA-Pakets des Pinniped-Supervisors veraltet ist. Führen Sie zum Aktualisieren des CA-Pakets des Supervisors die folgenden Schritte aus:
Legen Sie den kubectl
-Kontext auf den Verwaltungscluster fest.
Rufen Sie das Base64-codierte CA-Paket und den issuer
-Endpoint aus der pinniped-info
-ConfigMap ab:
kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
Rufen Sie den Abschnitt values.yaml
aus dem geheimen Schlüssel des Pinniped-Add-Ons für den Arbeitslastcluster ab:
kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Dieser geheime Schlüssel befindet sich im Verwaltungscluster.
Aktualisieren Sie in der oben erstellten Datei values.yaml
den supervisor_ca_bundle_data
-Schlüssel so, dass er mit dem CA-Paket aus der pinniped-info
-ConfigMap übereinstimmt. Stellen Sie außerdem sicher, dass der supervisor_svc_endpoint
-Endpoint mit dem issuer
-Endpoint übereinstimmt.
Wenden Sie Ihr Update an, indem Sie die bearbeitete Datei values.yaml
mit Base64 verschlüsseln und im geheimen Schlüssel des Arbeitslastclusters ersetzen. Dieser Befehl unterscheidet sich je nach dem in Ihrer Umgebung eingesetzten Betriebssystem. Beispiel:
Linux:
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
macOS:
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
Bestätigen Sie im Arbeitslastcluster, dass die Pinniped-App die Änderungen erfolgreich abgeglichen hat:
kubectl get app pinniped -n tkg-system
Authentifizieren Sie sich beim Cluster. Beispiel:
kubectl get pods -A --kubeconfig my-cluster-credentials
Problem
Wenn Sie kubectl get pods -A
in dem erstellten Cluster ausführen, verbleiben bestimmte Pods im Status „Ausstehend“.
Sie führen kubectl describe pod -n pod-namespace pod-name
auf einem betroffenen Pod aus und sehen das folgende Ereignis:
n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate
Lösung
Stellen Sie sicher, dass Konnektivitäts- und Firewallregeln vorhanden sind, um die Kommunikation zwischen dem Cluster und vCenter sicherzustellen. Informationen zu firewallbasierten Ports und Protokollanforderungen finden Sie in den vSphere-Listen in VMware Ports and Protocols.
Problem
Die Ausführung von Befehlen der tanzu
-CLI schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:
Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying
Lösung
Informationen finden Sie unter Aktualisieren des Verwaltungsclusterzertifikats in Ihrer Tanzu CLI-Konfiguration und Kein Zugriff auf die Cluster mithilfe der CLI-Befehle „tkg/tanzu“ in Tanzu Kubernetes Grid.
Problem
In der Windows-Eingabeaufforderung (Command Prompt, CMD) enthält eine in Spalten formatierte Tanzu CLI-Befehlsausgabe überflüssige Zeichen in Spaltenüberschriften. Dieses Problem tritt nicht in Windows Terminal oder PowerShell auf.
Lösung
Führen Sie auf Windows-Bootstrap-Maschinen die Tanzu CLI über Windows Terminal aus.
Problem
Wenn Maschinenintegritätsprüfungen (Machine Health Checks, MHCs) deaktiviert sind, melden Tanzu CLI-Befehle wie tanzu cluster status
möglicherweise nicht den aktuellen Knotenzustand, während die Infrastruktur neu erstellt wird.
Lösung
Keine.
Problem
Wenn Sie den Befehl tanzu management-cluster create --ui
oder tanzu mc create --ui
auf einem Windows-System ausführen, wird die Benutzeroberfläche in Ihrem Standardbrowser geöffnet. Die Grafiken und Formatierungen werden jedoch nicht übernommen. Dies tritt auf, weil eine Windows-Registrierung auf application/x-css
festgelegt ist.
Lösung
regedit
in der Windows-Suche ein, um das Dienstprogramm „Registrierungs-Editor“ zu öffnen.HKEY_CLASSES_ROOT
und wählen Sie .js
aus.application/javascript
fest und klicken Sie auf OK.tanzu mc create --ui
erneut aus, um die Benutzeroberfläche neu zu starten.Problem
Wenn Sie NSX Advanced Load Balancer für Arbeitslasten (AVI_ENABLE
) oder die Steuerungsebene (AVI_CONTROL_PLANE_HA_PROVIDER
) verwenden, kann der Avi-Controller möglicherweise nicht zwischen Clustern mit identischen Namen unterscheiden.
Lösung:
Legen Sie einen eindeutigen CLUSTER_NAME
-Wert für jeden Cluster fest. Erstellen Sie nicht mehrere Verwaltungscluster mit demselben Wert für CLUSTER_NAME
, auch nicht von unterschiedlichen Bootstrap-Maschinen.
Problem
Wenn die Gesamtzahl der Dienste vom Typ LoadBalancer
hoch ist und alle Dienstmodule im selben L2-Netzwerk bereitgestellt werden, können Anforderungen an die NSX Advanced Load Balancer-VIP mit der Meldung no route to host
fehlschlagen.
Dies tritt auf, weil der Standardwert der ARP-Ratenbegrenzung für Dienstmodule auf 100 festgelegt ist.
Lösung
Legen Sie für die ARP-Ratenbegrenzung eine höhere Anzahl fest. Dieser Parameter kann in NSX Advanced Load Balancer Essentials nicht geändert werden, in NSX Advanced Load Balancer Enterprise Edition ist dies jedoch möglich.
AKODeploymentConfig
während der Erstellung des VerwaltungsclustersProblem
Beim Ausführen von tanzu management-cluster create
zum Erstellen eines Verwaltungsclusters mit NSX ALB wird der Fehler no matches for kind AKODeploymentConfig in version networking.tkg.tanzu.vmware.com/v1alpha1
ausgegeben.
Lösung
Der Fehler kann ignoriert werden. Weitere Informationen finden Sie in diesem KB-Artikel.
medium
und kleiner mit NSX Advanced Load Balancer fehlProblem
Auf vSphere können Arbeitslastcluster mit Worker-Knoten der Größe medium
oder kleiner, auf denen das Multus-CNI-Paket mit NSX ALB ausgeführt wird, mit dem Fehler Insufficient CPU
oder anderen Fehlern fehlschlagen.
Lösung
Um die Multus-CNI mit NSX ALB zu verwenden, stellen Sie Arbeitslastcluster mit Worker-Knoten der Größe large
oder extra-large
bereit.
Problem
Auf Azure schlägt das Upgrade von Verwaltungsclustern und Arbeitslastclustern mit Fehlern fehl, z. B. context deadline exceeded
oder unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane
. Dies geschieht, weil Vorgänge auf Azure manchmal länger dauern als auf anderen Plattformen.
Lösung
Führen Sie tanzu management-cluster upgrade
oder tanzu cluster upgrade
erneut aus, indem Sie im Flag --timeout
eine längere Zeitüberschreitung angeben. Der Standard-Zeitüberschreitungswert beträgt 30 Minuten, 0 Sekunden.
Problem
In TKG v2.4 werden die Komponenten, die einen generischen Cluster in einen eigenständigen TKG-Verwaltungscluster umwandeln, in einem Carvel-Paket tkg-pkg
gepackt. Bei eigenständigen Verwaltungsclustern, die ursprünglich in TKG v1.3 oder früher erstellt wurden, fehlt ein Konfigurationsschlüssel, den der Upgrade-Vorgang zum Installieren von tkg-pkg
benötigt. Dies führt dazu, dass das Upgrade fehlschlägt.
Lösung
Führen Sie die zusätzlichen Schritte unter Upgrade eigenständiger Verwaltungscluster für eigenständige Verwaltungscluster aus, die in TKG v1.3 oder früher erstellt wurden.