Auf dieser Seite werden alle bekannten Probleme bei Google Distributed Cloud Virtual for Bare Metal aufgeführt. Filtern Sie die bekannten Probleme nach Produktversion oder Kategorie, indem Sie die entsprechenden Filter aus den folgenden Drop-down-Menüs auswählen.
Wählen Sie Ihre GDCV für Bare-Metal-Version aus:
Wählen Sie die Problemkategorie aus:
Sie können auch nach Ihrem Problem suchen:
Kategorie
Erkannte Version(en)
Problem und Problemumgehung
Zurücksetzen/Löschen
1.29.0
Beim Zurücksetzen des Nutzerclusters konnte kein Namespace gelöscht werden
Wenn bmctl reset cluster -c ${USER_CLUSTER} ausgeführt wird und alle zugehörigen Jobs abgeschlossen sind, kann der Nutzercluster-Namespace mit dem Befehl nicht gelöscht werden. Der Nutzercluster-Namespace bleibt im Status Terminating hängen. Irgendwann wird beim Zurücksetzen des Clusters eine Zeitüberschreitung ausgegeben und ein Fehler zurückgegeben.
Workaround:
Führen Sie die folgenden Schritte aus, um den Namespace zu entfernen und das Zurücksetzen des Nutzerclusters abzuschließen:
Löschen Sie den Pod metrics-server aus dem Administratorcluster:
Nachdem der Finalierer entfernt wurde, wird der Cluster-Namespace entfernt und der Cluster wurde zurückgesetzt.
Konfiguration, Installation, Sicherheit
1.16.0 bis 1.16.7 und 1.28.0 bis 1.28.400
Im Deployment zur Binärautorisierung fehlt ein nodeSelector
Wenn Sie die Binärautorisierung für GKE on Bare Metal aktiviert haben und eine Version von 1.16.0 bis 1.16.7 oder 1.28.0 bis 1.28.400 verwenden, tritt möglicherweise ein Problem mit der Planung der Pods für das Feature auf. In diesen Versionen fehlt dem Deployment zur Binärautorisierung ein nodeSelector. Daher können die Pods für das Feature auf Worker-Knoten anstelle von Knoten der Steuerungsebene geplant werden. Dieses Verhalten verursacht zwar keinen Fehler, ist aber nicht beabsichtigt.
Workaround:
Führen Sie für alle betroffenen Cluster die folgenden Schritte aus:
Öffnen Sie die Deployment-Datei für die Binärautorisierung:
Nachdem die Änderung gespeichert wurde, werden die Pods nur noch auf den Knoten der Steuerungsebene noch einmal bereitgestellt. Diese Korrektur muss nach jedem Upgrade durchgeführt werden.
Upgrades und Updates
1.28.0, 1.28.100, 1.28.200, 1.28.300
Fehler beim Upgrade eines Clusters auf 1.28.0-1.28.300
Ein Upgrade von Clustern, die vor der Version 1.11.0 auf die Versionen 1.28.0 bis 1.28.300 erstellt wurden, kann dazu führen, dass der Pod zum Bereitstellen des Lebenszyklus-Controllers während des Upgrades in einen Fehlerstatus wechselt. In diesem Fall erhalten die Logs des Lebenszyklus-Controller-Bereitsteller-Pods eine Fehlermeldung wie diese:
"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions
Workaround:
Dieses Problem wurde in Version 1.28.400 behoben. Führen Sie ein Upgrade auf Version 1.28.400 oder höher durch, um das Problem zu beheben.
Wenn Sie kein Upgrade durchführen können, führen Sie die folgenden Befehle aus, um das Problem zu beheben:
Manchmal werden Cluster- oder Containerlogs mit einer anderen Projekt-ID in resource.labels.project_id im Log-Explorer getaggt.
Dies kann passieren, wenn der Cluster für die Verwendung des PROJECT_ONE für die Beobachtbarkeit konfiguriert ist, der in der Clusterkonfiguration im Feld clusterOperations.projectID festgelegt ist.
Das cloudOperationsServiceAccountKeyPath in der Konfiguration enthält jedoch einen Dienstkontoschlüssel aus dem Projekt PROJECT_TWO.
In solchen Fällen werden alle Logs an PROJECT_ONE weitergeleitet, resource.labels.project_id wird jedoch als PROJECT_TWO gekennzeichnet.
Workaround:
Verwenden Sie eine der folgenden Optionen, um das Problem zu beheben:
Verwenden Sie ein Dienstkonto aus demselben Zielprojekt.
Ändern Sie project_id in der JSON-Datei des Dienstkontoschlüssels in das aktuelle Projekt.
Ändern Sie project_id direkt im Logfilter aus dem Log-Explorer.
Netzwerk
1.29.0
Leistungsverschlechterung bei Clustern, die gebündeltes Load-Balancing mit BGP verwenden
Bei Clustern der Version 1.29.0, die gebündeltes Load-Balancing mit BGP verwenden, kann die Leistung des Load-Balancings sinken, wenn die Gesamtzahl der Dienste vom Typ LoadBalancer 2.000 erreicht. Wenn die Leistung abnimmt, dauert die Verbindung mit neu erstellten Diensten entweder sehr lange oder kann von einem Client nicht erreicht werden. Vorhandene Dienste funktionieren weiterhin, können jedoch Fehlermodi wie den Verlust eines Load-Balancer-Knotens nicht effektiv handhaben. Diese Dienstprobleme treten auf, wenn das ang-controller-manager-Deployment aufgrund von zu wenig Arbeitsspeicher beendet wird.
Wenn Ihr Cluster von diesem Problem betroffen ist, sind die Dienste im Cluster nicht erreichbar und nicht fehlerfrei und das ang-controller-manager-Deployment befindet sich in einer CrashLoopBackOff. Die Antwort beim Auflisten der ang-controller-manager-Deployments sieht in etwa so aus:
Als Behelfslösung können Sie das Limit für Arbeitsspeicherressourcen des Deployments ang-controller-manager um 100 MiB erhöhen und das CPU-Limit entfernen:
NAME CPU_LIMITS MEMORY_LIMITS
ang-controller-manager <none> 400Mi
Installation, Upgrades, Sicherung und Wiederherstellung
1.28.0, 1.28.100
Verbindungsprobleme am Container Registry-Endpunkt gcr.io können Clustervorgänge blockieren
Durch mehrere Clustervorgänge für Administratorcluster wird ein Bootstrap-Cluster erstellt. Bevor ein Bootstrap-Cluster erstellt wird, führt bmctl eine Google Cloud-Erreichbarkeitsprüfung über die Administratorworkstation durch.
Diese Prüfung kann aufgrund von Verbindungsproblemen mit dem Container Registry-Endpunkt gcr.io fehlschlagen. Außerdem wird eine Fehlermeldung wie die folgende angezeigt:
system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Problemumgehung
Wiederholen Sie den Vorgang mit dem Flag --ignore-validation-errors, um dieses Problem zu umgehen.
Netzwerk
1,15; 1,16
GKE Dataplane V2 mit einigen Speichertreibern nicht kompatibel
GKE on Bare Metal-Cluster verwenden die GKE Dataplane V2, die mit einigen Speicheranbietern nicht kompatibel ist. Es können Probleme mit hängenden NFS-Volumes oder Pods auftreten. Dies ist besonders wahrscheinlich, wenn Sie Arbeitslasten mit ReadWriteMany-Volumes haben, die von Speichertreibern unterstützt werden, die für dieses Problem anfällig sind:
Robin.io
Portworx (sharedv4 Dienst-Volumes)
csi-nfs
Diese Liste ist nicht vollständig.
Problemumgehung
Eine Lösung für dieses Problem ist für die folgenden Ubuntu-Versionen verfügbar:
20.04 LTS: Verwenden Sie ein 5.4.0-Kernel-Image, das höher als linux-image-5.4.0-166-generic ist.
22.04 LTS: Verwenden Sie entweder ein Kernel-Image der Version 5.15.0, das höher als linux-image-5.15.0-88-generic ist, oder den HWE-Kernel 6.5.
Wenn Sie eine andere Version verwenden, wenden Sie sich an den Google-Support.
Logging und Monitoring
1,15, 1,16, 1,28
kube-state-metrics OOM in großem Cluster
Möglicherweise stellen Sie fest, dass kube-state-metrics oder der Pod gke-metrics-agent, der sich auf demselben Knoten wie kube-state-metrics befindet, keinen Arbeitsspeicher (OOM) hat.
Dies kann bei Clustern mit mehr als 50 Knoten oder mit vielen Kubernetes-Objekten der Fall sein.
Problemumgehung
Um dieses Problem zu beheben, aktualisieren Sie die benutzerdefinierte Ressourcendefinition stackdriver, um das Feature-Gate ksmNodePodMetricsOnly zu verwenden. Dieses Feature-Gate sorgt dafür, dass nur eine kleine Anzahl kritischer Messwerte verfügbar ist.
Führen Sie die folgenden Schritte aus, um diese Problemumgehung zu verwenden:
Prüfen Sie die benutzerdefinierte Ressourcendefinition stackdriver auf verfügbare Feature-Gatter:
Preflight-Prüfung schlägt unter RHEL 9.2 aufgrund fehlender iptables fehl
Bei der Installation eines Clusters unter dem Betriebssystem Red Hat Enterprise Linux (RHEL) 9.2 kann aufgrund des fehlenden iptables-Pakets ein Fehler auftreten. Der Fehler tritt während Preflight-Prüfungen auf und löst eine Fehlermeldung aus, die in etwa so aussieht:
'check_package_availability_pass': "The following packages are not available: ['iptables']"
RHEL 9.2 befindet sich in der Vorabversion für GKE on Bare Metal-Version 1.28.
Problemumgehung
Um den Preflight-Prüfungsfehler zu umgehen, legen Sie spec.bypassPreflightCheck für Ihre Clusterressource auf true fest.
Vorgang
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16
Langsamer MetalLB-Failover in großem Maßstab
Wenn MetalLB eine hohe Anzahl von Diensten verarbeitet (über 10.000), kann der Failover über eine Stunde dauern. Dies liegt daran, dass MetalLB eine ratenbegrenzte Warteschlange verwendet, die bei hoher Skalierung eine Weile dauern kann, um zu dem Dienst zu gelangen, der ein Failover erfordert.
Problemumgehung
Führen Sie ein Upgrade des Clusters auf Version 1.28 oder höher durch. Wenn Sie kein Upgrade durchführen können, führt das manuelle Bearbeiten des Dienstes (z. B. durch Hinzufügen einer Annotation) dazu, dass das Failover des Dienstes schneller ausgeführt wird.
Vorgang
1.16.0–1.16.6, 1.28.0–1.28.200
Umgebungsvariablen müssen auf der Administratorworkstation festgelegt sein, wenn der Proxy aktiviert ist
bmctl check cluster kann aufgrund von Proxyfehlern fehlschlagen, wenn Sie die Umgebungsvariablen HTTPS_PROXY und NO_PROXY nicht auf der Administratorworkstation definiert haben. Der Befehl „bmctl“ meldet eine Fehlermeldung darüber, dass einige Google-Dienste nicht aufgerufen werden können, wie im folgenden Beispiel:
Legen Sie HTTPS_PROXY und NO_PROXY manuell auf der Administratorworkstation fest.
Upgrades und Updates
1.28.0-gke.435
Upgrades auf Version 1.28.0-gke.435 schlagen möglicherweise fehl, wenn die Eigentümerschaft von audit.log falsch ist
In einigen Fällen ist für die Datei /var/log/apiserver/audit.log auf Knoten der Steuerungsebene sowohl die Gruppen- als auch die Nutzerinhaberschaft auf root festgelegt.
Diese Einstellung für die Dateieigentümerschaft führt zu Upgradefehlern für die Knoten der Steuerungsebene, wenn ein Cluster von Version 1.16.x auf Version 1.28.0-gke.435 aktualisiert wird.
Dieses Problem betrifft nur Cluster, die vor Version 1.11 erstellt wurden und für die Cloud-Audit-Logs deaktiviert waren. Cloud-Audit-Logs sind für Cluster ab Version 1.9 standardmäßig aktiviert.
Problemumgehung
Wenn Sie Ihren Cluster nicht auf Version 1.28.100-gke.146 aktualisieren können, führen Sie die folgenden Schritte aus, um das Clusterupgrade auf Version 1.28.0-gke.435 abzuschließen:
Wenn Cloud-Audit-Logs aktiviert sind, entfernen Sie die Datei /var/log/apiserver/audit.log.
Wenn Cloud-Audit-Logs deaktiviert sind, ändern Sie die Eigentümerschaft von /var/log/apiserver/audit.log in das übergeordnete Verzeichnis /var/log/apiserver.
Netzwerk, Upgrades und Updates
1.28.0-gke.435
MetalLB weist VIP-Diensten keine IP-Adressen zu
GKE on Bare Metal verwendet MetalLB für gebündeltes Load-Balancing. In der GKE on Bare Metal-Version 1.28.0-gke.435 wird das gebündelte MetalLB auf Version 0.13 aktualisiert, mit der CRD-Unterstützung für IPAddressPools eingeführt wird. Da ConfigMaps jedoch jeden beliebigen Namen für ein IPAddressPool zulässt, mussten die Poolnamen in einen Kubernetes-kompatiblen Namen umgewandelt werden. Dazu muss am Ende des Namens der IPAddressPool ein Hash angehängt werden.
Ein IPAddressPool mit dem Namen default wird beispielsweise in einen Namen wie default-qpvpd konvertiert, wenn Sie Ihren Cluster auf Version 1.28.0-gke.435 upgraden.
Da MetalLB einen bestimmten Namen eines IPPool zur Auswahl benötigt, verhindert die Namenskonvertierung, dass MetalLB eine Poolauswahl trifft und IP-Adressen zuweist. Daher erhalten Dienste, die metallb.universe.tf/address-pool als Annotation zur Auswahl des Adresspools für eine IP-Adresse verwenden, keine IP-Adresse mehr vom MetalLB-Controller.
Dieses Problem wurde in GKE on Bare Metal Version 1.28.100-gke.146 behoben.
Problemumgehung
Wenn Sie Ihren Cluster nicht auf Version 1.28.100-gke.146 aktualisieren können, verwenden Sie die folgenden Schritte als Behelfslösung:
Rufen Sie den konvertierten Namen von IPAddressPool ab:
kubectl get IPAddressPools -n kube-system
Aktualisieren Sie den betroffenen Dienst, um die Annotation metallb.universe.tf/address-pool auf den konvertierten Namen mit dem Hash festzulegen.
Wenn beispielsweise der Name IPAddressPool von default in einen Namen wie default-qpvpd konvertiert wurde, ändern Sie die Annotation metallb.universe.tf/address-pool: default im Dienst in metallb.universe.tf/address-pool: default-qpvpd.
Der bei der Namenskonvertierung verwendete Hash ist deterministisch, sodass die Problemumgehung dauerhaft ist.
Upgrades und Updates
1,14, 1,15, 1,16, 1,28, 1,29
Verwaiste Pods nach Upgrade auf Version 1.14.x
Wenn Sie ein Upgrade von GKE on Bare-Metal-Clustern auf Version 1.14.x durchführen, werden einige Ressourcen aus der vorherigen Version nicht gelöscht. Insbesondere sehen Sie möglicherweise eine Reihe von verwaisten Pods wie die folgenden:
Dieses Problem wurde in GKE on Bare Metal Version 1.15.0 und höher behoben.
Installation
1,14
Clustererstellung bleibt beim machine-init-Job hängen
Wenn Sie versuchen, Version 1.14.x von Google Distributed Cloud Virtual for Bare Metal zu installieren, kann aufgrund der machine-init-Jobs ein Fehler auftreten, der der folgenden Beispielausgabe ähnelt:
"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference
Workaround:
Entfernen Sie das veraltete etcd-Mitglied, das dazu führt, dass der Job machine-init fehlschlägt. Führen Sie die folgenden Schritte für einen funktionierenden Knoten der Steuerungsebene aus:
Listen Sie die vorhandenen etcd-Mitglieder auf:
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
member list
Suchen Sie nach Mitgliedern mit dem Status unstarted, wie in der folgenden Beispielausgabe gezeigt:
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/peer.crt \
member remove MEMBER_ID
Ersetzen Sie MEMBER_ID durch die ID des ausgefallenen etcd-Mitglieds. In der vorherigen Beispielausgabe lautet diese ID bd1949bcb70e2cb5.
Die folgende Beispielausgabe zeigt, dass das Mitglied entfernt wurde:
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Netzwerk
1.28.0
Cilium-operator fehlen Berechtigungen für Knoten list und watch
In Cilium 1.13 sind die ClusterRole-Berechtigungen cilium-operator falsch. Die Berechtigungen list und watch für den Knoten fehlen. cilium-operator startet keine automatische Speicherbereinigung, was zu folgenden Problemen führt:
Ausspähen von Cilium-Ressourcen.
Veraltete Identitäten werden nicht aus den TCF-Richtlinienzuordnungen entfernt.
Richtlinienzuordnungen erreichen möglicherweise das Limit von 16.000.
Es können keine neuen Einträge hinzugefügt werden.
Falsche NetworkPolicy-Erzwingung.
Identitäten können das Limit von 64.000 unter Umständen erreichen.
Es können keine neuen Pods erstellt werden.
Ein Operator, bei dem die Knotenberechtigungen fehlen, meldet die folgende Beispiel-Lognachricht:
2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s
Der Cilium-Agent gibt eine Fehlermeldung aus, wenn er keinen Eintrag in eine Richtlinienzuordnung einfügen kann. Beispiel:
level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint
Workaround:
Entfernen Sie die Cilium-Identitäten und fügen Sie dem Operator dann die fehlenden ClusterRole-Berechtigungen hinzu:
Entfernen Sie die vorhandenen CiliumIdentity-Objekte:
kubectl delete ciliumid –-all
Bearbeiten Sie das ClusterRole-Objekt cilium-operator:
kubectl edit clusterrole cilium-operator
Fügen Sie einen Abschnitt für nodes hinzu, der die fehlenden Berechtigungen enthält, wie im folgenden Beispiel gezeigt:
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
Speichern und schließen Sie den Editor. Der Operator erkennt die Berechtigungsänderung dynamisch. Sie müssen den Operator nicht manuell neu starten.
Upgrades und Updates
1.15.0–1.15.7, 1.16.0–1.16.3
Vorübergehendes Problem bei der Preflight-Prüfung
Eine der kubeadm-Systemdiagnoseaufgaben, die während der Preflight-Prüfung des Upgrades ausgeführt wird, schlägt möglicherweise mit der folgenden Fehlermeldung fehl:
[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found
Sie können diesen Fehler ignorieren. Wenn dieser Fehler auftritt, der das Upgrade blockiert, führen Sie den Upgradebefehl noch einmal aus.
Wenn dieser Fehler beim Ausführen des Preflights mit dem Befehl bmctl preflightcheck auftritt, wird durch den Fehler nichts blockiert. Sie können die Preflight-Prüfung noch einmal ausführen, um die korrekten Preflight-Informationen zu erhalten.
Workaround:
Führen Sie den Upgrade-Befehl noch einmal aus oder, wenn er während bmctl preflightcheck auftritt, noch einmal den preflightcheck-Befehl.
Vorgang
1.14, 1.15.0–1.15.7, 1.16.0–1.16.3, 1.28.0
Die regelmäßige Netzwerkdiagnose schlägt fehl, wenn ein Knoten ersetzt oder entfernt wird
Dieses Problem betrifft Cluster, die regelmäßige Netzwerk-Systemdiagnosen durchführen, nachdem ein Knoten ersetzt oder entfernt wurde. Wenn für Ihren Cluster regelmäßige Systemdiagnosen durchgeführt werden, schlägt sie nach dem Ersetzen oder Entfernen eines Knotens fehl, da die ConfigMap des Netzwerkinventars nach dem Erstellen nicht aktualisiert wird.
Workaround:
Die empfohlene Problemumgehung besteht darin, die Inventar-ConfigMap und die regelmäßige Netzwerkdiagnose zu löschen. Der Clusteroperator erstellt sie automatisch mit den neuesten Informationen neu.
Führen Sie für 1.14.x-Cluster die folgenden Befehle aus:
Network Gateway for GDC kann Ihre Konfiguration nicht anwenden, wenn der Gerätename einen Punkt enthält
Wenn Sie ein Netzwerkgerät haben, dessen Name einen Punkt (.) enthält, z. B. bond0.2, behandelt Network Gateway for GDC den Punkt als Pfad im Verzeichnis, wenn es sysctl ausführt, um Änderungen vorzunehmen. Wenn Network Gateway for GDC prüft, ob die Erkennung von Duplikaten (DAD) aktiviert ist, kann die Prüfung fehlschlagen und daher nicht abgeglichen werden.
Das Verhalten unterscheidet sich je nach Clusterversion:
1.14 und 1.15: Dieser Fehler tritt nur auf, wenn Sie IPv6-Floating-IP-Adressen verwenden. Wenn Sie keine IPv6-Floating-IP-Adressen verwenden, wird dieses Problem nicht angezeigt, wenn Ihre Gerätenamen einen Punkt enthalten.
1.16.0–1.16.2: Dieser Fehler tritt immer auf, wenn Gerätenamen einen Punkt enthalten.
Workaround:
Führen Sie ein Upgrade des Clusters auf Version 1.16.3 oder höher durch.
Entfernen Sie als Behelfslösung im Namen des Geräts den Punkt (.), bis Sie Ihre Cluster aktualisieren können.
Upgrades und Updates, Netzwerk, Sicherheit
1.16.0
Upgrades auf 1.16.0 schlagen fehl, wenn seccomp deaktiviert ist
Wenn seccomp für Ihren Cluster deaktiviert ist (spec.clusterSecurity.enableSeccomp auf false gesetzt), schlagen Upgrades auf Version 1.16.0 fehl.
GKE on Bare Metal Version 1.16 verwendet die Kubernetes-Version 1.27.
Ab Kubernetes-Version 1.27.0 ist die Funktion zum Festlegen von seccomp-Profilen allgemein verfügbar. Es wird kein Feature-Gate mehr verwendet.
Diese Kubernetes-Änderung führt dazu, dass Upgrades auf Version 1.16.0 fehlschlagen, wenn seccomp in der Clusterkonfiguration deaktiviert ist. Dieses Problem wurde in Clustern ab Version 1.16.1 behoben. Wenn Sie das Feld cluster.spec.clusterSecurity.enableSeccomp auf false gesetzt haben, können Sie ein Upgrade auf Version 1.16.1 oder höher ausführen.
Cluster, für die spec.clusterSecurity.enableSeccomp nicht konfiguriert oder auf true gesetzt ist, sind nicht betroffen.
containerd-Metadaten können nach einem Neustart beschädigt werden, wenn /var/lib/containerd bereitgestellt wird.
Wenn Sie /var/lib/containerd optional bereitgestellt haben, können die containerd-Metadaten nach einem Neustart beschädigt werden. Beschädigte Metadaten können dazu führen, dass Pods fehlschlagen, einschließlich systemkritischer Pods.
Wenn Sie prüfen möchten, ob dieses Problem Sie betrifft, prüfen Sie, ob in /etc/fstab eine optionale Bereitstellung für /var/lib/containerd/ definiert ist und nofail in den Bereitstellungsoptionen enthalten ist.
Workaround:
Entfernen Sie die Bereitstellungsoption nofail in /etc/fstab oder führen Sie ein Upgrade Ihres Clusters auf Version 1.15.6 oder höher durch.
Vorgang
1,13, 1,14, 1,15, 1,16, 1,28
Veraltete Pods im Cluster bereinigen
Möglicherweise werden von einem Deployment (ReplikatSet) verwaltete Pods mit dem Status Failed und dem Status TaintToleration angezeigt. Diese Pods verwenden keine Clusterressourcen, sollten aber gelöscht werden.
Mit dem folgenden kubectl-Befehl können Sie die Pods auflisten, die Sie bereinigen können:
kubectl get pods –A | grep TaintToleration
Die folgende Beispielausgabe zeigt einen Pod mit dem Status TaintToleration:
Prüfen Sie für jeden Pod mit den beschriebenen Symptomen das Replikatset, zu dem der Pod gehört. Wenn das Replikatset zufrieden ist, können Sie die Pods löschen:
Rufen Sie das Replikatset ab, das den Pod verwaltet, und suchen Sie den Wert ownerRef.Kind:
kubectl get pod POD_NAME -n NAMESPACE -o yaml
Rufen Sie das Replikatset ab und prüfen Sie, ob status.replicas mit spec.replicas übereinstimmt:
kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
Wenn die Namen übereinstimmen, löschen Sie den Pod:
kubectl delete pod POD_NAME -n NAMESPACE.
Upgrades
1.16.0
etcd-Ereignisse können beim Upgrade auf Version 1.16.0 verzögert werden
Wenn Sie einen vorhandenen Cluster auf Version 1.16.0 upgraden, können Pod-Fehler im Zusammenhang mit etcd-Ereignissen den Vorgang verzögern. Insbesondere schlägt der Upgrade-Knotenjob für den Schritt TASK [etcd_events_install : Run etcdevents] fehl.
Wenn Sie von diesem Problem betroffen sind, werden Pod-Fehler wie die folgenden angezeigt:
Der Pod kube-apiserver kann mit dem folgenden Fehler nicht gestartet werden:
Der Pod etcd-events kann nicht mit dem folgenden Fehler gestartet werden:
Error: error syncing endpoints with etcd: context deadline exceeded
Workaround:
Wenn Sie Ihren Cluster nicht auf eine Version mit dieser Version aktualisieren können, verwenden Sie die folgende vorübergehende Problemumgehung, um die Fehler zu beheben:
Greifen Sie mit SSH auf den Knoten der Steuerungsebene mit den gemeldeten Fehlern zu.
Bearbeiten Sie die Manifestdatei /etc/kubernetes/manifests/etcd-events.yaml von etcd-events und entfernen Sie das Flag initial-cluster-state=existing.
Wenden Sie das Manifest an.
Das Upgrade sollte fortgesetzt werden.
Netzwerk
1.15.0-1.15.2
CoreDNS orderPolicy nicht erkannt
OrderPolicy wird nicht als Parameter erkannt und nicht verwendet. Stattdessen verwendet GKE on Bare Metal immer Random.
Dieses Problem tritt auf, weil die CoreDNS-Vorlage nicht aktualisiert wurde. Dadurch wird orderPolicy ignoriert.
Workaround:
Aktualisieren Sie die CoreDNS-Vorlage und wenden Sie die Korrektur an. Diese Problembehebung bleibt bis zu einem Upgrade bestehen.
Bearbeiten Sie die vorhandene Vorlage:
kubectl edit cm -n kube-system coredns-template
Ersetzen Sie den Inhalt der Vorlage durch Folgendes:
coredns-template: |-
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
{{- if .PrivateGoogleAccess }}
import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
import zones/restricted.Corefile
{{- end }}
prometheus :9153
forward . {{ .UpstreamNameservers }} {
max_concurrent 1000
{{- if ne .OrderPolicy "" }}
policy {{ .OrderPolicy }}
{{- end }}
}
cache 30
{{- if .DefaultDomainQueryLogging }}
log
{{- end }}
loop
reload
loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
errors
{{- if $stubdomain.QueryLogging }}
log
{{- end }}
cache 30
forward . {{ $stubdomain.Nameservers }} {
max_concurrent 1000
{{- if ne $.OrderPolicy "" }}
policy {{ $.OrderPolicy }}
{{- end }}
}
}
{{- end }}
Netzwerk, Betrieb
1,10, 1,11, 1,12, 1,13, 1,14
Netzwerk-Gateway für GDC-Komponenten aufgrund fehlender Prioritätsklasse entfernt oder ausstehend
Netzwerk-Gateway-Pods in kube-system können den Status Pending oder Evicted anzeigen, wie in der folgenden komprimierten Beispielausgabe gezeigt:
Diese Fehler weisen auf Bereinigungsereignisse hin oder darauf, dass Pods aufgrund von Knotenressourcen nicht geplant werden können. Da Netzwerk-Gateway für GDC-Pods keine PriorityClass haben, haben sie dieselbe Standardpriorität wie andere Arbeitslasten.
Wenn Knoten ressourcenbeschränkt sind, werden die Netzwerk-Gateway-Pods möglicherweise entfernt. Dieses Verhalten ist besonders schlecht für das DaemonSet ang-node, da diese Pods auf einem bestimmten Knoten geplant werden müssen und nicht migriert werden können.
Workaround:
Führen Sie ein Upgrade auf Version 1.15 oder höher aus.
Als kurzfristige Lösung können Sie dem Netzwerk-Gateway für GDC-Komponenten manuell eine PriorityClass zuweisen. Der GKE on Bare Metal-Controller überschreibt diese manuellen Änderungen während eines Abgleichsprozesses, z. B. während eines Clusterupgrades.
Weisen Sie den Clustercontroller-Deployments ang-controller-manager und autoscaler die PriorityClass system-cluster-critical zu.
Weisen Sie dem DaemonSet des Knotens ang-daemon die PriorityClass system-node-critical zu.
Installation, Upgrades und Updates
1.15.0, 1.15.1, 1.15.2
Clustererstellung und ‐upgrades schlagen aufgrund der Länge des Clusternamens fehl
Das Erstellen von Clustern der Version 1.15.0, 1.15.1 oder 1.15.2 oder das Upgrade von Clustern auf Version 1.15.0, 1.15.1 oder 1.15.2 schlägt fehl, wenn der Clustername mehr als 48 Zeichen (Version 1.15.0) oder 45 Zeichen (Version 1.15.1 oder 1) umfasst. Beim Erstellen und Aktualisieren von Clustern erstellt GKE on Bare Metal eine Systemdiagnose-Ressource mit einem Namen, der den Namen und die Version des Clusters enthält:
Bei Clustern der Version 1.15.0 lautet der Ressourcenname für die Systemdiagnose CLUSTER_NAME-add-ons-CLUSTER_VER.
Bei Clustern der Version 1.15.1 oder 1.15.2 lautet der Ressourcenname für die Systemdiagnose CLUSTER_NAME-kubernetes-CLUSTER_VER.
Bei langen Clusternamen überschreitet der Name der Systemdiagnose-Ressource die Kubernetes-Beschränkung für Labelnamen mit 63 Zeichen. Dadurch kann die Systemdiagnose-Ressource nicht erstellt werden.
Ohne eine erfolgreiche Systemdiagnose schlägt der Clustervorgang fehl.
Wenn Sie feststellen möchten, ob Sie von diesem Problem betroffen sind, verwenden Sie kubectl describe, um die ausgefallene Ressource zu prüfen:
Wenn dieses Problem dich betrifft, enthält die Antwort eine Warnung für ein ReconcileError wie die folgende:
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred:
* failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]
Problemumgehung
Wenn Sie die Blockierung des Clusterupgrades oder der Clustererstellung aufheben möchten, können Sie die Systemdiagnose umgehen. Verwenden Sie den folgenden Befehl, um die benutzerdefinierte Systemdiagnose-Ressource mit Übergabe-Status zu patchen: (status: {pass: true})
Cluster der Versionen 1.14.0 und 1.14.1 mit Vorschaufunktionen können nicht auf Version 1.15.x aktualisiert werden.
Wenn für die Cluster der Version 1.14.0 und 1.14.1 eine Vorschaufunktion aktiviert ist, wird das Upgrade auf Version 1.15.x für die Cluster blockiert. Dies gilt für Vorschaufeatures wie die Möglichkeit, einen Cluster ohne kube-proxy zu erstellen, der mit der folgenden Annotation in der Clusterkonfigurationsdatei aktiviert wird:
Wenn Sie von diesem Problem betroffen sind, wird während des Clusterupgrades eine Fehlermeldung wie die folgende angezeigt:
[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version
Dieses Problem wurde in Clustern ab Version 1.14.2 behoben.
Workaround:
Wenn Sie Ihre Cluster vor dem Upgrade auf Version 1.15.x nicht auf Version 1.14.2 oder höher upgraden können, können Sie mithilfe eines Bootstrap-Clusters direkt auf Version 1.15.x upgraden:
bmctl upgrade cluster --use-bootstrap=true
Vorgang
1.15
Cluster der Version 1.15 akzeptieren keine doppelten Floating-IP-Adressen
Mit Network Gateway for GDC können Sie keine neuen benutzerdefinierten NetworkGatewayGroup-Ressourcen erstellen, die IP-Adressen in spec.floatingIPs enthalten, die bereits in vorhandenen benutzerdefinierten NetworkGatewayGroup-Ressourcen verwendet werden. Diese Regel wird durch einen Webhook in GKE on Bare-Metal-Clustern ab Version 1.15.0 erzwungen. Bereits vorhandene doppelte Floating-IP-Adressen verursachen keine Fehler. Der Webhook verhindert nur das Erstellen neuer benutzerdefinierter NetworkGatewayGroups-Ressourcen, die doppelte IP-Adressen enthalten.
Die Webhook-Fehlermeldung enthält die in Konflikt stehende IP-Adresse und die vorhandene benutzerdefinierte Ressource, die sie bereits verwendet:
IP address exists in other gateway with name default
In der ersten Dokumentation für erweiterte Netzwerkfeatures wie das NAT-Gateway für ausgehenden Traffic wird nicht vor doppelten IP-Adressen gewarnt.
Anfangs wurde nur die NetworkGatewayGroup-Ressource default vom Abgleich erkannt. Network Gateway for GDC erkennt jetzt alle benutzerdefinierten NetworkGatewayGroup-Ressourcen im System-Namespace. Vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen werden unverändert berücksichtigt.
Workaround:
Fehler treten nur beim Erstellen einer neuen benutzerdefinierten NetworkGatewayGroup-Ressource auf.
So beheben Sie den Fehler:
Verwenden Sie den folgenden Befehl, um benutzerdefinierte NetworkGatewayGroups-Ressourcen aufzulisten:
kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
-n kube-system -o yaml
Öffnen Sie vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen und entfernen Sie alle in Konflikt stehenden Floating-IP-Adressen (spec.floatingIPs):
Schließen und speichern Sie die bearbeiteten benutzerdefinierten Ressourcen, um die Änderungen zu übernehmen.
VM-Laufzeit auf GDC
1.13.7
VMs werden möglicherweise nicht in Clustern mit Version 1.13.7 gestartet, die eine private Registry verwenden
Wenn Sie die VM-Laufzeit auf GDC in einem neuen oder aktualisierten Cluster der Version 1.13.7 aktivieren, der eine private Registry verwendet, werden VMs, die eine Verbindung zum Knotennetzwerk herstellen oder eine GPU verwenden, möglicherweise nicht richtig gestartet. Dieses Problem ist darauf zurückzuführen, dass einige System-Pods im Namespace vm-system Image-Abruffehler erhalten. Wenn Ihre VM beispielsweise das Knotennetzwerk verwendet, melden einige Pods möglicherweise Image-Abruffehler wie die folgenden:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Dieses Problem wurde in Version 1.14.0 und höher von GKE on Bare-Metal-Clustern behoben.
Problemumgehung
Wenn Sie Ihre Cluster nicht sofort aktualisieren können, können Sie Images manuell abrufen. Mit den folgenden Befehlen rufen Sie das CNI-Plug-in-Image für Macvtap für Ihre VM ab und übertragen es in Ihre private Registry:
Ersetzen Sie REG_HOST durch den Domainnamen eines Hosts, den Sie lokal gespiegelt haben.
Installation
1,11, 1,12
Beim Erstellen des Clusters im Typcluster kann der Pod „gke-metric-agent“ nicht gestartet werden
Während der Clustererstellung im Typcluster kann der Pod „gke-metrics-agent“ aufgrund eines folgenden Fehlers beim Abrufen von Images nicht gestartet werden:
error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Außerdem finden Sie im containerd-Log des Bootstrap-Clusters den folgenden Eintrag:
Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"
Im Pod wird der folgende Fehler angezeigt, dass der Abruf fehlgeschlagen ist:
gcr.io/gke-on-prem-staging/gke-metrics-agent
Problemumgehung
Trotz der Fehler wird die Clustererstellung nicht blockiert, da der Zweck des Pods „gke-metrics-agent“ im Typcluster darin besteht, die Erfolgsquote der Clustererstellung zu erleichtern und internes Tracking und Monitoring zu ermöglichen.
In diesem Fall können Sie diesen Fehler ignorieren.
Problemumgehung
Trotz der Fehler wird die Clustererstellung nicht blockiert, da der Zweck des Pods „gke-metrics-agent“ im Typcluster darin besteht, die Erfolgsquote der Clustererstellung zu erleichtern und internes Tracking und Monitoring zu ermöglichen.
In diesem Fall können Sie diesen Fehler ignorieren.
Betrieb, Netzwerk
1,12, 1,13, 1,14, 1,15, 1,16, 1,28
Beim Zugriff auf einen IPv6-Dienstendpunkt stürzt der LoadBalancer-Knoten unter CentOS oder RHEL ab
Wenn Sie auf einen Dual-Stack-Dienst (einen Dienst mit IPv4- und IPv6-Endpunkten) zugreifen und den IPv6-Endpunkt verwenden, kann der LoadBalancer-Knoten, der den Dienst bereitstellt, abstürzen. Dieses Problem betrifft Kunden, die Dual-Stack-Dienste mit CentOS oder RHEL und einer Kernel-Version vor kernel-4.18.0-372.46.1.el8_6 verwenden.
Wenn Sie der Meinung sind, dass dieses Problem Sie betrifft, prüfen Sie die Kernel-Version auf dem LoadBalancer-Knoten mit dem Befehl uname -a.
Workaround:
Aktualisieren Sie den LoadBalancer-Knoten auf die Kernel-Version kernel-4.18.0-372.46.1.el8_6 oder höher. Diese Kernel-Version ist in CentOS und RHEL ab Version 8.6 standardmäßig verfügbar.
Netzwerk
1.11, 1.12, 1.13, 1.14.0
Zeitweilige Verbindungsprobleme nach Knotenneustart
Nach dem Neustart eines Knotens können zeitweise Verbindungsprobleme für einen NodePort- oder LoadBalancer-Dienst auftreten. Beispielsweise können zeitweise Fehler beim TLS-Handshake oder beim Zurücksetzen der Verbindung auftreten. Dieses Problem wurde für die Clusterversion 1.14.1 und höher behoben.
Wenn Sie prüfen möchten, ob Sie von diesem Problem betroffen sind, sehen Sie sich die iptables-Weiterleitungsregeln auf Knoten an, auf denen der Back-End-Pod für den betroffenen Dienst ausgeführt wird:
sudo iptables -L FORWARD
Wenn Sie die Regel KUBE-FORWARD vor der Regel CILIUM_FORWARD in iptables sehen, sind Sie möglicherweise von diesem Problem betroffen. Die folgende Beispielausgabe zeigt einen Knoten, auf dem das Problem besteht:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
Workaround:
Starten Sie den anetd-Pod auf dem Knoten neu, der falsch konfiguriert ist. Nachdem Sie den anetd-Pod neu gestartet haben, sollte die Weiterleitungsregel in iptables korrekt konfiguriert sein.
Die folgende Beispielausgabe zeigt, dass die Regel CILIUM_FORWARD jetzt korrekt vor der Regel KUBE-FORWARD konfiguriert ist:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Upgrades und Updates
1,9; 1,10
Für die Vorschaufunktion bleiben die ursprünglichen Berechtigungen und Informationen zum Inhaber nicht erhalten
Die Vorabversion eines 1.9.x-Clusters mit bmctl 1.9.x behält nicht die ursprünglichen Berechtigungen und Inhaberinformationen. Extrahieren Sie die gesicherte Datei mit dem folgenden Befehl, um zu prüfen, ob Sie von diesem Feature betroffen sind:
tar -xzvf BACKUP_FILE
Problemumgehung
Prüfen Sie, ob metadata.json vorhanden ist und bmctlVersion 1.9.x ist. Wenn metadata.json nicht vorhanden ist, führen Sie ein Upgrade auf den 1.10.x-Cluster durch und verwenden Sie bmctl 1.10.x zum Sichern/Wiederherstellen.
Upgrades und Kreationen
1.14.2
clientconfig-operator bleibt bei CreateContainerConfigError im Status „Ausstehend“
Wenn Sie ein Upgrade auf einen Cluster der Version 1.14.2 mit einer OIDC/LDAP-Konfiguration durchgeführt oder einen solchen erstellt haben, bleibt der Pod clientconfig-operator möglicherweise im Status „Ausstehend“ hängen. Bei diesem Problem gibt es zwei clientconfig-operator-Pods, einer im Status „Wird ausgeführt“ und der andere im Status „Ausstehend“.
Dieses Problem betrifft nur Cluster der Version 1.14.2. Frühere Clusterversionen wie 1.14.0 und 1.14.1 sind nicht betroffen. Dieses Problem wurde in Version 1.14.3 und allen nachfolgenden Releases, einschließlich 1.15.0 und höher, behoben.
Workaround:
Als Behelfslösung können Sie die clientconfig-operator-Bereitstellung patchen, um zusätzlichen Sicherheitskontext hinzuzufügen und die Bereitstellung sicherzustellen.
Verwenden Sie den folgenden Befehl, um clientconfig-operator im Zielcluster zu patchen:
CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei für den Zielcluster.
Vorgang
1,11, 1,12, 1,13, 1,14, 1,15
Die Rotation der Zertifizierungsstelle schlägt bei Clustern ohne gebündeltes Load-Balancing fehl
Bei Clustern ohne gebündeltes Load-Balancing (spec.loadBalancer.mode auf manual gesetzt) kann der Befehl bmctl update credentials certificate-authorities rotate nicht mehr reagieren und mit dem folgenden Fehler fehlschlagen: x509: certificate signed by unknown authority.
Wenn Sie von diesem Problem betroffen sind, gibt der Befehl bmctl möglicherweise die folgende Nachricht aus, bevor er nicht mehr reagiert:
Signing CA completed in 3/0 control-plane nodes
In diesem Fall schlägt der Befehl fehl. Das Log der Zertifizierungsstelle für die Rotation bei einem Cluster mit drei Steuerungsebenen kann Einträge wie die folgenden enthalten:
[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")
Problemumgehung
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Google-Support.
Installation, Netzwerk
1.11, 1.12, 1.13, 1.14.0–1.14.1
ipam-controller-manager Absturzschleifen in Dual-Stack-Clustern
Wenn Sie einen Dual-Stack-Cluster (einen Cluster mit IPv4- und IPv6-Adressen) bereitstellen, können die ipam-controller-manager-Pods in einer Absturzschleife auftreten. Dieses Verhalten führt dazu, dass die Knoten zwischen den Status Ready und NotReady wechseln, und kann dazu führen, dass die Clusterinstallation fehlschlägt. Dieses Problem kann auftreten, wenn der API-Server stark ausgelastet ist.
Prüfen Sie, ob die ipam-controller-manager-Pods mit CrashLoopBackOff-Fehlern fehlschlagen, um festzustellen, ob Sie von diesem Problem betroffen sind:
kubectl -n kube-system get pods | grep ipam-controller-manager
Die folgende Beispielausgabe zeigt Pods mit dem Status CrashLoopBackOff:
1,6, 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 und 1,14
EZD-Smartwatch-Aushunger
Bei Clustern, auf denen die etcd-Version 3.4.13 oder niedriger ausgeführt wird, kann es zu einem Watch-Mangel und nicht operativen Ressourcen-Uhren kommen, was zu folgenden Problemen führen kann:
Pod-Planung ist unterbrochen
Knoten können nicht registriert werden
Kubelet beobachtet keine Pod-Änderungen
Diese Probleme können dazu führen, dass der Cluster nicht mehr funktioniert.
Dieses Problem wurde in GDCV für Bare-Metal-Version 1.12.9, 1.13.6, 1.14.3 und nachfolgenden Releases behoben. Diese neueren Releases verwenden die etcd-Version 3.4.21. Von diesem Problem sind alle früheren Versionen von GDCV für Bare Metal betroffen.
Problemumgehung
Wenn Sie kein sofortiges Upgrade durchführen können, können Sie das Risiko eines Clusterausfalls verringern, indem Sie die Anzahl der Knoten im Cluster reduzieren. Entfernen Sie Knoten, bis der Messwert etcd_network_client_grpc_sent_bytes_total unter 300 Mbit/s liegt.
So rufen Sie diesen Messwert im Metrics Explorer auf:
Rufen Sie in der Google Cloud Console den Metrics Explorer auf:
Maximieren Sie Messwert auswählen, geben Sie Kubernetes Container in die Filterleiste ein und wählen Sie dann über die Untermenüs den Messwert aus:
Wählen Sie im Menü Aktive Ressourcen die Option Kubernetes-Container aus.
Wählen Sie im Menü Aktive Messwertkategorien die Option Anthos aus.
Wählen Sie im Menü Aktive Messwerte die Option etcd_network_client_grpc_sent_bytes_total aus.
Klicken Sie auf „Anwenden“.
Netzwerk
1.11.6, 1.12.3
vfio-pci-Modus des SR-IOV-Operators: Status „Fehlgeschlagen“
Der syncStatus des SriovNetworkNodeState-Objekts kann den Wert „Fehlgeschlagen“ für einen konfigurierten Knoten melden. Führen Sie den folgenden Befehl aus, um den Status eines Knotens anzusehen und festzustellen, ob das Problem Sie betrifft:
kubectl -n gke-operators get \
sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
-o jsonpath='{.status.syncStatus}'
Ersetzen Sie NODE_NAME durch den Namen des zu prüfenden Knotens.
Workaround:
Wenn der Objektstatus SriovNetworkNodeState „Fehlgeschlagen“ ist, führen Sie ein Upgrade des Clusters auf Version 1.11.7 oder höher bzw. Version 1.12.4 oder höher aus.
Upgrades und Updates
1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1
Einige Worker-Knoten befinden sich nach dem Upgrade nicht im Status „Bereit“
Nach Abschluss des Upgrades ist bei einigen Worker-Knoten die Bedingung „Bereit“ auf false gesetzt. Auf der Knotenressource wird neben der Bedingung "Bereit" ein Fehler angezeigt, der dem folgenden Beispiel ähnelt:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Wenn Sie sich auf dem angehaltenen Computer anmelden, ist die CNI-Konfiguration auf dem Computer leer:
sudo ls /etc/cni/net.d/
Problemumgehung
Starten Sie den Pod anetd des Knotens neu, indem Sie ihn löschen.
Upgrades und Updates, Sicherheit
1.10
Mehrere Zertifikatsrotationen von cert-manager führen zu Inkonsistenzen
Nach mehreren manuellen oder automatischen Zertifikatsrotationen wird der Webhook-Pod (z. B. anthos-cluster-operator) nicht mit den neuen Zertifikaten aktualisiert, die von cert-manager ausgestellt wurden. Jede Aktualisierung der benutzerdefinierten Clusterressource schlägt fehl und führt zu einem Fehler wie diesem:
Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")
Dieses Problem kann unter folgenden Umständen auftreten:
Wenn Sie zwei manuelle, vom cert Manager ausgestellte Zertifikatsrotationen in einem Cluster ausgeführt haben, die älter als 180 Tage sind, und den anthos-cluster-operator nie neu gestartet haben.
Wenn Sie eine manuelle cert-manager-Zertifikatsrotation in einem Cluster ausgeführt haben, der älter als 90 Tage ist, und anthos-cluster-operator noch nie neu gestartet haben.
Problemumgehung
Starten Sie den Pod neu, indem Sie anthos-cluster-operator beenden.
Upgrades und Updates
1.14.0
Veraltete Lebenszyklus-Controller-Deployer-Pods, die beim Nutzerclusterupgrade erstellt wurden
In Version 1.14.0-Administratorclustern werden bei Upgrades von Nutzerclustern möglicherweise ein oder mehrere veraltete Lebenszyklus-Controller-Deployer-Pods erstellt.
Dieses Problem betrifft Nutzercluster, die ursprünglich mit Versionen vor 1.12 erstellt wurden. Die unbeabsichtigt erstellten Pods behindern Upgradevorgänge nicht, können aber in einem unerwarteten Zustand gefunden werden. Wir empfehlen, die veralteten Pods zu entfernen.
Dieses Problem wurde in Version 1.14.1 behoben.
Workaround:
So entfernen Sie die veralteten Bereitstellungs-Pods des Lebenszyklus-Controllers:
Ressourcen für Preflight-Prüfungen auflisten:
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
Sie erhalten folgende Ausgabe:
NAMESPACE NAME PASS AGE
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d
cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d
Dabei ist ci-87a021b9dcbb31c der Clustername.
Ressourcen löschen, deren Wert in der Spalte BESTANDEN entweder true oder false ist.
Verwenden Sie beispielsweise die folgenden Befehle, um die Ressourcen aus der vorherigen Beispielausgabe zu löschen:
Der Status BGPSession ändert sich aufgrund einer großen Anzahl eingehender Routen kontinuierlich
Im erweiterten GKE on Bare Metal-Netzwerk werden BGP-Sitzungen nicht korrekt verwaltet, wenn externe Peers eine große Anzahl von Routen (etwa 100 oder mehr) anbieten. Bei einer großen Anzahl von eingehenden Routen braucht der lokale BGP-Controller des Knotens zu lange für den Abgleich von BGP-Sitzungen und kann den Status nicht aktualisieren. Das Fehlen von Statusaktualisierungen oder eine Systemdiagnose führt dazu, dass die Sitzung gelöscht wird, da sie veraltet ist.
Unerwünschtes Verhalten bei BGP-Sitzungen, das Sie möglicherweise bemerken und auf ein Problem hinweisen können, ist beispielsweise:
Kontinuierliches Löschen und Wiederherstellen von bgpsession.
bgpsession.status.state wird nie zu Established
Routen, die nicht beworben werden oder wiederholt beworben und zurückgezogen werden.
Probleme beim BGP-Load-Balancing können bei Verbindungsproblemen zu LoadBalancer-Diensten auftreten.
Das BGP-Problem FlatIP kann mit Verbindungsproblemen zu Pods auftreten.
Ermitteln Sie, ob Ihre BGP-Probleme dadurch verursacht werden, dass Remote-Peers zu viele Routen bewerben. Prüfen Sie mit den folgenden Befehlen den zugehörigen Status und die zugehörige Ausgabe:
Verwenden Sie kubectl get bgpsessions für den betroffenen Cluster.
Die Ausgabe zeigt bgpsessions mit dem Status „Nicht eingerichtet“. Die letzte Berichtszeit wird kontinuierlich bis etwa 10 bis 12 Sekunden gezählt, bevor sie auf null zurückgesetzt wird.
Die Ausgabe von kubectl get bgpsessions zeigt, dass die betroffenen Sitzungen wiederholt neu erstellt werden:
kubectl get bgpsessions \
-o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
Lognachrichten zeigen an, dass veraltete BGP-Sitzungen gelöscht werden:
kubectl logs ang-controller-manager-POD_NUMBER
Ersetzen Sie POD_NUMBER durch den Leader-Pod in Ihrem Cluster.
Workaround:
Reduzieren oder entfernen Sie die Anzahl der vom Remote-Peer zum Cluster beworbenen Routen mit einer Exportrichtlinie.
In GKE on Bare Metal-Clusterversion 1.14.2 und höher können Sie auch das Feature deaktivieren, das empfangene Routen mit einem AddOnConfiguration verarbeitet. Fügen Sie dem bgpd-Container des ang-daemon-Daemonsets das Argument --disable-received-routes hinzu.
Netzwerk
1,14, 1,15, 1,16, 1,28
Anwendungszeitüberschreitungen, die durch Fehler beim Einfügen von Conntrack-Tabellen verursacht werden
Cluster, die auf einem Ubuntu-Betriebssystem mit Kernel 5.15 oder höher ausgeführt werden, sind anfällig für Fehler beim Einfügen von Tabellen mit Netfilter-Verbindungsverfolgung (Conntrack). Einfügungsfehler können auch dann auftreten, wenn in der Conntrack-Tabelle Platz für neue Einträge vorhanden ist. Die Fehler werden durch Änderungen in Kernel 5.15 und höher verursacht, die das Einfügen von Tabellen je nach Kettenlänge einschränken.
Um festzustellen, ob Sie von diesem Problem betroffen sind, können Sie die Systemstatistiken der In-Kernel-Verbindungsverfolgung mit dem folgenden Befehl überprüfen:
Wenn ein chaintoolong-Wert in der Antwort eine Zahl ungleich null ist, sind Sie von diesem Problem betroffen.
Problemumgehung
Zur vorläufigen Abhilfe können Sie die Größe der Netfiler-Hash-Tabelle (nf_conntrack_buckets) und der Netfilter-Verbindungs-Tracking-Tabelle (nf_conntrack_max) erhöhen. Verwenden Sie die folgenden Befehle auf jedem Clusterknoten, um die Tabellengröße zu erhöhen:
Ersetzen Sie TABLE_SIZE durch die neue Größe in Byte. Der Standardwert für die Tabellengröße ist 262144. Es empfiehlt sich, einen Wert festzulegen, der dem 65.536-Fachen der Anzahl der Kerne auf dem Knoten entspricht. Wenn Ihr Knoten beispielsweise acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
Clustersicherungen mit bmctl können bei einigen Versionen nicht wiederhergestellt werden
Wir empfehlen, die Cluster vor dem Upgrade zu sichern, damit Sie die frühere Version wiederherstellen können, wenn das Upgrade nicht erfolgreich ist.
Ein Problem mit dem Befehl bmctl restore cluster führt dazu, dass Sicherungen von Clustern mit den identifizierten Versionen nicht wiederhergestellt werden können. Dieses Problem betrifft nur Upgrades, bei denen Sie eine Sicherung einer früheren Version wiederherstellen.
Wenn Ihr Cluster betroffen ist, enthält das Log bmctl restore cluster den folgenden Fehler:
Error: failed to extract image paths from profile: anthos version VERSION not supported
Workaround:
Bis zur Behebung dieses Problems empfehlen wir, die Anleitung unter Cluster sichern und wiederherstellen zu verwenden, um Ihre Cluster manuell zu sichern und bei Bedarf manuell wiederherzustellen.
Netzwerk
1.10, 1.11, 1.12, 1.13, 1.14.0–1.14.2
NetworkGatewayGroup stürzt ab, wenn die Schnittstelle keine IP-Adresse enthält
Mit NetworkGatewayGroup können keine Daemons für Knoten erstellt werden, die nicht sowohl IPv4- als auch IPv6-Schnittstellen haben. Dies führt dazu, dass Features wie das BGP-Load-Balancing und IngressNAT fehlschlagen. Wenn Sie die Logs des fehlerhaften ang-node-Pods im Namespace kube-system prüfen, werden Fehler wie im folgenden Beispiel angezeigt, wenn eine IPv6-Adresse fehlt:
ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}
Im vorherigen Beispiel ist auf der ens192-Schnittstelle keine IPv6-Adresse vorhanden. Ähnliche ARP-Fehler werden angezeigt, wenn dem Knoten eine IPv4-Adresse fehlt.
NetworkGatewayGroup versucht, eine ARP-Verbindung und eine NDP-Verbindung zur Link-Local-IP-Adresse herzustellen. Wenn die IP-Adresse nicht vorhanden ist (IPv4 für ARP, IPv6 für NDP), schlägt die Verbindung fehl und der Daemon fährt nicht weiter.
Dieses Problem wurde in Version 1.14.3 behoben.
Workaround:
Stellen Sie über SSH eine Verbindung zum Knoten her und fügen Sie dem Link, der die Knoten-IP-Adresse enthält, eine IPv4- oder IPv6-Adresse hinzu. Im vorherigen Beispiellogeintrag war diese Schnittstelle ens192:
ip address add dev INTERFACE scope link ADDRESS
Ersetzen Sie Folgendes:
INTERFACE: Die Schnittstelle für Ihren Knoten, z. B. ens192.
ADDRESS: Die IP-Adresse und Subnetzmaske, die auf die Schnittstelle angewendet werden sollen.
Zurücksetzen/Löschen
1.10, 1.11, 1.12, 1.13.0–1.13.2
Absturzschleife von anthos-cluster-operator beim Entfernen eines Knotens der Steuerungsebene
Wenn Sie versuchen, einen Knoten der Steuerungsebene durch Entfernen der IP-Adresse aus dem Cluster.Spec zu entfernen, tritt der anthos-cluster-operator in eine Absturzschleife auf, die alle anderen Vorgänge blockiert.
Workaround:
Das Problem wurde in 1.13.3 und 1.14.0 und höher behoben. Alle anderen Versionen sind davon betroffen. Upgrade auf eine der korrigierten Versionen ausführen
Um das Problem zu umgehen, führen Sie den folgenden Befehl aus:
IP_ADDRESS: Die IP-Adresse des Knotens in einer Absturzschleife.
CLUSTER_NAMESPACE: Der Cluster-Namespace.
Installation
1.13.1, 1.13.2 und 1.13.3
kubeadm join schlägt in großen Clustern aufgrund von Tokenabweichungen fehl
Wenn Sie GKE in Bare-Metal-Clustern mit einer großen Anzahl von Knoten installieren, wird möglicherweise eine kubeadmin join-Fehlermeldung ähnlich dem folgenden Beispiel angezeigt:
TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}
Workaround:
Dieses Problem wurde in GDCV für Bare-Metal-Version 1.13.4 und höher behoben.
Wenn Sie eine betroffene Version verwenden müssen, erstellen Sie zuerst einen Cluster mit weniger als 20 Knoten. Passen Sie dann die Größe des Clusters an und fügen Sie nach Abschluss der Installation weitere Knoten hinzu.
Logging und Monitoring
1.10, 1.11, 1.12, 1.13.0
Niedriges CPU-Limit für metrics-server in Edge-Clustern
In GKE on Bare-Metal-Edge-Clustern können niedrige CPU-Limits für metrics-server zu häufigen Neustarts von metrics-server führen. Horizontales Pod-Autoscaling (HPA) funktioniert nicht, weil metrics-server fehlerhaft ist.
Wenn das CPU-Limit für metrics-server unter 40m liegt, können Ihre Cluster betroffen sein. Prüfen Sie die CPU-Limits metrics-server in einer der folgenden Dateien:
Entfernen Sie die Zeile --config-dir=/etc/config und erhöhen Sie die CPU-Limits, wie im folgenden Beispiel gezeigt:
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- Remove this line
- --container=metrics-server
- --cpu=50m # <--- Increase CPU, such as to 50m
- --extra-cpu=0.5m
- --memory=35Mi
- --extra-memory=4Mi
- --threshold=5
- --deployment=metrics-server
- --poll-period=30000
- --estimator=exponential
- --scale-down-delay=24h
- --minClusterSize=5
- --use-metrics=true
[...]
Speichern und schließen Sie metrics-server, um die Änderungen zu übernehmen.
Netzwerk
1,14, 1,15, 1,16
Direkte NodePort-Verbindung zum hostNetwork-Pod funktioniert nicht
Die Verbindung zu einem Pod, der über den NodePort-Dienst mit hostNetwork aktiviert wurde, schlägt fehl, wenn sich der Back-End-Pod auf demselben Knoten wie der gewünschte NodePort befindet. Dieses Problem betrifft LoadBalancer-Dienste, wenn sie mit hostNetwork-ed Pods verwendet werden. Bei mehreren Back-Ends kann es zu einem sporadischen Verbindungsfehler kommen.
Dieses Problem wird durch einen Fehler im eBPF-Programm verursacht.
Workaround:
Wenn Sie einen Nodeport-Dienst verwenden, wählen Sie nicht den Knoten aus, auf dem einer der Back-End-Pods ausgeführt wird. Achten Sie bei Verwendung des LoadBalancer-Dienstes darauf, dass die Pods mit hostNetwork nicht auf LoadBalancer-Knoten ausgeführt werden.
Upgrades und Updates
1.12.3, 1.13.0
1.13.0-Administratorcluster können keine 1.12.3-Nutzercluster verwalten
Administratorcluster mit Version 1.13.0 können keine Nutzercluster verwalten, auf denen Version 1.12.3 ausgeführt wird. Vorgänge für einen Nutzercluster der Version 1.12.3 schlagen fehl.
Workaround:
Führen Sie ein Upgrade Ihres Administratorclusters auf Version 1.13.1 oder ein Upgrade des Nutzerclusters auf dieselbe Version wie der Administratorcluster durch.
Upgrades und Updates
1.12
Das Upgrade auf 1.13.x wird für Administratorcluster mit Worker-Knotenpools blockiert
Administratorcluster der Version 1.13.0 und höher können keine Worker-Knotenpools enthalten.
Upgrades auf Version 1.13.0 oder höher für Administratorcluster mit Worker-Knotenpools werden blockiert. Wenn das Upgrade des Administratorclusters angehalten wird, können Sie prüfen, ob Worker-Knotenpools die Ursache sind. Prüfen Sie dazu den folgenden Fehler in der Datei upgrade-cluster.log im Ordner bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.
Workaround:
Verschieben Sie vor dem Upgrade alle Worker-Knotenpools in Nutzercluster. Eine Anleitung zum Hinzufügen und Entfernen von Knotenpools finden Sie unter Knotenpools in einem Cluster verwalten.
Upgrades und Updates
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28
Fehler beim Aktualisieren von Ressourcen mit kubectl apply
Wenn Sie vorhandene Ressourcen wie die benutzerdefinierten Ressourcen ClientConfig oder Stackdriver mit kubectl apply aktualisieren, gibt der Controller möglicherweise einen Fehler zurück oder macht Ihre Eingabe und geplante Änderungen rückgängig.
So können Sie beispielsweise versuchen, die benutzerdefinierte Ressource Stackdriver so zu bearbeiten, dass Sie zuerst die Ressource abrufen und dann eine aktualisierte Version anwenden:
Aktivieren Sie Features oder aktualisieren Sie die Konfiguration in der YAML-Datei.
Wenden Sie die aktualisierte YAML-Datei wieder an:
kubectl apply -f stackdriver.yaml
Im letzten Schritt für kubectl apply können Probleme auftreten.
Workaround:
Verwenden Sie kubectl apply nicht, um Änderungen an vorhandenen Ressourcen vorzunehmen. Verwende stattdessen kubectl edit oder kubectl patch, wie in den folgenden Beispielen gezeigt:
Bearbeiten Sie die benutzerdefinierte Ressource Stackdriver:
Beschädigte Backlog-Chunks verursachen eine Absturzschleife von stackdriver-log-forwarder
Die Absturzschleifen von stackdriver-log-forwarder, wenn versucht wird, einen beschädigten Backlog-Chunk zu verarbeiten. Die folgenden Beispielfehler werden in den Containerlogs angezeigt:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Wenn diese Absturzschleife auftritt, werden in Cloud Logging keine Logs angezeigt.
Workaround:
So beheben Sie diese Fehler:
Identifizieren Sie die beschädigten Backlog-Chunks. Sehen Sie sich die folgenden Beispielfehlermeldungen an:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
In diesem Beispiel ist die Datei tail.1/1-1659339894.252926599.flb, die in var/log/fluent-bit-buffers/tail.1/ gespeichert ist, fehlerhaft. Jede *.flb-Datei, die die Formatprüfung nicht bestanden hat, muss entfernt werden.
Beenden Sie die ausgeführten Pods für stackdriver-log-forwarder:
Der Neustart von Dataplane V2 (anetd) in Clustern kann dazu führen, dass vorhandene VMs nicht an ein Nicht-Pod-Netzwerk angehängt werden können
In Clustern mit mehreren NICs kann ein Neustart von Dataplane V2 (anetd) dazu führen, dass virtuelle Maschinen nicht an Netzwerke angehängt werden können. In den Pod-Logs anetd kann ein ähnlicher Fehler wie der folgende auftreten:
could not find an allocator to allocate the IP of the multi-nic endpoint
Workaround:
Als schnelle Lösung können Sie die VM neu starten. Damit das Problem nicht noch einmal auftritt, führen Sie ein Upgrade Ihres Clusters auf Version 1.14.1 oder höher durch.
Vorgang
1.13, 1.14.0, 1.14.1
gke-metrics-agent hat kein Arbeitsspeicherlimit für Edge-Profilcluster
Abhängig von der Arbeitslast des Clusters kann gke-metrics-agent mehr als 4.608 MiB Arbeitsspeicher verwenden. Dieses Problem betrifft nur GKE on Bare Metal Edge-Profilcluster. Standardprofilcluster sind davon nicht betroffen.
Workaround:
Führen Sie ein Upgrade des Clusters auf Version 1.14.2 oder höher durch.
Installation
1,12, 1,13
Die Clustererstellung kann aufgrund von Race-Bedingungen fehlschlagen
Wenn Sie Cluster mit kubectl erstellen, wird die Preflight-Prüfung aufgrund von Race-Bedingungen möglicherweise nie abgeschlossen. Daher kann die Clustererstellung in bestimmten Fällen fehlschlagen.
Der Abgleich der Preflight-Prüfungen erstellt ein SecretForwarder, um das Standard-ssh-key-Secret in den Ziel-Namespace zu kopieren.
In der Regel werden bei der Preflight-Prüfung die Inhaberverweise genutzt und nach Abschluss von SecretForwarder abgeglichen. In seltenen Fällen können die Inhaberverweise von SecretForwarder jedoch den Verweis auf die Preflight-Prüfung verlieren, wodurch die Preflight-Prüfung hängen bleibt. Daher schlägt die Clustererstellung fehl. Um den Abgleich für die Controller-gesteuerte Preflight-Prüfung fortzusetzen, löschen Sie den Cluster-Operator-Pod oder die Preflight-check-Ressource. Wenn Sie die Preflight-Check-Ressource löschen, wird eine neue erstellt und der Abgleich fortgesetzt. Alternativ können Sie Ihre vorhandenen Cluster, die mit einer früheren Version erstellt wurden, auf eine korrigierte Version aktualisieren.
Netzwerk
1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Reservierte IP-Adressen werden nicht freigegeben, wenn das Standort-Plug-in mit der Multi-NIC-Funktion verwendet wird
Wenn Sie in der Multi-Nic-Funktion das CNI-Standort-Plug-in verwenden und den CNI-DEL-Vorgang zum Löschen einer Netzwerkschnittstelle für einen Pod verwenden, werden einige reservierte IP-Adressen möglicherweise nicht ordnungsgemäß freigegeben. Dies geschieht, wenn der CNI DEL-Vorgang unterbrochen wird.
Sie können die nicht verwendeten IP-Adressreservierungen der Pods prüfen, indem Sie den folgenden Befehl ausführen:
kubectl get ippools -A --kubeconfig KUBECONFIG_PATH
Problemumgehung:
Löschen Sie die nicht verwendeten IP-Adressen (ippools) manuell.
Installation
1.10, 1.11.0, 1.11.1, 1.11.2
Node Problem Detector schlägt im Nutzercluster 1.10.4 fehl
Der Node Problem Detector kann in Nutzerclustern der Version 1.10.x fehlschlagen, wenn die Administratorcluster der Version 1.11.0, 1.11.1 oder 1.11.2 die Nutzercluster der Version 1.10.x verwalten. Wenn der Node Problem Detector fehlschlägt, wird das Log mit der folgenden Fehlermeldung aktualisiert:
Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.
Problemumgehung
Führen Sie ein Upgrade des Administratorclusters auf 1.11.3 durch, um das Problem zu beheben.
Vorgang
1,14
1,14-IPv4-Clusterknoten im Inselmodus haben eine Pod-CIDR-Maskengröße von 24
In Version 1.14 wird die Einstellung maxPodsPerNode für Cluster im Inselmodus nicht berücksichtigt. Daher wird den Knoten eine Pod-CIDR-Maskengröße von 24 (256 IP-Adressen) zugewiesen. Dies kann dazu führen, dass dem Cluster früher als erwartet keine Pod-IP-Adressen mehr zur Verfügung stehen. Wenn Ihr Cluster beispielsweise eine Pod-CIDR-Maskengröße von 22 hat, wird jedem Knoten eine Pod-CIDR-Maske von 24 zugewiesen und der Cluster kann nur bis zu 4 Knoten unterstützen. In Ihrem Cluster kann es auch in einem Zeitraum mit hoher Pod-Abwanderung zu Netzwerkinstabilität kommen, wenn maxPodsPerNode auf 129 oder höher festgelegt ist und im Pod-CIDR-Bereich nicht genügend Aufwand für jeden Knoten vorhanden ist.
Wenn Ihr Cluster betroffen ist, meldet der Pod anetd den folgenden Fehler, wenn Sie dem Cluster einen neuen Knoten hinzufügen und kein podCIDR verfügbar ist:
error="required IPv4 PodCIDR not available"
Problemumgehung
Gehen Sie so vor, um das Problem zu beheben:
Führen Sie ein Upgrade auf 1.14.1 oder eine höhere Version durch.
Entfernen Sie die Worker-Knoten und fügen Sie sie wieder hinzu.
Entfernen Sie die Knoten der Steuerungsebene und fügen Sie sie wieder hinzu, vorzugsweise nacheinander, um Ausfallzeiten des Clusters zu vermeiden.
Upgrades und Updates
1.14.0, 1.14.1
Fehler beim Rollback des Clusterupgrades
Ein Upgrade-Rollback kann für Cluster der Version 1.14.0 oder 1.14.1 fehlschlagen.
Wenn Sie einen Cluster von 1.14.0 auf 1.14.1 upgraden und dann versuchen, mit dem Befehl bmctl restore cluster ein Rollback auf 1.14.0 durchzuführen, wird möglicherweise ein Fehler wie der folgende zurückgegeben:
I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable
Workaround:
Löschen Sie alle healthchecks.baremetal.cluster.gke.io-Ressourcen unter dem Cluster-Namespace und führen Sie dann den Befehl bmctl restore
cluster noch einmal aus:
Alle healthchecks.baremetal.cluster.gke.io-Ressourcen auflisten:
kubectl get healthchecks.baremetal.cluster.gke.io \
--namespace=CLUSTER_NAMESPACE \
--kubeconfig=ADMIN_KUBECONFIG
Ersetzen Sie Folgendes:
CLUSTER_NAMESPACE: der Namespace für den Cluster.
ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
Löschen Sie alle healthchecks.baremetal.cluster.gke.io-Ressourcen, die im vorherigen Schritt aufgeführt wurden:
Ersetzen Sie HEALTHCHECK_RESOURCE_NAME durch den Namen der Systemdiagnose-Ressourcen.
Führen Sie den Befehl bmctl restore cluster noch einmal aus.
Netzwerk
1.12.0
Die externe IP-Adresse des Dienstes funktioniert im Flat-Modus nicht
In einem Cluster, für den flatIPv4 auf true gesetzt ist, sind Dienste vom Typ LoadBalancer über ihre externen IP-Adressen nicht zugänglich.
Dieses Problem wurde in Version 1.12.1 behoben.
Workaround:
Legen Sie in der ConfigMap cilium-configenable-415 auf "true" fest und starten Sie dann die anetd-Pods neu.
Upgrades und Updates
1.13.0, 1.14
Direkte Upgrades von 1.13.0 auf 1.14.x werden nie abgeschlossen.
Wenn Sie ein direktes Upgrade von 1.13.0 auf 1.14.x mit bmctl 1.14.0 und dem Flag --use-bootstrap=false ausführen, wird das Upgrade nie abgeschlossen.
Ein Fehler mit dem Operator preflight-check führt dazu, dass der Cluster die erforderlichen Prüfungen nie plant. Das bedeutet, dass die Preflight-Prüfung nie abgeschlossen wird.
Workaround:
Führen Sie zuerst ein Upgrade auf 1.13.1 durch, bevor Sie auf 1.14.x upgraden. Ein direktes Upgrade von 1.13.0 auf 1.13.1 sollte funktionieren. Alternativ können Sie ein Upgrade von 1.13.0 auf 1.14.x ohne das Flag --use-bootstrap=false ausführen.
Upgrades und Updates, Sicherheit
1,13 und 1,14
Bei Clustern, die auf 1.14.0 aktualisiert wurden, gehen Mastermarkierungen verloren
Für die Knoten der Steuerungsebene sind eine von zwei spezifischen Markierungen erforderlich, um zu verhindern, dass Arbeitslast-Pods dafür geplant werden. Wenn Sie GKE-Cluster der Version 1.13 auf Version 1.14.0 upgraden, verlieren die Knoten der Steuerungsebene die folgenden erforderlichen Markierungen:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Dieses Problem führt nicht zu Upgradefehlern, aber es können jetzt Pods von Pods, die nicht auf den Knoten der Steuerungsebene ausgeführt werden sollten, dazu kommen. Diese Arbeitslast-Pods können Knoten der Steuerungsebene überlasten und zu Clusterinstabilität führen.
Ermitteln, ob Sie betroffen sind
Suchen Sie mit dem folgenden Befehl die Knoten der Steuerungsebene:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Verwenden Sie den folgenden Befehl, um die Liste der Markierungen auf einem Knoten aufzurufen:
Wenn keine der erforderlichen Markierungen aufgeführt ist, sind Sie davon betroffen.
Problemumgehung
Führen Sie die folgenden Schritte für jeden Knoten der Steuerungsebene des betroffenen Clusters der Version 1.14.0 aus, um die ordnungsgemäße Funktion wiederherzustellen. Diese Schritte gelten für die Markierung node-role.kubernetes.io/master:NoSchedule und die zugehörigen Pods. Wenn die Knoten der Steuerungsebene die Markierung PreferNoSchedule verwenden sollen, passen Sie die Schritte entsprechend an.
Suchen Sie nach Pods ohne die Toleranz node-role.kubernetes.io/master:NoSchedule:
kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \
-o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \
--kubeconfig KUBECONFIG_PATH | \
grep -v "node-role.kubernetes.io/master" | uniq
Löschen Sie die Pods ohne die Toleranz node-role.kubernetes.io/master:NoSchedule:
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Vorgang, VM-Laufzeit auf GDC
1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28, 1,29
VM-Erstellung schlägt zeitweise mit Uploadfehlern fehl
Das Erstellen einer neuen virtuellen Maschine (VM) mit dem Befehl kubectl virt create vm schlägt beim Hochladen des Images selten fehl. Dieses Problem betrifft sowohl Linux- als auch Windows-VMs. Der Fehler sieht in etwa so aus:
PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51
2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s
fail to upload image: unexpected return value 500, ...
Problemumgehung
Wiederholen Sie den Befehl kubectl virt create vm, um die VM zu erstellen.
Upgrades und Updates, Logging und Monitoring
1.11
Verwaltete Sammlungskomponenten in Clustern der Version 1.11 werden bei Upgrades auf Version 1.12 nicht beibehalten.
Komponenten der verwalteten Sammlung sind Teil von Managed Service for Prometheus.
Wenn Sie Komponenten der verwalteten Sammlung im Namespace gmp-system Ihrer Cluster der Version 1.11 manuell bereitgestellt haben, bleiben die zugehörigen Ressourcen beim Upgrade auf Version 1.12 nicht erhalten.
Ab Version 1.12.0 werden Komponenten von Managed Service for Prometheus im Namespace gmp-system und zugehörige benutzerdefinierte Ressourcendefinitionen von stackdriver-operator mit dem Feld enableGMPForApplications verwaltet. Das Feld enableGMPForApplications ist standardmäßig auf true gesetzt. Wenn Sie also vor dem Upgrade auf Version 1.12 manuell Komponenten von Managed Service for Prometheus im Namespace bereitstellen, werden die Ressourcen von stackdriver-operator gelöscht.
Problemumgehung
So behalten Sie manuell verwaltete Sammlungsressourcen bei:
Alle vorhandenen benutzerdefinierten PodMonitoring-Ressourcen sichern.
Stellen Sie die benutzerdefinierten PodMonitoring-Ressourcen noch einmal im aktualisierten Cluster bereit.
Upgrades und Updates
1.13
Einige Cluster der Version 1.12 mit der Docker-Containerlaufzeit können nicht auf Version 1.13 aktualisiert werden
Wenn in einem Cluster der Version 1.12, der die Docker-Containerlaufzeit verwendet, die folgende Annotation fehlt, kann kein Upgrade auf Version 1.13 durchgeführt werden:
Wenn dieses Problem bei Ihnen auftritt, schreibt bmctl den folgenden Fehler in die Datei upgrade-cluster.log im Ordner bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.
Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.
Dies tritt am wahrscheinlichsten bei Docker-Clustern der Version 1.12 auf, die von Version 1.11 aktualisiert wurden, da für dieses Upgrade die Annotation zur Aufrechterhaltung der Docker-Containerlaufzeit nicht erforderlich ist. In diesem Fall haben Cluster beim Upgrade auf 1.13 keine Annotation. Ab Version 1.13 ist containerd die einzige zulässige Containerlaufzeit.
Workaround:
Wenn Sie von diesem Problem betroffen sind, aktualisieren Sie die Clusterressource mit der fehlenden Annotation. Sie können die Annotation entweder während oder nach dem Abbruch des Upgrades hinzufügen, bevor Sie das Upgrade wiederholen.
Installation
1.11
bmctl wird beendet, bevor die Clustererstellung abgeschlossen ist
Die Clustererstellung kann für GDCV für Bare Metal Version 1.11.0 fehlschlagen. Dieses Problem wurde in GDCV für Bare Metal-Version 1.11.1 behoben. In einigen Fällen wird der Befehl bmctl create cluster vorzeitig beendet und es werden Fehler wie die folgenden in die Logs geschrieben:
Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster
Problemumgehung
Der fehlgeschlagene Vorgang erzeugt Artefakte, der Cluster ist jedoch nicht betriebsbereit. Wenn Sie von diesem Problem betroffen sind, führen Sie die folgenden Schritte aus, um Artefakte zu bereinigen und einen Cluster zu erstellen:
Umgehungsschritte ansehen
Führen Sie den folgenden Befehl aus, um Clusterartefakte zu löschen und die Knotenmaschine zurückzusetzen:
bmctl reset -c USER_CLUSTER_NAME
Führen Sie den folgenden Befehl aus, um die Clustererstellung zu starten:
Das Flag --keep-bootstrap-cluster ist wichtig, wenn dieser Befehl fehlschlägt.
Wenn der Befehl zur Clustererstellung erfolgreich war, können Sie die verbleibenden Schritte überspringen. Andernfalls fahren Sie mit der Erstellung fort.
Führen Sie den folgenden Befehl aus, um die Version für den Bootstrap-Cluster abzurufen:
Dieser Fehler ist harmlos und kann ignoriert werden.
Installation
1.10, 1.11, 1.12
Die Clustererstellung schlägt fehl, wenn mehrere NICs, containerd und ein HTTPS-Proxy verwendet werden
Die Clustererstellung schlägt fehl, wenn die folgende Kombination von Bedingungen vorliegt:
Der Cluster ist so konfiguriert, dass containerd als Containerlaufzeit verwendet wird (nodeConfig.containerRuntime in der Clusterkonfigurationsdatei auf containerd gesetzt, die Standardeinstellung für GDCV für Bare Metal-Version 1.13 und höher).
Der Cluster ist so konfiguriert, dass mehrere Netzwerkschnittstellen (Multi-NICs) für Pods bereitgestellt werden (clusterNetwork.multipleNetworkInterfaces in der Clusterkonfigurationsdatei auf true gesetzt).
Der Cluster ist für die Verwendung eines Proxys konfiguriert (spec.proxy.url ist in der Clusterkonfigurationsdatei angegeben). Auch wenn die Clustererstellung fehlschlägt, wird diese Einstellung weitergegeben, wenn Sie versuchen, einen Cluster zu erstellen. Diese Proxyeinstellung wird möglicherweise als HTTPS_PROXY-Umgebungsvariable oder in Ihrer containerd-Konfiguration (/etc/systemd/system/containerd.service.d/09-proxy.conf) angezeigt.
Problemumgehung
Hängen Sie auf allen Knotenmaschinen Dienst-CIDRs (clusterNetwork.services.cidrBlocks) an die Umgebungsvariable NO_PROXY an.
Installation
1.10, 1.11, 1.12
Fehler bei Systemen mit restriktiver umask-Einstellung
Bei der GDCV für Bare Metal-Version 1.10.0 wurde eine wurzellose Steuerungsebene eingeführt, die alle Komponenten der Steuerungsebene als Nicht-Root-Nutzer ausführt. Wenn alle Komponenten als Nicht-Root-Nutzer ausgeführt werden, kann es bei Systemen mit einer restriktiveren umask-Einstellung von 0077 zu Installations- oder Upgradefehlern kommen.
Problemumgehung
Setzen Sie die Knoten der Steuerungsebene zurück und ändern Sie die Einstellung umask auf allen Maschinen der Steuerungsebene in 0022. Wiederholen Sie nach dem Aktualisieren der Maschinen die Installation.
Alternativ können Sie die Verzeichnis- und Dateiberechtigungen von /etc/kubernetes auf den Maschinen der Steuerungsebene ändern, damit die Installation oder das Upgrade fortgesetzt werden kann.
Mache /etc/kubernetes und alle zugehörigen Unterverzeichnisse lesbar: chmod o+rx.
Alle Dateien des root-Nutzers im Verzeichnis /etc/kubernetes (rekursiv) allgemein lesbar (chmod o+r). Schließen Sie private Schlüsseldateien (.key) von diesen Änderungen aus, da sie bereits mit den richtigen Eigentümerschafts- und Berechtigungen erstellt wurden.
Die
Kontrollgruppe v2 (cgroup v2) wird in GKE in Bare-Metal-Clustern ab Version 1.13 von GDCV für Bare Metal nicht unterstützt. Version 1.14 unterstützt jedoch cgroup v2 als Vorabversion
. Wenn /sys/fs/cgroup/cgroup.controllers vorhanden ist, verwendet Ihr System cgroup v2.
Problemumgehung
Wenn Ihr System cgroup v2 verwendet, führen Sie ein Upgrade Ihres Clusters auf Version 1.14 durch.
Preflight-Prüfungen und Anmeldedaten für Dienstkonten
Bei Installationen, die von Administrator- oder Hybridclustern ausgelöst werden (d. h. Cluster, die nicht mit bmctl erstellt wurden, wie Nutzercluster), prüft die Preflight-Prüfung weder die Anmeldedaten des Google Cloud-Dienstkontos noch die zugehörigen Berechtigungen.
Wenn Sie GKE in Bare-Metal-Clustern auf vSphere-VMs installieren, müssen Sie die Flags tx-udp_tnl-segmentation und tx-udp_tnl-csum-segmentation auf „Aus“ setzen. Diese Flags beziehen sich auf das Auslagerung der Hardwaresegmentierung durch den vSphere-Treiber VMXNET3 und funktionieren nicht mit dem GENEVE-Tunnel von GKE on Bare Metal-Clustern.
Problemumgehung
Führen Sie auf jedem Knoten den folgenden Befehl aus, um die aktuellen Werte für diese Flags zu prüfen:
ethtool -k NET_INTFC | grep segm
Ersetzen Sie NET_INTFC durch die Netzwerkschnittstelle, die der IP-Adresse des Knotens zugeordnet ist.
Die Antwort sollte Einträge wie die folgenden enthalten:
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
Manchmal zeigt ethtool in RHEL 8.4 an, dass diese Flags deaktiviert sind, während sie nicht aktiv sind. Wenn Sie diese Flags explizit deaktivieren möchten, aktivieren und deaktivieren Sie sie mit den folgenden Befehlen:
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
tx-udp_tnl-csum-segmentation off
Diese Flag-Änderung bleibt bei Neustarts nicht bestehen. Konfigurieren Sie die Startskripts so, dass diese Flags beim Booten des Systems explizit gesetzt werden.
Upgrades und Updates
1.10
bmctl kann keine Nutzercluster mit niedrigerer Version erstellen, aktualisieren oder zurücksetzen
Die bmctl-Befehlszeile kann unabhängig von der Version des Administratorclusters keinen Nutzercluster mit einer niedrigeren Nebenversion erstellen, aktualisieren oder zurücksetzen. Sie können beispielsweise bmctl nicht mit einer Version von 1.N.X verwenden, um einen Nutzercluster der Version 1.N-1.Y zurückzusetzen, selbst wenn der Administratorcluster ebenfalls Version 1.N.X hat.
Wenn Sie von diesem Problem betroffen sind, sollten bei der Verwendung von bmctl die Logs in etwa so aussehen:
[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:
* cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported
Workaround:
Verwenden Sie kubectl, um die benutzerdefinierte Ressource des Nutzerclusters im Administratorcluster zu erstellen, zu bearbeiten oder zu löschen.
Die Möglichkeit, Nutzercluster zu aktualisieren, ist nicht betroffen.
Upgrades und Updates
1.12
Clusterupgrades auf Version 1.12.1 können verzögert werden
Das Upgrade von Clustern auf Version 1.12.1 wird manchmal unterbrochen, da der API-Server nicht mehr verfügbar ist. Dieses Problem betrifft alle Clustertypen und alle unterstützten Betriebssysteme. Wenn dieses Problem auftritt, kann der Befehl bmctl
upgrade cluster an mehreren Punkten fehlschlagen, auch während der zweiten Phase von Preflight-Prüfungen.
Problemumgehung
Anhand der Upgradelogs können Sie feststellen, ob Sie von diesem Problem betroffen sind. Upgradelogs befinden sich standardmäßig in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP.
upgrade-cluster.log kann Fehler wie die folgenden enthalten:
Failed to upgrade cluster: preflight checks failed: preflight check failed
Das Maschinenlog kann Fehler wie die folgenden enthalten (wiederholte Fehler weisen darauf hin, dass Sie von diesem Problem betroffen sind):
HAProxy und KeepaErlebnisse müssen auf jedem Knoten der Steuerungsebene ausgeführt werden, bevor Sie noch einmal versuchen, den Cluster auf Version 1.12.1 zu aktualisieren. Prüfen Sie mit der crictl-Befehlszeile auf jedem Knoten, ob die Container haproxy und keepalived ausgeführt werden:
Wenn HAProxy oder Keepaowned nicht auf einem Knoten ausgeführt werden, starten Sie kubelet auf dem Knoten neu:
systemctl restart kubelet
Upgrades und Updates, VM-Laufzeit auf GDC
1,11, 1,12
Das Upgrade von Clustern auf Version 1.12.0 oder höher schlägt fehl, wenn die VM-Laufzeit auf GDC aktiviert ist.
In GKE on Bare Metal-Clustern in Version 1.12.0 werden alle Ressourcen, die sich auf die VM-Laufzeit in GDC beziehen, zum Namespace vm-system migriert, um den GA-Release der VM-Laufzeit in GDC besser zu unterstützen. Wenn Sie die VM-Laufzeit auf GDC in einem Cluster der Version 1.11.x oder niedriger aktiviert haben, schlägt das Upgrade auf Version 1.12.0 oder höher fehl, sofern Sie nicht zuvor die VM-Laufzeit auf GDC deaktivieren. Wenn Sie von diesem Problem betroffen sind, wird beim Upgradevorgang der folgende Fehler gemeldet:
Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version
Problemumgehung
So deaktivieren Sie die VM-Laufzeit auf GDC:
Bearbeiten Sie die benutzerdefinierte Ressource VMRuntime:
kubectl edit vmruntime
Legen Sie enabled in der Spezifikation auf false fest:
Upgrade hängt bei error during manifests operations
In einigen Situationen können Clusterupgrades nicht abgeschlossen werden und die bmctl-Befehlszeile reagiert nicht mehr. Dieses Problem kann durch eine falsch aktualisierte Ressource verursacht werden. Um festzustellen, ob Sie von diesem Problem betroffen sind, und um es zu beheben, prüfen Sie die anthos-cluster-operator-Logs und suchen Sie nach Fehlern, die den folgenden Einträgen ähneln:
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
Diese Einträge sind ein Hinweis auf eine falsch aktualisierte Ressource, wobei {RESOURCE_NAME} der Name der Problemressource ist.
Problemumgehung
Wenn Sie diese Fehler in Ihren Protokollen finden, führen Sie die folgenden Schritte aus:
Verwenden Sie kubectl edit, um die Annotation kubectl.kubernetes.io/last-applied-configuration aus der Ressource zu entfernen, die in der Lognachricht enthalten ist.
Speichern Sie die Änderungen und wenden Sie sie auf die Ressource an.
Wiederholen Sie das Clusterupgrade.
Upgrades und Updates
1.10, 1.11, 1.12
Upgrades sind für Cluster mit Funktionen blockiert, die Network Gateway für GDC verwenden.
Clusterupgrades von 1.10.x auf 1.11.x schlagen bei Clustern fehl, die entweder ausgehendes NAT-Gateway oder gebündeltes Load-Balancing mit BGP verwenden. Für diese Funktionen wird Network Gateway for GDC verwendet. Clusterupgrades bleiben in der Waiting for upgrade to complete...-Befehlszeilennachricht und in anthos-cluster-operator protokolliert Fehler wie die folgenden:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Problemumgehung
Führen Sie die folgenden Befehle für den Cluster aus, den Sie aktualisieren möchten, um die Blockierung des Upgrades aufzuheben:
Mit dem Befehl bmctl update kann der Abschnitt maintenanceBlocks aus der Clusterressourcenkonfiguration weder entfernt noch geändert werden.
Problemumgehung
Weitere Informationen, einschließlich einer Anleitung zum Entfernen von Knoten aus dem Wartungsmodus, finden Sie unter Knoten in den Wartungsmodus versetzen.
Vorgang
1.10, 1.11, 1.12
Knoten werden entsperrt, wenn Sie das Verfahren für den Wartungsmodus nicht verwenden
Wenn Sie Cluster der Version 1.12.0 (anthosBareMetalVersion: 1.12.0) oder niedriger ausführen und kubectl cordon auf einem Knoten manuell verwenden, kann GKE on Bare Metal den Knoten entriegeln, bevor Sie bereit sind, den erwarteten Zustand abzugleichen.
Problemumgehung
Verwenden Sie für Cluster der Version 1.12.0 und niedriger den Wartungsmodus, um Knoten sicher ab- und abzuschalten.
In Version 1.12.1 (anthosBareMetalVersion: 1.12.1) oder höher hebt GKE on Bare Metal die Knoten nicht unerwartet auf, wenn Sie kubectl cordon verwenden.
Vorgang
1.11
Version 11-Administratorcluster, die einen Registrierungsspiegel verwenden, können keine Cluster der Version 1.10 verwalten
Wenn Ihr Administratorcluster die Version 1.11 verwendet und einen Registrierungsspiegel verwendet, kann er keine Nutzercluster mit einer niedrigeren Nebenversion verwalten. Dieses Problem betrifft Vorgänge zum Zurücksetzen, Aktualisieren und Upgraden im Nutzercluster.
Prüfen Sie Ihre Logs auf Clustervorgänge wie Erstellen, Upgraden oder Zurücksetzen, um festzustellen, ob Sie von diesem Problem betroffen sind. Diese Logs befinden sich standardmäßig im Ordner bmctl-workspace/CLUSTER_NAME/. Wenn Sie von diesem Problem betroffen sind, enthalten Ihre Logs die folgende Fehlermeldung:
flag provided but not defined: -registry-mirror-host-to-endpoints
Vorgang
1,10; 1,11
kubeconfig-Secret überschrieben
Der Befehl bmctl check cluster überschreibt bei der Ausführung auf Nutzerclustern das kubeconfig-Secret des Nutzerclusters mit der kubeconfig-Datei des Administratorclusters. Das Überschreiben der Datei führt dazu, dass Standardclustervorgänge wie Aktualisierungen und Upgrades bei betroffenen Nutzerclustern fehlschlagen. Dieses Problem gilt für GKE on Bare Metal-Clusterversionen bis einschließlich 1.11.1.
Führen Sie den folgenden Befehl aus, um festzustellen, ob dieses Problem einen Nutzercluster betrifft:
ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
USER_CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für GKE on Bare Metal-Cluster der Name des Clusters, dem cluster- vorangestellt ist. Wenn Sie den Cluster beispielsweise test nennen, ist der Standard-Namespace cluster-test.
USER_CLUSTER_NAME: der Name des zu prüfenden Nutzerclusters.
Wenn der Clustername in der Ausgabe (siehe contexts.context.cluster in der folgenden Beispielausgabe) der Name des Administratorclusters ist, ist der angegebene Nutzercluster betroffen.
Mit den folgenden Schritten wird die Funktion in einem betroffenen Nutzercluster (USER_CLUSTER_NAME) wiederhergestellt:
Suchen Sie die kubeconfig-Datei des Nutzerclusters. GKE on Bare Metal generiert die kubeconfig-Datei auf der Administratorworkstation, wenn Sie einen Cluster erstellen. Die Datei befindet sich standardmäßig im Verzeichnis bmctl-workspace/USER_CLUSTER_NAME.
Prüfen Sie, ob die kubeconfig-Datei des Nutzerclusters korrekt ist:
kubectl get nodes \
--kubeconfig PATH_TO_GENERATED_FILE
Ersetzen Sie PATH_TO_GENERATED_FILE durch den Pfad zur kubeconfig-Datei des Nutzerclusters. In der Antwort werden Details zu den Knoten für den Nutzercluster zurückgegeben. Prüfen Sie, ob die Maschinennamen für Ihren Cluster korrekt sind.
Führen Sie den folgenden Befehl aus, um die beschädigte kubeconfig-Datei im Administratorcluster zu löschen:
Snapshot als angemeldeter Nutzer ohne Root-Berechtigung erstellen
Wenn Sie containerd als Containerlaufzeit verwenden und einen Snapshot als Nicht-Root-Nutzer ausführen, muss sich /usr/local/bin im PATH des Nutzers befinden.
Andernfalls wird der Fehler crictl: command not found zurückgegeben.
Wenn Sie nicht als Root-Nutzer angemeldet sind, wird sudo zum Ausführen der Snapshot-Befehle verwendet. Der Pfad sudo kann sich vom Stammprofil unterscheiden und darf nicht /usr/local/bin enthalten.
Problemumgehung
Aktualisieren Sie secure_path in /etc/sudoers so, dass /usr/local/bin enthalten ist. Alternativ können Sie einen symbolischen Link für crictl in einem anderen /bin-Verzeichnis erstellen.
Logging und Monitoring
1.10
stackdriver-log-forwarder hat [parser:cri] invalid
time format Warnungsprotokolle
Wenn der CRI-Parser (Container Runtime Interface) einen falschen regulären Ausdruck zum Parsen der Zeit verwendet, enthalten die Logs für den Pod stackdriver-log-forwarder Fehler und Warnungen wie die folgenden:
[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'
Workaround:
Umgehungsschritte ansehen
Führen Sie ein Upgrade des Clusters auf Version 1.11.0 oder höher durch.
Wenn Sie Ihre Cluster nicht sofort aktualisieren können, führen Sie die folgenden Schritte aus, um das CRI-Parsing des regulären Ausdrucks zu aktualisieren:
Verkleinern Sie stackdriver-operator, um zu verhindern, dass die folgenden Änderungen rückgängig gemacht werden:
Die bearbeitete Ressource sollte in etwa so aussehen:
[PARSER]
# https://rubular.com/r/Vn30bO78GlkvyB
Name cri
Format regex
# The timestamp is described in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6
Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9]
{2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9]
{2}:[0-9]{2})) (?<stream>stdout|stderr)
(?<logtag>[^ ]*) (?<log>.*)$
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
Time_Keep off
Bei den GKE on Bare Metal-Clusterversionen 1.10 bis 1.15 haben einige Kunden auf der Seite Abrechnung eine unerwartet hohe Abrechnung für Metrics volume festgestellt. Dieses Problem betrifft Sie nur, wenn alle der folgenden Umstände zutreffen:
Anwendungsmonitoring ist aktiviert (enableStackdriverForApplications=true)
Anwendungs-Pods haben die Annotation prometheus.io/scrap=true
Wenn Sie prüfen möchten, ob Sie von diesem Problem betroffen sind, Listen Sie Ihre benutzerdefinierten Messwerte auf. Wenn Sie die Abrechnung mit unerwünschten Messwerten sehen, betrifft Sie das Problem.
Problemumgehung
Wenn Sie von diesem Problem betroffen sind, empfehlen wir Ihnen, Ihre Cluster auf Version 1.12 zu aktualisieren und zur neuen Lösung für das Anwendungsmonitoring managed-service-for-prometheus zu wechseln, die dieses Problem behebt:
Separate Flags zur Steuerung der Erhebung von Anwendungslogs im Vergleich zu Anwendungsmesswerten
Gebündelter Google Cloud Managed Service for Prometheus
Wenn Sie kein Upgrade auf Version 1.12 durchführen können, führen Sie die folgenden Schritte aus:
Suchen Sie die Quell-Pods und -dienste mit der unerwünschten Abrechnung:
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
Entfernen Sie die Annotation prometheus.io/scrap=true aus dem Pod oder Dienst.
Logging und Monitoring
1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28
Änderungen an metrics-server-config werden nicht beibehalten
Eine hohe Pod-Dichte kann im Extremfall zu einem übermäßigen Logging- und Monitoringaufwand führen, was dazu führen kann, dass Metrics Server beendet und neu gestartet wird. Sie können die ConfigMap metrics-server-config bearbeiten, um mehr Ressourcen zuzuweisen, damit der Metrics Server weiter ausgeführt wird. Aufgrund des Abgleichs können jedoch Änderungen an metrics-server-config während einer Clusteraktualisierung oder eines Upgradevorgangs auf den Standardwert zurückgesetzt werden.
Metrics Server ist nicht sofort betroffen, aber beim nächsten Neustart übernimmt er die zurückgesetzte ConfigMap und ist wieder anfällig für übermäßigen Mehraufwand.
Problemumgehung
Für 1.11.x können Sie ein Script für die ConfigMap-Bearbeitung ausführen und sie zusammen mit Updates oder Upgrades für den Cluster ausführen. Wenden Sie sich ab Version 1.12 an den Support.
Logging und Monitoring
1,11, 1,12
Verworfene Messwerte wirken sich auf das Cloud Monitoring-Dashboard aus
Mehrere GKE on Bare Metal-Messwerte wurden verworfen. Ab GDCV für Bare Metal-Version 1.11 werden für diese verworfenen Messwerte keine Daten mehr erhoben. Wenn Sie diese Messwerte in einer Ihrer Benachrichtigungsrichtlinien verwenden, gibt es keine Daten, die die Benachrichtigungsbedingung auslösen.
In der folgenden Tabelle sind die einzelnen Messwerte, die eingestellt wurden, sowie die Messwerte aufgeführt, die sie ersetzen.
In GKE on Bare Metal-Clusterversionen vor 1.11 verwendet die Richtliniendefinitionsdatei für die empfohlene Anthos on baremetal node cpu usage exceeds
80 percent (critical)-Benachrichtigung die verworfenen Messwerte. Die JSON-Definitionsdatei node-cpu-usage-high.json wurde für Releases ab 1.11.0 aktualisiert.
Problemumgehung
Führen Sie die folgenden Schritte aus, um zu den Ersatzmesswerten zu migrieren:
Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche: Zu Monitoring
Wählen Sie im Navigationsbereich Dashboards aus und löschen Sie das Dashboard Status des Anthos-Clusterknotens.
Klicken Sie auf den Tab Beispielbibliothek und installieren Sie das Dashboard Knotenstatus des Anthos-Clusters neu.
Es kann vorkommen, dass der Logging-Agent fluent-bit bei der Verarbeitung beschädigter Blöcke hängen bleibt. Wenn der Logging-Agent beschädigte Blöcke nicht umgehen kann, stellen Sie unter Umständen fest, dass stackdriver-log-forwarder ständig mit dem Fehler CrashloopBackOff abstürzt. Wenn dieses Problem auftritt, enthalten Ihre Logs Einträge wie die folgenden:
[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5
in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0
Workaround:
Bereinigen Sie die Pufferblöcke für den Stackdriver Log Forwarder.
Hinweis: Ersetzen Sie in den folgenden Befehlen KUBECONFIG durch den Pfad zur kubeconfig-Datei des Administratorclusters.
Unbekannter Messwertfehler im Log des gke-metrics-agenten
gke-metrics-agent ist ein Daemonset, das Messwerte auf jedem Knoten erfasst und an Cloud Monitoring weiterleitet. Dadurch können Logs wie die folgenden erzeugt werden:
Diese Fehlerlogs können ignoriert werden, da die Messwerte, auf die sie sich beziehen, nicht unterstützt werden und für Monitoringzwecke nicht kritisch sind.
Logging und Monitoring
1,10; 1,11
Intermittierende Messwertexportunterbrechungen
Bei GKE on Bare-Metal-Clustern kann es im normalen Modus, beim kontinuierlichen Export von Messwerten oder bei fehlenden Messwerten auf einigen Knoten zu Unterbrechungen kommen. Wenn dieses Problem Ihre Cluster betrifft, sehen Sie möglicherweise Datenlücken für die folgenden Messwerte (mindestens):
Wenn Sie die CPU-Anfrage für gke-metrics-agent von 10m auf 50m erhöhen möchten, fügen Sie dem Manifest stackdriver den folgenden Abschnitt resourceAttrOverride hinzu:
Der Befehl ermittelt cpu: 50m, wenn Ihre Änderungen wirksam wurden.
Netzwerk
1.10
Mehrere Standardgateways unterbrechen die Konnektivität zu externen Endpunkten
Mehrere Standardgateways in einem Knoten können dazu führen, dass die Verbindung innerhalb eines Pods zu externen Endpunkten wie google.com unterbrochen wird.
Um festzustellen, ob Sie von diesem Problem betroffen sind, führen Sie den folgenden Befehl auf dem Knoten aus:
ip route show
Mehrere Instanzen von default in der Antwort weisen darauf hin, dass Sie betroffen sind.
Netzwerk
1.12
Änderungen an benutzerdefinierten Netzwerkressourcen in Nutzerclustern werden überschrieben
GKE on Bare-Metal-Cluster der Version 1.12.x verhindern nicht, dass Sie benutzerdefinierte Netzwerkressourcen in Ihrem Nutzercluster manuell bearbeiten. GKE on Bare Metal gleicht benutzerdefinierte Ressourcen in den Nutzerclustern mit den benutzerdefinierten Ressourcen in Ihrem Administratorcluster während Clusterupgrades ab. Durch diesen Abgleich werden alle Änderungen überschrieben, die direkt an den benutzerdefinierten Netzwerkressourcen im Nutzercluster vorgenommen wurden. Die benutzerdefinierten Netzwerkressourcen sollten nur im Administratorcluster geändert werden, aber Cluster der Version 1.12.x erzwingen diese Anforderung nicht.
Sie bearbeiten diese benutzerdefinierten Ressourcen in Ihrem Administratorcluster und der Abgleichsschritt wendet die Änderungen auf Ihre Nutzercluster an.
Problemumgehung
Wenn Sie eine der zuvor genannten benutzerdefinierten Ressourcen in einem Nutzercluster geändert haben, passen Sie die entsprechenden benutzerdefinierten Ressourcen in Ihrem Administratorcluster vor dem Upgrade an. Dadurch wird sichergestellt, dass Ihre Konfigurationsänderungen beibehalten werden. GKE on Bare Metal-Clusterversionen ab 1.13.0 verhindern, dass Sie die benutzerdefinierten Netzwerkressourcen in Ihren Nutzerclustern direkt ändern.
Netzwerk
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28
Pod-Konnektivitätsfehler und Filterung für umgekehrte Pfade
GKE on Bare Metal konfiguriert die umgekehrte Pfadfilterung für Knoten, um die Quellvalidierung (net.ipv4.conf.all.rp_filter=0) zu deaktivieren. Wenn die Einstellung rp_filter in 1 oder 2 geändert wird, schlagen Pods aufgrund von Zeitüberschreitungen bei der Kommunikation außerhalb des Knotens fehl.
Die umgekehrte Pfadfilterung wird mit rp_filter-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all) festgelegt. Dieser Wert kann auch durch sysctl überschrieben werden, in dem die Einstellungen für das Filtern von umgekehrten Pfaden in einer Konfigurationsdatei für die Netzwerksicherheit gespeichert werden, z. B. /etc/sysctl.d/60-gce-network-security.conf.
Problemumgehung
Die Pod-Verbindung kann mit einer der folgenden Problemumgehungen wiederhergestellt werden:
Setzen Sie den Wert für net.ipv4.conf.all.rp_filter manuell wieder auf 0 und führen Sie dann sudo sysctl -p aus, um die Änderung zu übernehmen.
Oder
Starten Sie den Pod anetd neu, um net.ipv4.conf.all.rp_filter wieder auf 0 zu setzen. Wenn Sie den anetd-Pod neu starten möchten, verwenden Sie die folgenden Befehle, um den anetd-Pod zu suchen und zu löschen. Daraufhin wird an seiner Stelle ein neuer anetd-Pod gestartet:
Ersetzen Sie ANETD_XYZ durch den Namen des Pods anetd.
Nachdem Sie eine der Problemumgehungen durchgeführt haben, prüfen Sie, ob der Wert net.ipv4.conf.all.rp_filter auf 0 gesetzt ist. Führen Sie dazu sysctl net.ipv4.conf.all.rp_filter auf jedem Knoten aus.
IP-Adressen von Bootstrap-Clustern (Art) und IP-Adressen von Clusterknoten überschneiden sich
192.168.122.0/24 und 10.96.0.0/27 sind die Standard-Pod- und Dienst-CIDRs, die vom Bootstrap-Cluster (Art) verwendet werden.
Preflight-Prüfungen schlagen fehl, wenn sie sich mit IP-Adressen der Maschinen von Clusterknoten überschneiden.
Problemumgehung
Um den Konflikt zu vermeiden, können Sie die Flags --bootstrap-cluster-pod-cidr und --bootstrap-cluster-service-cidr an bmctl übergeben, um unterschiedliche Werte anzugeben.
Betriebssystem
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28
Clustererstellung oder -upgrade schlägt unter CentOS fehl
Im Dezember 2020 haben die CentOS-Community und Red Hat die Einstellung von CentOS angekündigt. Am 31. Januar 2022 hat CentOS 8 das Ende des Produktzyklus (End of Life, EOL) erreicht. Infolge des EOL funktionieren yum-Repositories nicht mehr für CentOS, wodurch die Clustererstellung und Clusterupgrades fehlschlagen. Dies gilt für alle unterstützten CentOS-Versionen und wirkt sich auf alle Versionen von GKE on Bare Metal-Clustern aus.
Problemumgehung
Umgehungsschritte ansehen
Als Behelfslösung können Sie die folgenden Befehle ausführen, damit Ihr CentOS einen Archivfeed verwendet:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
/etc/yum.repos.d/CentOS-Linux-*
Als langfristige Lösung kann ein Wechsel zu einem anderen unterstützten Betriebssystem in Betracht gezogen werden.
Sicherheit
1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28
Container kann nicht in das Feld VOLUME schreiben, das im Dockerfile mit containerd und SELinux definiert ist
Wenn Sie containerd als Containerlaufzeit verwenden und auf Ihrem Betriebssystem SELinux aktiviert ist, ist der im Dockerfile der Anwendung definierte VOLUME möglicherweise nicht beschreibbar. Mit dem folgenden Dockerfile erstellte Container können beispielsweise nicht in den Ordner /tmp schreiben.
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
Wenn Sie prüfen möchten, ob Sie von diesem Problem betroffen sind, führen Sie den folgenden Befehl auf dem Knoten aus, auf dem der problematische Container gehostet wird:
ausearch -m avc
Wenn Sie von diesem Problem betroffen sind, wird ein denied-Fehler wie der folgende angezeigt:
Führen Sie eine der folgenden Änderungen aus, um dieses Problem zu umgehen:
Deaktivieren Sie SELinux.
Verwenden Sie das Feature VOLUME nicht im Dockerfile.
Upgrades und Updates
1.10, 1.11, 1.12
Node Problem Detector ist nach Clusterupgrades nicht standardmäßig aktiviert
Wenn Sie ein Upgrade von GKE on Bare-Metal-Clustern durchführen, ist Node Problem Detector standardmäßig nicht aktiviert. Dieses Problem gilt für Upgrades in den Versionen 1.10 bis 1.12.1 und wurde in Version 1.12.2 behoben.
Workaround:
So aktivieren Sie die Erkennung von Knotenproblemen:
Prüfen Sie, ob der node-problem-detector systemd-Dienst auf dem Knoten ausgeführt wird.
Stellen Sie mit dem SSH-Befehl eine Verbindung zum Knoten her.
Prüfen Sie, ob der node-problem-detector systemd-Dienst auf dem Knoten ausgeführt wird:
systemctl is-active node-problem-detector
Wenn im Ergebnis des Befehls inactive angezeigt wird, wird der Knotenproblemdetektor nicht auf dem Knoten ausgeführt.
Verwenden Sie den Befehl kubectl edit und bearbeiten Sie die ConfigMap node-problem-detector-config, um die Erkennung von Knotenproblemen zu aktivieren. Weitere Informationen finden Sie unter Erkennung von Knotenproblemen.
Vorgang
1,9; 1,10
Die Clustersicherung schlägt bei Verwendung von Nicht-Root-Anmeldung fehl
Der Befehl bmctl backup cluster schlägt fehl, wenn nodeAccess.loginUser auf einen Nicht-Root-Nutzernamen festgelegt ist.]
Workaround:
Dieses Problem betrifft die Versionen 1.9.x, 1.10.0 und 1.10.1 und wurde in Version 1.10.2 und höher behoben.
Netzwerk
1.10, 1.11, 1.12
Load-Balancer-Dienste funktionieren nicht mit Containern im Hostnetzwerk der Steuerungsebene
Es gibt einen Fehler in anetd, bei dem Pakete für LoadBalancer-Dienste verworfen werden, wenn die Back-End-Pods auf dem Knoten der Steuerungsebene ausgeführt werden und das Feld hostNetwork: true in der Containerspezifikation verwenden.
Der Fehler tritt in Version 1.13 oder höher nicht auf.
Workaround:
Die folgenden Behelfslösungen können hilfreich sein, wenn Sie einen LoadBalancer-Dienst verwenden, der von hostNetwork-Pods unterstützt wird:
Führen Sie sie auf Worker-Knoten aus (nicht auf Knoten der Steuerungsebene).
Verwaister Pod anthos-version-$version$ kann kein Image abrufen
Beim Clusterupgrade von 1.12.x auf 1.13.x tritt möglicherweise ein fehlgeschlagener anthos-version-$version$-Pod mit ImagePullBackOff-Fehler auf.
Dies liegt daran, dass für anthos-cluster-operator ein Upgrade durchgeführt wird und es sich nicht auf reguläre Clusterfunktionen auswirken sollte.
Nach Version 1.13 oder höher tritt der Fehler nicht mehr auf.
Workaround:
Löschen Sie den Job von dynamic-version-installer bis kubectl delete job anthos-version-$version$ -n kube-system
Upgrades und Updates
1.13
1.12-Cluster, die von 1.11 aktualisiert wurden, können nicht auf 1.13.0 aktualisiert werden
Cluster der Version 1.12, die von Version 1.11 aktualisiert wurden, können nicht auf Version 1.13.0 aktualisiert werden. Dieses Upgradeproblem gilt nicht für Cluster, die mit Version 1.12 erstellt wurden.
Prüfen Sie die Logs des Upgradejobs, der im Administratorcluster den String upgrade-first-no* enthält, um festzustellen, ob Sie betroffen sind.
Wenn die folgende Fehlermeldung angezeigt wird, sind Sie davon betroffen.
Versuchen Sie noch einmal, das Clusterupgrade durchzuführen.
Logging und Monitoring
1.16.2, 1.16.3
Hohe CPU-Auslastung für stackdriver-operator
Es gibt ein Problem mit stackdriver-operator, das dazu führt, dass mehr CPU-Zeit beansprucht wird als normal. Die normale CPU-Nutzung beträgt im Ruhezustand weniger als 50 MilliCPU (50m) für stackdriver-operator. Die Ursache ist eine Abweichung der Zertifikatsressourcen, die stackdriver-operator mit den Erwartungen von cert-manager anwendet. Diese Abweichung führt beim Aktualisieren dieser Ressourcen zu einer Wettlaufbedingung zwischen cert-manager und stackdriver-operator.
Dieses Problem kann bei Clustern mit eingeschränkter CPU-Verfügbarkeit zu einer verringerten Leistung führen.
Workaround:
Bis Sie ein Upgrade auf eine Version durchführen können, die diesen Fehler behoben hat, verwenden Sie die folgende Problemumgehung:
Wenden Sie eine benutzerdefinierte AddonConfiguration-Ressource an, um stackdriver-operator vorübergehend auf 0 Replikate herunterzuskalieren:
Anmerkungsbasiertes Scraping von Messwerten funktioniert nicht
In der Nebenversion der GDCV für Bare Metal 1.16 wurde das Feld enableStackdriverForApplications in der benutzerdefinierten Ressourcenspezifikation stackdriver eingestellt. Dieses Feld wird durch die beiden Felder enableCloudLoggingForApplications und enableGMPForApplications in der benutzerdefinierten Stackdriver-Ressource ersetzt.
Wir empfehlen Ihnen, Ihre Arbeitslasten mit Google Cloud Managed Service for Prometheus zu überwachen. Verwenden Sie das Feld enableGMPForApplications, um dieses Feature zu aktivieren.
Wenn Sie sich auf die Messwerterfassung verlassen, die durch prometheus.io/scrape-Annotationen für Ihre Arbeitslasten ausgelöst wird, können Sie das Feature-Gate-Flag annotationBasedApplicationMetrics verwenden, um das alte Verhalten beizubehalten. Es gibt jedoch ein Problem, das verhindert, dass annotationBasedApplicationMetrics richtig funktioniert, sodass Messwerte aus Ihren Anwendungen nicht in Cloud Monitoring erfasst werden können.
Workaround:
Führen Sie ein Upgrade Ihres Clusters auf Version 1.16.2 oder höher durch, um dieses Problem zu beheben.
Die anmerkungsbasierte Erfassung von Arbeitslastmesswerten, die durch das Feature-Gate annotationBasedApplicationMetrics aktiviert wird, erfasst Messwerte für Objekte mit der Annotation prometheus.io/scrape. Viele Softwaresysteme, die als Open-Source-Software genutzt wurden, können diese Annotation verwenden. Wenn Sie diese Methode der Messwerterfassung weiterhin verwenden, sollten Sie sich dieser Abhängigkeit bewusst sein, damit Sie nicht über die Messwertgebühren in Cloud Monitoring überrascht werden.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.
Dashboards aus und löschen Sie das Dashboard Status des Anthos-Clusterknotens.