Bekannte Probleme bei Anthos-Clustern on Bare-Metal

Installation

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.

Ab Anthos-Cluster on Bare Metal 1.6.2 prüft Preflight, ob cgroup v2 auf dem Clustercomputer verwendet wird.

Fehlermeldungen während der Installation

Bei der Hochverfügbarkeit (HA) des Clusters werden möglicherweise Fehler zu etcdserver leader change angezeigt. Diese Fehlermeldungen sind harmlos und können ignoriert werden.

Wenn Sie bmctl für die Cluster-Installation verwenden, wird möglicherweise am Ende von create-cluster.log die Lognachricht Log streamer failed to get BareMetalMachine angezeigt. Diese Fehlermeldung ist harmlos und kann ignoriert werden.

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..

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.

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.

Upgrades und Updates

Ein Upgrade ist in den Anthos-Clustern auf Bare-Metal 1.6.x-Releases nicht verfügbar.

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 diesem 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.

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.

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

Anmeldedaten für Nutzercluster

Der Befehl bmctl reset basiert auf der obersten Ebene der Anmeldedaten in der Cluster-Konfigurationsdatei. Bei Nutzerclustern müssen Sie die Datei manuell aktualisieren, um den Abschnitt "Anmeldedaten" hinzuzufügen.

Bereitstellungspunkte und fstab

Durch das Zurücksetzen werden die Bereitstellungspunkte unter /mnt/anthos-system und /mnt/localpv-share/ nicht getrennt. Außerdem werden die entsprechenden Einträge in /etc/fstab nicht bereinigt.

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.

Sicherheit

Die Cluster-Zertifizierungsstelle wird während des Upgrades rotiert. Eine On-Demand-Rotation wird derzeit nicht unterstützt.

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.

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.

Pod-Konnektivitätsfehler und Filterung für umgekehrte Pfade

Anthos-Cluster on Bare Metal konfiguriert die Filterung für umgekehrte Pfade 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 fehl, da außerhalb der Knoten das Kommunikationszeitlimit überschritten wird.

Die Filterung für umgekehrte Pfade wird mit rp_filter-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all) festgelegt. Dieser Wert kann auch von sysctl überschrieben werden. Damit werden Einstellungen der Filterung für umgekehrte Pfade in einer Netzwerksicherheitskonfigurationsdatei gespeichert, z. B. /etc/sysctl.d/60-gce-network-security.conf.

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. Für einen Neustart des anetd-Pods verwenden Sie die folgenden Befehle, um den anetd-Pod zu ermitteln und zu löschen und einen neuen anetd-Pod an seiner Stelle 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.

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 keine Vorabprüfung, um überlappende IP-Adressen in verschiedenen Clustern zu prüfen.

Funktion hostport in Anthos-Cluster on Bare Metal

Die Funktion hostport in ContainerPort wird derzeit nicht unterstützt.

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-*

Langfristige Lösung finden Sie in der Migration zu einem anderen unterstützten Betriebssystem wie Ubuntu oder RHEL.

Einschränkungen des Betriebssystem-Endpunkts

Bei RHEL und CentOS gibt es eine Beschränkung auf Clusterebene von 100.000 Endpunkten. Kubernetes-Dienst. 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.

Änderbare Felder in der Cluster- und Knotenpoolspezifikation

Derzeit können nur die folgenden Cluster- und Knotenpool-Spezifikationsfelder in der Cluster-Konfigurationsdatei aktualisiert werden, nachdem der Cluster erstellt wurde (änderbare Felder):

  • Für das Objekt Cluster (kind: Cluster) können die folgenden Felder geändert werden:

    • spec.anthosBareMetalVersion
    • spec.bypassPreflightCheck
    • spec.controlPlane.nodePoolSpec.nodes
    • spec.loadBalancer.nodePoolSpec.nodes
    • spec.maintenanceBlocks
    • spec.nodeAccess.loginUser

  • Für das Objekt NodePool (kind: NodePool) können die folgenden Felder geändert werden:

    • spec.nodes

Knoten zeigt den Status NotReady an

Unter bestimmten Lastbedingungen können Anthos-Cluster auf Bare-Metal 1.6.x-Knoten den Status NotReady zeigen, da Pod Lifecycle Event Generator (PLEG) fehlerhaft ist. Der Knotenstatus enthält den folgenden Eintrag:

PLEG is not healthy: pleg was last seen active XXXmXXXs ago; threshold is 3m0s

Woher weiß ich, ob ich betroffen bin?

Eine mögliche Ursache für dieses Problem ist die Binärversion von runc. Sie können prüfen, ob die problematische Version installiert ist, indem Sie eine SSH-Verbindung zu einem der Clustermaschinen herstellen und Folgendes ausführen:

/usr/bin/runc -v

Wenn die Ausgabe 1.0.0-rc93 lautet, ist die problematische Version installiert.

Mögliche Problemumgehungen

Um dieses Problem zu beheben, empfehlen wir die Aktualisierung auf Anthos-Cluster auf Bare-Metal 1.7.0 oder eine höhere Version.

Wenn das Upgrade nicht möglich ist, können Sie das Paket containerd.io auf eine frühere Version der problematischen Knotenmaschinen zurücksetzen. Stellen Sie dazu eine SSH-Verbindung zur Knotenmaschine her und führen Sie Folgendes aus:

Ubuntu 

apt install containerd.io=1.4.3-1

CentOS/RHEL 

dnf install containerd.io-1.3.9-3.1.el8.