Bekannte Probleme bei Anthos-Clustern on Bare-Metal

Installation

Die Clustererstellung schlägt fehl, wenn Multi-NIC, containerd und Proxy verwendet werden

Die Clustererstellung schlägt fehl, wenn die folgende Kombination von Bedingungen vorliegt:

  • Der Cluster ist so konfiguriert, dass containerd als Containerlaufzeit verwendet wird (nodeConfig.containerRuntime ist in der Clusterkonfigurationsdatei auf containerd gesetzt), der Standard für Anthos-Cluster auf Bare-Metal-Version 1.8.

  • Der Cluster ist so konfiguriert, dass mehrere Netzwerkschnittstellen mit mehreren NICs für Pods bereitgestellt werden (spec.clusterNetwork.multipleNetworkInterfaces ist in der Cluster-Konfigurationsdatei auf true gesetzt).

  • Der Cluster ist für die Verwendung eines Proxys konfiguriert (spec.proxy.url wird in der Clusterkonfigurationsdatei angegeben). Obwohl die Clustererstellung fehlschlägt, wird diese Einstellung übernommen, wenn Sie versuchen, einen Cluster zu erstellen. Diese Proxyeinstellung wird möglicherweise als Umgebungsvariable HTTPS_PROXY oder in der Konfiguration containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf) angezeigt.

Als Behelfslösung für dieses Problem hängen Sie Dienst-CIDRs (clusterNetwork.services.cidrBlocks) an die Umgebungsvariable NO_PROXY auf allen Knotenmaschinen an.

Inkompatibilität der Kontrollgruppe v2

Kontrollgruppe v2 (cgroup v2) ist mit Bare-Metal-1.6-Ressourcen nicht mit Anthos-Clustern kompatibel. Kubernetes 1.18 unterstützt cgroup v2 nicht. Außerdem bietet Docker experimentelle Unterstützung ab 20.10. systemd wurde in der Version 247.2-2 standardmäßig auf cgroup v2 umgestellt. Das Vorhandensein von /sys/fs/cgroup/cgroup.controllers gibt an, dass Ihr System cgroup v2 verwendet.

Die Preflight-Prüfungen kontrollieren, dass cgroup v2 nicht auf der Clustermaschine verwendet wird.

Fehlermeldungen während der Installation

Bei der Untersuchung von Logs zur Clustererstellung können Sie unter Umständen vorübergehende Fehler beim Registrieren von Clustern oder Aufrufen von Webhooks feststellen. Diese Fehler können ignoriert werden, da die Installation diese Vorgänge so lange wiederholt, bis sie erfolgreich sind.

Preflight-Prüfungen und Anmeldedaten für Dienstkonten

Bei Installationen, die durch Administrator- oder Hybridcluster ausgelöst werden, also Cluster, die nicht mit bmctl erstellt wurden, wie etwa Nutzercluster, werden bei der Preflight-Prüfung die Anmeldedaten des Google Cloud Platform-Dienstkontos oder deren zugehörigen Berechtigungen nicht geprüft..

Preflight-Prüfungen und Berechtigung verweigert

Während der Installation werden möglicherweise Fehler zu /bin/sh: /tmp/disks_check.sh: Permission denied angezeigt. Diese Fehlermeldungen führen dazu, dass /tmp mit der Option noexec bereitgestellt wurde. Damit bmctl funktioniert, müssen Sie die Option noexec aus dem Bereitstellungspunkt /tmp entfernen.

Standardanmeldedaten für Anwendungen und bmctl

bmctl verwendet Standardanmeldedaten für Anwendungen für die Validierung des Standortwerts des Clustervorgangs in cluster spec, wenn dieser nicht auf global gesetzt ist.

Damit ADC funktioniert, müssen Sie entweder die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS auf eine Datei mit den Anmeldedaten des Dienstkontos verweisen oder gcloud auth application-default login ausführen.

Ubuntu 20.04 LTS und bmctl

Auf Anthos-Clustern mit Bare-Metal-Versionen vor 1.8.2 haben einige Ubuntu 20.04 LTS-Distributionen mit einem neueren Linux-Kernel (einschließlich GCP Ubuntu 20.04 LTS-Images auf dem 5.8-Kernel) /proc/sys/net/netfilter/nf_conntrack_max in Nicht-init-Netzwerk-Namespaces schreibgeschützt gemacht. Dadurch wird verhindert, dass bmctl die maximale Tabellengröße für die Verbindungs-Tracking-Tabelle festlegt. Dadurch wird der Bootstrap-Cluster nicht gestartet. Ein Anzeichen für die fehlerhafte Tabellengröße besteht darin, dass der Pod kube-proxy im Bootstrap-Cluster abstürzt, wie im folgenden Beispiel für ein Fehlerlog gezeigt:

kubectl logs -l k8s-app=kube-proxy -n kube-system --kubeconfig ./bmctl-workspace/.kindkubeconfig
I0624 19:05:08.009565       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 393216
F0624 19:05:08.009646       1 server.go:495] open /proc/sys/net/netfilter/nf_conntrack_max: permission denied

Das Problem lässt sich umgehen, wenn für net/netfilter/nf_conntrack_max manuell der erforderliche Wert auf dem Host festgelegt wird: sudo sysctl net.netfilter.nf_conntrack_max=393216 Der erforderliche Wert hängt von der Anzahl der Kerne des Knotens ab. Verwenden Sie den obigen kubectl logs-Befehl, um den gewünschten Wert aus den kube-proxy-Logs zu bestätigen.

Dieses Problem wurde in Anthos-Clustern ab Bare-Metal-Version 1.8.2 behoben.

Docker-Dienst

Wenn auf Computern von Clusterknoten die ausführbare Docker-Datei in der Umgebungsvariable PATH vorhanden ist, der Docker-Dienst jedoch nicht aktiv ist, schlägt die Preflight-Prüfung fehl und meldet die Docker service is not active. Sie können den Fehler beheben, indem Sie Docker entfernen oder den Docker-Dienst aktivieren.

Registry-Spiegelung und Cloud-Audit-Logging

In Anthos-Cluster auf Bare Metal-Versionen vor 1.8.2 fehlt im Registry-Spiegelungspaket bmctl das Image gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00. Um Cloud-Audit-Logging bei Verwendung einer Registry-Spiegelung aktivieren zu können, müssen Sie das fehlende Image manuell herunterladen und mit den folgenden Befehlen per Push auf Ihren Registry-Server übertragen:

docker pull gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker tag gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00 REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker push REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00

Containerd erfordert /usr/local/bin in PATH

Bei Clustern mit der containerd-Laufzeit muss /usr/local/bin im Pfad des SSH-Nutzers für den Befehl kubeadm init vorhanden sein, um die Binärdatei crictl zu finden. Wenn crictl nicht gefunden werden kann, schlägt die Clustererstellung fehl.

Wenn Sie nicht als Root-Nutzer angemeldet sind, wird sudo verwendet, um den Befehl kubeadm init auszuführen. Der PATH sudo kann sich vom Root-Profil unterscheiden und darf nicht /usr/local/bin enthalten.

Sie können diesen Fehler beheben, indem Sie secure_path in /etc/sudoers so ändern, dass /usr/local/bin einbezogen wird. Alternativ können Sie einen symbolischen Link für crictl in einem anderen /bin-Verzeichnis erstellen.

Ab 1.8.2 fügt Anthos-Cluster on Bare Metal beim Ausführen von Befehlen /usr/local/bin zum PATH hinzu. Wenn Sie jedoch einen Snapshot als Nicht-Root-Nutzer ausführen, ist weiterhin crictl: command not found enthalten. Dieses Problem kann durch die Problemumgehung oben behoben werden.

Auf vSphere installieren

Wenn Sie Anthos-Cluster on 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 Auslagerung der Hardwaresegmentierung von vSphere. Treiber-VMXNET3 und funktionieren nicht mit dem GENEVE-Tunnel von Anthos-Clustern on Bare-Metal-Servern.

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 ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Ersetzen Sie NET_INTFC durch die Netzwerkschnittstelle, die der IP-Adresse des Knotens zugeordnet ist.

Manchmal zeigt ethtool in RHEL 8.4 an, dass diese Flags deaktiviert sind, obwohl sie aktiv sind. Um diese Flags explizit zu deaktivieren, aktivieren und deaktivieren Sie die Flags mit folgenden Befehlen.

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

Diese Flag-Änderung bleibt bei Neustarts nicht bestehen. Konfigurieren Sie die Startskripts so, dass diese Flags beim Systemstart explizit festgelegt werden.

Flapping von Knotenbereitschaft

Cluster haben gelegentlich die Bereitschaft von Flapping-Knoten, sodass sich der Knotenstatus zwischen Ready und NotReady schnell ändert. Ein fehlerhafter Pod-Lebenszyklus-Ereignisgenerator (PLEG) verursacht dieses Verhalten. Das PLEG ist ein Modul in kubelet.

Wenn Sie prüfen möchten, ob ein fehlerhafter PLEG dieses Verhalten verursacht, suchen Sie mit dem folgenden journalctl-Befehl nach PLEG-Logeinträgen:

journalctl -f | grep -i pleg

Logeinträge wie die folgenden weisen darauf hin, dass der PLEG fehlerhaft ist:

...
skipping pod synchronization - PLEG is not healthy: pleg was last seen active
3m0.793469
...

Eine bekannte runc-Race-Bedingung ist die wahrscheinliche Ursache eines fehlerhaften PLEGs. Feste runc-Prozesse sind ein Symptom der Race-Bedingung. Verwenden Sie den folgenden Befehl, um den Prozessstatus runc init zu prüfen:

ps aux | grep 'runc init'

So beheben Sie das Problem:

  1. Bestimmen Sie die Clusterlaufzeit.

    Bevor Sie die Version runc aktualisieren können, müssen Sie ermitteln, welche Containerlaufzeit Ihr Cluster verwendet. Das Feld containerRuntime in der Clusterkonfigurationsdatei gibt an, welche Containerlaufzeit Ihr Cluster verwendet. Wenn containerRuntime auf containerd gesetzt ist, verwendet der Cluster die containerd-Laufzeit. Wenn das Feld auf docker gesetzt oder nicht festgelegt ist, verwendet der Cluster die Docker-Laufzeit.

    Öffnen Sie zum Abrufen des Werts entweder die Clusterkonfigurationsdatei mit Ihrem bevorzugten Editor oder, wenn Sie Zugriff auf die kubeconfig-Datei des Administratorclusters haben, führen Sie den folgenden Befehl aus:

    kubctl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE | grep -i runtime

    Dabei gilt:

    • CLUSTER_NAME: der Name des zu sichernden Clusters.
    • CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Anthos-Cluster auf Bare-Metal der Name des Clusters, dem cluster- vorangestellt ist.

  2. Führen Sie die Befehle für Ihr Betriebssystem und Ihre Containerlaufzeit auf jedem Knoten aus, um „containerd.io“ oder „docker-ce“ zu installieren und das neueste runc-Befehlszeilentool zu extrahieren.

    Ubuntu Containerd

    sudo apt update
sudo apt install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

    Ubuntu-Docker

    sudo apt update
sudo apt install docker-ce
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

    CentOS/RHEL-Containerd

    sudo dnf install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

    CentOS/RHEL-Docker

    sudo dnf install docker-ce
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

  3. Starten Sie den Knoten neu, wenn runc init hängen geblieben ist.

    Alternativ können Sie alle hängen gebliebenen Prozesse manuell bereinigen.

Upgrades und Updates

bmctl update cluster schlägt fehl, wenn das Verzeichnis .manifests fehlt

Wenn das Verzeichnis .manifests vor der Ausführung von bmctl update cluster entfernt wird, schlägt der Befehl mit einem Fehler wie dem folgenden fehl:

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

Sie können dieses Problem beheben, indem Sie zuerst bmctl check cluster ausführen. Dadurch wird das Verzeichnis .manifests neu erstellt.

Dieses Problem betrifft Anthos-Cluster auf Bare-Metal-Versionen ab 1.10 und wurde in Version 1.11 und höher behoben.

Upgrade bleibt bei error during manifests operations hängen

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. So können Sie feststellen, ob Sie von diesem Problem betroffen sind, und es beheben:

  1. Prüfen Sie die anthos-cluster-operator-Logs und suchen Sie nach Fehlern, die den folgenden Einträgen ähneln:

    controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
...
{RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

    Diese Einträge sind ein Symptom einer falsch aktualisierten Ressource, wobei {RESOURCE_NAME} der Name der problematischen Ressource ist.

  2. Wenn Sie diese Fehler in Ihren Logs finden, entfernen Sie die Annotation kubectl.kubernetes.io/last-applied-configuration aus der Ressource aus der Lognachricht mit kubectl edit.

  3. Speichern Sie die Änderungen und wenden Sie sie auf die Ressource an.

  4. Wiederholen Sie das Clusterupgrade.

Upgrades schlagen in Clustern der Version 1.8 im Wartungsmodus fehl

Der Versuch, ein Cluster der Version 1.8.x auf Version 1.9.x zu aktualisieren, schlägt fehl, wenn zuvor Knotenmaschinen in den Wartungsmodus versetzt wurden. Dies liegt an einer Annotation, die auf diesen Knoten verbleibt.

So ermitteln Sie, ob Sie von diesem Problem betroffen sind:

  1. Rufen Sie die Version des Clusters ab, den Sie aktualisieren möchten, indem Sie den folgenden Befehl ausführen:

    kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME  \
    -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"

    Wenn der zurückgegebene Versionswert für die Nebenversion 1.8 gilt (z. B. 1.8.3), fahren Sie fort. Andernfalls gilt dieses Problem nicht für Sie.

  2. Prüfen Sie mit dem folgenden Befehl, ob der Cluster Knoten enthält, die zuvor in den Wartungsmodus versetzt wurden:

    kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE  \
    --output=jsonpath="{.items[*].metadata.annotations}"

    Wenn die zurückgegebenen Annotationen baremetal.cluster.gke.io/maintenance-mode-duration enthalten, sind Sie von diesem bekannten Problem betroffen.

Damit die Blockierung des Cluster-Upgrades aufgehoben wird, führen Sie den folgenden Befehl für jede betroffene Knotenmaschine aus, um die Annotation baremetal.cluster.gke.io/maintenance-mode-duration zu entfernen:

kubectl --kubeconfig ADMIN_KUBECONFIG  annotate BareMetalMachine -n CLUSTER_NAMESPACE \
    NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-

bmctl update entfernt keine Wartungsblöcke

Mit dem Befehl bmctl update kann der Abschnitt maintenanceBlocks nicht aus der Konfiguration der Clusterressource entfernt oder geändert werden. Weitere Informationen, einschließlich Anweisungen zum Entfernen von Knoten aus dem Wartungsmodus, finden Sie unter Knoten in den Wartungsmodus versetzen.

Clusterupgrades von 1.7.x schlagen bei bestimmten Load-Balancer-Konfigurationen fehl

Das Upgrade von Clustern von Version 1.7.x auf 1.8.y kann bei den folgenden Load-Balancer-Konfigurationen fehlschlagen:

  • Manuell konfigurierter externer Load-Balancer (loadBalancer.mode auf manual festgelegt)

  • Gebündeltes Load-Balancing (loadBalancer.mode auf bundled festgelegt), wobei ein separater Knotenpool (loadBalancer.nodePoolSpec.nodes ist festgelegt) verwendet wird

Ein Symptom dieses Fehlers ist, dass der cal-update-Job auf einem Knoten der Steuerungsebene bei Aufgabe Check apiserver health mit Fehlermeldungen über verweigerte Verbindungen fehlschlägt.

Hier ist ein Beispiellog für den Job cal-update:

TASK [cal-update : Check apiserver health] *************************************
Thursday 20 January 2022  13:50:46 +0000 (0:00:00.033)       0:00:09.316 ******
FAILED - RETRYING: Check apiserver health (30 retries left).
FAILED - RETRYING: Check apiserver health (29 retries left).
FAILED - RETRYING: Check apiserver health (28 retries left).
FAILED - RETRYING: Check apiserver health (27 retries left).
FAILED - RETRYING: Check apiserver health (26 retries left).
...
FAILED - RETRYING: Check apiserver health (3 retries left).
FAILED - RETRYING: Check apiserver health (2 retries left).
FAILED - RETRYING: Check apiserver health (1 retries left).
[WARNING]: Consider using the get_url or uri module rather than running 'curl'.
If you need to use command because get_url or uri is insufficient you can add
'warn: false' to this command task or set 'command_warnings=False' in
ansible.cfg to get rid of this message.
fatal: [10.50.116.79]: FAILED! => {"attempts": 30, "changed": true, "cmd": "curl
-k https://127.0.0.1/healthz", "delta": "0:00:00.008949", "end": "2022-01-20
19:22:30.381875", "msg": "non-zero return code", "rc": 7, "start": "2022-01-20
19:22:30.372926", "stderr": "  % Total    % Received % Xferd  Average Speed
Time    Time     Time  Current\n                                 Dload  Upload
Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --
:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to 127.0.0.1 port 443:
Connection refused", "stderr_lines": ["  % Total    % Received % Xferd  Average
Speed   Time    Time     Time  Current", "                                 Dload
Upload   Total   Spent    Left  Speed", "", "  0     0    0     0    0     0
0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to
127.0.0.1 port 443: Connection refused"], "stdout": "", "stdout_lines": []}

Erstellen Sie als manuelle Problemumgehung eine Portweiterleitung von Port 443 (wo die Diagnose erfolgt) zu Port 6444 (wobei apiserver überwacht wird), bevor Sie ein Upgrade durchführen. Führen Sie den folgenden Befehl auf jedem Knoten der Steuerungsebene aus, um die Portweiterleitung zu erstellen:

sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

Der cal-update-Job wird ausgeführt, wenn es einen Abgleich gibt, und prüft Port 443. Sie sollten diesen Port also für Ihre 1.8.x aktualisierten Cluster beibehalten.

Nach dem Upgrade auf Version 1.9.0 oder höher entfernen Sie die Portweiterleitung, indem Sie auf jedem Knoten der Steuerungsebene den folgenden Befehl ausführen:

sudo iptables -t nat -D OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

Upgrades auf Administrator-, Hybrid- und eigenständige Cluster der Versionen 1.8.0 und 1.8.1 werden nicht abgeschlossen

Das Upgrade von Administrator-, Hybrid- oder eigenständigen Clustern von Version 1.7.x auf Version 1.8.0 oder 1.8.1 kann manchmal nicht abgeschlossen werden. Dieser Upgrade-Fehler gilt für Cluster, die Sie nach dem Erstellen des Clusters aktualisiert haben.

Ein Hinweis auf dieses Upgrade-Problem ist die Konsolenausgabe Waiting for upgrade to complete ..., falls dabei nicht angegeben wird, welcher Knoten aktualisiert wird. Dieses Symptom weist auch darauf hin, dass Ihr Administratorcluster erfolgreich auf die Kubernetes-Version 1.20.8-gke.1500 aktualisiert wurde (Kubernetes-Version für Anthos-Cluster auf Bare-Metal-Releases 1.8.0 und 1.8.1).

Dieses Upgrade-Problem wurde für Anthos-Cluster mit Bare-Metal-Release 1.8.2 behoben.

So prüfen Sie, ob sich dieses Problem Ihr Clusterupgrade auf 1.8.0 oder 1.8.1 betrifft:

  1. Erstellen Sie folgendes Shell-Skript:

    if [ $(kubectl get cluster <var>CLUSTER\_NAME -n <var>CLUSTER\_NAMESPACE
    --kubeconfig bmctl-workspace/.kindkubeconfig -o=jsonpath='{.metadata.generation}')
    -le $(kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE
    --kubeconfig bmctl-workspace/.kindkubeconfig
    -o=jsonpath='{{.status.systemServiceConditions[?(@.type=="Reconciling")].observedGeneration}}') ];
    then echo "Bug Detected"; else echo "OK"; fi

    Dabei gilt:

    • CLUSTER_NAME: der Name des zu prüfenden Clusters.
    • CLUSTER_NAMESPACE: der Namespace für den Cluster.

  2. Führen Sie das Skript aus, während das Upgrade ausgeführt wird, aber nach Abschluss der Preflight-Prüfungen.

    Wenn der Wert von observedGeneration nicht kleiner als der Wert von generation ist, wird Bug Detected in die Konsolenausgabe geschrieben. Diese Ausgabe zeigt an, dass Ihr Clusterupgrade betroffen ist.

  3. Führen Sie den folgenden Befehl aus, um die Blockierung des Upgrades aufzuheben.

    kubectl get --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
    --kubeconfig bmctl-workspace/.kindkubeconfig | \
    sed -e 's/\("systemServiceConditions":\[{[^{]*"type":"DashboardReady"}\),{[^{}]*}/\1/g' | \
    kubectl replace --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
    --kubeconfig bmctl-workspace/.kindkubeconfig -f-

    Dabei gilt:

    • CLUSTER_NAME: der Name des zu prüfenden Clusters.
    • CLUSTER_NAMESPACE: der Namespace für den Cluster.

Upgrades auf 1.8.3 oder 1.8.4

Das Upgrade von Anthos-Clustern auf Bare-Metal-Versionen auf Version 1.8.3 oder 1.8.4 schlägt manchmal mit einem Null-Kontextfehler fehl. Wenn das Clusterupgrade mit einem Fehler des Typs "nil Context" fehlschlägt, führen Sie die folgenden Schritte aus, um das Upgrade abzuschließen:

  1. Legen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS so fest, dass sie auf Ihre Dienstkonto-Schlüsseldatei verweist.

    export GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH

    Geben Sie für KEY_PATH den Dateipfad der JSON-Datei an, die Ihren Dienstkontoschlüssel enthält.

  2. Führen Sie den Befehl bmctl upgrade cluster noch einmal aus.

Einschränkung bei Nutzercluster-Patch-Upgrades

Nutzercluster, die von einem Administratorcluster verwaltet werden, müssen denselbe Anthos-Cluster auf Bare Metal-Version oder maximal eine Nebenversion niedriger haben. Beispielsweise ist ein Administratorcluster der Version 1.7.1 (anthosBareMetalVersion: 1.7.1), der Nutzercluster der Version 1.6.2 verwaltet, akzeptabel.

Eine Upgrade-Einschränkung verhindert, dass Sie Ihre Nutzercluster auf einen neuen Sicherheitspatch aktualisieren, wenn der Patch nach der Release-Version, die der Administratorcluster verwendet, veröffentlicht wird. Wenn Ihr Administratorcluster beispielsweise Version 1.7.2 hat, die am 2. Juni 2021 veröffentlicht wurde, können Sie Ihre Nutzercluster nicht auf Version 1.6.4 aktualisieren, da sie am 13. August 2021 veröffentlicht wurde.

Inkompatibilität bei Ubuntu 18.04 und 18.04.1

Für ein Upgrade auf 1.8.1 oder 1.8.2 benötigen Clusterknotenmaschinen und die Workstation, auf der bmctl ausgeführt wird, die Linux-Kernel-Version 4.17.0 oder höher. Andernfalls funktioniert der Netzwerk-Controller anetd nicht. Das Symptom ist, dass Pods mit dem Präfix anet im Namespace kube-system weiterhin mit der folgenden Fehlermeldung abstürzen: BPF NodePort services needs kernel 4.17.0 or newer.

Dieses Problem betrifft Ubuntu 18.04 und 18.04.1, da sie auf der Kernel-Version 4.15 basieren.

Dieses Problem wurde in Anthos-Cluster auf Bare Metal 1.8.3 behoben.

1.7.x-Cluster aktualisieren, die containerd verwenden

Clusterupgrades auf 1.8.x sind für 1.7.x-Cluster blockiert, die für die Verwendung der Vorschaufunktion "containerd" konfiguriert sind. Die containerd-Vorschau verwendet den falschen Steuerungsgruppen-Treiber (cgroup) cgroupfs anstelle des empfohlenen systemd-Treibers. Es werden Fälle von Cluster-Instabilität gemeldet, wenn Cluster, die den cgroupfs-Treiber verwenden, unter Ressourcen-Druck gesetzt werden. Die GA-containerd-Funktion in Version 1.8.0 verwendet den richtigen Treiber systemd.

Wenn Sie bereits 1.7.x-Cluster haben, die die Containerlaufzeit "containerd" verwenden, empfehlen wir das Erstellen neuer 1.8.0-Cluster, die für containerd konfiguriert sind, und das Migrieren aller vorhandenen Anwendungen und Arbeitslasten. Hierdurch erreichen Sie die höchste Clusterstabilität bei Verwendung der containerd-Containerlaufzeit.

Fehler beim SELinux-Upgrade

Das Upgrade von Clustern der Version 1.7.1, die mit der containerd-Containerlaufzeit konfiguriert sind und SELinux unter RHEL oder CentOS ausführen, schlägt fehl. Wir empfehlen das Erstellen neuer 1.8.0-Cluster, die für die Verwendung von "containerd" konfiguriert sind, und das Migrieren Ihrer Arbeitslasten.

Der Knotenausgleich kann nicht gestartet werden, wenn der Knoten außerhalb der Reichweite liegt

Der Draining-Vorgang für Knoten startet nicht, wenn der Knoten von Anthos-Cluster auf Bare Metal nicht erreicht werden kann. Wenn ein Knoten beispielsweise während eines Clusterupgrades offline geht, reagiert das Upgrade möglicherweise nicht mehr. Dies kommt aber nur selten vor. Um die Wahrscheinlichkeit eines solchen Problems zu minimieren, sollten Sie vor dem Upgrade prüfen, ob die Knoten ordnungsgemäß funktionieren.

Aktion

kubeconfig-Secret überschrieben

Der Befehl bmctl check cluster überschreibt bei Ausführung in Nutzerclustern das kubeconfig-Secret des Nutzerclusters mit der Administratorcluster-kubeconfig. Das Überschreiben der Datei führt dazu, dass Standard-Clustervorgänge wie das Aktualisieren und Upgraden für betroffene Nutzercluster fehlschlagen. Dieses Problem betrifft die Anthos-Cluster auf Bare-Metal-Version 1.11.1 und frühere Versionen.

Führen Sie den folgenden Befehl aus, um festzustellen, ob ein Nutzercluster von diesem Problem betroffen ist:

kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
    USER_CLUSTER_NAME -kubeconfig  -o json  | jq -r '.data.value'  | base64 -d

Dabei gilt:

  • ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
  • USER_CLUSTER_NAME: der Name des zu prüfenden Nutzerclusters.

Wenn der Clustername in der Ausgabe (siehe contexts.context.cluster in der folgenden Beispielausgabe) der Name des Administratorclusters ist, ist der angegebene Nutzercluster betroffen.

user-cluster-kubeconfig  -o json  | jq -r '.data.value'  | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Mit den folgenden Schritten stellen Sie die Funktion in einem betroffenen Nutzercluster wieder her (USER_CLUSTER_NAME):

  1. Suchen Sie die kubeconfig-Datei des Nutzerclusters.

    Anthos-Cluster auf Bare-Metal generiert die kubeconfig-Datei auf der Administrator-Workstation, wenn Sie einen Cluster erstellen. Die Datei befindet sich standardmäßig im Verzeichnis bmctl-workspace/USER_CLUSTER_NAME.

  2. 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. In der Antwort werden Details zu den Knoten für den Nutzercluster zurückgegeben. Prüfen Sie, ob die Maschinennamen für Ihren Cluster korrekt sind.

  3. Führen Sie den folgenden Befehl aus, um die beschädigte kubeconfig-Datei im Administratorcluster zu löschen:

    kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig

  4. Führen Sie den folgenden Befehl aus, um das richtige kubeconfig-Secret wieder im Administratorcluster zu speichern:

    kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE

Zurücksetzen/Löschen

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. Wenn Sie einen Nutzercluster löschen, müssen Sie zuerst das Clusterobjekt löschen, bevor Sie seinen Namespace löschen. Andernfalls können die Jobs zum Zurücksetzen der Maschinen nicht erstellt werden und beim Löschen wird der Bereinigungsvorgang der Maschine übersprungen.

containerd-Dienst

Mit dem Befehl bmctl reset werden keine containerd-Konfigurationsdateien oder -Binärdateien gelöscht. Der Dienst containerd systemd bleibt aktiv. Mit dem Befehl werden die Container gelöscht, in denen für den Knoten geplante Pods ausgeführt werden.

Sicherheit

Die Cluster-Zertifizierungsstelle wird während des Upgrades rotiert. Die Unterstützung für On-Demand-Rotation ist ein Vorschaufeature.

Anthos-Cluster on Bare Metal rotiert kubelet-Zertifikate automatisch. Jeder kubelet-Knoten-Agent kann eine Anfrage zur Signierung des Zertifikats (Certificate Signing Request, CSR) senden, wenn ein Zertifikat die Ablaufzeit überschreitet. Ein Controller in Ihren Administratorclustern validiert und genehmigt die CSR.

Cluster-CA-Rotation (Vorschaufunktion)

Nachdem Sie in einem Cluster eine CA-Rotation (User Cluster Certificate Authority) durchgeführt haben, schlagen alle Nutzerauthentifizierungsabläufe fehl. Diese Fehler treten auf, da die in Authentifizierungsabläufen verwendete benutzerdefinierte ClientConfig-Ressource während der CA-Rotation nicht mit den neuen CA-Daten aktualisiert wird. Wenn Sie für Ihren Cluster eine CA-Rotation durchgeführt haben, prüfen Sie, ob das Feld certificateAuthorityData in default ClientConfig des Namespace kube-public die ältere Cluster-CA enthält.

Aktualisieren Sie das Feld certificateAuthorityData mit der aktuellen Cluster-CA, um das Problem manuell zu beheben.

Netzwerk

Quell-IP von Clients mit gebündeltem Layer-2-Load-Balancing

Wenn Sie die externe Trafficrichtlinie auf Local setzen, können Routingfehler wie No route to host für das gebündelte Layer-2-Load-Balancing auftreten. Die Richtlinie für externen Traffic ist standardmäßig auf Cluster (externalTrafficPolicy: Cluster) gesetzt. Mit dieser Einstellung verarbeitet Kubernetes den gesamten Cluster-Traffic. Dienste vom Typ LoadBalancer oder NodePort können externalTrafficPolicy: Local verwenden, um die Quell-IP-Adresse des Clients beizubehalten. Bei dieser Einstellung verarbeitet Kubernetes jedoch nur den lokalen Knoten-Traffic.

Wenn Sie die Quell-IP-Adresse des Clients beibehalten möchten, ist möglicherweise eine zusätzliche Konfiguration erforderlich, damit die Dienst-IP-Adressen erreichbar sind. Konfigurationsdetails finden Sie unter Gebündeltes Client-IP-Adressen beibehalten.

Durch Ändern von firewalld werden Cilium-iptable-Richtlinienketten gelöscht

Wenn Sie Anthos-Cluster on Bare-Metal ausführen und firewalld entweder in 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 anetd-Pod beim Start hinzugefügt. Der Verlust der Cilium-iptables-Ketten führt dazu, dass die Pod-Verbindung zum Knoten außerhalb des Knotens unterbrochen wird.

Änderungen an firewalld, die die iptables-Ketten entfernen, sind unter anderem:

  • firewalld mit systemctl neu starten
  • firewalld mit dem Befehlszeilenclient neu laden (firewall-cmd --reload)

Sie können dieses Verbindungsproblem beheben, indem Sie anetd auf dem Knoten neu starten. Suchen Sie den anetd-Pod und löschen Sie ihn mit den folgenden Befehlen, um anetd neu zu starten:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Ersetzen Sie ANETD_XYZ durch den Namen des anetd-Pods.

Doppelte egressSourceIP-Adressen

Bei Verwendung der Feature-Vorschau des NAT-Gateways für ausgehenden Traffic besteht die Möglichkeit, Trafficauswahlregeln festzulegen, die eine egressSourceIP-Adresse angeben, die bereits für ein anderes EgressNATPolicy-Objekt verwendet wird. Dies kann zu Konflikten beim Routing von ausgehendem Traffic führen. Erkundigen Sie sich bei Ihrem Entwicklungsteam, welche Floating-IP-Adressen zur Verfügung stehen, bevor Sie die egressSourceIP-Adresse in Ihrer benutzerdefinierten EgressNATPolicy-Ressource angeben.

Pod-Verbindungsfehler aufgrund von E/A-Zeitüberschreitungen und Reverse-Pfadfilterung

Anthos-Cluster auf Bare Metal konfigurieren die Reverse-Pfadfilterung auf Knoten, um die Quellvalidierung (net.ipv4.conf.all.rp_filter=0) zu deaktivieren. Wenn die Einstellung rp_filter in 1 oder 2 geändert wird, schlagen Pods aufgrund von Zeitüberschreitungen außerhalb des Knotens fehl.

Beobachtete Verbindungsfehler, die mit IP-Adressen des Kubernetes-Dienstes kommunizieren, sind ein Symptom für dieses Problem. Im Folgenden finden Sie einige Beispiele für die möglichen Fehlertypen:

  • Wenn alle Pods für einen bestimmten Knoten nicht mit den Dienst-IP-Adressen kommunizieren, meldet der Pod istiod möglicherweise einen Fehler wie den folgenden:

     {"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z",
    "message":"watch error in cluster Kubernetes: failed to list *v1.Node:
    Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5  34239\":
    dial tcp 172.26.0.1:443: i/o timeout"}

  • Für den auf jedem Knoten ausgeführten Daemon-Satz localpv wird im Log möglicherweise eine Zeitüberschreitung wie die folgende angezeigt:

     I1112 17:24:33.191654       1 main.go:128] Could not get node information
(remaining retries: 2): Get
https://172.26.0.1:443/api/v1/nodes/NODE_NAME:
dial tcp 172.26.0.1:443: i/o timeout

Die Reverse-Pfadfilterung wird mit rp_filter-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all) festgelegt. Mit dem Befehl sysctl werden Einstellungen für die Reverse-Pfadfilterung in einer Netzwerksicherheits-Konfigurationsdatei gespeichert, z. B. /etc/sysctl.d/60-gce-network-security.conf. Der Befehl sysctl kann die Einstellung für die Reverse-Pfadfilterung überschreiben.

Zur Wiederherstellung der Pod-Verbindung können Sie net.ipv4.conf.all.rp_filter entweder manuell auf 0 zurücksetzen oder den anetd-Pod neu starten, um net.ipv4.conf.all.rp_filter wieder auf 0 zurückzusetzen. Wenn Sie den Pod anetd neu starten möchten, verwenden Sie die folgenden Befehle, um den Pod anetd zu finden und zu löschen. Stattdessen wird ein neuer Pod anetd gestartet:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Ersetzen Sie ANETD_XYZ durch den Namen des anetd-Pods.

Führen Sie den folgenden Befehl aus, um net.ipv4.conf.all.rp_filter manuell festzulegen:

sysctl -w net.ipv4.conf.all.rp_filter = 0

Cluster-IP-Adressen vom Typ Bootstrap und IP-Adressen von Clusterknoten:

192.168.122.0/24 und 10.96.0.0/27 sind die Standard-Pod- und Dienst-CIDRs, die vom Bootstrap-Cluster (Typ) verwendet werden. Preflight-Prüfungen schlagen fehl, wenn sie sich mit IP-Adressen von Clusterknoten überschneiden. Zur Vermeidung des Konflikts können Sie die Flags --bootstrap-cluster-pod-cidr und --bootstrap-cluster-service-cidr an bmctl übergeben, um andere Werte anzugeben.

Überlappende IP-Adressen in verschiedenen Clustern

Es gibt während der Aktualisierung keine Validierung für überlappende IP-Adressen über verschiedene Cluster hinweg. Die Validierung gilt nur beim Erstellen des Clusters/Knotenpools.

Betriebssystem

Fehler beim Erstellen oder Upgraden von Clustern unter CentOS

Im Dezember 2020 gab die CentOS-Community und Red Hat die Einstellung von CentOS bekannt. Am 31. Januar 2022 erreicht CentOS 8 das Ende des Produktzyklus (End of Life, EOL). Aufgrund der EOL-Dauer funktionieren yum-Repositories nicht mehr für CentOS, was dazu führt, dass Clustererstellung und Cluster-Upgrade-Vorgänge fehlschlagen. Dies gilt für alle unterstützten Versionen von CentOS und betrifft alle Versionen von Anthos-Clustern auf Bare-Metal.

Um das Problem zu umgehen, führen Sie die folgenden Befehle aus, damit Ihr CentOS einen Archiv-Feed verwendet:

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
    /etc/yum.repos.d/CentOS-Linux-*

Als langfristige Lösung sollten Sie zu einem anderen unterstützten Betriebssystem migrieren.

Einschränkungen des Betriebssystem-Endpunkts

Bei RHEL und CentOS gibt es eine Beschränkung auf Clusterebene von 100.000 Endpunkten. Diese Zahl ist die Summe aller Pods, auf die ein Kubernetes-Dienst verweist. Wenn zwei Dienste auf dieselbe Gruppe von Pods verweisen, wird dies als zwei separate Gruppen von Endpunkten gezählt. Die zugrunde liegende nftable-Implementierung unter RHEL und CentOS führt diese Einschränkung aus. Es ist keine Systeminstabilität von Anthos-Cluster on Bare Metal.

Konfiguration

Spezifikationen der Steuerungsebene und des Load-Balancers

Die Knotenpoolspezifikationen der Steuerungsebene und des Load-Balancers sind spezifisch. Diese Spezifikationen deklarieren und steuern wichtige Clusterressourcen. Die kanonische Quelle für diese Ressourcen sind die entsprechenden Abschnitte in der Cluster-Konfigurationsdatei:

  • spec.controlPlane.nodePoolSpec
  • spec.LoadBalancer.nodePoolSpec

Daher sollten Sie die Knotenpoolressourcen der obersten Ebene und die Load-Balancer-Knotenressourcen nicht direkt ändern. Ändern Sie stattdessen die zugehörigen Abschnitte in der Cluster-Konfigurationsdatei.

Anthos VM Runtime

  • Beim Neustart eines Pods ändern sich die IP-Adressen der VMs auf dem Pod oder gehen ganz verloren. Wenn sich die IP-Adresse einer VM ändert, wirkt sich das nicht auf die Erreichbarkeit von VM-Anwendungen aus, die als Kubernetes-Dienst bereitgestellt werden. Wenn die IP-Adresse verloren geht, müssen Sie dhclient von der VM aus ausführen, um eine IP-Adresse für die VM zu erhalten.

SELinux

SELinux-Fehler bei der Pod-Erstellung

Die Pod-Erstellung schlägt manchmal fehl, wenn SELinux verhindert, dass die Containerlaufzeit Labels auf tmpfs-Bereitstellungen festlegt. Dieser Fehler ist selten, kann aber auftreten, wenn SELinux im Modus Enforcing ist, und in einigen Kerneln.

Mit folgendem Befehl prüfen Sie in den kubelet-Logs, ob SELinux die Ursache für Fehler bei der Pod-Erstellung ist:

journalctl -u kubelet

Wenn SELinux dazu führt, dass die Pod-Erstellung fehlschlägt, enthält die Befehlsantwort einen Fehler wie den folgenden:

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 folgenden Befehl aus, um zu kontrollieren, dass dieses Problem mit der SELinux-Erzwingung zusammenhängt:

ausearch -m avc

Dieser Befehl durchsucht die Auditlogs nach Berechtigungsfehlern des Zugriffsvektor-Cache (Access Vector Cache, AVC). Die Ausgabe avc: denied in der folgenden Beispielantwort bestätigt, dass Fehler bei der Pod-Erstellung mit der SELinux-Erzwingung zusammenhängen.

type=AVC msg=audit(1627410995.808:9534): avc:  denied  { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0

Die Ursache dieses Problems der Pod-Erstellung mit SELinux ist ein Kernel-Fehler in den folgenden Linux-Images:

  • Red Hat Enterprise Linux (RHEL)-Releases vor 8.3
  • CentOS-Releases vor 8.3

Sie können das Problem durch einen Neustart des Computers beheben.

Damit Fehler bei der Pod-Erstellung vermieden werden, verwenden Sie RHEL 8.3 oder höher oder CentOS 8.3 oder höher, da diese Versionen den Kernel-Fehler behoben haben.

Snapshots

Snapshot als angemeldeter Nutzer ohne Root-Berechtigung erstellen

Wenn Sie bei Anthos-Clustern mit Bare-Metal-Versionen bis 1.8.1 und niedriger nicht als Root angemeldet sind, können Sie mit dem Befehl bmctl keinen Cluster-Snapshot erstellen. Ab Version 1.8.2 berücksichtigen Anthos-Cluster auf Bare-Metal nodeAccess.loginUser in der Clusterspezifikation. Wenn der Administratorcluster nicht erreichbar ist, können Sie den Anmeldenutzer mit dem Flag --login-user angeben.

Wenn Sie "containerd" als Containerlaufzeit verwenden, kann der Snapshot weiter keine crictl-Befehle ausführen. Eine Behelfslösung finden Sie unter containerd erfordert /usr/local/bin in PATH. Dieses Problem wird durch die PATH-Einstellungen für SUDO bedingt.

GKE Connect

gke-connect-agent-Pod in Absturzschleife

Eine intensive Nutzung des GKE Connect-Gateways kann manchmal zu Problemen mit unzureichendem Arbeitsspeicher bei gke-connect-agent-Pods führen. Mögliche Symptome von Problemen mit unzureichendem Arbeitsspeicher:

  • Der gke-connect-agent-Pod zeigt eine hohe Anzahl an Neustarts an oder endet verfängt sich in einer Absturzschleife.
  • Das Connect-Gateway funktioniert nicht mehr.

Um Problem mit fehlendem Speicher zu beheben, bearbeiten Sie die Bereitstellung mit dem Präfix gke-connect-agent unter dem Namespace gke-connect und erhöhen das Speicherlimit auf 256 MiB oder höher.

kubectl patch deploy $(kubectl get deploy -l app=gke-connect-agent -n gke-connect -o jsonpath='{.items[0].metadata.name}') -n gke-connect --patch '{"spec":{"containers":[{"resources":{"limits":{"memory":"256Mi"}}}]}}'

Dieses Problem wurde in Anthos-Clustern ab Bare-Metal-Version 1.8.2 behoben.

Logging und Monitoring

stackdriver-log-forwarder-Pod hängt beim Neustart

Bei Anthos-Cluster on Bare-Metal-Versionen vor 1.9 kann der stackdriver-log-forwarder-Pod im Status "Neustart" hängen bleiben, wenn ein Knoten zwangsweise heruntergefahren wird. In diesem Fall wird möglicherweise ein Logeintrag wie dieser angezeigt:

[error] [input:storage_backlog:storage_backlog.7] chunk validation failed, data might
be corrupted. Found 0 valid records, failed content starts right after byte 0.

Wenn der Pod stackdriver-log-forwarder hängen bleibt, werden die meisten Logs daran gehindert, zu Cloud Logging zu wechseln, und alle nicht geleerten Daten gehen verloren. Setzen Sie die Logging-Pipeline zurück, um dieses Problem zu beheben.

So setzen Sie die Logging-Pipeline zurück:

  1. Skalieren Sie den stackdriver-operator herunter.

    kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=0

  2. Löschen Sie das DaemonSet stackdriver-log-forwarder:

    kubectl --kubeconfig KUBECONFIG -n kube-system delete daemonset \
    stackdriver-log-forwarder

    Prüfen Sie, ob die stackdriver-log-forwarder-Pods gelöscht wurden, bevor Sie mit dem nächsten Schritt fortfahren.

  3. Stellen Sie das folgende DaemonSet bereit, um beschädigte Daten in fluent-bit-Puffern zu bereinigen:

    kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

  4. Prüfen Sie, ob das DaemonSet alle Knoten bereinigt hat.

    Die Ausgabe der folgenden Befehle sollte der Anzahl der Knoten in Ihrem Cluster entsprechen.

    kubectl --kubeconfig KUBECONFIG logs -n kube-system -l app=fluent-bit-cleanup | \
    grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG -n kube-system get pods -l app=fluent-bit-cleanup \
    --no-headers | wc -l

  5. Löschen Sie das Bereinigungs-Daemonset:

    kubectl --kubeconfig KUBECONFIG -n kube-system delete ds fluent-bit-cleanup

  6. Skalieren Sie den Operator vertikal und warten Sie, bis die Logging-Pipeline noch einmal bereitgestellt wird.

    kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=1

Dieses Problem wurde in den Anthos-Cluster on Bare-Metal-Versionen 19.0 und höher behoben.