Version 1.7. Diese Version wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Richtlinie zu unterstützten Versionen. Informationen zum Upgrade auf Version 1.8 finden Sie unter Upgrade von Anthos auf BareMetal ausführen in der Dokumentation zu 1.8.

Verfügbare unterstützte Versionen: 1.14 | 1.13 | 1.12

Diese Seite wurde von der Cloud Translation API übersetzt.

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

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 werden angezeigt, weil /tmp mit der Option noexec bereitgestellt wird. Damit bmctl funktioniert, müssen Sie die Option noexec aus dem Bereitstellungspunkt /tmp entfernen.

Erstellen eines Cloud Monitoring-Arbeitsbereichs vor dem Aufrufen von Dashboards

Sie müssen einen Cloud Monitoring-Arbeitsbereich über die Google Cloud Console erstellen, bevor Sie Anthos-Cluster auf Bare-Metal-Monitoring-Dashboards ansehen können.

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.

Ubuntu 20.04.3+ LTS und HWE

Ubuntu 20.04.3 aktiviert Kernel 5.11 im Hardware-Aktivierungspaket (HWE). Anthos-Cluster auf Bare-Metal Version 1.7.x unterstützt diesen Kernel nicht. Wenn Sie Kernel 5.11 verwenden möchten, laden Sie Anthos-Cluster auf Bare-Metal 1.8.0 oder höher herunter und führen Sie ein Upgrade auf Anthos-Cluster aus.

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.

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.

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 (Pod Lifecycle Event Generator, 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:

Führen Sie die folgenden Befehle auf jedem Knoten aus, um die neueste Datei „containerd.io“ zu installieren und extrahieren Sie das aktuelle runc-Befehlszeilentool:

Ubuntu

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

CentOS/RHEL

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

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

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:

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.
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.
Speichern Sie die Änderungen und wenden Sie sie auf die Ressource an.
Wiederholen Sie das Clusterupgrade.

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

Das Upgrade von Clustern auf 1.7.6 von 1.7.5 ist blockiert.

Sie können kein Upgrade von Anthos on Bare Metal Version 1.7.5 auf Version 1.7.6 durchführen. Diese Blockierung hat keine Auswirkungen auf andere Versionen von Anthos-Clustern on Bare Metal. Beispielsweise ist ein Upgrade der Cluster von Version 1.7.4 auf Version 1.7.6 möglich. Wenn Sie Cluster der Version 1.7.5 haben, müssen Sie, um die in Version 1.7.6 behobenen Sicherheitslücken ebenfalls zu beheben, ein Upgrade auf eine neuere Version durchführen, sobald diese verfügbar ist.

Von 1.6.0 upgraden.

Ein Upgrade ist in Version 1.6.0 nicht verfügbar.

Von 1.7.0 auf 1.7.x upgraden

Beim Upgrade von 1.7.0 auf 1.7.x kann es passieren, dass Ihr Cluster beim Knotenupgrade der Steuerungsebene hängen bleibt. Möglicherweise sehen Sie, dass MACHINE-IP-machine-upgrade-Jobs regelmäßig ausgeführt werden und fehlschlagen. Dieses Problem betrifft 1.7.0-Cluster mit:

Auf Knoten der Steuerungsebene vorinstallierten Docker.
Als Laufzeit ausgewähltem containerd.

Dieses Problem wird durch Anthos-Cluster on Bare Metal verursacht, wenn der cri-socket mit Docker statt mit containerd konfiguriert wird. Um dieses Problem zu beheben, müssen Sie die Image-Pull-Anmeldedaten für Docker festlegen:

Melden Sie sich bei Docker an:
```
docker login gcr.io
```
Dadurch wird eine $HOME/.docker/config.json-Datei erstellt.
Listen Sie die IP-Adressen aller Knoten der Steuerungsebene auf, getrennt durch ein Leerzeichen:
```
IPs=(NODE_IP1 NODE_IP2 ...)
```
Kopieren Sie die Docker-Konfiguration in die Knoten:
```
for ip in "${IPs[@]}"; do
  scp $HOME/.docker/config.json USER_NAME@{ip}:docker-config.json
```
Ersetzen Sie USER_NAME durch den Nutzernamen, der in der Konfigurationsdatei des Administratorclusters konfiguriert ist.

Legen Sie die Image-Pull-Anmeldedaten für Docker fest:

ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"

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.8.1 (anthosBareMetalVersion: 1.8.1), der Nutzercluster der Version 1.7.2 verwaltet, akzeptabel, aber Nutzercluster der Version 1.6.3 sind mehr als eine Nebenversion niedriger.

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.8.2 hat, die am 29. Juli 2021 veröffentlicht wurde, können Sie Ihre Nutzercluster nicht auf Version 1.7.3 aktualisieren, da sie am 16. August veröffentlicht wurde.

Der Treiber der Kontrollgruppe ist falsch zu `cgroupfs` konfiguriert

Probleme im Zusammenhang mit dem Treiber der Kontrollgruppe (cgroup) können durch Anthos-Cluster on Bare Metal verursacht werden, wenn der Treiber mit cgroupfs statt mit systemd konfiguriert ist.

So beheben Sie das Problem:

Melden Sie sich auf Ihrem Computer an, öffnen Sie /etc/containerd/config.toml.

Fügen Sie unter [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true hinzu:

...
   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
     [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
       runtime_type = "io.containerd.runc.v2"
       runtime_engine = ""
       runtime_root = ""
       privileged_without_host_devices = false
       base_runtime_spec = ""
       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
         SystemdCgroup = true
 [plugins."io.containerd.grpc.v1.cri".cni]
   bin_dir = "/opt/cni/bin"
   conf_dir = "/etc/cni/net.d"
   max_conf_num = 1
   conf_template = ""
...

Speichern Sie die Änderungen und schließen Sie die Datei.
Öffnen Sie /etc/systemd/system/kubelet.service.d/10-kubeadm.conf.

Fügen Sie am Ende der Datei --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service hinzu:

[Service]
Environment="HOME=/root"
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service

Speichern Sie die Änderungen und starten Sie den Server neu:
Prüfen Sie, ob systemd der Treiber für die Kontrollgruppe ist. Führen Sie dazu folgenden Befehl aus:
```
systemd-cgls
```
Prüfen Sie, ob der Abschnitt kubepods.slice vorhanden ist und ob sich alle Pods in diesem Abschnitt befinden.

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):

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

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

Unterstützung für Nutzercluster

Sie können Nutzercluster nicht mit dem Befehl bmctl reset zurücksetzen.

Bereitstellungspunkte und `fstab`

Durch das Zurücksetzen werden die Bereitstellungspunkte unter /mnt/localpv-share/ nicht getrennt und die entsprechenden Einträge in /etc/fstab werden 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.

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

Logging und Monitoring

Knotenlogs werden nicht nach Cloud Logging exportiert

Knotenlogs von Knoten mit einem Punkt (".") im Namen werden nicht nach Cloud Logging exportiert. Um dieses Problem zu umgehen, fügen Sie der Ressource stackdriver-log-forwarder-config einen Filter hinzu, damit der Stackdriver-Operator diese Logs erkennen und exportieren kann.

Skalieren Sie die Größe des Stackdriver-Operators stackdriver-operator:

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

Bearbeiten Sie die ConfigMap stackdriver-log-forwarder-config:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system edit configmap \
    stackdriver-log-forwarder-config

Fügen Sie den folgenden Filter am Ende des Abschnitts input-systemd.conf der ConfigMap hinzu:

   [FILTER]
       Name    lua
       Match_Regex   container-runtime|kubelet|node-problem-detector|node-journal
       script  replace_dot.lua
       call    replace

 replace_dot.lua: |
   function replace(tag, timestamp, record)
       new_record = record

       local local_resource_id_key = "logging.googleapis.com/local_resource_id"

       -- Locate the local_resource_id
       local local_resource_id = record[local_resource_id_key]

       local first = 1
       local new_local_resource_id = ""
       for s in string.gmatch(local_resource_id, "[^.]+") do
           new_local_resource_id = new_local_resource_id .. s
           if first == 1 then
               new_local_resource_id = new_local_resource_id .. "."
               first = 0
           else
               new_local_resource_id = new_local_resource_id .. "_"
           end
       end

       -- Remove the trailing underscore
       new_local_resource_id = new_local_resource_id:sub(1, -2)
       new_record[local_resource_id_key] = new_local_resource_id
       return 1, timestamp, new_record
   end

Löschen Sie alle Log Weiterleitungs-Pods:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch daemonset \
    stackdriver-log-forwarder -p \
    '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

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

Stellen Sie ein Daemonset bereit, um alle bereinigten, unverarbeiteten Daten in Puffern in Fließkomma-Bit zu bereinigen:

kubectl --kubeconfig ADMIN_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

Prüfen Sie mit den folgenden Befehlen, ob das Daemonset alle Knoten bereinigt hat.

kubectl --kubeconfig ADMIN_KUBECONFIG logs -n kube-system \
    -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get pods \
    -l app=fluent-bit-cleanup --no-headers | wc -l

Die Ausgabe der beiden Befehle sollte Ihrer Knotennummer im Cluster entsprechen

Löschen Sie das Cleanup-Daemonset:

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

Starten Sie die Pods neu:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch \
    daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

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 auf Bare Metal ausführen und firewalld unter 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.

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

Ä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

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"}}}]}}'