Problembehebung

In den folgenden Abschnitten werden mögliche Probleme bei der Verwendung von GKE On-Prem beschrieben. Außerdem erfahren Sie, wie Sie diese beheben können.

Hinweis

Sehen Sie sich die folgenden Abschnitte an, bevor Sie mit der Problembehebung beginnen.

Clusterprobleme mit gkectl diagnostizieren

Verwenden Sie gkectl diagnose-Befehle, um Clusterprobleme zu identifizieren und Clusterinformationen an Google zu senden. Siehe Clusterprobleme diagnostizieren.

gkectl-Befehle umfassend ausführen

-v5

gkectl-Fehler in stderr protokollieren

--alsologtostderr

gkectl-Logs auf der Administratorworkstation suchen

Auch wenn Sie nicht die Debugging-Flags übergeben, können Sie gkectl-Logs im folgenden Verzeichnis der Administrator-Workstation aufrufen:

/home/ubuntu/.config/gke-on-prem/logs

Cluster-API-Logs im Administratorcluster suchen

Wenn eine VM nach dem Start der Administrator-Steuerungsebene nicht gestartet wird, versuchen Sie, dies durch Untersuchen der Logs der Cluster-API-Controller im Administratorcluster zu beheben:

  1. Suchen Sie im Namespace kube-system den Namen des Cluster-API-Controller-Pods, wobei [ADMIN_CLUSTER_KUBECONFIG] der Pfad zur kubeconfig-Datei des Administratorclusters ist:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. Öffnen Sie die Logs des Pods, wobei [POD_NAME] der Name des Pods ist. Sie können auch grep oder ein ähnliches Tool für die Fehlersuche verwenden:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Installation

F5 BIG-IP-Probleme mit der kubeconfig-Datei des Administratorcluster-Knotens für die Steuerungsebene beheben

Nach der Installation generiert GKE On-Prem eine kubeconfig-Datei im Basisverzeichnis Ihrer Administratorworkstation mit dem Namen internal-cluster-kubeconfig-debug. Diese kubeconfig-Datei ist mit der kubeconfig-Datei Ihres Administratorclusters identisch, mit der Ausnahme, dass sie direkt auf den Knoten der Steuerungsebene des Administratorclusters verweist, auf dem die Administratorsteuerungsebene ausgeführt wird. Sie können die Datei internal-cluster-kubeconfig-debug verwenden, um F5 BIG-IP-Probleme zu beheben.

gkectl check-config-Validierung schlägt fehl: F5 BIG-IP-Partitionen können nicht gefunden werden

Symptome

Die Validierung schlägt fehl, weil F5 BIG-IP-Partitionen nicht gefunden werden können, obwohl sie vorhanden sind.

Mögliche Ursachen

Ein Problem mit der F5 BIG-IP API kann dazu führen, dass die Validierung fehlschlägt.

Lösung

Versuchen Sie, gkectl check-config noch einmal auszuführen.

gkectl prepare --validate-attestations schlägt fehl: Build-Attestierung konnte nicht validiert werden

Symptome

Die Ausführung von gkectl prepare mit dem optionalen Flag --validate-attestations gibt den folgenden Fehler zurück:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
Mögliche Ursachen

Für die betroffenen Images ist möglicherweise keine Attestierung vorhanden.

Lösung

Versuchen Sie, die OVA der Administratorworkstation noch einmal herunterzuladen und bereitzustellen, wie in Administrator-Workstation erstellen beschrieben. Wenn das Problem weiterhin besteht, wenden Sie sich an Google.

Fehlerbehebung mit den Logs des Bootstrap-Clusters

Während der Installation erstellt GKE On-Prem einen temporären Bootstrap-Cluster. Nach einer erfolgreichen Installation löscht GKE On-Prem den Bootstrap-Cluster, sodass Sie Ihren Administratorcluster und Ihren Nutzercluster erhalten. Normalerweise sollten Sie keinen Grund haben, mit diesem Cluster zu interagieren.

Wenn während einer Installation ein Fehler auftritt und Sie --cleanup-external-cluster=false an gkectl create cluster übergeben haben, ist es möglicherweise hilfreich, das Debugging mit den Logs des Bootstrap-Clusters durchzuführen. Sie können nach dem Pod suchen und seine Logs abrufen:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Authentifizierungs-Plug-in für Anthos

Fehler beim Ausführen von gkectl create-login-config

Problem 1:

Symptome

Beim Ausführen von gkectl create-login-config tritt der folgende Fehler auf:

Error getting clientconfig using [user_cluster_kubeconfig]
Mögliche Ursachen

Dieser Fehler bedeutet, dass die an gkectl create-login-config übergebene kubeconfig-Datei nicht für einen Nutzercluster verwendet wird oder die ClientConfig-CRD beim Erstellen des Clusters nicht vorgekommen ist.

Lösung

Führen Sie den folgenden Befehl aus, um zu prüfen, ob sich die ClientConfig-CRD im Cluster befindet:

$ kubectl --kubeconfig
  [user_cluster_kubeconfig] get clientconfig default -n kube-public

Problem 2:

Symptome

Beim Ausführen von gkectl create-login-config tritt der folgende Fehler auf:

error merging with file [merge_file] because [merge_file] contains a
  cluster with the same name as the one read from [kubeconfig]. Please write to
  a new output file
Mögliche Ursachen

Jede Anmeldekonfigurationsdatei muss eindeutige Clusternamen enthalten. Wenn dieser Fehler angezeigt wird, enthält die Datei, in die Sie Anmeldekonfigurationsdaten schreiben, einen Clusternamen, der bereits in der Zieldatei vorhanden ist.

Lösung

Schreiben Sie in eine neue --output-Datei. Wichtige Hinweise:

  • Wenn --output nicht angegeben ist, werden die Anmeldekonfigurationsdaten standardmäßig in eine Datei namens kubectl-anthos-config.yaml im aktuellen Verzeichnis geschrieben.
  • Wenn --output bereits vorhanden ist, versucht der Befehl, die neue Anmeldekonfiguration mit --output zusammenzuführen.

Fehler beim Ausführen von gcloud anthos auth login

Problem 1:

Symptome

Die Ausführung von login mit dem Plug-in für die Authentifizierung und der generierten YAML-Datei für die Anmeldekonfiguration schlägt fehl.

Mögliche Ursachen

Die OIDC-Konfigurationsdetails sind möglicherweise fehlerhaft.

Lösung

Prüfen Sie die Registrierung des OIDC-Clients bei Ihrem Administrator.

Problem 2:

Symptome

Wenn ein Proxy für HTTPS-Traffic konfiguriert ist, schlägt die Ausführung des Befehls gcloud anthos auth login fehl. In der Fehlermeldung wird proxyconnect tcp angegeben. Die Meldung kann beispielsweise so aussehen: proxyconnect tcp: tls: first record does not look like a TLS handshake

Mögliche Ursachen

Die Konfiguration der Umgebungsvariablen https_proxy oder HTTPS_PROXY kann einen Fehler enthalten. Wenn in den Umgebungsvariablen https:// angegeben ist, können die GoLang-HTTP-Clientbibliotheken fehlschlagen, wenn der Proxy für die Verarbeitung von HTTPS-Verbindungen mit anderen Protokollen konfiguriert wird, wie etwa SOCK5.

Lösung

Lassen Sie bei den Umgebungsvariablen https_proxy und HTTPS_PROXY das Präfix https:// weg. Wenn Sie Windows verwenden, ändern Sie die Systemumgebungsvariablen. Ändern Sie beispielsweise den Wert der Umgebungsvariablen https_proxy von https://webproxy.example.com:8000 in webproxy.example.com:8000.

Fehler bei Verwendung der mit gcloud anthos auth login generierten kubeconfig-Datei, um auf den Cluster zuzugreifen

Symptome

Fehler: "Unauthorized"

Wenn bei Verwendung der mit gcloud anthos auth login generierten kubeconfig-Datei der Zugriff auf den Cluster mit dem Fehler "Unauthorized" auftritt, kann der API-Server den Nutzer nicht autorisieren.

Mögliche Ursachen
Entweder fehlen die entsprechenden RBACs oder sie sind fehlerhaft oder in der OIDC-Konfiguration für den Cluster ist ein Fehler aufgetreten.
Lösung
Versuchen Sie Folgendes, um das Problem zu beheben:

  1. Parsen Sie das id-token aus der kubeconfig-Datei.

    Kopieren Sie in der mit dem Anmeldebefehl generierten kubeconfig-Datei das id-token:

    kind: Config
…
users:
- name: …
  user:
    auth-provider:
      config:
        id-token: [id-token]
        …

    Führen Sie die folgenden Schritte aus, um jwt-cli zu installieren und auszuführen:

    $ jwt [id-token]

  2. OIDC-Konfiguration prüfen

    Der in config.yaml ausgefüllte Abschnitt oidc, der zum Erstellen des Clusters verwendet wurde, enthält die Felder group und username, die zum Festlegen der Flags --oidc-group-claim und --oidc-username-claim im API-Server verwendet wurden. Nach Erhalt des Tokens sucht der API-Server nach diesem group-claim und username-claim und prüft, ob die entsprechende Gruppe oder der entsprechende Nutzer über die richtigen Berechtigungen verfügt.

    Prüfen Sie, ob die für group und user im Abschnitt oidc von config.yaml festgelegten Anforderungen im id-token vorhanden sind.

  3. Prüfen Sie die angewendeten RBACs.

    Prüfen Sie, ob es einen RBAC mit den richtigen Berechtigungen für den Nutzer gibt, der durch den username-claim oder eine der im vorherigen Schritt unter group-claim aufgeführten Gruppen angegeben wurde. Der Name des Nutzers oder der Gruppe in der RBAC sollte das Präfix usernameprefix oder groupprefix erhalten, das im Abschnitt oidc von config.yaml angegeben wurde.

    Wenn usernameprefix leer gelassen wurde und username ein anderer Wert als email ist, wird das Präfix standardmäßig auf issuerurl# gesetzt. Zum Deaktivieren von Nutzernamenpräfixen muss usernameprefix auf - gesetzt werden.

    Weitere Informationen zu Nutzer- und Gruppenpräfixen finden Sie hier.

    Der Kubernetes API-Server behandelt derzeit einen umgekehrten Schrägstrich als Escape-Zeichen. Wenn der Name des Nutzers oder der Gruppe \\ enthält, liest der API-Server diese daher beim Parsen von id_token als einzelne \. Daher sollte der für diesen Nutzer oder diese Gruppe angewendete RBAC nur einen umgekehrten Schrägstrich enthalten, da andernfalls der Fehler Unauthorized angezeigt wird.

    Beispiel:

    config.yaml:

    oidc:
    issuerurl:
    …
    username: "unique_name"
    usernameprefix: "-"
    group: "group"
    groupprefix: "oidc:"
    ...

    id_token: 

    {
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\\developers"
],
  ...
}

    Die folgenden RBACs gewähren diesem Nutzer Clusteradministrator-Berechtigungen. Im Namensfeld ist statt eines doppelten Schrägstrichs ein einzelner Schrägstrich angegeben:

    Group RBAC:

    apiVersion:
kind:
metadata:
   name: example-binding
subjects:
-  kind: Group
   name: "oidc:EXAMPLE\developers"
   apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io

    User RBAC:

    apiVersion:
kind:
metadata:
   name: example-binding
subjects:
-  kind: User
               name: "EXAMPLE\cluster-developer"
               apiGroup: rbac.authorization.k8s.io
           roleRef:
           kind: ClusterRole
               name: pod-reader
               apiGroup: rbac.authorization.k8s.io

  4. API Server-Logs prüfen

    Wenn das im API-Server von Kube konfigurierte OIDC-Plug-in nicht korrekt gestartet wird, gibt der API-Server bei Erhalt des id-token den Fehler "Unauthorized" zurück. Prüfen Sie mit dem folgenden Befehl, ob Probleme mit dem OIDC-Plug-in auf dem API-Server aufgetreten sind: 

    $ kubectl
      --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n
      [user_cluster_name]
Symptome

Keine Verbindung zum Server möglich. Die Fehlermeldung lautet: Get {DISCOVERY_ENDPOINT}: x509: certificate signed by unknown authority

Mögliche Ursachen

Das Aktualisierungstoken in der kubeconfig-Datei ist abgelaufen.

Lösung

Führen Sie den Befehl login noch einmal aus.

Anmeldung in der Google Cloud Console

Die folgenden Probleme treten häufig auf, wenn Sie sich mit der Google Cloud Console anmelden:

Anmeldung führt zur Seite mit dem Fehler "URL nicht gefunden"

Symptome

Die Google Cloud Console kann den GKE On-Prem-Identitätsanbieter nicht erreichen.

Mögliche Ursachen

Die Google Cloud Console kann den GKE On-Prem-Identitätsanbieter nicht erreichen.

Lösung

Versuchen Sie, das Problem mit den folgenden Schritten zu beheben:

  1. Setzen Sie useHTTPProxy auf true.

    Wenn der IdP nicht über das öffentliche Internet erreichbar ist, müssen Sie den OIDC-HTTP-Proxy aktivieren, um sich über die Google Cloud Console anzumelden. Im Abschnitt oidc von config.yaml sollte usehttpproxy auf true gesetzt werden. Wenn Sie bereits einen Cluster erstellt haben und den Proxy aktivieren möchten, können Sie die ClientConfig-CRD direkt bearbeiten. Führen Sie $ kubectl edit clientconfig default -n kube-public aus und ändern Sie useHTTPProxy in true.

  2. useHTTPProxy ist bereits auf true festgelegt.

    Wenn der HTTP-Proxy aktiviert ist und dieser Fehler weiterhin angezeigt wird, ist möglicherweise ein Problem beim Start des Proxys aufgetreten. Führen Sie $ kubectl logs deployment/clientconfig-operator -n kube-system aus, um die Logs des Proxys abzurufen. Selbst wenn Ihr IdP eine bekannte Zertifizierungsstelle hat, muss das Feld capath im Abschnitt oidc von config.yaml angegeben werden, damit der HTTP-Proxy gestartet wird.

  3. IDP fordert Ihre Einwilligung an.

    Wenn der Autorisierungsserver um Ihre Einwilligung bittet und Sie den zusätzlichen Parameter prompt=consent nicht hinzugefügt haben, wird möglicherweise diese Fehlermeldung angezeigt. Führen Sie $ kubectl edit clientconfig default -n kube-public aus, fügen Sie prompt=consent zu extraparams hinzu und versuchen Sie noch einmal, sich anzumelden.

  4. RBACs sind falsch konfiguriert.

    Falls noch nicht geschehen, versuchen Sie, sich mit dem Authentifizierungs-Plug-in für Anthos zu authentifizieren. Wenn auch bei der Anmeldung mit dem Plug-in ein Autorisierungsfehler angezeigt wird, befolgen Sie die Schritte zur Fehlerbehebung. Melden Sie sich dann noch einmal über die Google Cloud Console an.

  5. Melden Sie sich ab und wieder an.

    In einigen Fällen müssen Sie sich möglicherweise explizit abmelden, wenn Sie Einstellungen für den Speicherdienst ändern. Rufen Sie die Seite mit den Clusterdetails auf, melden Sie sich ab und versuchen Sie noch einmal, sich anzumelden.

Administratorworkstation

AccessDeniedException beim Herunterladen von OVA

Symptome

Beim Versuch, die OVA-Datei für die Administrator-Workstation und die Signatur herunterzuladen, wird folgender Fehler zurückgegeben:

AccessDeniedException: 403 whitelisted-service-account@project.iam.gserviceaccount.com does not have storage.objects.list access to gke-on-prem-release
Mögliche Ursache

Ihr Dienstkonto auf der Zulassungsliste ist nicht aktiviert.

Lösung

Aktivieren Sie Ihr Dienstkonto auf der Zulassungsliste. Wenn das Problem weiterhin besteht, wenden Sie sich an Google.

openssl kann die OVA-Datei für die Administrator-Workstation nicht validieren

Symptome

Wenn Sie openssl dgst für die OVA-Datei für die Administrator-Workstation ausführen, wird nicht Verified OK zurückgegeben.

Mögliche Ursache

Die OVA-Datei enthält ein Problem, das die erfolgreiche Validierung verhindert.

Lösung

Versuchen Sie, die OVA-Datei der Administrator-Workstation noch einmal herunterzuladen und bereitzustellen, wie unter OVA-Datei der Administrator-Workstation herunterladen beschrieben. Wenn das Problem weiterhin besteht, wenden Sie sich an Google.

Verbinden

Nutzercluster kann nicht registriert werden

Sollten bei der Registrierung von Nutzerclustern Probleme auftreten, wenden Sie sich an Google.

Registrierung eines während der Alpha-Phase erstellten Clusters wurde aufgehoben

Weitere Informationen finden Sie in der Connect-Dokumentation.

Sie können den Cluster auch löschen und neu erstellen.

Speicher

Volume kann nicht angehängt werden

Symptome

Die Ausgabe von gkectl diagnose cluster sieht so aus:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

Mindestens ein Pod hängt im Status ContainerCreating mit einer Warnung wie der folgenden fest:

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

Mögliche Ursachen

Wenn ein virtuelles Laufwerk mit der falschen virtuellen Maschine verbunden ist, kann dies an Problem 32727 in Kubernetes 1.12 liegen.

Lösung

Wenn ein virtuelles Laufwerk mit der falschen virtuellen Maschine verbunden ist, müssen Sie es möglicherweise manuell lösen:

  1. Leeren Sie den Knoten. Weitere Informationen finden Sie in der Anleitung zum sicheren Leeren von Knoten. Sie können die Flags --ignore-daemonsets und --delete-local-data in den Befehl kubectl drain einbinden.
  2. Schalten Sie die VM aus.
  3. Entfernen Sie das Volume, indem Sie die VM-Hardwarekonfiguration in vCenter entsprechend bearbeiten.
  4. Schalten Sie die VM ein.
  5. Trennen Sie die Knotenverbindung.

Das Volume geht verloren

Symptome

Die Ausgabe von gkectl diagnose cluster sieht so aus:

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

Mindestens ein Pod hängt im Status ContainerCreating mit einer Warnung wie der folgenden fest:

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

Mögliche Ursachen

Wenn der Fehler "not found" für Ihre VMDK-Datei angezeigt wird, wurde das virtuelle Laufwerk wahrscheinlich endgültig gelöscht. Dies kann passieren, wenn ein Operator ein virtuelles Laufwerk oder die zugehörige virtuelle Maschine manuell löscht. Um dies zu verhindern, verwalten Sie Ihre virtuellen Maschinen wie in den Artikeln zur Größenänderung von Nutzerclustern und zum Aktualisieren von GKE On-Prem beschrieben.

Lösung

Wenn ein virtuelles Laufwerk endgültig gelöscht wurde, müssen Sie möglicherweise zugehörige Kubernetes-Ressourcen manuell bereinigen:

  1. Löschen Sie mit dem Befehl kubectl delete pvc [PVC_NAME]. den PVC, der auf den PV verwiesen hat.
  2. Löschen Sie durch Ausführen von kubectl delete pod [POD_NAME]. den Pod, der auf den PVC verwiesen hat.
  3. Wiederholen Sie Schritt 2. (Ja, wirklich. Siehe Kubernetes-Problem 74374.)

Upgrades

Informationen zu Ausfallzeiten bei Upgrades

Ressource Beschreibung
Administratorcluster

Wenn ein Administratorcluster ausfällt, werden die Steuerungsebenen und Arbeitslasten von Nutzerclustern weiterhin ausgeführt, es sei denn, sie sind von einem Fehler betroffen, der die Ausfallzeit verursacht hat.
Steuerungsebene der Nutzercluster

Normalerweise sollten Sie keine nennenswerten Ausfallzeiten für Nutzercluster-Steuerungsebenen erwarten. Lang andauernde Verbindungen zum Kubernetes API-Server können jedoch unterbrochen werden und müssen neu hergestellt werden. In diesen Situationen sollte der API-Aufrufer noch einmal versuchen, eine Verbindung herzustellen. Im schlimmsten Fall kann es während eines Upgrades bis zu einer Minute dauern.
Nutzerclusterknoten

Wenn ein Upgrade eine Änderung an Nutzerclusterknoten erfordert, erstellt GKE On-Prem die Knoten rollierend neu und verschiebt die auf diesen Knoten ausgeführten Pods neu. Sie können Auswirkungen auf Ihre Arbeitslasten verhindern, wenn Sie die entsprechenden PodDisruptionBudgets und Anti-Affinitätsregeln konfigurieren.

Größe von Nutzerclustern anpassen

Das Anpassen der Größe eines Nutzerclusters schlägt fehl

Symptome

Ein Vorgang zum Anpassen der Größe eines Nutzerclusters schlägt fehl.

Mögliche Ursachen

Mehrere Faktoren können dazu führen, dass die Größenanpassung fehlschlägt.

Lösung

Wenn die Größenanpassung fehlschlägt, führen Sie die folgenden Schritte aus:

  1. Prüfen Sie den MachineDeployment-Status des Clusters, um festzustellen, ob Ereignisse oder Fehlermeldungen vorliegen:

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

  2. Prüfen Sie, ob auf den neu erstellten Maschinen Fehler vorliegen:

    kubectl describe machine [MACHINE_NAME]

Fehler: "no addresses can be allocated"

Symptome

Nach der Anpassung der Größe eines Nutzerclusters zeigt kubectl describe machine [MACHINE_NAME] den folgenden Fehler an:

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
Mögliche Ursachen

Für den Nutzercluster sind nicht genügend IP-Adressen verfügbar.

Lösung

Weisen Sie weitere IP-Adressen für den Cluster zu. Löschen Sie dann die betroffene Maschine:

kubectl delete machine [MACHINE_NAME]

Wenn der Cluster richtig konfiguriert ist, wird eine Ersatzmaschine mit einer IP-Adresse erstellt.

Ausreichende Anzahl von zugewiesenen IP-Adressen, aber Maschine kann sich nicht beim Cluster registrieren

Symptome

Dem Netzwerk wurden genügend Adressen zugewiesen, aber die Maschine kann sich trotzdem nicht beim Nutzercluster registrieren.

Mögliche Ursachen:

Möglicherweise liegt ein IP-Adresskonflikt vor. Die IP-Adresse wird eventuell bereits von einer anderen Maschine oder Ihrem Load-Balancer verwendet.

Lösung

Prüfen Sie, ob die IP-Adresse der betroffenen Maschine nicht schon verwendet wird. Wenn eine Konflikt vorliegt, müssen Sie diesen in Ihrer Umgebung lösen.

vSphere

Fehlerbehebung mit govc

Wenn Sie Probleme mit vSphere haben, können Sie govc zur Fehlerbehebung verwenden. Sie können beispielsweise ganz einfach die Berechtigungen und den Zugriff für Ihre vCenter-Nutzerkonten bestätigen und vSphere-Logs erfassen.

vCenter-Zertifikat ändern

Wenn Sie einen vCenter-Server im Auswertungs- oder Standardeinrichtungsmodus ausführen und über ein generiertes TLS-Zertifikat verfügt, kann sich dieses Zertifikat im Laufe der Zeit ändern. Wenn sich das Zertifikat geändert hat, müssen Sie die ausgeführten Cluster über das neue Zertifikat informieren:

  1. Rufen Sie das neue vCenter-Zertifikat ab und speichern Sie es in einer Datei:

    true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

  2. Löschen Sie nun für jeden Cluster die ConfigMap, die das vSphere- und vCenter-Zertifikat für jeden Cluster enthält, und erstellen Sie eine neue ConfigMap mit dem neuen Zertifikat. Beispiel:

    kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
    kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
    kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -
    kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

  3. Löschen Sie den clusterapi-controllers-Pod für jeden Cluster. Wenn der Pod neu gestartet wird, verwendet er das neue Zertifikat. Beispiel:

    kubectl --kubeconfig kubeconfig -n kube-system get pods
    kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...

Sonstiges

Sitzungslimit für Terraform vSphere-Anbieter

GKE On-Prem verwendet den vSphere-Anbieter von Terraform, um VMs in Ihrer vSphere-Umgebung zu aktivieren. Das Sitzungslimit des Anbieters beträgt 1.000 Sitzungen. Die aktuelle Implementierung schließt aktive Sitzungen nach der Verwendung nicht. Wenn zu viele Sitzungen ausgeführt werden, können Fehler vom Typ 503 auftreten.

Sitzungen werden nach 300 Sekunden automatisch beendet.

Symptome

Wenn zu viele Sitzungen ausgeführt werden, kann der folgende Fehler auftreten:

Error connecting to CIS REST endpoint: Login failed: body:
  {"type":"com.vmware.vapi.std.errors.service_unavailable","value":
  {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is
  limited to 1000. Existing sessions are 1000.",
  "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}},
  status: 503 Service Unavailable
Mögliche Ursachen

In Ihrer Umgebung werden zu viele Terraform-Anbietersitzungen ausgeführt.

Lösung

Derzeit funktioniert dies wie vorgesehen. Sitzungen werden nach 300 Sekunden automatisch beendet. Weitere Informationen finden Sie im Artikel zum GitHub-Problem 618.

Für Docker wird ein Proxy verwendet: oauth2: cannot fetch token

Symptome

Bei der Verwendung eines Proxys tritt der folgende Fehler auf:

oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
Mögliche Ursachen

Möglicherweise haben Sie statt eines HTTP-Proxys einen HTTPS-Proxy angegeben.

Lösung

Ändern Sie in der Docker-Konfiguration die Proxyadresse in http:// statt https://.

Gültigkeit der Lizenzen prüfen

Achten Sie darauf, dass Ihre Lizenzen gültig sind, insbesondere, wenn Sie Testlizenzen verwenden. Wenn Ihre F5-, ESXi-Host- oder vCenter-Lizenzen abgelaufen sind, können unerwartete Fehler auftreten.