Auf dieser Seite werden alle bekannten Probleme für Anthos-Cluster auf Bare Metal aufgeführt. Wählen Sie zum Filtern der bekannten Probleme nach einer Produktversion oder Kategorie die gewünschten Filter aus den folgenden Drop-down-Menüs aus.
Wählen Sie Ihre Version von Anthos-Clustern auf Bare Metal aus:
Wählen Sie eine Problemkategorie aus:
Sie können auch nach Ihrem Problem suchen:
Kategorie
Ermittelte Version(en)
Problem und Problemumgehung
Netzwerk, Betrieb
1.10, 1.11, 1.12, 1.13, 1.14
Anthos Network Gateway-Komponenten, die entfernt wurden oder ausstehend sind, weil die Prioritätsklasse fehlt
Netzwerk-Gateway-Pods in kube-system können den Status Pending oder Evicted haben, wie in der folgenden verkürzten Beispielausgabe gezeigt:
Diese Fehler weisen auf Bereinigungsereignisse oder auf die Unmöglichkeit hin, Pods aufgrund von Knotenressourcen zu planen. Da Anthos Network Gateway-Pods keine PriorityClass haben, haben sie dieselbe Standardpriorität wie andere Arbeitslasten.
Wenn Knoten durch Ressourcen beschränkt sind, werden die Netzwerk-Gateway-Pods möglicherweise entfernt. Dieses Verhalten ist insbesondere für das ang-node-DaemonSet schlecht, da diese Pods auf einem bestimmten Knoten geplant werden können 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 den Anthos Network Gateway-Komponenten manuell eine PriorityClass zuweisen. Die Anthos-Cluster auf Bare Metal-Controller überschreiben diese manuellen Änderungen während eines Abgleichsprozesses, z. B. bei einem Cluster-Upgrade.
Weisen Sie den Deployment-Controllern Cluster ang-controller-manager und autoscaler die Priorität system-cluster-critical zu.
Weisen Sie dem ang-daemon-Knoten-DaemonSet die Prioritätsklasse 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 länger als 48 Zeichen (Version 1.15.0) oder 45 Zeichen (Version 1.15.1 oder 1) ist. Beim Erstellen und Upgraden von Clustern wird für Anthos-Cluster auf Bare Metal eine Systemdiagnoseressource mit einem Namen erstellt, der den Clusternamen und die Clusterversion enthält:
Bei Clustern der Version 1.15.0 lautet der Ressourcenname der Systemdiagnose CLUSTER_NAME-add-ons-CLUSTER_VER.
Für Cluster der Version 1.15.1 oder 1.15.2 lautet der Ressourcenname der Systemdiagnose CLUSTER_NAME-kubernetes-CLUSTER_VER.
Bei langen Clusternamen überschreitet der Systemdiagnoseressourcenname die Zeichenbeschränkung von Kubernetes 63 für Labelnamen, wodurch das Erstellen der Systemdiagnoseressource verhindert wird.
Ohne eine erfolgreiche Systemdiagnose schlägt der Clustervorgang fehl.
Prüfen Sie mit kubectl describe, ob Sie von diesem Problem betroffen sind:
Wenn dieses Problem Sie betrifft, enthält die Antwort eine Warnung für 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 Clusteraktualisierung oder -erstellung aufheben möchten, können Sie die Systemdiagnose umgehen. Verwenden Sie den folgenden Befehl, um die benutzerdefinierte Ressource mit Systemdiagnose mit Patching-Status zu patchen: (status: {pass: true})
Cluster mit Version 1.14.0 und 1.14.1 mit Vorschaufunktionen können nicht auf Version 1.15.x aktualisiert werden.
Wenn für Cluster der Version 1.14.0 und 1.14.1 ein Vorschaufeature aktiviert ist, ist kein Upgrade auf Version 1.15.x mehr möglich. Dies gilt für Vorschaufeatures wie die Möglichkeit, einen Cluster ohne kube-proxy zu erstellen. Dieser ist mit der folgenden Annotation in der Clusterkonfigurationsdatei aktiviert:
Wenn Sie von diesem Problem betroffen sind, erhalten Sie während des Clusterupgrades eine Fehlermeldung wie die folgende:
[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 Anthos-Clustern mit Bare-Metal-Version 1.14.2 und höher behoben.
Workaround:
Wenn ein Upgrade Ihrer Cluster auf Version 1.14.2 oder höher nicht möglich ist, können Sie direkt mit einem Bootstrap-Cluster auf Version 1.15.x upgraden:
bmctl upgrade cluster --use-bootstrap=true
Vorgang
1.15
Cluster mit Version 1.15 akzeptieren keine doppelten Floating-IP-Adressen
Mit Anthos Network Gateway können Sie keine neuen benutzerdefinierten Ressourcen vom Typ NetworkGatewayGroup erstellen, die IP-Adressen in spec.floatingIPs enthalten, die bereits in vorhandenen benutzerdefinierten NetworkGatewayGroup-Ressourcen verwendet werden. Diese Regel wird von einem Webhook in Anthos-Clustern auf Bare-Metal-Version 1.15.0 und höher erzwungen. Bereits vorhandene Floating-IP-Adressen verursachen keine Fehler. Der Webhook verhindert nur das Erstellen neuer benutzerdefinierter NetworkGatewayGroups-Ressourcen mit doppelten IP-Adressen.
Die Webhook-Fehlermeldung gibt die in Konflikt stehende IP-Adresse und die vorhandene benutzerdefinierte Ressource an, die sie bereits verwendet:
IP address exists in other gateway with name default
In der ersten Dokumentation zu erweiterten Netzwerkfeatures wie dem NAT-Gateway für ausgehenden Traffic können Sie doppelte IP-Adressen nicht berücksichtigen.
Anfangs wurde nur die Ressource NetworkGatewayGroup mit dem Namen default vom Abgleich erkannt. Anthos Network Gateway erkennt jetzt alle benutzerdefinierten NetworkGatewayGroup-Ressourcen im System-Namespace. Vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen werden unverändert beibehalten.
Workaround:
Fehler treten nur beim Erstellen einer neuen benutzerdefinierten Ressource vom Typ NetworkGatewayGroup auf.
So beheben Sie den Fehler:
Verwenden Sie den folgenden Befehl, um NetworkGatewayGroups benutzerdefinierte Ressourcen aufzulisten:
kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
-n kube-system -o yaml
Öffnen Sie vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen und entfernen Sie in Konflikt stehende Floating-IP-Adressen (spec.floatingIPs):
Schließen und speichern Sie bearbeitete benutzerdefinierte Ressourcen, um Ihre Änderungen zu übernehmen.
Anthos-VM-Laufzeit
1.13.7
VMs werden möglicherweise nicht auf 1.13.7-Clustern gestartet, die eine private Registry verwenden
Wenn Sie die Anthos-VM-Laufzeit 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 Anthos-Clustern mit Bare-Metal-Version 1.14.0 und höher behoben.
Problemumgehung
Wenn Sie Ihre Cluster nicht sofort upgraden können, können Sie Images manuell abrufen. Mit den folgenden Befehlen rufen Sie das MACNI-CNI-Plug-in-Image für Ihre VM ab und übertragen es per Push in Ihre private Registry:
Ersetzen Sie REG_HOST durch den Domainnamen eines lokal gespiegelten Hosts.
Installation
1,11, 1,12
Beim Erstellen des Clusters im Artcluster kann der gke-metric-agent-Pod nicht gestartet werden
Während der Clustererstellung im Artcluster kann der gke-metrics-agent-Pod aufgrund eines Fehlers beim Abrufen des Images so 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 sehen 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 Fehler „Fehler beim Abrufen“ angezeigt:
gcr.io/gke-on-prem-staging/gke-metrics-agent
Problemumgehung
Trotz der Fehler wird der Clustererstellungsprozess nicht blockiert, da der Zweck des gke-metrics-agent-Pods in Artclustern die Erfolgsquote bei der Clustererstellung sowie das interne Tracking und Monitoring erleichtert wird.
Daher können Sie diesen Fehler ignorieren.
Problemumgehung
Trotz der Fehler wird der Clustererstellungsprozess nicht blockiert, da der Zweck des gke-metrics-agent-Pods in Artclustern die Erfolgsquote bei der Clustererstellung sowie das interne Tracking und Monitoring erleichtert wird.
Daher können Sie diesen Fehler ignorieren.
Betrieb, Netzwerk
1,12, 1,13, 1,14, 1,15
Beim Zugriff auf einen IPv6-Dienstendpunkt stürzt der LoadBalancer-Knoten unter CentOS oder RHEL ab
Wenn Sie auf einen Dual-Stack-Dienst (ein 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 Kernel-Version kernel-4.18.0-372.46.1.el8_6. Diese Kernel-Version ist standardmäßig in CentOS und RHEL Version 8.6 und höher verfügbar.
Netzwerk
1.11, 1.12, 1.13, 1.14.0
Zeitweilige Verbindungsprobleme nach dem Neustart des Knotens
Nach dem Neustart eines Knotens können zeitweise Verbindungsprobleme für einen NodePort- oder LoadBalancer-Dienst auftreten. Beispielsweise kann es zu vorübergehenden TLS-Handshake- oder Verbindungsfehlern kommen. Dieses Problem wurde für Anthos-Cluster mit Bare-Metal-Version 1.14.1 und höher behoben.
Prüfen Sie anhand der iptables-Weiterleitungsregeln auf Knoten, auf denen der Back-End-Pod für den betroffenen Dienst ausgeführt wird, ob das Problem Auswirkungen hat:
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, bei 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 Pod neu gestartet haben, sollte die Weiterleitungsregel in iptables korrekt konfiguriert sein.
Die folgende Beispielausgabe zeigt, dass die Regel CILIUM_FORWARD jetzt korrekt konfiguriert ist als die Regel KUBE-FORWARD:
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
Das Vorschaufeature enthält nicht die ursprünglichen Berechtigungen und Inhaberinformationen.
Die Vorschaufunktion des Clusters 1.9.x 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 ermitteln, ob Sie von diesem Feature betroffen sind:
tar -xzvf BACKUP_FILE
Problemumgehung
Prüfe, ob metadata.json vorhanden ist und ob bmctlVersion 1.9.x ist. Wenn metadata.json nicht vorhanden ist, führen Sie ein Upgrade auf den Cluster 1.10.x aus und verwenden Sie bmctl 1.10.x zum Sichern/Wiederherstellen.
Upgrades und Erstellungen
1.14.2
clientconfig-operator bleibt mit CreateContainerConfigError im Status „Ausstehend“
Wenn Sie ein Upgrade auf einen Cluster der Version 1.14.2 mit einer OIDC/LDAP-Konfiguration durchgeführt oder ein Upgrade dafür erstellt haben, wird der Pod clientconfig-operator möglicherweise im Status „Ausstehend“ hängen gelassen. Bei diesem Problem gibt es zwei clientconfig-operator-Pods, einer davon im Status „Wird ausgeführt“ und der andere im Status „Ausstehend“.
Dieses Problem gilt nur für Anthos-Cluster auf Bare-Metal-Version 1.14.2. Ältere Versionen wie 1.14.0 und 1.14.1 sind nicht betroffen. Dieses Problem wurde in Version 1.14.3 und allen nachfolgenden Releases behoben, einschließlich 1.15.0 und höher.
Workaround:
Als Behelfslösung können Sie das clientconfig-operator-Deployment patchen, um zusätzlichen Sicherheitskontext hinzuzufügen und dafür zu sorgen, dass das Deployment bereit ist.
Verwenden Sie den folgenden Befehl, um clientconfig-operator im Zielcluster zu patchen:
CLUSTER_KUBECONFIG ist 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 für Cluster ohne gebündeltes Load-Balancing fehl
Bei Clustern ohne gebündeltes Load-Balancing (spec.loadBalancer.mode auf manual festgelegt) kann der Befehl bmctl update credentials certificate-authorities rotate nicht 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 Meldung aus, bevor er nicht reagiert:
Signing CA completed in 3/0 control-plane nodes
In diesem Fall schlägt der Befehl fehl. Das Log der Zertifizierungsstelle für einen Cluster mit drei Steuerungsebenen kann Einträge wie den 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 Hilfe 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 (ein Cluster mit IPv4- und IPv6-Adressen) bereitstellen, können die ipam-controller-manager-Pods eine Absturzschleife verursachen. Dieses Verhalten führt dazu, dass die Knoten zwischen Ready und NotReady wechseln und 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:
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
etcd Watch Hunger
Bei Clustern mit der etcd-Version 3.4.13 oder niedriger können Watch-Wartungsaufgaben und nicht operative Ressourcenüberwachung ausfallen. Dies kann zu den folgenden Problemen führen:
Pod-Planung ist unterbrochen
Knoten können nicht registriert werden
Kubelet berücksichtigt keine Pod-Änderungen
Diese Probleme können dazu führen, dass der Cluster nicht mehr funktioniert.
Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Releases 1.12.9, 1.13.6, 1.14.3 und den nachfolgenden Releases behoben. Diese neueren Versionen verwenden die etcd-Version 3.4.21. Alle vorherigen Versionen von Anthos-Clustern auf Bare Metal sind von diesem Problem betroffen.
Problemumgehung
Wenn Sie das Upgrade nicht sofort ausführen können, verringern Sie das Risiko eines Clusterfehlers, 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 den Messwert dann in den Untermenüs 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 „Übernehmen“.
Netzwerk
1.11.6, 1.12.3
vfio-pci-Modus des SR-IOV-Operators „Fehlgeschlagen“
Der syncStatus des SriovNetworkNodeState-Objekts kann den Wert „Failed“ für einen konfigurierten Knoten melden. Führen Sie den folgenden Befehl aus, um den Status eines Knotens aufzurufen und zu prüfen, ob das Problem sich auf Sie auswirkt:
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 SriovNetworkNodeState-Objektstatus „Fehlgeschlagen“ lautet, aktualisieren Sie auf Anthos-Cluster auf Bare-Metal-Version 1.11.7 oder höher oder Version 1.12.4 oder höher.
Upgrades und Updates
1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1
Einige Worker-Knoten sind nach dem Upgrade nicht mehr bereit
Nachdem das Upgrade abgeschlossen ist, wird für einige Worker-Knoten möglicherweise die Status „Bereit“ auf false gesetzt. Für die Knotenressource wird ein Fehler neben der „Bereit“-Bedingung 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 bei der angehaltenen Maschine anmelden, ist die CNI-Konfiguration auf der Maschine leer:
sudo ls /etc/cni/net.d/
Problemumgehung
Starten Sie den anetd-Pod des Knotens neu. Löschen Sie dazu den Pod.
Upgrades und Updates, Sicherheit
1.10
Mehrere Zertifikatsrotationen vom Zertifikatmanager führen zu Inkonsistenzen
Nach mehreren manuellen oder automatischen Zertifikatsrotationen wird der Webhook-Pod, z. B. anthos-cluster-operator, nicht mit den neuen Zertifikaten von cert-manager aktualisiert. 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 in den folgenden Fällen auftreten:
Wenn Sie zwei manuelle Zertifikatzertifikate für einen Cluster ausgeführt haben, der älter als 180 Tage ist, und den Anthos-Cluster-Operator nie neu gestartet haben.
Wenn Sie eine manuelle cert-manager-Zertifikatsrotation für einen Cluster durchgeführt haben, der älter als 90 Tage ist, und den Anthos-Cluster-Operator nie neu gestartet hat.
Problemumgehung
Starten Sie den Pod neu, indem Sie den anthos-cluster-Operator beenden.
Upgrades und Updates
1.14.0
Veraltete Lebenszyklus-Controller-Bereitsteller-Pods, die beim Upgrade des Nutzerclusters erstellt wurden
In Version 1.14.0-Administratorclustern können während Nutzerupgrades ein oder mehrere veraltete Lebenszyklus-Controller-Deployment-Pods erstellt werden.
Dieses Problem tritt auf Nutzercluster auf, die ursprünglich in Versionen unter 1.12 erstellt wurden. Die unbeabsichtigt erstellten Pods wirken sich nicht auf Upgradevorgänge aus, können aber im abnormalen Zustand auftreten. Wir empfehlen, die veralteten Pods zu entfernen.
Dieses Problem wurde in Version 1.14.1 behoben.
Workaround:
So entfernen Sie die veralteten Lebenszyklus-Controller-Bereitsteller-Pods:
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.
Löschen Sie Ressourcen, deren Wert in der Spalte „Pass“ entweder true oder false ist.
Verwenden Sie beispielsweise die folgenden Befehle, um die Ressourcen in der vorherigen Beispielausgabe zu löschen:
Status BGPSession ändert sich aufgrund der großen Anzahl eingehender Routen ständig
Anthos-Cluster in erweiterten Bare-Metal-Netzwerken können BGP-Sitzungen nicht korrekt verwalten, wenn externe Peers eine große Anzahl von Routen bewerben (etwa 100 oder mehr). Bei einer großen Anzahl von eingehenden Routen dauert der Knoten-lokale BGP-Controller zu lange, um BGP-Sitzungen abzugleichen, und kann den Status nicht aktualisieren. Liegen keine Statusaktualisierungen oder eine Systemdiagnose vor, wird die Sitzung gelöscht.
Unerwünschtes Verhalten in BGP-Sitzungen, das Sie bemerken und auf ein Problem hinweisen können, ist Folgendes:
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.
BGP-Load-Balancing-Probleme können bei Verbindungsproblemen mit LoadBalancer-Diensten auftreten.
Das BGP-FlatIP-Problem kann bei Verbindungsproblemen mit Pods erkennbar sein.
Wenn Sie herausfinden möchten, ob Ihre BGP-Probleme durch Remote-Peers verursacht werden, die zu viele Routen anbieten, können Sie die folgenden Status und Ausgaben mit den folgenden Befehlen prüfen:
Verwenden Sie kubectl get bgpsessions für den betroffenen Cluster.
Die Ausgabe zeigt bgpsessions mit dem Status „Nicht festgelegt“ und die letzte Zeit des Berichts dauert bis zu 10–12 Sekunden, bis es 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']}"
Logmeldungen weisen darauf hin, 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 verhindern Sie die Anzahl der Routen, die vom Remote-Peer zum Cluster mit einer Exportrichtlinie beworben werden.
In Anthos-Clustern auf Bare-Metal-Version 1.14.2 und höher können Sie das Feature, das empfangene Routen verarbeitet, mit einem AddOnConfiguration deaktivieren. Fügen Sie dem bgpd-Container des ang-daemon-Daemonset das Argument --disable-received-routes hinzu.
Netzwerk
1,14, 1,15
Zeitüberschreitungen bei Anwendungen aufgrund von Fehlern beim Einfügen der Conntrack-Tabelle
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 Netfilter-Verbindungstabellen (Conntrack). Fehler beim Einfügen können auch dann auftreten, wenn in der Conntrack-Tabelle Platz für neue Einträge ist. Die Fehler werden durch Änderungen im Kernel 5.15 und höher verursacht, durch die Tabellenbereitstellungen basierend auf der Kettenlänge eingeschränkt werden.
Wenn Sie wissen möchten, ob Sie von diesem Problem betroffen sind, können Sie die Statistiken für das In-Kernel-Verbindungs-Tracking mit dem folgenden Befehl prüfen:
Wenn ein chaintoolong-Wert in der Antwort eine Zahl ungleich null ist, sind Sie von diesem Problem betroffen.
Problemumgehung
Die vorläufige Risikominderung besteht darin, die Größe der Netfiler-Hash-Tabelle (nf_conntrack_buckets) und der Netfilter-Verbindungs-Tracking-Tabelle (nf_conntrack_max) zu erhöhen. Verwenden Sie die folgenden Befehle auf jedem Clusterknoten, um die Größe der Tabellen zu erhöhen:
Ersetzen Sie TABLE_SIZE durch eine neue Größe in Byte. Der Standardwert für die Tabellengröße ist 262144. Wir empfehlen, einen Wert festzulegen, der der 65.536-fachen 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 für einige Versionen nicht wiederhergestellt werden
Wir empfehlen, Ihre Cluster vor dem Upgrade zu sichern, damit Sie die vorherige 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 angegebenen Versionen nicht wiederhergestellt werden können. Dieses Problem betrifft insbesondere Upgrades, bei denen Sie eine Sicherung aus 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 Cluster 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 hat
NetworkGatewayGroup kann keine Daemons für Knoten erstellen, die nicht sowohl IPv4- als auch IPv6-Schnittstellen haben. Dadurch können Features wie BGP-Load-Balancer und Outbound-NAT fehlschlagen. Wenn Sie die Logs des fehlgeschlagenen ang-node-Pods im kube-system-Namespace prüfen, werden ähnliche 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- und NDP-Verbindung zur lokalen IP-Adresse des Links herzustellen. Ist die IP-Adresse nicht vorhanden (IPv4 für ARP, IPv6 für NDP), schlägt die Verbindung fehl und der Daemon wird nicht fortgesetzt.
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 enthält, eine IPv4- oder IPv6-Adresse hinzu. Im vorherigen Beispiel für den Logeintrag lautete 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 soll.
Zurücksetzen/Löschen
1.10, 1.11, 1.12, 1.13.0–1.13.2
anthos-cluster-operator-Absturzschleife beim Entfernen eines Knotens der Steuerungsebene
Wenn Sie versuchen, einen Knoten der Steuerungsebene zu entfernen, indem Sie die IP-Adresse aus Cluster.Spec entfernen, gerät anthos-cluster-operator in einen Absturzschleifenstatus, der andere 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 durchführen
Führen Sie als Behelfslösung den folgenden Befehl aus:
IP_ADDRESS: Die IP-Adresse des Knotens im Absturzschleifenstatus.
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 abweichenden Tokens fehl
Wenn Sie Anthos-Cluster auf Bare Metal mit einer großen Anzahl von Knoten installieren, wird möglicherweise eine kubeadmin join-Fehlermeldung wie im 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 Anthos-Clustern auf 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 und passen Sie dann die Größe des Clusters an, um nach Abschluss der Installation zusätzliche Knoten hinzuzufügen.
Logging und Monitoring
1.10, 1.11, 1.12, 1.13.0
Niedriges CPU-Limit für metrics-server in Edge-Clustern
In Anthos-Clustern auf 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, da metrics-server fehlerhaft ist.
Wenn das CPU-Limit von metrics-server unter 40m liegt, können Ihre Cluster betroffen sein. Prüfen Sie eine der folgenden Dateien, um die CPU-Limits metrics-server zu prüfen:
Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Version 1.13.1 oder höher behoben. Führen Sie ein Upgrade Ihrer Cluster durch, um dieses Problem zu beheben.
Eine kurzfristige Problemumgehung ist, bis Sie ein Clusterupgrade durchführen, indem Sie die CPU-Limits für metrics-server manuell erhöhen:
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><--- CPU,
[...] Increase 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 die metrics-server, um die Änderungen zu übernehmen.
Netzwerk
1,14, 1,15
Direkte NodePort-Verbindung zum hostNetwork-Pod funktioniert nicht
Eine Verbindung zu einem Pod, der über hostNetwork über den NodePort-Dienst aktiviert wurde, schlägt fehl, wenn sich der Back-End-Pod auf demselben Knoten wie der Ziel-NodePort befindet. Dieses Problem betrifft LoadBalancer-Dienste, wenn es mit Hostnetzwerk-Pods verwendet wird. Bei mehreren Back-Ends kann es zu einem sporadischen Verbindungsfehler kommen.
Dieses Problem wird durch einen Fehler im eBPF-Programm verursacht.
Workaround:
Verwenden Sie bei Verwendung eines Nodeport-Dienstes kein Targeting auf den Knoten, auf dem einer der Back-End-Pods ausgeführt wird. Achten Sie bei Verwendung des LoadBalancer-Dienstes darauf, dass die vom Hostnetzwerk gehosteten Pods 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 von 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 die gleiche Version wie der Administratorcluster aus.
Upgrades und Updates
1.12
Das Upgrade auf 1.13.x wird für Administratorcluster mit Worker-Knotenpools blockiert
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 wurde, können Sie prüfen, ob Worker-Knotenpools die Ursache sind, indem Sie den folgenden Fehler in der Datei upgrade-cluster.log im Ordner bmctl-workspace prüfen:
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
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 setzt Ihre Eingabe und die gewünschten Änderungen zurück.
Sie können beispielsweise die benutzerdefinierte Ressource Stackdriver so bearbeiten, indem 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. Verwenden Sie stattdessen kubectl edit oder kubectl patch, wie in den folgenden Beispielen gezeigt:
Bearbeiten Sie die benutzerdefinierte Stackdriver-Ressource:
Der Absturz stackdriver-log-forwarder, wenn versucht wird, einen beschädigten Rückstandsblock 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 keine Logs in Cloud Logging angezeigt.
Workaround:
So beheben Sie diese Fehler:
Identifizieren Sie die beschädigten Backlog-Blöcke. 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 in var/log/fluent-bit-buffers/tail.1/ gespeicherte Datei tail.1/1-1659339894.252926599.flb fehlerhaft. Jede *.flb-Datei, deren Formatierung fehlgeschlagen ist, muss entfernt werden.
Beenden Sie die ausgeführten Pods für stackdriver-log-forwarder:
Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres Nutzerclusters.
Achten Sie darauf, dass die stackdriver-log-forwarder-Pods gelöscht werden, bevor Sie mit dem nächsten Schritt fortfahren.
Stellen Sie eine SSH-Verbindung zum Knoten her, auf dem stackdriver-log-forwarder ausgeführt wird.
Löschen Sie auf dem Knoten alle beschädigten *.flb-Dateien in var/log/fluent-bit-buffers/tail.1/.
Wenn es zu viele beschädigte Dateien gibt und Sie ein Skript anwenden möchten, um alle Rückstandsblöcke zu bereinigen, verwenden Sie die folgenden Skripts:
Stellen Sie ein DaemonSet bereit, um alle unsicheren Daten in Zwischenspeichern in fluent-bit zu bereinigen:
Wenn Sie Dataplane V2 (anetd) auf Clustern neu starten, können vorhandene VMs nicht mehr an ein Nicht-Pod-Netzwerk angehängt werden
Auf Multi-nic-Clustern kann ein Neustart von Dataplane V2 (anetd) dazu führen, dass virtuelle Maschinen keine Verbindung zu Netzwerken herstellen können. In den Pod-Logs von anetd kann ein Fehler wie der folgende auftreten:
could not find an allocator to allocate the IP of the multi-nic endpoint
Workaround:
Sie können die VM als Schnelllösung neu starten. Führen Sie ein Upgrade auf Anthos-Cluster auf Bare Metal 1.14.1 oder höher durch, um eine Wiederholung des Problems zu vermeiden.
Vorgang
1.13, 1.14.0, 1.14.1
gke-metrics-agent hat kein Speicherlimit für Edge-Profilcluster
Je nach Arbeitslast des Clusters kann gke-metrics-agent mehr als 4.608 MiB Arbeitsspeicher belegen. Dieses Problem betrifft nur Anthos-Cluster auf Bare-Metal-Edge-Profilclustern. Standardprofilcluster sind davon nicht betroffen.
Workaround:
Aktualisieren Sie Ihren Cluster auf Version 1.14.2 oder höher.
Installation
1,12, 1,13
Das Erstellen des Clusters kann aufgrund von Race-Bedingungen fehlschlagen
Wenn Sie Cluster mit kubectl erstellen, wird die Preflight-Prüfung aufgrund von Race-Bedingungen möglicherweise nicht abgeschlossen. Daher kann die Clustererstellung in bestimmten Fällen fehlschlagen.
Der Preflight-Abgleichabgleich erstellt ein SecretForwarder, um das standardmäßige ssh-key-Secret in den Ziel-Namespace zu kopieren.
In der Regel wird die Preflight-Prüfung auf die Inhaberreferenzen und Abgleiche angewendet, wenn SecretForwarder abgeschlossen ist. In seltenen Fällen kann die Inhaberreferenz von SecretForwarder jedoch die Referenz auf die Preflight-Prüfung verlieren, wodurch die Preflight-Prüfung hängt. Daher schlägt die Clustererstellung fehl. Löschen Sie den Cluster-Operator-Pod oder die Preflight-Check-Ressource, um den Abgleich für die Controller-basierte Preflight-Prüfung fortzusetzen. Wenn Sie die Preflight-Check-Ressource löschen, wird eine weitere Ressource erstellt und der Abgleich fortgesetzt. Alternativ können Sie Ihre vorhandenen Cluster, die mit einer früheren Version erstellt wurden, auf eine korrigierte Version upgraden.
Netzwerk
1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Reservierte IP-Adressen werden nicht freigegeben, wenn das „abouts“-Plug-in mit der Funktion „Multi-NIC“ verwendet wird.
Wenn Sie im Multi-Nic-Feature das CNI-Plug-in "aboutabout" verwenden und den CNI-DEL-Vorgang zum Löschen einer Netzwerkschnittstelle für einen Pod verwenden, werden einige reservierte IP-Adressen möglicherweise nicht richtig freigegeben. Dies tritt auf, wenn der CNI-DEL-Vorgang unterbrochen wird.
Sie können die nicht verwendeten IP-Adressreservierungen der Pods mit dem folgenden Befehl prüfen:
kubectl get ippools -A --kubeconfig KUBECONFIG_PATH
Problemlösung:
Löschen Sie nicht verwendete IP-Adressen (ippools).
Installation
1.10, 1.11.0, 1.11.1, 1.11.2
Knotenproblemerkennung in 1.10.4-Nutzercluster schlägt fehl
Der Node Problem Detector kann in den Clustern von Anthos Cluster on Bare Metal 1.10.x fehlschlagen, wenn Administratorcluster von Anthos on Bare Metal 1.11.0, 1.11.1 oder 1.11.2 Nutzercluster von Version 1.10.x verwalten. Wenn der Node Problem Detector ausfällt, 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
IPv4-Clusterknoten im Inselmodus 1.14 haben eine Pod-CIDR-Maskengröße von 24
In Release 1.14 wird die Einstellung maxPodsPerNode für Cluster im Inselnmodus nicht berücksichtigt. Daher wird den Knoten eine Pod-CIDR-Maskengröße von 24 (256 IP-Adressen) zugewiesen.nDies kann dazu führen, dass der Cluster nicht mehr die erwarteten IP-Adressen des Clusters erreicht. 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. Es kann auch zu einer Instabilität Ihres Clusters in einem Zeitraum mit hoher Pod-Abwanderung kommen, wenn maxPodsPerNode auf 129 oder höher festgelegt ist und nicht genügend Pod-CIDR für jeden Knoten vorhanden ist.
Wenn Ihr Cluster betroffen ist, meldet der Pod anetd den folgenden Fehler, wenn Sie einen neuen Knoten zum Cluster hinzufügen und kein podCIDR verfügbar ist:
error="required IPv4 PodCIDR not available"
Problemumgehung
So beheben Sie das Problem:
Führen Sie ein Upgrade auf Version 1.14.1 oder höher aus.
Entfernen Sie die Worker-Knoten und fügen Sie sie wieder hinzu.
Entfernen Sie die Knoten der Steuerungsebene und fügen Sie sie nacheinander hinzu, am besten einzeln nacheinander, um Clusterausfälle zu vermeiden.
Upgrades und Updates
1.14.0, 1.14.1
Rollback des Clusterupgrades fehlgeschlagen
Ein Upgrade-Rollback kann für Anthos-Cluster auf Bare Metal 1.14.0 auf 1.14.1 fehlschlagen.
Wenn Sie ein Cluster von 1.14.0 auf 1.14.1 aktualisieren und dann mit dem Befehl bmctl restore cluster ein Rollback auf 1.14.0 durchführen, wird möglicherweise ein Fehler wie im folgenden Beispiel 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 ist 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 Systemdiagnoseressourcen.
Führen Sie den Befehl bmctl restore cluster noch einmal aus.
Netzwerk
1.12.0
Externe Dienst-IP-Adresse funktioniert im Flat Mode nicht
In einem Cluster, in dem flatIPv4 auf true gesetzt ist, sind Dienste des Typs LoadBalancer nicht über ihre externen IP-Adressen 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 ein Upgrade auf 1.14.x vornehmen. Ein direktes Upgrade von 1.13.0 auf 1.13.1 sollte funktionieren. Alternativ ist ein Upgrade von 1.13.0 auf 1.14.x ohne das Flag --use-bootstrap=false möglich.
Upgrades und Updates, Sicherheit
1.13 und 1.14
Cluster, die auf 1.14.0 aktualisiert wurden, verlieren Mastermarkierungen
Knoten der Steuerungsebene benötigen eine von zwei bestimmten Markierungen, um zu verhindern, dass Arbeitslast-Pods auf ihnen geplant werden. Wenn Sie Anthos-Cluster auf 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 verursacht keine Upgradefehler, aber Pods, die nicht auf den Knoten der Steuerungsebene ausgeführt werden sollten, können damit beginnen. Diese Arbeitslast-Pods können die Knoten der Steuerungsebene überfordern und zu Clusterinstabilität führen.
Prüfen, ob Sie betroffen sind
Suchen Sie mit dem folgenden Befehl nach 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 zu prüfen:
Wenn keine der erforderlichen Markierungen aufgelistet ist, sind Sie betroffen.
Problemumgehung
Führen Sie die folgenden Schritte für jeden Knoten der Steuerungsebene des betroffenen Clusters 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 PreferNoSchedule die Markierung der Steuerungsebene verwenden sollen, passen Sie die Schritte entsprechend an.
Suchen Sie Pods ohne die Toleranz für 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 node-role.kubernetes.io/master:NoSchedule-Toleranz:
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Vorgang, Anthos-VM-Laufzeit
1,11, 1,12, 1,13, 1,14, 1,15
VM-Erstellung schlägt zeitweise mit Uploadfehlern vor
Das Erstellen einer neuen virtuellen Maschine (VM) mit dem Befehl kubectl virt create vm schlägt beim Hochladen von Images nur selten fehl. Dieses Problem gilt sowohl für Linux- als auch für 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 Ihre VM zu erstellen.
Upgrades und Updates, Logging und Monitoring
1.11
Komponenten der verwalteten Sammlung in 1.11-Clustern werden bei Upgrades auf 1.12 nicht beibehalten
Komponenten der verwalteten Sammlung sind Teil des Managed Service for Prometheus.
Wenn Sie Komponenten der verwalteten Sammlung manuell im gmp-system-Namespace Ihrer Anthos-Cluster der Version 1.11 bereitgestellt haben, werden die zugehörigen Ressourcen beim Upgrade auf Version 1.12 nicht beibehalten.
Ab Anthos-Clustern auf Bare-Metal-Version 1.12.0 werden verwaltete Dienst für Prometheus-Komponenten 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 Managed Service for Prometheus-Komponenten vor dem Upgrade auf Version 1.12 manuell 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 im aktualisierten Cluster noch einmal bereit.
Upgrades und Updates
1.13
Für einige Cluster der Version 1.12 mit der Docker-Containerlaufzeit kann kein Upgrade auf Version 1.13 durchgeführt werden
Wenn einem Cluster in Version 1.12, der die Docker-Containerlaufzeit verwendet, die folgende Annotation fehlt, ist kein Upgrade auf Version 1.13 möglich:
Wenn Sie von diesem Problem betroffen sind, 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 geschieht am wahrscheinlichsten bei Docker-Clustern der Version 1.12, die von 1.11 aktualisiert wurden, da dieses Upgrade keine Annotation erfordert, um die Docker-Containerlaufzeit aufrechtzuerhalten. In diesem Fall haben Cluster die Annotation nicht, wenn sie auf 1.13 aktualisiert werden. 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 der Stornierung hinzufügen, bevor das Upgrade wiederholt wird.
Installation
1.11
bmctl wird beendet, bevor die Clustererstellung abgeschlossen ist
Die Clustererstellung kann für Anthos-Cluster auf Bare-Metal-Version 1.11.0 fehlschlagen. Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Release 1.11.1 behoben. In einigen Fällen wird der Befehl bmctl create cluster vorzeitig beendet und schreibt Fehler wie den folgenden in die Logs:
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, aber der Cluster ist 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:
Problemumgehungen ansehen
Führen Sie den folgenden Befehl aus, um Clusterartefakte zu löschen und den Knotencomputer zurückzusetzen:
bmctl reset -c USER_CLUSTER_NAME
Führen Sie den folgenden Befehl aus, um den Vorgang der Clustererstellung zu starten:
Das Flag --keep-bootstrap-cluster ist wichtig, wenn dieser Befehl fehlschlägt.
Wenn der Clustererstellungsbefehl erfolgreich ist, 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 der HTTPS-Proxy verwendet werden
Die Clustererstellung schlägt fehl, wenn Sie die folgende Kombination von Bedingungen haben:
Der Cluster ist so konfiguriert, dass containerd als Containerlaufzeit verwendet wird (nodeConfig.containerRuntime ist in der Clusterkonfigurationsdatei auf containerd festgelegt, die Standardeinstellung für Anthos-Cluster auf Bare-Metal-Version 1.12).
Der Cluster ist so konfiguriert, dass mehrere Netzwerkschnittstellen und mehrere NICs für Pods angegeben werden (clusterNetwork.multipleNetworkInterfaces in der Clusterkonfigurationsdatei auf true festgelegt).
Der Cluster ist so konfiguriert, dass ein Proxy verwendet wird (spec.proxy.url ist in der Clusterkonfigurationsdatei angegeben). Obwohl die Clustererstellung fehlschlägt, wird diese Einstellung weitergegeben, wenn Sie einen Cluster erstellen. Diese Proxyeinstellung kann auch als HTTPS_PROXY-Umgebungsvariable oder in der containerd-Konfiguration (/etc/systemd/system/containerd.service.d/09-proxy.conf) angezeigt werden.
Problemumgehung
Hängen Sie Dienst-CIDRs (clusterNetwork.services.cidrBlocks) an die Umgebungsvariable NO_PROXY auf allen Knotencomputern an.
Installation
1.10, 1.11, 1.12
Fehler auf Systemen mit restriktiver umask-Einstellung
Anthos-Cluster auf Bare-Metal-Release 1.10.0 haben ein Feature ohne Root-Steuerungsebene eingeführt, das alle Komponenten der Steuerungsebene als Nicht-Root-Nutzer ausführt. Wenn alle Komponenten als Nicht-Root-Nutzer ausgeführt werden, kann dies zu System- und Upgradefehlern auf Systemen mit einer restriktiveren umask-Einstellung von 0077 führen.
Problemumgehung
Setzen Sie die Knoten der Steuerungsebene zurück und ändern Sie umask auf allen Maschinen der Steuerungsebene in 0022. Wiederholen Sie die Installation, nachdem die Maschinen aktualisiert wurden.
Alternativ können Sie die Verzeichnis- und Dateiberechtigungen von /etc/kubernetes auf den Computern der Steuerungsebene ändern, damit die Installation oder das Upgrade fortgesetzt werden kann.
/etc/kubernetes und alle Unterverzeichnisse sind weltweit lesbar: chmod o+rx.
Sorge dafür, dass alle Dateien, die Nutzern von root im Verzeichnis (rekursiv) /etc/kubernetes gehören, schreibgeschützt lesbar sind (chmod o+r). Schließe private Dateien (.key) aus diesen Änderungen aus, da sie bereits mit der richtigen Inhaberschaft und den richtigen Berechtigungen erstellt wurden.
Kontrollgruppe v2 (cgroup v2) wird in Version 1.13 und früheren Versionen von Anthos-Clustern auf Bare Metal nicht unterstützt. Version 1.14 unterstützt jedoch cgroup v2 als Vorabversion
. Das Vorhandensein von /sys/fs/cgroup/cgroup.controllers weist darauf hin, dass Ihr System cgroup v2 verwendet.
Problemumgehung
Wenn Ihr System cgroup v2 verwendet, führen Sie ein Upgrade auf Version 1.14 von Anthos-Clustern auf Bare Metal aus.
Installation
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
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, z. B. Nutzerclustern), prüfen die Preflight-Prüfung nicht die Anmeldedaten des Google Cloud-Dienstkontos oder die zugehörigen Berechtigungen.
Installation
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Standardanmeldedaten für Anwendungen und bmctl
bmctl verwendet Standardanmeldedaten für Anwendungen, um den Standortwert des Clustervorgangs im cluster spec zu validieren, wenn er nicht auf global festgelegt ist.
Problemumgehung
Damit ADC funktioniert, müssen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS auf eine Dienstkonto-Anmeldedatendatei verweisen oder gcloud auth application-default login ausführen.
Installation
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Docker-Dienst
Auf Clusterknotencomputern gilt Folgendes: Wenn die ausführbare Docker-Datei in der Umgebungsvariable PATH vorhanden ist, der Docker-Dienst aber nicht aktiv ist, schlägt die Preflight-Prüfung fehl und meldet, dass Docker service
is not active.
Problemumgehung
Entfernen Sie Docker oder aktivieren Sie den Docker-Dienst.
Installation
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Auf vSphere installieren
Wenn Sie Anthos-Cluster auf Bare Metal auf vSphere-VMs installieren, müssen Sie die Flags tx-udp_tnl-segmentation und tx-udp_tnl-csum-segmentation deaktivieren. Diese Flags beziehen sich auf die Hardwaresegmentierung, die vom vSphere-Treiber VMXNET3 ausgeführt wird, und funktionieren nicht mit dem GENEVE-Tunnel von Anthos-Clustern auf Bare Metal.
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 mit der IP-Adresse des Knotens verknüpft ist.
Die Antwort sollte Einträge wie die folgenden enthalten:
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
In RHEL 8.4 gibt ethtool an, dass diese Flags deaktiviert sind, während sie nicht vorhanden sind. Sie können die Flags explizit mit den folgenden Befehlen aktivieren bzw. deaktivieren:
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 sie die Flags beim Systemstart explizit festlegen.
Upgrades und Updates
1.10
bmctl kann keine Nutzercluster mit niedrigeren Versionen erstellen, aktualisieren oder zurücksetzen
Die bmctl-Befehlszeile kann unabhängig von der Version des Administratorclusters keine Nutzercluster mit einer niedrigeren Nebenversion erstellen, aktualisieren oder zurücksetzen. Sie können beispielsweise bmctl mit einer Version von 1.N.X nicht verwenden, um einen Nutzercluster der Version 1.N-1.Y zurückzusetzen, selbst wenn sich der Administratorcluster auch in Version 1.N.X befindet.
Wenn Sie von diesem Problem betroffen sind, sollten Sie bei der Verwendung von bmctl ähnliche Logs sehen:
[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 is not supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported
Workaround:
Mit kubectl können Sie die benutzerdefinierte Ressource des Nutzerclusters im Administratorcluster erstellen, bearbeiten oder löschen.
Die Möglichkeit, Nutzercluster zu aktualisieren, ist nicht betroffen.
Upgrades und Updates
1.12
Clusterupgrades auf Version 1.12.1 verzögern sich möglicherweise
Clusterupgrades auf Version 1.12.1 werden manchmal ausgesetzt, weil 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 der Preflight-Prüfungen.
Problemumgehung
In Ihren Upgradelogs können Sie nachsehen, ob Sie von diesem Problem betroffen sind. Upgrade-Logs befinden sich standardmäßig in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP.
upgrade-cluster.log kann die folgenden Fehler enthalten:
Failed to upgrade cluster: preflight checks failed: preflight check failed
Das Maschinenlog kann Fehler wie den folgenden enthalten (Wiederholte Fehler weisen darauf hin, dass Sie von diesem Problem betroffen sind):
Clickserver und Keepalive müssen auf jedem Knoten der Steuerungsebene ausgeführt werden, bevor Sie noch einmal versuchen, den Cluster auf Version 1.12.1 zu aktualisieren. Mit der crictl-Befehlszeile auf jedem Knoten können Sie prüfen, ob die Container haproxy und keepalived ausgeführt werden:
Wenn HMAC oder Keepalive nicht auf einem Knoten ausgeführt wird, starten Sie kubelet auf dem Knoten neu:
systemctl restart kubelet
Upgrades und Updates, Anthos-VM-Laufzeit
1,11, 1,12
Das Upgrade von Clustern auf Version 1.12.0 oder höher schlägt fehl, wenn die Anthos-VM-Laufzeit aktiviert ist
In Anthos-Clustern auf Bare Metal-Release 1.12.0 werden alle Ressourcen im Zusammenhang mit der Anthos-VM-Laufzeit zum Namespace vm-system migriert, um den Release der GA-Version der Anthos-VM-Laufzeit besser zu unterstützen. Wenn Sie die Anthos-VM-Laufzeit 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 die Anthos-VM-Laufzeit nicht deaktivieren. Wenn Sie von diesem Problem betroffen sind, meldet der Upgradevorgang den folgenden Fehler:
Failed to upgrade cluster: cluster is not 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 Anthos VM-Laufzeit:
Bearbeiten Sie die benutzerdefinierte VMRuntime-Ressource:
kubectl edit vmruntime
Legen Sie enabled in der Spezifikation auf false fest:
Upgrade hängt bei error during manifests operations fest
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. Prüfen Sie in den anthos-cluster-operator-Logs nach Fehlern, die den folgenden Einträgen ähneln, um zu ermitteln, ob Sie von diesem Problem betroffen sind:
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 Symptom einer falsch aktualisierten 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:
Mit kubectl edit können Sie die Annotation kubectl.kubernetes.io/last-applied-configuration aus der Ressource in der Lognachricht entfernen.
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 von Clustern, die Features von Anthos Network Gateway verwenden, werden blockiert.
Clusterupgrades von 1.10.x auf 1.11.x schlagen für Cluster fehl, die entweder ein ausgehendes NAT-Gateway oder ein gebündeltes Load-Balancing mit BGP verwenden. Beide Funktionen verwenden Anthos Network Gateway. Clusterupgrades hängen an der Waiting for upgrade to complete...-Befehlszeile fest und die anthos-cluster-operator-Logfehler wie der folgende:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Problemumgehung
Führen Sie die folgenden Befehle für den Cluster aus, für den Sie ein Upgrade durchführen möchten:
Mit dem Befehl bmctl update kann der Bereich maintenanceBlocks aus der Clusterressourcenkonfiguration nicht entfernt oder geändert werden.
Problemumgehung
Weitere Informationen, einschließlich Anleitungen zum Entfernen von Knoten aus dem Wartungsmodus, finden Sie unter Knoten in den Wartungsmodus versetzen.
Upgrades und Updates
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Knotenausgleich kann nicht gestartet werden, wenn sich der Knoten außerhalb der Reichweite befindet
Der Draining-Prozess für Knoten beginnt nicht, wenn der Knoten außerhalb der Anthos-Cluster auf Bare Metal liegt. Wenn ein Knoten beispielsweise während eines Clusterupgrades offline geht, kann es dazu führen, dass das Upgrade nicht mehr reagiert. Das kommt selten vor.
Problemumgehung
Achten Sie darauf, dass Ihre Knoten korrekt funktionieren, bevor Sie ein Upgrade starten, um die Wahrscheinlichkeit eines Problems zu minimieren.
Upgrades und Updates
1.12
containerd 1.5.13 erfordert libseccomp 2.5 oder höher
Anthos-Cluster auf Bare-Metal-Release 1.12.1 werden mit containerd-Version 1.5.13 ausgeliefert. Für diese containerd-Version ist libseccomp Version 2.5 oder höher erforderlich.
Wenn libseccomp auf Ihrem System nicht die Version 2.5 oder höher installiert ist, aktualisieren Sie diese vor dem Upgrade der vorhandenen Cluster auf Version 1.12.1. Andernfalls können in cplb-update-Pods Fehler für Load-Balancer-Knoten auftreten, z. B.:
runc did not terminate successfully: runc: symbol lookup error: runc: undefined
symbol: seccomp_notify_respond
Problemumgehung
Führen Sie den folgenden Befehl aus, um die neueste Version von libseccomp in Ubuntu zu installieren:
sudo apt-get install libseccomp-dev
Führen Sie den folgenden Befehl aus, um die neueste Version von libseccomp in CentOS oder RHEL zu installieren:
sudo dnf -y install libseccomp-devel
Vorgang
1.10, 1.11, 1.12
Knoten, die nicht verwendet werden, wenn Sie das Verfahren für den Wartungsmodus nicht verwenden
Wenn Sie Anthos-Cluster auf Bare-Metal-Version 1.12.0 (anthosBareMetalVersion: 1.12.0) oder niedriger ausführen und kubectl cordon auf einem Knoten manuell verwenden, kann es passieren, dass Anthos-Cluster auf Bare Metal den Knoten trennen, bevor Sie bereit sind, den erwarteten Status abzugleichen.
Problemumgehung
Verwenden Sie für Anthos-Cluster auf Bare-Metal-Version 1.12.0 und niedriger den Wartungsmodus, um Knoten sicher zu sperren und zu leeren.
Ab Version 1.12.1 (anthosBareMetalVersion: 1.12.1) werden Knoten durch Anthos-Cluster auf Bare Metal nicht unerwartet gesperrt, wenn Sie kubectl cordon verwenden.
Vorgang
1.11
Cluster mit Version 11, die einen Registry-Spiegel verwenden, können Cluster mit Version 1.10 nicht verwalten
Wenn Ihr Administratorcluster Version 1.11 hat und einen Registrierungsspiegel verwendet, können keine Nutzercluster verwaltet werden, auf denen eine niedrigere Nebenversion verwendet wird. Dieses Problem wirkt sich auf das Zurücksetzen, Aktualisieren und Upgrade des Nutzerclusters aus.
Prüfen Sie die Logs auf Clustervorgänge wie Erstellen, Upgrade oder Zurücksetzen, um zu ermitteln, ob dieses Problem Sie betrifft. Diese Logs befinden sich standardmäßig im Ordner bmctl-workspace/CLUSTER_NAME/. Wenn Sie von dem 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
Bei Ausführung in Nutzerclustern überschreibt der Befehl bmctl check cluster den Nutzercluster kubeconfig-Secret mit dem Administratorcluster kubeconfig. Das Überschreiben der Datei führt dazu, dass Standardclustervorgänge wie die Aktualisierung und das Upgrade für betroffene Nutzercluster fehlschlagen. Dieses Problem gilt für Anthos-Cluster auf Bare-Metal-Versionen 1.11.1 und niedriger.
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 ist der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Anthos-Cluster auf Bare Metal der Name des Clusters, dem das Präfix cluster- vorangestellt ist. Wenn Sie dem Cluster beispielsweise test nennen, ist der Standard-Namespace cluster-test.
USER_CLUSTER_NAME ist der Name des zu überprü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 für einen betroffenen Nutzercluster (USER_CLUSTER_NAME) wiederhergestellt:
Suchen Sie die kubeconfig-Datei des Nutzerclusters. Anthos-Cluster auf Bare Metal generieren beim Erstellen eines Clusters die kubeconfig-Datei auf der Administratorworkstation. Standardmäßig befindet sich die Datei im Verzeichnis bmctl-workspace/USER_CLUSTER_NAME.
Prüfen Sie, ob die kubeconfig-Datei die richtige Nutzercluster-kubeconfig ist:
kubectl get nodes \
--kubeconfig PATH_TO_GENERATED_FILE
Ersetzen Sie PATH_TO_GENERATED_FILE durch den Pfad zur kubeconfig-Datei des Nutzerclusters. Die Antwort gibt Details zu den Knoten für den Nutzercluster zurück. 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, muss zum Ausführen von Snapshots als Nicht-Root-Nutzer /usr/local/bin im PATH des Nutzers sein.
Andernfalls tritt ein crictl: command not found-Fehler auf.
Wenn Sie nicht als Root-Nutzer angemeldet sind, wird sudo zum Ausführen der Snapshot-Befehle verwendet. Der PATH (sudo) kann sich vom Stammprofil unterscheiden und darf nicht /usr/local/bin enthalten.
Problemumgehung
Aktualisieren Sie secure_path in /etc/sudoers, um /usr/local/bin einzuschließen. Alternativ können Sie einen symbolischen Link für crictl in einem anderen /bin-Verzeichnis erstellen.
Vorgang, Anthos-VM-Laufzeit
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Anthos-VM-Laufzeit: Wenn Sie einen Pod neu starten, ändern die VMs im Pod IP-Adressen oder verlieren ihre IP-Adresse insgesamt.
Wenn sich die IP-Adresse einer VM ändert, wirkt sich das nicht auf die Erreichbarkeit der als Kubernetes-Dienst bereitgestellten VM-Anwendungen aus.
Problemumgehung
Wenn die IP-Adresse verloren geht, müssen Sie dhclient auf der VM ausführen, um eine IP-Adresse für die VM zu erhalten.
Logging und Monitoring
1.10
stackdriver-log-forwarder hat [parser:cri] invalid
time format Warnungsprotokolle
Wenn der CRI-Parser für die Containerlaufzeit einen falschen regulären Ausdruck zum Parsen von Zeit verwendet, enthalten die Logs für den stackdriver-log-forwarder-Pod 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:
Problemumgehungen ansehen
Führen Sie ein Upgrade von Anthos-Clustern auf Bare Metal auf Version 1.11.0 oder höher aus.
Wenn Sie Ihre Cluster nicht sofort upgraden können, führen Sie die folgenden Schritte aus, um den CRI-Parsing-Regex zu aktualisieren:
Damit die folgenden Änderungen nicht rückgängig gemacht werden, skalieren Sie stackdriver-operator herunter:
Ihre 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 Anthos-Clustern auf Bare-Metal-Version 1.10 haben einige Kunden auf der Seite Abrechnung einen unerwartet hohen Preis für Metrics volume festgestellt. Dieses Problem betrifft Sie nur, wenn folgende Bedingungen erfüllt sind:
Anwendungsmonitoring ist aktiviert (enableStackdriverForApplications=true)
Wenn Sie von diesem Problem betroffen sind, empfehlen wir Ihnen, Ihre Cluster auf Version 1.12 zu aktualisieren und zu einer neuen Lösung für das Anwendungsmonitoring managed-service-for-prometheus zu wechseln, die dieses Problem löst:
Separate Flags zum Steuern der Erfassung von Anwendungslogs und Anwendungsmesswerten
Gebündelter Google Cloud Managed Service for Prometheus
Wenn Sie kein Upgrade auf Version 1.12 ausführen können, gehen Sie so vor:
Suchen Sie die Quell-Pods und -Dienste, die über die unerwünschte Abrechnung verfügen:
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
Änderungen an metrics-server-config werden nicht beibehalten
Eine hohe Pod-Dichte kann in extremen Fällen zu einem übermäßigen Logging- und Monitoring-Aufwand führen, was dazu führen kann, dass der Metrics Server beendet und neu gestartet wird. Sie können die ConfigMap metrics-server-config bearbeiten, um mehr Ressourcen zuzuweisen, damit Metrics Server weiterhin ausgeführt wird. Aufgrund des Abgleichs können Änderungen, die an metrics-server-config vorgenommen werden, jedoch während eines Clusteraktualisierungs- oder Upgradevorgangs auf den Standardwert zurückgesetzt werden.
Der Messwertserver ist nicht sofort betroffen. Beim nächsten Neustart wird jedoch die rückgängig gemachte ConfigMap abgerufen und ist dem übermäßigen Aufwand wieder ausgesetzt.
Problemumgehung
Bei Version 1.11.x können Sie ein Skript für die ConfigMap ausführen und diese zusammen mit Aktualisierungen oder Upgrades des Clusters ausführen. Ab Version 1.12 wenden Sie sich bitte an den Support.
Logging und Monitoring
1,11, 1,12
Eingestellte Messwerte wirken sich auf das Cloud Monitoring-Dashboard aus
Einige Anthos-Messwerte wurden eingestellt. Ab Anthos-Cluster auf Bare-Metal-Release 1.11 werden für diese verworfenen Messwerte keine Daten mehr erhoben. Wenn Sie diese Messwerte in einer Ihrer Benachrichtigungsrichtlinien verwenden, sind keine Daten zum Auslösen der Benachrichtigungsbedingung vorhanden.
In der folgenden Tabelle sind die einzelnen Messwerte, die eingestellt wurden, und der Messwert, der sie ersetzt, aufgeführt.
In Anthos-Clustern auf Bare-Metal-Releases vor 1.11 werden für die Richtliniendefinitionsdatei für die empfohlene Benachrichtigung Anthos on baremetal node cpu usage exceeds
80 percent (critical) die verworfenen Messwerte verwendet. Die JSON-Definitionsdatei node-cpu-usage-high.json wird für Releases 1.11.0 und höher 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 Status des Anthos-Clusterknotens neu.
In einigen Fällen kann der Logging-Agent fluent-bit dazu führen, dass die Verarbeitung beschädigter Segmente nicht reagiert. Wenn der Logging-Agent keine beschädigten Teile umgehen kann, stellen Sie möglicherweise fest, dass stackdriver-log-forwarder immer wieder 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.
Diese Messwerte vom Typ „Zusammenfassung“ sind zwar in der Messwertliste enthalten, werden aber derzeit von gke-metrics-agent nicht unterstützt.
Logging und Monitoring
1,10, 1,11
Intermittierende Messwertexportunterbrechungen
Anthos-Cluster auf Bare Metal können durch normale, kontinuierliche Export von Messwerten oder fehlende Messwerte auf einigen Knoten unterbrochen werden. Wenn dieses Problem Ihre Cluster betrifft, sehen Sie mindestens Datenlücken für die folgenden Messwerte:
Fügen Sie dem Manifest stackdriver den folgenden resourceAttrOverride-Abschnitt hinzu, um die CPU-Anfrage für gke-metrics-agent von 10m auf 50m zu erhöhen:
Der Befehl sucht nach cpu: 50m, sobald Ihre Änderungen wirksam wurden.
Netzwerk
1.10
Mehrere Standardgateways unterbrechen die Konnektivität zu externen Endpunkten
Die Verwendung mehrerer Standardgateways in einem Knoten kann zu einer fehlerhaften Verbindung innerhalb eines Pods zu externen Endpunkten führen, z. B. zu google.com.
Führen Sie den folgenden Befehl auf dem Knoten aus, um zu ermitteln, ob Sie von diesem Problem betroffen sind:
ip route show
Mehrere Instanzen von default in der Antwort weisen darauf hin, dass Sie betroffen sind.
Netzwerk
1.12
Änderungen von benutzerdefinierten Netzwerkressourcen in Nutzerclustern werden überschrieben
Anthos-Cluster auf Bare-Metal-Version 1.12.x verhindern nicht, dass Sie benutzerdefinierte Ressourcen im Netzwerk manuell in Ihrem Nutzercluster bearbeiten. Anthos-Cluster auf Bare Metal gleichen benutzerdefinierte Ressourcen in den Nutzerclustern während der Clusterupgrades mit den benutzerdefinierten Ressourcen in Ihrem Administratorcluster ab. Dieser Abgleich überschreibt alle Änderungen, die direkt an den benutzerdefinierten Netzwerkressourcen im Nutzercluster vorgenommen werden. Die benutzerdefinierten Netzwerkressourcen sollten nur im Administratorcluster geändert werden, aber Anthos-Cluster auf Bare-Metal-Version 1.12.x erzwingen diese Anforderung nicht.
Sie bearbeiten diese benutzerdefinierten Ressourcen im Administratorcluster und der Schritt für den Abgleich 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 im Administratorcluster vor dem Upgrade an. Mit diesem Schritt sorgen Sie dafür, dass Ihre Konfigurationsänderungen beibehalten werden. Anthos-Cluster auf Bare-Metal-Versionen ab 1.13.0 verhindern, dass Sie die benutzerdefinierten Netzwerkressourcen auf Ihren Nutzerclustern direkt ändern.
Netzwerk
1,11, 1,12, 1,13, 1,14, 1,15
NAT-Fehler mit zu vielen parallelen Verbindungen
Für einen bestimmten Knoten in Ihrem Cluster bietet die Knoten-IP-Adresse eine Netzwerkadressübersetzung (Network Address Translation, NAT) für Pakete, die an eine Adresse außerhalb des Clusters weitergeleitet werden. Wenn eingehende Pakete in einen Load-Balancing-Knoten eingehen, der für die Verwendung des gebündelten Load-Balancings (spec.loadBalancer.mode:
bundled) konfiguriert ist, werden die Pakete von der Quellnetzwerkadressübersetzung (SNAT) an die IP-Adresse des Knotens weitergeleitet, bevor sie an einen Back-End-Pod weitergeleitet werden.
Der Portbereich für NAT, die von Anthos-Clustern auf Bare Metal verwendet wird, ist 32768–65535. Dieser Bereich begrenzt die Anzahl paralleler Verbindungen auf 32.767 pro Protokoll auf diesem Knoten. Für jede Verbindung ist ein Eintrag in der Conntrack-Tabelle erforderlich. Wenn zu viele kurzlebige Verbindungen vorhanden sind, werden in der Conntrack-Tabelle keine Ports für NAT mehr ausgeführt. Eine automatische Speicherbereinigung bereinigt die veralteten Einträge, die Bereinigung erfolgt jedoch nicht sofort.
Wenn die Anzahl der Verbindungen auf Ihrem Knoten 32.767 erreicht, werden Sie für Paketverbindungen, die NAT benötigen, Paketverluste feststellen.
Dieses Problem können Sie ermitteln, indem Sie den folgenden Befehl auf dem Pod anetd auf dem problematischen Knoten ausführen:
Es sollten Fehler in folgender Form angezeigt werden:
No mapping for NAT masquerade DROPPED
Problemumgehung
Verteilen Sie Ihren Traffic auf andere Knoten.
Netzwerk
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Quell-IP des Clients mit gebündeltem Layer-2-Load-Balancing
Wenn Sie die Richtlinie für externen Traffic auf Local festlegen, kann es zu Routingfehlern wie No route to
host für ein gebündeltes Layer-2-Load-Balancing kommen. Die Richtlinie für externen Traffic ist standardmäßig auf Cluster (externalTrafficPolicy:
Cluster) festgelegt. Mit dieser Einstellung verarbeitet Kubernetes den gesamten Cluster. Dienste vom Typ LoadBalancer oder NodePort können externalTrafficPolicy: Local verwenden, um die IP-Adresse der Clientquelle beizubehalten. Bei dieser Einstellung verarbeitet Kubernetes jedoch nur lokalen Knotentraffic.
Problemumgehung
Wenn Sie die IP-Adresse der Clientquelle beibehalten möchten, ist möglicherweise eine zusätzliche Konfiguration erforderlich, um sicherzustellen, dass Dienst-IP-Adressen erreichbar sind. Weitere Informationen zur Konfiguration finden Sie unter Quell-IP-Adresse des Clients beibehalten im Abschnitt „Gebündeltes Load-Balancing konfigurieren“.
Netzwerk
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Wenn Sie firewalld ändern, werden Cilium iptable-Richtlinienketten gelöscht
Wenn Sie Anthos-Cluster auf Bare Metal ausführen, wobei firewalld auf CentOS oder Red Had Enterprise Linux (RHEL) aktiviert ist, können Änderungen an firewalld die Cilium-iptables-Ketten im Hostnetzwerk entfernen. Die iptables-Ketten werden vom Pod anetd hinzugefügt, wenn er gestartet wird. Der Verlust der Cilium-iptables-Ketten führt dazu, dass der Pod auf dem Knoten die Netzwerkverbindung außerhalb des Knotens verliert.
Änderungen an firewalld, die die Ketten iptables entfernen, sind unter anderem:
firewalld mit systemctl neu starten
firewalld mit dem Befehlszeilenclient (firewall-cmd --reload) neu laden
Problemumgehung
Starten Sie anetd auf dem Knoten neu. Suchen und löschen Sie den anetd-Pod mit den folgenden Befehlen, um anetd neu zu starten:
Ersetzen Sie ANETD_XYZ durch den Namen des Pods anetd.
Netzwerk
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Doppelte egressSourceIP-Adressen
Bei Verwendung der Vorschaufunktion für ausgehendes NAT-Gateway ist es möglich, Regeln für die Traffic-Auswahl festzulegen, die eine egressSourceIP-Adresse angeben, die bereits für ein anderes EgressNATPolicy-Objekt verwendet wird. Dies kann zu Konflikten mit dem ausgehenden Traffic-Routing führen.
Problemumgehung
Ermitteln Sie zusammen mit Ihrem Entwicklungsteam, welche Floating-IP-Adressen verfügbar sind, bevor Sie die egressSourceIP-Adresse in der benutzerdefinierten Ressource EgressNATPolicy angeben.
Netzwerk
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Pod-Konnektivitätsfehler und Filterung für umgekehrte Pfade
Anthos-Cluster auf Bare Metal konfigurieren die umgekehrte Pfadfilterung auf Knoten, um die Quellvalidierung zu deaktivieren (net.ipv4.conf.all.rp_filter=0). Wenn die Einstellung rp_filter in 1 oder 2 geändert wird, schlagen Pods aufgrund von Zeitüberschreitungen bei der Knotenkommunikation fehl.
Der Filter für den umgekehrten Pfad wird mit rp_filter-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all) festgelegt. Dieser Wert kann auch von sysctl überschrieben werden, wodurch die Einstellungen für den umgekehrten Pfadfilter in einer Netzwerksicherheitskonfigurationsdatei gespeichert werden, z. B. /etc/sysctl.d/60-gce-network-security.conf.
Problemumgehung
Wenn Sie die Pod-Konnektivität wiederherstellen möchten, setzen Sie net.ipv4.conf.all.rp_filter manuell auf 0 oder starten Sie den anetd-Pod neu, um net.ipv4.conf.all.rp_filter wieder auf 0 zurückzusetzen. Wenn Sie den anetd-Pod neu starten möchten, verwenden Sie die folgenden Befehle, um den anetd-Pod zu suchen und zu löschen. Stattdessen wird ein neuer anetd-Pod gestartet:
Ersetzen Sie ANETD_XYZ durch den Namen des Pods anetd.
Netzwerk
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Cluster-IP-Adressen von Bootstrap (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-Typ (Typ) verwendet werden.
Preflight-Prüfungen schlagen fehl, wenn sie sich mit IP-Adressen von Clusterknotenmaschinen überschneiden.
Problemumgehung
Um den Konflikt zu vermeiden, können Sie die Flags --bootstrap-cluster-pod-cidr und --bootstrap-cluster-service-cidr an bmctl übergeben und unterschiedliche Werte angeben.
Betriebssystem
1.11
Inkompatibilität mit Ubuntu 18.04.6 im GA-Kernel
Anthos-Cluster auf Bare-Metal-Versionen 1.11.0 und 1.11.1 sind mit Ubuntu 18.04.6 im GA-Kernel (von 4.15.0-144-generic bis 4.15.0-176-generic) nicht kompatibel. Die Inkompatibilität führt dazu, dass der Netzwerk-Agent das Clusternetzwerk nicht mit dem Fehler „BPF-Programm ist zu groß“ in den anetd-Logs konfiguriert. Es kann sein, dass Pods im Status ContainerCreating hängen und im Ereignis-Log der Pods der Fehler networkPlugin cni failed to set up pod angezeigt wird. Dieses Problem gilt nicht für die Ubuntu-Kernel-Aktivierung (HWE).
Problemumgehung
Wir empfehlen, den HWE-Kernel herunterzuladen und auf die neueste unterstützte HWE-Version für Ubuntu 18.04 zu aktualisieren.
Betriebssystem
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Clustererstellung oder Upgrade schlägt unter CentOS fehl
Im Dezember 2020 haben die CentOS-Community und Red Hat den Sonnenuntergang von CentOS angekündigt. Am 31. Januar 2022 hat CentOS 8 sein End of Life (EOL) erreicht. In der End of Life funktioniert yum-Repositories nicht mehr für CentOS. Dadurch können die Clustererstellung und die Clusterupgrades fehlschlagen. Dies gilt für alle unterstützten Versionen von CentOS und alle Versionen von Anthos-Clustern auf Bare Metal.
Problemumgehung
Problemumgehungen ansehen
Führen Sie als Behelfslösung die folgenden Befehle aus, damit nach und nach ein Archivfeed verwendet wird:
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-*
Auf RHEL und CentOS gibt es eine Beschränkung auf Clusterebene von 100.000 Endpunkten. Kubernetes-Dienst. Wenn zwei Dienste auf dieselben Pods verweisen, zählt dies als zwei separate Sätze von Endpunkten. Die zugrunde liegende nftable-Implementierung auf RHEL und CentOS verursacht diese Einschränkung; sie ist keine inhärente Einschränkung von Anthos-Clustern auf Bare Metal.
Sicherheit
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
Container kann in VOLUME, die im Dockerfile definiert ist, nicht mit containerd und SELinux schreiben
Wenn Sie „containerd“ als Containerlaufzeit verwenden und in Ihrem Betriebssystem SELinux aktiviert ist, ist das im Anwendungs-Dockerfile 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
Führen Sie den folgenden Befehl auf dem Knoten aus, auf dem der problematische Container gehostet wird, um zu sehen, ob Sie von diesem Problem betroffen sind:
ausearch -m avc
Wenn Sie von diesem Problem betroffen sind, wird unter Umständen 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 die Funktion VOLUME nicht in Dockerfile.
Sicherheit
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
SELinux-Fehler bei der Pod-Erstellung
Die Pod-Erstellung schlägt manchmal fehl, wenn SELinux verhindert, dass die Containerlaufzeit Labels auf tmpfs-Bereitstellungen legt. Dieser Fehler tritt eher selten auf, kann aber auftreten, wenn sich SELinux im Modus Enforcing und in einigen Kernels befindet.
Mit dem folgenden Befehl können Sie in den kubelet-Logs prüfen, ob SELinux die Ursache für Fehler beim Erstellen von Pods ist:
journalctl -u kubelet
Wenn SELinux dazu führt, dass die Pod-Erstellung fehlschlägt, enthält die Befehlsantwort einen ähnlichen Fehler wie diesen:
error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied
Führen Sie den folgenden Befehl aus, um zu prüfen, ob das Problem mit der SELinux-Erzwingung zusammenhängt:
ausearch -m avc
Mit diesem Befehl werden die Audit-Logs nach Berechtigungsfehlern im Zugriffsvektorcache (AVC) durchsucht. Der avc: denied in der folgenden Beispielantwort bestätigt, dass die Fehler beim Erstellen des Pods mit der SELinux-Erzwingung zusammenhängen.
Die Ursache dieses Pod-Erstellungsproblems mit SELinux ist ein Kernel-Fehler, der in den folgenden Linux-Images gefunden wird:
Red Hat Enterprise Linux (RHEL)-Releases vor 8.3
CentOS-Releases vor 8.3
Problemumgehung
Sie können das Problem durch einen Neustart des Computers beheben.
Verwenden Sie RHEL 8.3 oder höher oder CentOS 8.3 oder höher, um zu verhindern, dass Fehler beim Erstellen von Pods auftreten, da diese Versionen den Kernel-Fehler behoben haben.
Zurücksetzen/Löschen
1.10, 1.11, 1.12
Namespace löschen
Das Löschen eines Namespace verhindert, dass neue Ressourcen in diesem Namespace erstellt werden, einschließlich Jobs zum Zurücksetzen von Maschinen.
Problemumgehung
Zum Löschen eines Nutzerclusters müssen Sie zuerst das Clusterobjekt löschen, bevor Sie seinen Namespace löschen. Andernfalls können die Jobs zum Zurücksetzen von Maschinen nicht erstellt werden und der Löschvorgang wird übersprungen.
Zurücksetzen/Löschen
1,10, 1,11, 1,12, 1,13, 1,14, 1,15
containerd-Dienst
Mit dem Befehl bmctl reset werden keine containerd-Konfigurationsdateien oder Binärdateien gelöscht. Der containerd systemd-Dienst bleibt aktiviert und wird ausgeführt. Mit dem Befehl werden die Container gelöscht, die die für den Knoten geplanten Pods ausführen.
Upgrades und Updates
1.10, 1.11, 1.12
Knotenproblemerkennung ist nach Clusterupgrades standardmäßig nicht aktiviert
Wenn Sie Anthos-Cluster auf Bare Metal upgraden, ist Node Problem Detector standardmäßig nicht aktiviert. Dieses Problem gilt für Upgrades von Version 1.10 auf 1.12.1 und wurde in Version 1.12.2 behoben.
Workaround:
So aktivieren Sie den Knotenproblemdetektor:
Prüfen Sie, ob der node-problem-detector systemd-Dienst auf dem Knoten ausgeführt wird.
Verwenden Sie den SSH-Befehl und stellen Sie 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 in dem Befehlsergebnis inactive angezeigt wird, wird der Knotenproblem-Detektor nicht auf dem Knoten ausgeführt.
Verwenden Sie zum Aktivieren des Knotenproblemdetektors den Befehl kubectl edit und bearbeiten Sie die ConfigMap node-problem-detector-config. Weitere Informationen finden Sie unter Knotenproblemerkennung.
Vorgang
1,9, 1,10
Clustersicherung schlägt fehl, wenn eine Nicht-Root-Anmeldung verwendet wird
Der Befehl bmctl backup cluster schlägt fehl, wenn nodeAccess.loginUser auf einen Nicht-Root-Nutzernamen festgelegt ist.]
Workaround:
Dieses Problem gilt für Anthos-Cluster auf Bare Metal 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 Steuerungsebenen-Hostnetzwerk
Bei anetd tritt ein Fehler auf, 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 Spezifikation des Containers verwenden.
Der Fehler ist in Version 1.13 oder höher nicht vorhanden.
Workaround:
Die folgenden Problemumgehungen können helfen, wenn Sie einen LoadBalancer-Dienst verwenden, der von hostNetwork-Pods gesichert wird:
Führen Sie sie auf Worker-Knoten aus (nicht auf Knoten der Steuerungsebene).
Pod für verwaiste anthos-version-$version$ konnte das Image nicht abrufen
Bei einem Clusterupgrade von 1.12.x auf 1.13.x kann ein fehlgeschlagener anthos-version-$version$-Pod mit ImagePullBackOff-Fehler auftreten.
Dies geschieht aufgrund der Race-Bedingung des anthos-cluster-operators, das aktualisiert werden sollte, und sollte keine Auswirkungen auf die regulären Clusterfunktionen haben.
Der Fehler ist nach Version 1.13 oder höher nicht mehr vorhanden.
Workaround:
Job des Dynamic-Installer von kubectl delete job anthos-version-$version$ -n kube-system
löschen
Upgrades und Updates
1.13
1.12-Cluster, die von 1.11 aktualisiert wurden, können nicht auf 1.13.0 aktualisiert werden
Cluster mit 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 in Version 1.12 erstellt wurden.
In den Logs des Upgradejobs, der den upgrade-first-no*-String im Administratorcluster enthält, können Sie feststellen, ob Sie betroffen sind.
Die folgende Fehlermeldung ist betroffen:
TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
...
Workaround:
So umgehen Sie dieses Problem:
Führen Sie auf der Administratorworkstation die folgenden Befehle aus:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2023-08-10 (UTC)."],[],[]]
Dashboards aus und löschen Sie das Dashboard Status des Anthos-Clusterknotens.