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.
Standard-Logging-Verhalten
Für gkectl
und gkeadm
reicht es aus, die Standard-Logging-Einstellungen zu verwenden:
-
Standardmäßig werden Logeinträge so gespeichert:
-
Für
gkectl
ist die Standard-Logdatei/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
. Die Datei ist per Symlink mit der Dateilogs/gkectl-$(date).log
im lokalen Verzeichnis verknüpft, in dem Siegkectl
ausführen. -
Für
gkeadm
ist die Standard-Logdateilogs/gkeadm-$(date).log
im lokalen Verzeichnis, in dem Siegkeadm
ausführen.
-
Für
- Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn
--alsologtostderr
auffalse
gesetzt ist). - Die Ausführlichkeitsstufe
-v5
(Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden. - Die Logdatei enthält auch den ausgeführten Befehl und die Fehlermeldung.
Wir empfehlen Ihnen, die Logdatei an das Supportteam zu senden, wenn Sie Hilfe benötigen.
Nicht standardmäßigen Speicherort für die Logdatei angeben
Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkectl
angeben möchten, verwenden Sie das Flag --log_file
. Die von Ihnen angegebene Logdatei wird nicht per Symlink mit dem lokalen Verzeichnis verknüpft.
Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkeadm
angeben möchten, verwenden Sie das Flag --log_file
.
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:
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
Ö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 Knotens für die Steuerungsebene des Administratorclusters 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.
Debugging 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]
Administratorworkstation
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 nichtVerified 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.
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 plant 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:
Prüfen Sie den MachineDeployment-Status des Clusters, um festzustellen, ob Ereignisse oder Fehlermeldungen vorliegen:
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
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 es einen Konflikt gibt, müssen Sie den Konflikt in Ihrer Umgebung lösen.
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://
statthttps://
.
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.