This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Fehlerbehebung bei Problemen mit dem Verwaltungscluster

Mithilfe der Tipps in diesem Thema können Sie Fehler in Bereitstellungen eigenständiger Verwaltungscluster beheben. In einigen der folgenden Verfahren wird die kind-CLI verwendet. Informationen zum Installieren von kind finden Sie unter Installation in der Dokumentation zu kind. Weitere Informationen zur Fehlerbehebung in Arbeitslastclustern finden Sie unter Beheben von Problemen mit Arbeitslastclustern.

Allgemeine Aufgaben

Herstellen einer Verbindung zu Clusterknoten mit SSH

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:

  • vSphere-Verwaltungscluster und Tanzu Kubernetes-Knoten, die sowohl auf Photon OS als auch auf Ubuntu ausgeführt werden: capv
  • AWS-Bastion-Knoten: ubuntu
  • AWS-Verwaltungscluster und Tanzu Kubernetes-Knoten, die unter Ubuntu ausgeführt werden: ubuntu
  • AWS-Verwaltungscluster und Tanzu Kubernetes-Knoten, die unter Amazon Linux ausgeführt werden: ec2-user
  • Azure-Verwaltungscluster und Tanzu Kubernetes-Knoten (immer Ubuntu): 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:

  • vSphere-Knoten: ssh capv@node-address
  • AWS-Bastion-Knoten sowie Verwaltungscluster- und Arbeitslastknoten auf Ubuntu: ssh ubuntu@node-address
  • AWS-Verwaltungscluster und Tanzu Kubernetes-Knoten, die unter Amazon Linux ausgeführt werden: ssh ec2-user@node-address
  • Azure-Knoten: 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.

Löschen von Benutzern, Kontexten und Clustern mit kubectl

So bereinigen Sie den Zustand von kubectl, indem Sie bestimmte oder alle Benutzer, Kontexte und Cluster löschen:

  1. Öffnen Sie die Datei ~/.kube-tkg/config.

  2. 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.

  3. 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.

  4. 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.

  5. 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

  6. Wenn Sie von der tanzu-CLI nachverfolgte Verwaltungscluster gelöscht haben, löschen Sie sie aus dem Status der tanzu-CLI, indem Sie tanzu config server delete ausführen (siehe Beschreibung unter Löschen von Verwaltungsclustern aus der Konfiguration der Tanzu CLI).

Deaktivieren von nfs-utils auf Photon OS-Knoten

Problem

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

Zielplattform

Validierung fehlgeschlagen, Anmeldedatenfehler auf AWS

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.

Fehlgeschlagene Validierung, Fehler bei rechtlichen Bedingungen in Azure

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:

Verwaltungscluster

Durchführen einer Bereinigung nach einer nicht erfolgreichen Verwaltungsclusterbereitstellung

Problem

Aufgrund eines erfolglosen Versuchs, einen eigenständigen Verwaltungscluster bereitzustellen, verbleiben verwaiste Objekte in Ihrer Cloud-Infrastruktur und auf Ihrer Bootstrap-Maschine.

Lösung

  1. Überwachen Sie die 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).
  2. Führen Sie 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:

    • vSphere: Suchen Sie nach den von Tanzu Kubernetes Grid erstellten VMs und anderen Ressourcen, schalten Sie sie aus und löschen Sie sie.
    • AWS: Melden Sie sich bei Ihrem Amazon EC2-Dashboard an und löschen Sie die Ressourcen manuell oder verwenden Sie eine automatisierte Lösung.
    • Azure: Öffnen Sie in Ressourcengruppen (Resource Groups) die 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.

Verwaltungscluster in AWS kann nicht gelöscht werden

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:

  • Der Cluster wird nicht aus der AWS-Infrastruktur gelöscht, und seine Knoten werden weiterhin im Amazon EC2-Dashboard angezeigt
  • In Verwaltungsclusterprotokollen wird der Fehler cluster infrastructure is still being provisioned: VpcReconciliationFailed angezeigt

Lö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.

    • Sie können die Anmeldedaten des AWS-Instanzprofils nicht verwenden, um einen Verwaltungscluster zu löschen.

  • Wiederherstellen (Recover) mithilfe des EC2-Dashboards: Löschen Sie die Knoten des Verwaltungsclusters manuell aus dem EC2-Dashboard

  • Wiederherstellen (Recover) mithilfe der CLI:

    1. 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

    2. 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>

    3. Führen Sie tanzu mc delete erneut aus.

Kind-Cluster bleibt nach dem Löschen des Verwaltungsclusters bestehen

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

  1. 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

  2. Listen Sie alle ausgeführten Cluster auf und geben Sie den kind-Cluster an.

    docker ps -a

  3. Kopieren Sie die Container-ID des kind-Clusters und entfernen Sie sie.

    docker kill container-ID

Maschinen reagieren nicht mehr, nachdem die Bereitstellung des Verwaltungsclusters fehlgeschlagen ist

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.

  1. Rufen Sie den Status des Verwaltungsclusters ab. Beispiel:

    kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml

  2. 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

  3. 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.

  4. Legen Sie kubectl auf den Kontext des Verwaltungsclusters fest. Beispiel:

    kubectl config use-context mgmt-cluster-admin@mgmt-cluster

  5. 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.

  6. Warten Sie, bis der KubeadmControlPlane-Controller die Maschine erneut bereitgestellt hat.

Wiederherstellen des Verzeichnisses ~/.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:

  1. 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.

  2. 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 login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER

Das Ausführen von tanzu management-cluster create auf macOS hat einen kubectl-Versionsfehler zur Folge

Problem

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.24.10

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.

Wiederherstellen der Anmeldedaten des Verwaltungsclusters

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.

  1. Führen Sie tanzu mc create aus, um die Datei .kube-tkg/config neu zu erstellen.
  2. Rufen Sie die öffentliche IP-Adresse des Steuerungsebenenknotens des Verwaltungsclusters aus vSphere, AWS oder Azure ab.

  3. 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.

  4. 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.

  5. Kopieren Sie den Namen und den Benutzernamen des Clusters, den Clusterkontext sowie die Daten für das Clientzertifikat in die Datei .kube-tkg/config auf dem System, auf dem Sie tanzu-Befehle ausführen.

Pinniped

Pinniped-Auftrag schlägt nach der Bereitstellung fehl

Problem

Beim Upgrade auf Tanzu Kubernetes Grid v2.1.1 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.

  1. Löschen Sie den Pinniped-Auftrag nach der Bereitstellung.

    kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job

  2. Warten Sie etwa 5 Minuten, bis kapp-controller den Auftrag nach der Bereitstellung erneut bereitstellt.

  3. Ü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.

  4. Ü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

Pinniped-Authentifizierungsfehler im Arbeitslastcluster nach einem Verwaltungscluster-Upgrade

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:

  1. Legen Sie den kubectl-Kontext auf den Verwaltungscluster fest.

  2. 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

  3. 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.

  4. 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.

  5. 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

  6. Bestätigen Sie im Arbeitslastcluster, dass die Pinniped-App die Änderungen erfolgreich abgeglichen hat:

    kubectl get app pinniped -n tkg-system

  7. Authentifizieren Sie sich beim Cluster. Beispiel:

    kubectl get pods -A --kubeconfig my-cluster-credentials

Pods

Pods verbleiben aufgrund der vCenter-Konnektivität im Cluster mit dem Status „Ausstehend“

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.

Tanzu CLI

Tanzu CLI kann den Verwaltungscluster nicht erreichen

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

Dies ist ein bekanntes Problem, das TKG v1.2 und höher betrifft. Eine Problemumgehung finden Sie unter Aktualisieren des Verwaltungsclusterzertifikats in der Tanzu CLI-Konfiguration und Kein Zugriff auf die Cluster mithilfe der TKG/Tanzu CLI-Befehle in Tanzu Kubernetes Grid.

Benutzeroberfläche des Tanzu Kubernetes Grid-Installationsprogramms

Die Tanzu Kubernetes Grid-Benutzeroberfläche wird unter Windows nicht ordnungsgemäß angezeigt

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

  1. Geben Sie regedit in der Windows-Suche ein, um das Dienstprogramm „Registrierungs-Editor“ zu öffnen.
  2. Erweitern Sie HKEY_CLASSES_ROOT und wählen Sie .js aus.
  3. Klicken Sie mit der rechten Maustaste auf Inhaltstyp (Content Type) und wählen Sie Ändern (Modify) aus.
  4. Legen Sie den Wert auf application/javascript fest und klicken Sie auf OK.
  5. Führen Sie den Befehl tanzu mc create --ui erneut aus, um die Benutzeroberfläche neu zu starten.

NSX Advanced Load Balancer

Anforderungen an die NSX Advanced Load Balancer-VIP schlagen mit der Meldung „Keine Route zum Host (No route to host)“ fehl

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.

check-circle-line exclamation-circle-line close-line
Scroll to top icon