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 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
gcloud anthos auth
-Befehlszeile auf dem neuesten Stand halten
Viele häufige Probleme lassen sich vermeiden, indem Sie überprüfen, ob die Komponenten Ihrer gcloud anthos auth
-Installation mit den Korrekturen aus dem neuesten Versionsrelease auf dem neuesten Stand sind.
Zwei Komponenten müssen überprüft werden, da der gcloud anthos auth
-Befehl Logik in der gcloud
-Kernkomponente und eine separate verpackte anthos-auth
-Komponente enthält.
-
Die
gcloud
-Kernkomponente.-
Führen Sie zum Aktualisieren der
gcloud
-Kernkomponente Folgendes aus:gcloud components update
-
Prüfen Sie, ob die Installation von
gcloud
veraltet ist. Führen Sie dazu den folgenden Befehl aus und überprüfen Sie, ob das gedruckte Datum innerhalb der letzten 12 Tage liegt.gcloud version
-
-
Die
anthos-auth
-Komponente :-
Führen Sie zum Aktualisieren der
anthos-auth
-Komponente Folgendes aus:gcloud components install anthos-auth
-
Prüfen Sie, ob die Installation von
anthos-auth
veraltet ist. Führen Sie dazu den folgenden Befehl aus und überprüfen Sie, ob es sich um Version v1.1.3 oder höher handelt.gcloud anthos auth version
-
apt-get
Installationen von gcloud
Wenn Sie prüfen möchten, ob die Installation von gcloud
über apt-get
verwaltet wird, führen Sie den Befehl gcloud
components update
aus und suchen Sie nach einem Fehler.
$ gcloud components update ERROR: (gcloud.components.update) You cannot perform this action because the gcloud CLI component manager is disabled for this installation. You can run the following command to achieve the same result for this installation: ...
Problem: Sie können diese Aktion nicht ausgeführen, da der gcloud CLI-Komponentenmanager für diese Installation deaktiviert ist:
Bei Installationen, die über apt-get
verwaltet werden, funktioniert das Ausführen der oben genannten gcloud components
-Befehle nicht direkt. Sie erhalten dann eine Fehlermeldung, die der oben gezeigten ähnelt. Wenn Sie jedoch die Befehle gcloud components update
und gcloud components install anthos-auth
ausführen, werden die spezifischen apt-get
-Befehle ausgegeben, die Sie zum Aktualisieren der Installation ausführen können.
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 namenskubectl-anthos-config.yaml
im aktuellen Verzeichnis geschrieben. - Wenn
--output
bereits vorhanden ist, versucht der Befehl, die neue Anmeldekonfiguration mit--output
zusammenzuführen.
- Wenn
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 wirdproxyconnect 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
oderHTTPS_PROXY
kann einen Fehler enthalten. Wenn in den Umgebungsvariablenhttps://
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
undHTTPS_PROXY
das Präfixhttps://
weg. Wenn Sie Windows verwenden, ändern Sie die Systemumgebungsvariablen. Ändern Sie beispielsweise den Wert der Umgebungsvariablenhttps_proxy
vonhttps://webproxy.example.com:8000
inwebproxy.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:
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]
OIDC-Konfiguration prüfen
Der in
config.yaml
ausgefüllte Abschnittoidc
, der zum Erstellen des Clusters verwendet wurde, enthält die Feldergroup
undusername
, 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
unduser
im Abschnittoidc
vonconfig.yaml
festgelegten Anforderungen imid-token
vorhanden sind.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
odergroupprefix
erhalten, das im Abschnittoidc
vonconfig.yaml
angegeben wurde.Wenn
usernameprefix
leer gelassen wurde undusername
ein anderer Wert alsemail
ist, wird das Präfix standardmäßig aufissuerurl#
gesetzt. Zum Deaktivieren von Nutzernamenpräfixen mussusernameprefix
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 vonid_token
als einzelne\
. Daher sollte der für diesen Nutzer oder diese Gruppe angewendete RBAC nur einen umgekehrten Schrägstrich enthalten, da andernfalls der FehlerUnauthorized
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
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:
-
Setzen Sie
useHTTPProxy
auftrue
.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
vonconfig.yaml
sollteusehttpproxy
auftrue
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 SieuseHTTPProxy
intrue
. useHTTPProxy
ist bereits auftrue
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 Feldcapath
im Abschnittoidc
vonconfig.yaml
angegeben werden, damit der HTTP-Proxy gestartet wird.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 Sieprompt=consent
zuextraparams
hinzu und versuchen Sie noch einmal, sich anzumelden.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.
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
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.
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:
- 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 Befehlkubectl drain
einbinden. - Schalten Sie die VM aus.
- Entfernen Sie das Volume, indem Sie die VM-Hardwarekonfiguration in vCenter entsprechend bearbeiten.
- Schalten Sie die VM ein.
- 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:
- Löschen Sie mit dem Befehl
kubectl delete pvc [PVC_NAME].
den PVC, der auf den PV verwiesen hat. - Löschen Sie durch Ausführen von
kubectl delete pod [POD_NAME].
den Pod, der auf den PVC verwiesen hat. - Wiederholen Sie Schritt 2. (Ja, wirklich. Siehe Kubernetes-Problem 74374.)
vSphere-CSI-Volume kann nicht getrennt werden
Symptome
Wenn Pods in der
ContainerCreating
-Phase mitFailedAttachVolume
-Warnungen hängen, kann dies auf eine fehlgeschlagene Trennung auf einem anderen Knoten zurückzuführen sein.Führen Sie den folgenden Befehl aus, um CSI-Trennfehler zu ermitteln:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
Die Ausgabe sollte so aussehen:
NAME DETACH_ERROR csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8 Mögliche Ursachen
Die Berechtigung
CNS > Searchable
wurde dem vSphere-Nutzer nicht gewährt.Lösung
Fügen Sie Ihrem vCenter-Nutzerkonto die Berechtigung
CNS > Searchable
hinzu. Der Trennvorgang wird automatisch wiederholt, bis er erfolgreich ist.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.
Möglicherweise müssen die Zertifikate vor einem Upgrade des Administratorclusters verlängert werden
Bevor Sie mit dem Upgrade des Administratorclusters beginnen, sollten Sie prüfen, ob die Zertifikate des Administratorclusters derzeit gültig sind, und sie verlängern, falls nicht.
Verlängerungsprozess des Administratorclusterzertifikats
Prüfen Sie zuerst, ob OpenSSL auf der Administrator-Workstation installiert ist, bevor Sie beginnen.
Legen Sie die Variable
KUBECONFIG
fest.KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Ersetzen Sie ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG durch den absoluten Pfad zur kubeconfig-Datei des Administratorclusters.
Rufen Sie die IP-Adresse und die SSH-Schlüssel für den Administrator-Masterknoten ab:
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')
Prüfen Sie, ob die Zertifikate abgelaufen sind:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"
Wenn die Zertifikate abgelaufen sind, müssen Sie sie vor dem Upgrade des Administratorclusters verlängern.
Sichern Sie alte Zertifikate:
Dieser Schritt ist optional, wird jedoch empfohlen.
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
Verlängern Sie die Zertifikate mit kubeadm:
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all
Starten Sie den Administrator-Masterknoten neu:
# on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout
Da die kubeconfig-Datei des Administratorclusters auch abläuft, wenn die Administratorzertifikate ablaufen, sollten Sie diese Datei vor Ablauf sichern.
Sichern Sie die kubeconfig-Datei des Administratorclusters:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"Ersetzen Sie
client-certificate-data
undclient-key-data
in kubeconfig durchclient-certificate-data
undclient-key-data
in der von Ihnen erstellten Dateinew_admin.conf
.
Sie müssen die erneuerten Zertifikate und das Zertifikat von kube-apiserver validieren.
Prüfen Sie den Ablauf der Zertifikate:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"Prüfen Sie das Zertifikat von kube-apiserver:
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
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 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:
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
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 -
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://
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.
-