Bekannte Probleme bei Anthos-Clustern on Bare-Metal

Auf dieser Seite werden alle bekannten Probleme für Anthos-Cluster auf Bare Metal aufgeführt. Wählen Sie zum Filtern der bekannten Probleme nach einer Produktversion oder Kategorie die gewünschten Filter aus den folgenden Drop-down-Menüs aus.

Wählen Sie Ihre Version von Anthos-Clustern auf Bare Metal aus:

Wählen Sie eine Problemkategorie aus:

Sie können auch nach Ihrem Problem suchen:

Kategorie Ermittelte Version(en) Problem und Problemumgehung
Netzwerk 1.15.0–1.15.2

CoreDNS orderPolicy wurde nicht erkannt

OrderPolicy wird nicht als Parameter erkannt und nicht verwendet. Stattdessen verwendet Anthos-Cluster auf Bare Metal immer Random.

Dieses Problem tritt auf, weil die CoreDNS-Vorlage nicht aktualisiert wurde und orderPolicy deshalb ignoriert wird.


Workaround:

Aktualisieren Sie die CoreDNS-Vorlage und wenden Sie den Fehler an. Dieses Problem wird bis zum Upgrade behoben.

  1. Bearbeiten Sie die Vorlage: 
    kubectl edit cm -n kube-system coredns-template
     Ersetzen Sie den Inhalt der Vorlage durch Folgendes: 
    coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
Netzwerk, Betrieb 1.10, 1.11, 1.12, 1.13, 1.14

Anthos Network Gateway-Komponenten, die entfernt wurden oder ausstehend sind, weil die Prioritätsklasse fehlt

Netzwerk-Gateway-Pods in kube-system können den Status Pending oder Evicted haben, wie in der folgenden verkürzten Beispielausgabe gezeigt:

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Diese Fehler weisen auf Bereinigungsereignisse oder auf die Unmöglichkeit hin, Pods aufgrund von Knotenressourcen zu planen. Da Anthos Network Gateway-Pods keine PriorityClass haben, haben sie dieselbe Standardpriorität wie andere Arbeitslasten. Wenn Knoten durch Ressourcen beschränkt sind, werden die Netzwerk-Gateway-Pods möglicherweise entfernt. Dieses Verhalten ist insbesondere für das ang-node-DaemonSet schlecht, da diese Pods auf einem bestimmten Knoten geplant werden können und nicht migriert werden können.


Workaround:

Führen Sie ein Upgrade auf Version 1.15 oder höher aus.

Als kurzfristige Lösung können Sie den Anthos Network Gateway-Komponenten manuell eine PriorityClass zuweisen. Die Anthos-Cluster auf Bare Metal-Controller überschreiben diese manuellen Änderungen während eines Abgleichsprozesses, z. B. bei einem Cluster-Upgrade.

  • Weisen Sie den Deployment-Controllern Cluster ang-controller-manager und autoscaler die Priorität system-cluster-critical zu.
  • Weisen Sie dem ang-daemon-Knoten-DaemonSet die Prioritätsklasse system-node-critical zu.
Installation, Upgrades und Updates 1.15.0, 1.15.1, 1.15.2

Clustererstellung und Upgrades schlagen aufgrund der Länge des Clusternamens fehl

Das Erstellen von Clustern der Version 1.15.0, 1.15.1 oder 1.15.2 oder das Upgrade von Clustern auf Version 1.15.0, 1.15.1 oder 1.15.2 schlägt fehl, wenn der Clustername länger als 48 Zeichen (Version 1.15.0) oder 45 Zeichen (Version 1.15.1 oder 1) ist. Beim Erstellen und Upgraden von Clustern wird für Anthos-Cluster auf Bare Metal eine Systemdiagnoseressource mit einem Namen erstellt, der den Clusternamen und die Clusterversion enthält:

  • Bei Clustern der Version 1.15.0 lautet der Ressourcenname der Systemdiagnose CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Für Cluster der Version 1.15.1 oder 1.15.2 lautet der Ressourcenname der Systemdiagnose CLUSTER_NAME-kubernetes-CLUSTER_VER.

Bei langen Clusternamen überschreitet der Systemdiagnoseressourcenname die Zeichenbeschränkung von Kubernetes 63 für Labelnamen, wodurch das Erstellen der Systemdiagnoseressource verhindert wird. Ohne eine erfolgreiche Systemdiagnose schlägt der Clustervorgang fehl.

Prüfen Sie mit kubectl describe, ob Sie von diesem Problem betroffen sind: 

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Wenn dieses Problem Sie betrifft, enthält die Antwort eine Warnung für ReconcileError wie die folgende: 

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Problemumgehung

Wenn Sie die Clusteraktualisierung oder -erstellung aufheben möchten, können Sie die Systemdiagnose umgehen. Verwenden Sie den folgenden Befehl, um die benutzerdefinierte Ressource mit Systemdiagnose mit Patching-Status zu patchen: (status: {pass: true})

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Upgrades und Updates 1,14, 1,15

Cluster mit Version 1.14.0 und 1.14.1 mit Vorschaufunktionen können nicht auf Version 1.15.x aktualisiert werden.

Wenn für Cluster der Version 1.14.0 und 1.14.1 ein Vorschaufeature aktiviert ist, ist kein Upgrade auf Version 1.15.x mehr möglich. Dies gilt für Vorschaufeatures wie die Möglichkeit, einen Cluster ohne kube-proxy zu erstellen. Dieser ist mit der folgenden Annotation in der Clusterkonfigurationsdatei aktiviert:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Wenn Sie von diesem Problem betroffen sind, erhalten Sie während des Clusterupgrades eine Fehlermeldung wie die folgende:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Dieses Problem wurde in Anthos-Clustern mit Bare-Metal-Version 1.14.2 und höher behoben.


Workaround:

Wenn ein Upgrade Ihrer Cluster auf Version 1.14.2 oder höher nicht möglich ist, können Sie direkt mit einem Bootstrap-Cluster auf Version 1.15.x upgraden:

bmctl upgrade cluster --use-bootstrap=true
Vorgang 1.15

Cluster mit Version 1.15 akzeptieren keine doppelten Floating-IP-Adressen

Mit Anthos Network Gateway können Sie keine neuen benutzerdefinierten Ressourcen vom Typ NetworkGatewayGroup erstellen, die IP-Adressen in spec.floatingIPs enthalten, die bereits in vorhandenen benutzerdefinierten NetworkGatewayGroup-Ressourcen verwendet werden. Diese Regel wird von einem Webhook in Anthos-Clustern auf Bare-Metal-Version 1.15.0 und höher erzwungen. Bereits vorhandene Floating-IP-Adressen verursachen keine Fehler. Der Webhook verhindert nur das Erstellen neuer benutzerdefinierter NetworkGatewayGroups-Ressourcen mit doppelten IP-Adressen.

Die Webhook-Fehlermeldung gibt die in Konflikt stehende IP-Adresse und die vorhandene benutzerdefinierte Ressource an, die sie bereits verwendet: 

IP address exists in other gateway with name default

In der ersten Dokumentation zu erweiterten Netzwerkfeatures wie dem NAT-Gateway für ausgehenden Traffic können Sie doppelte IP-Adressen nicht berücksichtigen. Anfangs wurde nur die Ressource NetworkGatewayGroup mit dem Namen default vom Abgleich erkannt. Anthos Network Gateway erkennt jetzt alle benutzerdefinierten NetworkGatewayGroup-Ressourcen im System-Namespace. Vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen werden unverändert beibehalten.


Workaround:

Fehler treten nur beim Erstellen einer neuen benutzerdefinierten Ressource vom Typ NetworkGatewayGroup auf.

So beheben Sie den Fehler:

  1. Verwenden Sie den folgenden Befehl, um NetworkGatewayGroups benutzerdefinierte Ressourcen aufzulisten: 
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system -o yaml
  2. Öffnen Sie vorhandene benutzerdefinierte NetworkGatewayGroup-Ressourcen und entfernen Sie in Konflikt stehende Floating-IP-Adressen (spec.floatingIPs): 
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system RESOURCE_NAME
  3. Schließen und speichern Sie bearbeitete benutzerdefinierte Ressourcen, um Ihre Änderungen zu übernehmen.
Anthos-VM-Laufzeit 1.13.7

VMs werden möglicherweise nicht auf 1.13.7-Clustern gestartet, die eine private Registry verwenden

Wenn Sie die Anthos-VM-Laufzeit in einem neuen oder aktualisierten Cluster der Version 1.13.7 aktivieren, der eine private Registry verwendet, werden VMs, die eine Verbindung zum Knotennetzwerk herstellen oder eine GPU verwenden, möglicherweise nicht richtig gestartet. Dieses Problem ist darauf zurückzuführen, dass einige System-Pods im Namespace vm-system Image-Abruffehler erhalten. Wenn Ihre VM beispielsweise das Knotennetzwerk verwendet, melden einige Pods möglicherweise Image-Abruffehler wie die folgenden:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Dieses Problem wurde in Anthos-Clustern mit Bare-Metal-Version 1.14.0 und höher behoben.

Problemumgehung

Wenn Sie Ihre Cluster nicht sofort upgraden können, können Sie Images manuell abrufen. Mit den folgenden Befehlen rufen Sie das MACNI-CNI-Plug-in-Image für Ihre VM ab und übertragen es per Push in Ihre private Registry: 

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Ersetzen Sie REG_HOST durch den Domainnamen eines lokal gespiegelten Hosts.

Installation 1,11, 1,12

Beim Erstellen des Clusters im Artcluster kann der gke-metric-agent-Pod nicht gestartet werden

Während der Clustererstellung im Artcluster kann der gke-metrics-agent-Pod aufgrund eines Fehlers beim Abrufen des Images so nicht gestartet werden:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Außerdem sehen Sie im Containerd-Log des Bootstrap-Clusters den folgenden Eintrag:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Im Pod wird der Fehler „Fehler beim Abrufen“ angezeigt:

gcr.io/gke-on-prem-staging/gke-metrics-agent

Problemumgehung

Trotz der Fehler wird der Clustererstellungsprozess nicht blockiert, da der Zweck des gke-metrics-agent-Pods in Artclustern die Erfolgsquote bei der Clustererstellung sowie das interne Tracking und Monitoring erleichtert wird. Daher können Sie diesen Fehler ignorieren.

Problemumgehung

Trotz der Fehler wird der Clustererstellungsprozess nicht blockiert, da der Zweck des gke-metrics-agent-Pods in Artclustern die Erfolgsquote bei der Clustererstellung sowie das interne Tracking und Monitoring erleichtert wird. Daher können Sie diesen Fehler ignorieren.
Betrieb, Netzwerk 1,12, 1,13, 1,14, 1,15

Beim Zugriff auf einen IPv6-Dienstendpunkt stürzt der LoadBalancer-Knoten unter CentOS oder RHEL ab

Wenn Sie auf einen Dual-Stack-Dienst (ein Dienst mit IPv4- und IPv6-Endpunkten) zugreifen und den IPv6-Endpunkt verwenden, kann der LoadBalancer-Knoten, der den Dienst bereitstellt, abstürzen. Dieses Problem betrifft Kunden, die Dual-Stack-Dienste mit CentOS oder RHEL und einer Kernel-Version vor kernel-4.18.0-372.46.1.el8_6 verwenden.

Wenn Sie der Meinung sind, dass dieses Problem Sie betrifft, prüfen Sie die Kernel-Version auf dem LoadBalancer-Knoten mit dem Befehl uname -a.


Workaround:

Aktualisieren Sie den LoadBalancer-Knoten auf Kernel-Version kernel-4.18.0-372.46.1.el8_6. Diese Kernel-Version ist standardmäßig in CentOS und RHEL Version 8.6 und höher verfügbar.
Netzwerk 1.11, 1.12, 1.13, 1.14.0

Zeitweilige Verbindungsprobleme nach dem Neustart des Knotens

Nach dem Neustart eines Knotens können zeitweise Verbindungsprobleme für einen NodePort- oder LoadBalancer-Dienst auftreten. Beispielsweise kann es zu vorübergehenden TLS-Handshake- oder Verbindungsfehlern kommen. Dieses Problem wurde für Anthos-Cluster mit Bare-Metal-Version 1.14.1 und höher behoben.

Prüfen Sie anhand der iptables-Weiterleitungsregeln auf Knoten, auf denen der Back-End-Pod für den betroffenen Dienst ausgeführt wird, ob das Problem Auswirkungen hat:

sudo iptables -L FORWARD

Wenn Sie die Regel KUBE-FORWARD vor der Regel CILIUM_FORWARD in iptables sehen, sind Sie möglicherweise von diesem Problem betroffen. Die folgende Beispielausgabe zeigt einen Knoten, bei dem das Problem besteht:


Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Workaround:

Starten Sie den anetd-Pod auf dem Knoten neu, der falsch konfiguriert ist. Nachdem Sie den Pod neu gestartet haben, sollte die Weiterleitungsregel in iptables korrekt konfiguriert sein.

Die folgende Beispielausgabe zeigt, dass die Regel CILIUM_FORWARD jetzt korrekt konfiguriert ist als die Regel KUBE-FORWARD:


Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Upgrades und Updates 1,9, 1,10

Das Vorschaufeature enthält nicht die ursprünglichen Berechtigungen und Inhaberinformationen.

Die Vorschaufunktion des Clusters 1.9.x mit bmctl 1.9.x behält nicht die ursprünglichen Berechtigungen und Inhaberinformationen. Extrahieren Sie die gesicherte Datei mit dem folgenden Befehl, um zu ermitteln, ob Sie von diesem Feature betroffen sind:

tar -xzvf BACKUP_FILE

Problemumgehung

Prüfe, ob metadata.json vorhanden ist und ob bmctlVersion 1.9.x ist. Wenn metadata.json nicht vorhanden ist, führen Sie ein Upgrade auf den Cluster 1.10.x aus und verwenden Sie bmctl 1.10.x zum Sichern/Wiederherstellen.
Upgrades und Erstellungen 1.14.2

clientconfig-operator bleibt mit CreateContainerConfigError im Status „Ausstehend“

Wenn Sie ein Upgrade auf einen Cluster der Version 1.14.2 mit einer OIDC/LDAP-Konfiguration durchgeführt oder ein Upgrade dafür erstellt haben, wird der Pod clientconfig-operator möglicherweise im Status „Ausstehend“ hängen gelassen. Bei diesem Problem gibt es zwei clientconfig-operator-Pods, einer davon im Status „Wird ausgeführt“ und der andere im Status „Ausstehend“.

Dieses Problem gilt nur für Anthos-Cluster auf Bare-Metal-Version 1.14.2. Ältere Versionen wie 1.14.0 und 1.14.1 sind nicht betroffen. Dieses Problem wurde in Version 1.14.3 und allen nachfolgenden Releases behoben, einschließlich 1.15.0 und höher.


Workaround:

Als Behelfslösung können Sie das clientconfig-operator-Deployment patchen, um zusätzlichen Sicherheitskontext hinzuzufügen und dafür zu sorgen, dass das Deployment bereit ist.

Verwenden Sie den folgenden Befehl, um clientconfig-operator im Zielcluster zu patchen: 

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Ersetzen Sie Folgendes:

  • CLUSTER_KUBECONFIG ist der Pfad der kubeconfig-Datei für den Zielcluster.
Vorgang 1,11, 1,12, 1,13, 1,14, 1,15

Die Rotation der Zertifizierungsstelle schlägt für Cluster ohne gebündeltes Load-Balancing fehl

Bei Clustern ohne gebündeltes Load-Balancing (spec.loadBalancer.mode auf manual festgelegt) kann der Befehl bmctl update credentials certificate-authorities rotate nicht reagieren und mit dem folgenden Fehler fehlschlagen: x509: certificate signed by unknown authority.

Wenn Sie von diesem Problem betroffen sind, gibt der Befehl bmctl möglicherweise die folgende Meldung aus, bevor er nicht reagiert: 

Signing CA completed in 3/0 control-plane nodes
 In diesem Fall schlägt der Befehl fehl. Das Log der Zertifizierungsstelle für einen Cluster mit drei Steuerungsebenen kann Einträge wie den folgenden enthalten: 

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Problemumgehung

Wenn Sie weitere Hilfe benötigen, wenden Sie sich an den Google-Support.
Installation, Netzwerk 1.11, 1.12, 1.13, 1.14.0-1.14.1

ipam-controller-manager Absturzschleifen in Dual-Stack-Clustern

Wenn Sie einen Dual-Stack-Cluster (ein Cluster mit IPv4- und IPv6-Adressen) bereitstellen, können die ipam-controller-manager-Pods eine Absturzschleife verursachen. Dieses Verhalten führt dazu, dass die Knoten zwischen Ready und NotReady wechseln und die Clusterinstallation fehlschlägt. Dieses Problem kann auftreten, wenn der API-Server stark ausgelastet ist.

Prüfen Sie, ob die ipam-controller-manager-Pods mit CrashLoopBackOff-Fehlern fehlschlagen:

kubectl -n kube-system get pods | grep  ipam-controller-manager

Die folgende Beispielausgabe zeigt Pods mit dem Status CrashLoopBackOff:


ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Rufen Sie Details zum Knoten mit dem Status NotReady ab:

kubectl describe node <node-name> | grep PodCIDRs

In einem Cluster mit diesem Problem sind einem Knoten keine PodCIDRs zugewiesen, wie in der folgenden Beispielausgabe gezeigt:


PodCIDRs:

In einem fehlerfreien Cluster sollten allen Knoten wie im folgenden Beispiel ausgegebene Dual-Stack-PodCIDRs zugewiesen sein:


PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Workaround:

Starten Sie den ipam-controller-manager-Pod neu:

kubectl -n kube-system rollout restart ds ipam-controller-manager
Vorgang 1,6, 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 und 1,14

etcd Watch Hunger

Bei Clustern mit der etcd-Version 3.4.13 oder niedriger können Watch-Wartungsaufgaben und nicht operative Ressourcenüberwachung ausfallen. Dies kann zu den folgenden Problemen führen:

  • Pod-Planung ist unterbrochen
  • Knoten können nicht registriert werden
  • Kubelet berücksichtigt keine Pod-Änderungen

Diese Probleme können dazu führen, dass der Cluster nicht mehr funktioniert.

Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Releases 1.12.9, 1.13.6, 1.14.3 und den nachfolgenden Releases behoben. Diese neueren Versionen verwenden die etcd-Version 3.4.21. Alle vorherigen Versionen von Anthos-Clustern auf Bare Metal sind von diesem Problem betroffen.

Problemumgehung

Wenn Sie das Upgrade nicht sofort ausführen können, verringern Sie das Risiko eines Clusterfehlers, indem Sie die Anzahl der Knoten im Cluster reduzieren. Entfernen Sie Knoten, bis der Messwert etcd_network_client_grpc_sent_bytes_total unter 300 Mbit/s liegt.

So rufen Sie diesen Messwert im Metrics Explorer auf:

  1. Rufen Sie in der Google Cloud Console den Metrics Explorer auf:

    Zum Metrics Explorer

  2. Wählen Sie den Tab Konfiguration aus.
  3. Maximieren Sie Messwert auswählen, geben Sie Kubernetes Container in die Filterleiste ein und wählen Sie den Messwert dann in den Untermenüs aus:
    1. Wählen Sie im Menü Aktive Ressourcen die Option Kubernetes-Container aus.
    2. Wählen Sie im Menü Aktive Messwertkategorien die Option Anthos aus.
    3. Wählen Sie im Menü Aktive Messwerte die Option etcd_network_client_grpc_sent_bytes_total aus.
    4. Klicken Sie auf „Übernehmen“.
Netzwerk 1.11.6, 1.12.3

vfio-pci-Modus des SR-IOV-Operators „Fehlgeschlagen“

Der syncStatus des SriovNetworkNodeState-Objekts kann den Wert „Failed“ für einen konfigurierten Knoten melden. Führen Sie den folgenden Befehl aus, um den Status eines Knotens aufzurufen und zu prüfen, ob das Problem sich auf Sie auswirkt:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Ersetzen Sie NODE_NAME durch den Namen des zu prüfenden Knotens.


Workaround:

Wenn der SriovNetworkNodeState-Objektstatus „Fehlgeschlagen“ lautet, aktualisieren Sie auf Anthos-Cluster auf Bare-Metal-Version 1.11.7 oder höher oder Version 1.12.4 oder höher.
Upgrades und Updates 1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1

Einige Worker-Knoten sind nach dem Upgrade nicht mehr bereit

Nachdem das Upgrade abgeschlossen ist, wird für einige Worker-Knoten möglicherweise die Status „Bereit“ auf false gesetzt. Für die Knotenressource wird ein Fehler neben der „Bereit“-Bedingung angezeigt, der dem folgenden Beispiel ähnelt:


container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Wenn Sie sich bei der angehaltenen Maschine anmelden, ist die CNI-Konfiguration auf der Maschine leer:

sudo ls /etc/cni/net.d/

Problemumgehung

Starten Sie den anetd-Pod des Knotens neu. Löschen Sie dazu den Pod.
Upgrades und Updates, Sicherheit 1.10

Mehrere Zertifikatsrotationen vom Zertifikatmanager führen zu Inkonsistenzen

Nach mehreren manuellen oder automatischen Zertifikatsrotationen wird der Webhook-Pod, z. B. anthos-cluster-operator, nicht mit den neuen Zertifikaten von cert-manager aktualisiert. Jede Aktualisierung der benutzerdefinierten Clusterressource schlägt fehl und führt zu einem Fehler wie diesem: 


Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Dieses Problem kann in den folgenden Fällen auftreten:

  • Wenn Sie zwei manuelle Zertifikatzertifikate für einen Cluster ausgeführt haben, der älter als 180 Tage ist, und den Anthos-Cluster-Operator nie neu gestartet haben.
  • Wenn Sie eine manuelle cert-manager-Zertifikatsrotation für einen Cluster durchgeführt haben, der älter als 90 Tage ist, und den Anthos-Cluster-Operator nie neu gestartet hat.

Problemumgehung

Starten Sie den Pod neu, indem Sie den anthos-cluster-Operator beenden.
Upgrades und Updates 1.14.0

Veraltete Lebenszyklus-Controller-Bereitsteller-Pods, die beim Upgrade des Nutzerclusters erstellt wurden

In Version 1.14.0-Administratorclustern können während Nutzerupgrades ein oder mehrere veraltete Lebenszyklus-Controller-Deployment-Pods erstellt werden. Dieses Problem tritt auf Nutzercluster auf, die ursprünglich in Versionen unter 1.12 erstellt wurden. Die unbeabsichtigt erstellten Pods wirken sich nicht auf Upgradevorgänge aus, können aber im abnormalen Zustand auftreten. Wir empfehlen, die veralteten Pods zu entfernen.

Dieses Problem wurde in Version 1.14.1 behoben.

Workaround:

So entfernen Sie die veralteten Lebenszyklus-Controller-Bereitsteller-Pods:

  1. Ressourcen für Preflight-Prüfungen auflisten: 

    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A

    Sie erhalten folgende Ausgabe:

    NAMESPACE                    NAME                      PASS   AGE
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d

    Dabei ist ci-87a021b9dcbb31c der Clustername.

  2. Löschen Sie Ressourcen, deren Wert in der Spalte „Pass“ entweder true oder false ist.

    Verwenden Sie beispielsweise die folgenden Befehle, um die Ressourcen in der vorherigen Beispielausgabe zu löschen:

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG 
kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG
Netzwerk 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Status BGPSession ändert sich aufgrund der großen Anzahl eingehender Routen ständig

Anthos-Cluster in erweiterten Bare-Metal-Netzwerken können BGP-Sitzungen nicht korrekt verwalten, wenn externe Peers eine große Anzahl von Routen bewerben (etwa 100 oder mehr). Bei einer großen Anzahl von eingehenden Routen dauert der Knoten-lokale BGP-Controller zu lange, um BGP-Sitzungen abzugleichen, und kann den Status nicht aktualisieren. Liegen keine Statusaktualisierungen oder eine Systemdiagnose vor, wird die Sitzung gelöscht.

Unerwünschtes Verhalten in BGP-Sitzungen, das Sie bemerken und auf ein Problem hinweisen können, ist Folgendes:

  • Kontinuierliches Löschen und Wiederherstellen von bgpsession.
  • bgpsession.status.state wird nie zu Established
  • Routen, die nicht beworben werden, oder wiederholt beworben und zurückgezogen werden.

BGP-Load-Balancing-Probleme können bei Verbindungsproblemen mit LoadBalancer-Diensten auftreten.

Das BGP-FlatIP-Problem kann bei Verbindungsproblemen mit Pods erkennbar sein.

Wenn Sie herausfinden möchten, ob Ihre BGP-Probleme durch Remote-Peers verursacht werden, die zu viele Routen anbieten, können Sie die folgenden Status und Ausgaben mit den folgenden Befehlen prüfen:

  • Verwenden Sie kubectl get bgpsessions für den betroffenen Cluster. Die Ausgabe zeigt bgpsessions mit dem Status „Nicht festgelegt“ und die letzte Zeit des Berichts dauert bis zu 10–12 Sekunden, bis es auf null zurückgesetzt wird.
  • Die Ausgabe von kubectl get bgpsessions zeigt, dass die betroffenen Sitzungen wiederholt neu erstellt werden:

    kubectl get bgpsessions \
    -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
  • Logmeldungen weisen darauf hin, dass veraltete BGP-Sitzungen gelöscht werden:

    kubectl logs ang-controller-manager-POD_NUMBER
     Ersetzen Sie POD_NUMBER durch den Leader-Pod in Ihrem Cluster.


Workaround:

Reduzieren oder verhindern Sie die Anzahl der Routen, die vom Remote-Peer zum Cluster mit einer Exportrichtlinie beworben werden.

In Anthos-Clustern auf Bare-Metal-Version 1.14.2 und höher können Sie das Feature, das empfangene Routen verarbeitet, mit einem AddOnConfiguration deaktivieren. Fügen Sie dem bgpd-Container des ang-daemon-Daemonset das Argument --disable-received-routes hinzu.
Netzwerk 1,14, 1,15

Zeitüberschreitungen bei Anwendungen aufgrund von Fehlern beim Einfügen der Conntrack-Tabelle

Cluster, die auf einem Ubuntu-Betriebssystem mit Kernel 5.15 oder höher ausgeführt werden, sind anfällig für Fehler beim Einfügen von Netfilter-Verbindungstabellen (Conntrack). Fehler beim Einfügen können auch dann auftreten, wenn in der Conntrack-Tabelle Platz für neue Einträge ist. Die Fehler werden durch Änderungen im Kernel 5.15 und höher verursacht, durch die Tabellenbereitstellungen basierend auf der Kettenlänge eingeschränkt werden.

Wenn Sie wissen möchten, ob Sie von diesem Problem betroffen sind, können Sie die Statistiken für das In-Kernel-Verbindungs-Tracking mit dem folgenden Befehl prüfen:

sudo conntrack -S

Die Antwort sieht so aus:

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Wenn ein chaintoolong-Wert in der Antwort eine Zahl ungleich null ist, sind Sie von diesem Problem betroffen.

Problemumgehung

Die vorläufige Risikominderung besteht darin, die Größe der Netfiler-Hash-Tabelle (nf_conntrack_buckets) und der Netfilter-Verbindungs-Tracking-Tabelle (nf_conntrack_max) zu erhöhen. Verwenden Sie die folgenden Befehle auf jedem Clusterknoten, um die Größe der Tabellen zu erhöhen:

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE

sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Ersetzen Sie TABLE_SIZE durch eine neue Größe in Byte. Der Standardwert für die Tabellengröße ist 262144. Wir empfehlen, einen Wert festzulegen, der der 65.536-fachen Anzahl der Kerne auf dem Knoten entspricht. Wenn Ihr Knoten beispielsweise acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
Upgrades und Updates 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1

Clustersicherungen mit bmctl können für einige Versionen nicht wiederhergestellt werden

Wir empfehlen, Ihre Cluster vor dem Upgrade zu sichern, damit Sie die vorherige Version wiederherstellen können, wenn das Upgrade nicht erfolgreich ist. Ein Problem mit dem Befehl bmctl restore cluster führt dazu, dass Sicherungen von Clustern mit den angegebenen Versionen nicht wiederhergestellt werden können. Dieses Problem betrifft insbesondere Upgrades, bei denen Sie eine Sicherung aus einer früheren Version wiederherstellen.

Wenn Ihr Cluster betroffen ist, enthält das Log bmctl restore cluster den folgenden Fehler:


Error: failed to extract image paths from profile: anthos version VERSION not supported

Workaround:

Bis zur Behebung dieses Problems empfehlen wir, die Cluster unter Cluster sichern und wiederherstellen zu verwenden, um Ihre Cluster manuell zu sichern und bei Bedarf manuell wiederherzustellen.
Netzwerk 1.10, 1.11, 1.12, 1.13, 1.14.0–1.14.2

NetworkGatewayGroup stürzt ab, wenn die Schnittstelle keine IP-Adresse hat

NetworkGatewayGroup kann keine Daemons für Knoten erstellen, die nicht sowohl IPv4- als auch IPv6-Schnittstellen haben. Dadurch können Features wie BGP-Load-Balancer und Outbound-NAT fehlschlagen. Wenn Sie die Logs des fehlgeschlagenen ang-node-Pods im kube-system-Namespace prüfen, werden ähnliche Fehler wie im folgenden Beispiel angezeigt, wenn eine IPv6-Adresse fehlt:


ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

Im vorherigen Beispiel ist auf der ens192-Schnittstelle keine IPv6-Adresse vorhanden. Ähnliche ARP-Fehler werden angezeigt, wenn dem Knoten eine IPv4-Adresse fehlt.

NetworkGatewayGroup versucht, eine ARP- und NDP-Verbindung zur lokalen IP-Adresse des Links herzustellen. Ist die IP-Adresse nicht vorhanden (IPv4 für ARP, IPv6 für NDP), schlägt die Verbindung fehl und der Daemon wird nicht fortgesetzt.

Dieses Problem wurde in Version 1.14.3 behoben.


Workaround:

Stellen Sie über SSH eine Verbindung zum Knoten her und fügen Sie dem Link, der die Knoten-IP enthält, eine IPv4- oder IPv6-Adresse hinzu. Im vorherigen Beispiel für den Logeintrag lautete diese Schnittstelle ens192:

ip address add dev INTERFACE scope link ADDRESS

Ersetzen Sie Folgendes:

  • INTERFACE: Die Schnittstelle für Ihren Knoten, z. B. ens192.
  • ADDRESS: Die IP-Adresse und Subnetzmaske, die auf die Schnittstelle angewendet werden soll.
Zurücksetzen/Löschen 1.10, 1.11, 1.12, 1.13.0–1.13.2

anthos-cluster-operator-Absturzschleife beim Entfernen eines Knotens der Steuerungsebene

Wenn Sie versuchen, einen Knoten der Steuerungsebene zu entfernen, indem Sie die IP-Adresse aus Cluster.Spec entfernen, gerät anthos-cluster-operator in einen Absturzschleifenstatus, der andere Vorgänge blockiert.


Workaround:

Das Problem wurde in 1.13.3 und 1.14.0 und höher behoben. Alle anderen Versionen sind davon betroffen. Upgrade auf eine der korrigierten Versionen durchführen

Führen Sie als Behelfslösung den folgenden Befehl aus:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Ersetzen Sie Folgendes:

  • IP_ADDRESS: Die IP-Adresse des Knotens im Absturzschleifenstatus.
  • CLUSTER_NAMESPACE: Der Cluster-Namespace.
Installation 1.13.1, 1.13.2 und 1.13.3

kubeadm join schlägt in großen Clustern aufgrund von abweichenden Tokens fehl

Wenn Sie Anthos-Cluster auf Bare Metal mit einer großen Anzahl von Knoten installieren, wird möglicherweise eine kubeadmin join-Fehlermeldung wie im folgenden Beispiel angezeigt:


TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Workaround:

Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Version 1.13.4 und höher behoben.

Wenn Sie eine betroffene Version verwenden müssen, erstellen Sie zuerst einen Cluster mit weniger als 20 Knoten und passen Sie dann die Größe des Clusters an, um nach Abschluss der Installation zusätzliche Knoten hinzuzufügen.
Logging und Monitoring 1.10, 1.11, 1.12, 1.13.0

Niedriges CPU-Limit für metrics-server in Edge-Clustern

In Anthos-Clustern auf Bare-Metal-Edge-Clustern können niedrige CPU-Limits für metrics-server zu häufigen Neustarts von metrics-server führen. Horizontales Pod-Autoscaling (HPA) funktioniert nicht, da metrics-server fehlerhaft ist.

Wenn das CPU-Limit von metrics-server unter 40m liegt, können Ihre Cluster betroffen sein. Prüfen Sie eine der folgenden Dateien, um die CPU-Limits metrics-server zu prüfen:

  • Anthos-Cluster auf Bare-Metal-Version 1.x-1.12: 
    kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml
  • Anthos-Cluster auf Bare-Metal-Version Anthos 1.13 oder höher: 
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

Workaround:

Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Version 1.13.1 oder höher behoben. Führen Sie ein Upgrade Ihrer Cluster durch, um dieses Problem zu beheben.

Eine kurzfristige Problemumgehung ist, bis Sie ein Clusterupgrade durchführen, indem Sie die CPU-Limits für metrics-server manuell erhöhen:

  1. Skalieren Sie metrics-server-operator herunter: 
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Aktualisieren Sie die Konfiguration und erhöhen Sie die CPU-Limits:
    • Anthos-Cluster auf Bare-Metal-Version 1.x-1.12: 
      kubectl -n kube-system edit deployment metrics-server
    • Anthos-Cluster auf Bare-Metal-Version 1.13: 
      kubectl -n gke-managed-metrics-server edit deployment metrics-server
    Entfernen Sie die Zeile --config-dir=/etc/config und erhöhen Sie die CPU-Limits, wie im folgenden Beispiel gezeigt: 
    
[...]
- command:
  - /pod_nanny
  # - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
[...] Increase such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true>
  3. Speichern und schließen Sie die metrics-server, um die Änderungen zu übernehmen.
Netzwerk 1,14, 1,15

Direkte NodePort-Verbindung zum hostNetwork-Pod funktioniert nicht

Eine Verbindung zu einem Pod, der über hostNetwork über den NodePort-Dienst aktiviert wurde, schlägt fehl, wenn sich der Back-End-Pod auf demselben Knoten wie der Ziel-NodePort befindet. Dieses Problem betrifft LoadBalancer-Dienste, wenn es mit Hostnetzwerk-Pods verwendet wird. Bei mehreren Back-Ends kann es zu einem sporadischen Verbindungsfehler kommen.

Dieses Problem wird durch einen Fehler im eBPF-Programm verursacht.


Workaround:

Verwenden Sie bei Verwendung eines Nodeport-Dienstes kein Targeting auf den Knoten, auf dem einer der Back-End-Pods ausgeführt wird. Achten Sie bei Verwendung des LoadBalancer-Dienstes darauf, dass die vom Hostnetzwerk gehosteten Pods nicht auf LoadBalancer-Knoten ausgeführt werden.
Upgrades und Updates 1.12.3, 1.13.0

1.13.0-Administratorcluster können keine 1.12.3-Nutzercluster verwalten

Administratorcluster mit Version 1.13.0 können keine Nutzercluster verwalten, auf denen Version 1.12.3 ausgeführt wird. Vorgänge für einen Nutzercluster von Version 1.12.3 schlagen fehl.


Workaround:

Führen Sie ein Upgrade Ihres Administratorclusters auf Version 1.13.1 oder ein Upgrade des Nutzerclusters auf die gleiche Version wie der Administratorcluster aus.
Upgrades und Updates 1.12

Das Upgrade auf 1.13.x wird für Administratorcluster mit Worker-Knotenpools blockiert

Version 1.13.0 und höher können keine Worker-Knotenpools enthalten. Upgrades auf Version 1.13.0 oder höher für Administratorcluster mit Worker-Knotenpools werden blockiert. Wenn das Upgrade des Administratorclusters angehalten wurde, können Sie prüfen, ob Worker-Knotenpools die Ursache sind, indem Sie den folgenden Fehler in der Datei upgrade-cluster.log im Ordner bmctl-workspace prüfen:


Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Workaround:

Verschieben Sie vor dem Upgrade alle Worker-Knotenpools in Nutzercluster. Eine Anleitung zum Hinzufügen und Entfernen von Knotenpools finden Sie unter Knotenpools in einem Cluster verwalten.

Upgrades und Updates 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Fehler beim Aktualisieren von Ressourcen mit kubectl apply

Wenn Sie vorhandene Ressourcen wie die benutzerdefinierten Ressourcen ClientConfig oder Stackdriver mit kubectl apply aktualisieren, gibt der Controller möglicherweise einen Fehler zurück oder setzt Ihre Eingabe und die gewünschten Änderungen zurück.

Sie können beispielsweise die benutzerdefinierte Ressource Stackdriver so bearbeiten, indem Sie zuerst die Ressource abrufen und dann eine aktualisierte Version anwenden:

  1. Rufen Sie die vorhandene YAML-Definition ab: 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Aktivieren Sie Features oder aktualisieren Sie die Konfiguration in der YAML-Datei.
  3. Wenden Sie die aktualisierte YAML-Datei wieder an: 
    kubectl apply -f stackdriver.yaml

Im letzten Schritt für kubectl apply können Probleme auftreten.


Workaround:

Verwenden Sie kubectl apply nicht, um Änderungen an vorhandenen Ressourcen vorzunehmen. Verwenden Sie stattdessen kubectl edit oder kubectl patch, wie in den folgenden Beispielen gezeigt:

  1. Bearbeiten Sie die benutzerdefinierte Stackdriver-Ressource: 
    kubectl edit stackdriver -n kube-system stackdriver
  2. Aktivieren Sie Features oder aktualisieren Sie die Konfiguration in der YAML-Datei.
  3. Editor speichern und beenden

Alternativer Ansatz mit kubectl patch:

  1. Rufen Sie die vorhandene YAML-Definition ab: 
    kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Aktivieren Sie Features oder aktualisieren Sie die Konfiguration in der YAML-Datei.
  3. Wenden Sie die aktualisierte YAML-Datei wieder an: 
    kubectl patch stackdriver stackdriver --type merge \
    -n kube-system --patch-file stackdriver.yaml
Logging und Monitoring 1,12, 1,13, 1,14, 1,15

Beschädigte Backlog-Blocks verursachen stackdriver-log-forwarder-Absturzschleifen

Der Absturz stackdriver-log-forwarder, wenn versucht wird, einen beschädigten Rückstandsblock zu verarbeiten. Die folgenden Beispielfehler werden in den Containerlogs angezeigt:


[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Wenn diese Absturzschleife auftritt, werden keine Logs in Cloud Logging angezeigt.


Workaround:

So beheben Sie diese Fehler:

  1. Identifizieren Sie die beschädigten Backlog-Blöcke. Sehen Sie sich die folgenden Beispielfehlermeldungen an: 
    
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    In diesem Beispiel ist die in var/log/fluent-bit-buffers/tail.1/ gespeicherte Datei tail.1/1-1659339894.252926599.flb fehlerhaft. Jede *.flb-Datei, deren Formatierung fehlgeschlagen ist, muss entfernt werden.
  2. Beenden Sie die ausgeführten Pods für stackdriver-log-forwarder: 
    kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
     Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres Nutzerclusters.

    Achten Sie darauf, dass die stackdriver-log-forwarder-Pods gelöscht werden, bevor Sie mit dem nächsten Schritt fortfahren.
  3. Stellen Sie eine SSH-Verbindung zum Knoten her, auf dem stackdriver-log-forwarder ausgeführt wird.
  4. Löschen Sie auf dem Knoten alle beschädigten *.flb-Dateien in var/log/fluent-bit-buffers/tail.1/.

    Wenn es zu viele beschädigte Dateien gibt und Sie ein Skript anwenden möchten, um alle Rückstandsblöcke zu bereinigen, verwenden Sie die folgenden Skripts:
    1. Stellen Sie ein DaemonSet bereit, um alle unsicheren Daten in Zwischenspeichern in fluent-bit 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
    2. Prüfen Sie, ob das DaemonSet alle Knoten bereinigt hat. Die Ausgabe der folgenden beiden Befehle sollte der Anzahl der Knoten im 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
    3. Löschen Sie das Bereinigungs-Daemonset: 
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup
    4. Starten Sie die stackdriver-log-forwarder-Pods neu: 
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Netzwerk, Anthos-VM-Laufzeit 1.14.0

Wenn Sie Dataplane V2 (anetd) auf Clustern neu starten, können vorhandene VMs nicht mehr an ein Nicht-Pod-Netzwerk angehängt werden

Auf Multi-nic-Clustern kann ein Neustart von Dataplane V2 (anetd) dazu führen, dass virtuelle Maschinen keine Verbindung zu Netzwerken herstellen können. In den Pod-Logs von anetd kann ein Fehler wie der folgende auftreten:


could not find an allocator to allocate the IP of the multi-nic endpoint

Workaround:

Sie können die VM als Schnelllösung neu starten. Führen Sie ein Upgrade auf Anthos-Cluster auf Bare Metal 1.14.1 oder höher durch, um eine Wiederholung des Problems zu vermeiden.
Vorgang 1.13, 1.14.0, 1.14.1

gke-metrics-agent hat kein Speicherlimit für Edge-Profilcluster

Je nach Arbeitslast des Clusters kann gke-metrics-agent mehr als 4.608 MiB Arbeitsspeicher belegen. Dieses Problem betrifft nur Anthos-Cluster auf Bare-Metal-Edge-Profilclustern. Standardprofilcluster sind davon nicht betroffen.


Workaround:

Aktualisieren Sie Ihren Cluster auf Version 1.14.2 oder höher.
Installation 1,12, 1,13

Das Erstellen des Clusters kann aufgrund von Race-Bedingungen fehlschlagen

Wenn Sie Cluster mit kubectl erstellen, wird die Preflight-Prüfung aufgrund von Race-Bedingungen möglicherweise nicht abgeschlossen. Daher kann die Clustererstellung in bestimmten Fällen fehlschlagen.

Der Preflight-Abgleichabgleich erstellt ein SecretForwarder, um das standardmäßige ssh-key-Secret in den Ziel-Namespace zu kopieren. In der Regel wird die Preflight-Prüfung auf die Inhaberreferenzen und Abgleiche angewendet, wenn SecretForwarder abgeschlossen ist. In seltenen Fällen kann die Inhaberreferenz von SecretForwarder jedoch die Referenz auf die Preflight-Prüfung verlieren, wodurch die Preflight-Prüfung hängt. Daher schlägt die Clustererstellung fehl. Löschen Sie den Cluster-Operator-Pod oder die Preflight-Check-Ressource, um den Abgleich für die Controller-basierte Preflight-Prüfung fortzusetzen. Wenn Sie die Preflight-Check-Ressource löschen, wird eine weitere Ressource erstellt und der Abgleich fortgesetzt. Alternativ können Sie Ihre vorhandenen Cluster, die mit einer früheren Version erstellt wurden, auf eine korrigierte Version upgraden.

Netzwerk 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Reservierte IP-Adressen werden nicht freigegeben, wenn das „abouts“-Plug-in mit der Funktion „Multi-NIC“ verwendet wird.

Wenn Sie im Multi-Nic-Feature das CNI-Plug-in "aboutabout" verwenden und den CNI-DEL-Vorgang zum Löschen einer Netzwerkschnittstelle für einen Pod verwenden, werden einige reservierte IP-Adressen möglicherweise nicht richtig freigegeben. Dies tritt auf, wenn der CNI-DEL-Vorgang unterbrochen wird.

Sie können die nicht verwendeten IP-Adressreservierungen der Pods mit dem folgenden Befehl prüfen:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Problemlösung:

Löschen Sie nicht verwendete IP-Adressen (ippools).
Installation 1.10, 1.11.0, 1.11.1, 1.11.2

Knotenproblemerkennung in 1.10.4-Nutzercluster schlägt fehl

Der Node Problem Detector kann in den Clustern von Anthos Cluster on Bare Metal 1.10.x fehlschlagen, wenn Administratorcluster von Anthos on Bare Metal 1.11.0, 1.11.1 oder 1.11.2 Nutzercluster von Version 1.10.x verwalten. Wenn der Node Problem Detector ausfällt, wird das Log mit der folgenden Fehlermeldung aktualisiert:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Problemumgehung

Führen Sie ein Upgrade des Administratorclusters auf 1.11.3 durch, um das Problem zu beheben.
Vorgang 1.14

IPv4-Clusterknoten im Inselmodus 1.14 haben eine Pod-CIDR-Maskengröße von 24

In Release 1.14 wird die Einstellung maxPodsPerNode für Cluster im Inselnmodus nicht berücksichtigt. Daher wird den Knoten eine Pod-CIDR-Maskengröße von 24 (256 IP-Adressen) zugewiesen.nDies kann dazu führen, dass der Cluster nicht mehr die erwarteten IP-Adressen des Clusters erreicht. Wenn Ihr Cluster beispielsweise eine Pod-CIDR-Maskengröße von 22 hat, wird jedem Knoten eine Pod-CIDR-Maske von 24 zugewiesen und der Cluster kann nur bis zu 4 Knoten unterstützen. Es kann auch zu einer Instabilität Ihres Clusters in einem Zeitraum mit hoher Pod-Abwanderung kommen, wenn maxPodsPerNode auf 129 oder höher festgelegt ist und nicht genügend Pod-CIDR für jeden Knoten vorhanden ist.

Wenn Ihr Cluster betroffen ist, meldet der Pod anetd den folgenden Fehler, wenn Sie einen neuen Knoten zum Cluster hinzufügen und kein podCIDR verfügbar ist:

error="required IPv4 PodCIDR not available"

Problemumgehung

So beheben Sie das Problem:

  1. Führen Sie ein Upgrade auf Version 1.14.1 oder höher aus.
  2. Entfernen Sie die Worker-Knoten und fügen Sie sie wieder hinzu.
  3. Entfernen Sie die Knoten der Steuerungsebene und fügen Sie sie nacheinander hinzu, am besten einzeln nacheinander, um Clusterausfälle zu vermeiden.
Upgrades und Updates 1.14.0, 1.14.1

Rollback des Clusterupgrades fehlgeschlagen

Ein Upgrade-Rollback kann für Anthos-Cluster auf Bare Metal 1.14.0 auf 1.14.1 fehlschlagen. Wenn Sie ein Cluster von 1.14.0 auf 1.14.1 aktualisieren und dann mit dem Befehl bmctl restore cluster ein Rollback auf 1.14.0 durchführen, wird möglicherweise ein Fehler wie im folgenden Beispiel zurückgegeben:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Workaround:

Löschen Sie alle healthchecks.baremetal.cluster.gke.io-Ressourcen unter dem Cluster-Namespace und führen Sie dann den Befehl bmctl restore cluster noch einmal aus:

  1. Alle healthchecks.baremetal.cluster.gke.io-Ressourcen auflisten: 
    kubectl get healthchecks.baremetal.cluster.gke.io \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAMESPACE ist der Namespace für den Cluster.
    • ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
  2. Löschen Sie alle healthchecks.baremetal.cluster.gke.io Ressourcen, die im vorherigen Schritt aufgeführt wurden: 
    kubectl delete healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_RESOURCE_NAME \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG
     Ersetzen Sie HEALTHCHECK_RESOURCE_NAME durch den Namen der Systemdiagnoseressourcen.
  3. Führen Sie den Befehl bmctl restore cluster noch einmal aus.
Netzwerk 1.12.0

Externe Dienst-IP-Adresse funktioniert im Flat Mode nicht

In einem Cluster, in dem flatIPv4 auf true gesetzt ist, sind Dienste des Typs LoadBalancer nicht über ihre externen IP-Adressen zugänglich.

Dieses Problem wurde in Version 1.12.1 behoben.


Workaround:

Legen Sie in der ConfigMap cilium-config enable-415 auf "true" fest und starten Sie dann die anetd-Pods neu.
Upgrades und Updates 1,13,0, 1,14

Direkte Upgrades von 1.13.0 auf 1.14.x werden nie abgeschlossen

Wenn Sie ein direktes Upgrade von 1.13.0 auf 1.14.x mit bmctl 1.14.0 und dem Flag --use-bootstrap=false ausführen, wird das Upgrade nie abgeschlossen.

Ein Fehler mit dem Operator preflight-check führt dazu, dass der Cluster die erforderlichen Prüfungen nie plant. Das bedeutet, dass die Preflight-Prüfung nie abgeschlossen wird.


Workaround:

Führen Sie zuerst ein Upgrade auf 1.13.1 durch, bevor Sie ein Upgrade auf 1.14.x vornehmen. Ein direktes Upgrade von 1.13.0 auf 1.13.1 sollte funktionieren. Alternativ ist ein Upgrade von 1.13.0 auf 1.14.x ohne das Flag --use-bootstrap=false möglich.
Upgrades und Updates, Sicherheit 1.13 und 1.14

Cluster, die auf 1.14.0 aktualisiert wurden, verlieren Mastermarkierungen

Knoten der Steuerungsebene benötigen eine von zwei bestimmten Markierungen, um zu verhindern, dass Arbeitslast-Pods auf ihnen geplant werden. Wenn Sie Anthos-Cluster auf Version 1.13 auf Version 1.14.0 upgraden, verlieren die Knoten der Steuerungsebene die folgenden erforderlichen Markierungen:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Dieses Problem verursacht keine Upgradefehler, aber Pods, die nicht auf den Knoten der Steuerungsebene ausgeführt werden sollten, können damit beginnen. Diese Arbeitslast-Pods können die Knoten der Steuerungsebene überfordern und zu Clusterinstabilität führen.

Prüfen, ob Sie betroffen sind

  1. Suchen Sie mit dem folgenden Befehl nach Knoten der Steuerungsebene: 
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH
  2. Verwenden Sie den folgenden Befehl, um die Liste der Markierungen auf einem Knoten zu prüfen: 
    kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH

    Wenn keine der erforderlichen Markierungen aufgelistet ist, sind Sie betroffen.

Problemumgehung

Führen Sie die folgenden Schritte für jeden Knoten der Steuerungsebene des betroffenen Clusters 1.14.0 aus, um die ordnungsgemäße Funktion wiederherzustellen. Diese Schritte gelten für die Markierung node-role.kubernetes.io/master:NoSchedule und die zugehörigen Pods. Wenn die Knoten PreferNoSchedule die Markierung der Steuerungsebene verwenden sollen, passen Sie die Schritte entsprechend an.
Vorgang, Anthos-VM-Laufzeit 1,11, 1,12, 1,13, 1,14, 1,15

VM-Erstellung schlägt zeitweise mit Uploadfehlern vor

Das Erstellen einer neuen virtuellen Maschine (VM) mit dem Befehl kubectl virt create vm schlägt beim Hochladen von Images nur selten fehl. Dieses Problem gilt sowohl für Linux- als auch für Windows-VMs. Der Fehler sieht in etwa so aus: 

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Problemumgehung

Wiederholen Sie den Befehl kubectl virt create vm, um Ihre VM zu erstellen.
Upgrades und Updates, Logging und Monitoring 1.11

Komponenten der verwalteten Sammlung in 1.11-Clustern werden bei Upgrades auf 1.12 nicht beibehalten

Komponenten der verwalteten Sammlung sind Teil des Managed Service for Prometheus. Wenn Sie Komponenten der verwalteten Sammlung manuell im gmp-system-Namespace Ihrer Anthos-Cluster der Version 1.11 bereitgestellt haben, werden die zugehörigen Ressourcen beim Upgrade auf Version 1.12 nicht beibehalten.

Ab Anthos-Clustern auf Bare-Metal-Version 1.12.0 werden verwaltete Dienst für Prometheus-Komponenten im Namespace gmp-system und zugehörige benutzerdefinierte Ressourcendefinitionen von stackdriver-operator mit dem Feld enableGMPForApplications verwaltet. Das Feld enableGMPForApplications ist standardmäßig auf true gesetzt. Wenn Sie also Managed Service for Prometheus-Komponenten vor dem Upgrade auf Version 1.12 manuell im Namespace bereitstellen, werden die Ressourcen von stackdriver-operator gelöscht.

Problemumgehung

So behalten Sie manuell verwaltete Sammlungsressourcen bei:

  1. Alle vorhandenen benutzerdefinierten PodMonitoring-Ressourcen sichern.
  2. Aktualisieren Sie den Cluster auf Version 1.12 und aktivieren Sie Managed Service for Prometheus.
  3. Stellen Sie die benutzerdefinierten PodMonitoring-Ressourcen im aktualisierten Cluster noch einmal bereit.
Upgrades und Updates 1.13

Für einige Cluster der Version 1.12 mit der Docker-Containerlaufzeit kann kein Upgrade auf Version 1.13 durchgeführt werden

Wenn einem Cluster in Version 1.12, der die Docker-Containerlaufzeit verwendet, die folgende Annotation fehlt, ist kein Upgrade auf Version 1.13 möglich:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Wenn Sie von diesem Problem betroffen sind, schreibt bmctl den folgenden Fehler in die Datei upgrade-cluster.log im Ordner bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

Dies geschieht am wahrscheinlichsten bei Docker-Clustern der Version 1.12, die von 1.11 aktualisiert wurden, da dieses Upgrade keine Annotation erfordert, um die Docker-Containerlaufzeit aufrechtzuerhalten. In diesem Fall haben Cluster die Annotation nicht, wenn sie auf 1.13 aktualisiert werden. Ab Version 1.13 ist containerd die einzige zulässige Containerlaufzeit.

Workaround:

Wenn Sie von diesem Problem betroffen sind, aktualisieren Sie die Clusterressource mit der fehlenden Annotation. Sie können die Annotation entweder während oder nach der Stornierung hinzufügen, bevor das Upgrade wiederholt wird.
Installation 1.11

bmctl wird beendet, bevor die Clustererstellung abgeschlossen ist

Die Clustererstellung kann für Anthos-Cluster auf Bare-Metal-Version 1.11.0 fehlschlagen. Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Release 1.11.1 behoben. In einigen Fällen wird der Befehl bmctl create cluster vorzeitig beendet und schreibt Fehler wie den folgenden in die Logs:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Problemumgehung

Der fehlgeschlagene Vorgang erzeugt Artefakte, aber der Cluster ist nicht betriebsbereit. Wenn Sie von diesem Problem betroffen sind, führen Sie die folgenden Schritte aus, um Artefakte zu bereinigen und einen Cluster zu erstellen:
Installation, Anthos-VM-Laufzeit 1,11, 1,12

Installationsbericht enthält Fehler beim VM-Laufzeitabgleich

Beim Erstellen des Clusters kann ein Fehler wie dieser ausgegeben werden:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Problemumgehung

Dieser Fehler ist harmlos und kann ignoriert werden.
Installation 1.10, 1.11, 1.12

Die Clustererstellung schlägt fehl, wenn mehrere NICs, containerd und der HTTPS-Proxy verwendet werden

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

  • Der Cluster ist so konfiguriert, dass containerd als Containerlaufzeit verwendet wird (nodeConfig.containerRuntime ist in der Clusterkonfigurationsdatei auf containerd festgelegt, die Standardeinstellung für Anthos-Cluster auf Bare-Metal-Version 1.14).
  • Der Cluster ist so konfiguriert, dass mehrere Netzwerkschnittstellen und mehrere NICs für Pods angegeben werden (clusterNetwork.multipleNetworkInterfaces in der Clusterkonfigurationsdatei auf true festgelegt).
  • Der Cluster ist so konfiguriert, dass ein Proxy verwendet wird (spec.proxy.url ist in der Clusterkonfigurationsdatei angegeben). Obwohl die Clustererstellung fehlschlägt, wird diese Einstellung weitergegeben, wenn Sie einen Cluster erstellen. Diese Proxyeinstellung kann auch als HTTPS_PROXY-Umgebungsvariable oder in der containerd-Konfiguration (/etc/systemd/system/containerd.service.d/09-proxy.conf) angezeigt werden.

Problemumgehung

Hängen Sie Dienst-CIDRs (clusterNetwork.services.cidrBlocks) an die Umgebungsvariable NO_PROXY auf allen Knotencomputern an.
Installation 1.10, 1.11, 1.12

Fehler auf Systemen mit restriktiver umask-Einstellung

Anthos-Cluster auf Bare-Metal-Release 1.10.0 haben ein Feature ohne Root-Steuerungsebene eingeführt, das alle Komponenten der Steuerungsebene als Nicht-Root-Nutzer ausführt. Wenn alle Komponenten als Nicht-Root-Nutzer ausgeführt werden, kann dies zu System- und Upgradefehlern auf Systemen mit einer restriktiveren umask-Einstellung von 0077 führen.


Problemumgehung

Setzen Sie die Knoten der Steuerungsebene zurück und ändern Sie umask auf allen Maschinen der Steuerungsebene in 0022. Wiederholen Sie die Installation, nachdem die Maschinen aktualisiert wurden.

Alternativ können Sie die Verzeichnis- und Dateiberechtigungen von /etc/kubernetes auf den Computern der Steuerungsebene ändern, damit die Installation oder das Upgrade fortgesetzt werden kann.

  • /etc/kubernetes und alle Unterverzeichnisse sind weltweit lesbar: chmod o+rx.
  • Sorge dafür, dass alle Dateien, die Nutzern von root im Verzeichnis (rekursiv) /etc/kubernetes gehören, schreibgeschützt lesbar sind (chmod o+r). Schließe private Dateien (.key) aus diesen Änderungen aus, da sie bereits mit der richtigen Inhaberschaft und den richtigen Berechtigungen erstellt wurden.
  • /usr/local/etc/haproxy/haproxy.cfg lesbar machen.
  • /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml lesbar machen.
Installation 1.10, 1.11, 1.12, 1.13

Inkompatibilität der Kontrollgruppe v2

Kontrollgruppe v2 (cgroup v2) wird in Version 1.13 und früheren Versionen von Anthos-Clustern auf Bare Metal nicht unterstützt. Version 1.14 unterstützt jedoch cgroup v2 als Vorabversion . Das Vorhandensein von /sys/fs/cgroup/cgroup.controllers weist darauf hin, dass Ihr System cgroup v2 verwendet.


Problemumgehung

Wenn Ihr System cgroup v2 verwendet, führen Sie ein Upgrade auf Version 1.14 von Anthos-Clustern auf Bare Metal aus.
Installation 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Preflight-Prüfungen und Anmeldedaten für Dienstkonten

Bei Installationen, die von Administrator- oder Hybridclustern ausgelöst werden (d. h. Cluster, die nicht mit bmctl erstellt wurden, z. B. Nutzerclustern), prüfen die Preflight-Prüfung nicht die Anmeldedaten des Google Cloud-Dienstkontos oder die zugehörigen Berechtigungen.
Installation 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Standardanmeldedaten für Anwendungen und bmctl

bmctl verwendet Standardanmeldedaten für Anwendungen, um den Standortwert des Clustervorgangs im cluster spec zu validieren, wenn er nicht auf global festgelegt ist.


Problemumgehung

Damit ADC funktioniert, müssen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS auf eine Dienstkonto-Anmeldedatendatei verweisen oder gcloud auth application-default login ausführen.
Installation 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Docker-Dienst

Auf Clusterknotencomputern gilt Folgendes: Wenn die ausführbare Docker-Datei in der Umgebungsvariable PATH vorhanden ist, der Docker-Dienst aber nicht aktiv ist, schlägt die Preflight-Prüfung fehl und meldet, dass Docker service is not active.


Problemumgehung

Entfernen Sie Docker oder aktivieren Sie den Docker-Dienst.
Installation 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Auf vSphere installieren

Wenn Sie Anthos-Cluster auf Bare Metal auf vSphere-VMs installieren, müssen Sie die Flags tx-udp_tnl-segmentation und tx-udp_tnl-csum-segmentation deaktivieren. Diese Flags beziehen sich auf die Hardwaresegmentierung, die vom vSphere-Treiber VMXNET3 ausgeführt wird, und funktionieren nicht mit dem GENEVE-Tunnel von Anthos-Clustern auf Bare Metal.


Problemumgehung

Führen Sie auf jedem Knoten den folgenden Befehl aus, um die aktuellen Werte für diese Flags zu prüfen:

ethtool -k NET_INTFC | grep segm

Ersetzen Sie NET_INTFC durch die Netzwerkschnittstelle, die mit der IP-Adresse des Knotens verknüpft ist.

Die Antwort sollte Einträge wie die folgenden enthalten:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
 In RHEL 8.4 gibt ethtool an, dass diese Flags deaktiviert sind, während sie nicht vorhanden sind. Sie können die Flags explizit mit den folgenden Befehlen aktivieren bzw. deaktivieren: 
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 tx-udp_tnl-csum-segmentation off
 Diese Flag-Änderung bleibt bei Neustarts nicht bestehen. Konfigurieren Sie die Startskripts so, dass sie die Flags beim Systemstart explizit festlegen.
Upgrades und Updates 1.10

bmctl kann keine Nutzercluster mit niedrigeren Versionen erstellen, aktualisieren oder zurücksetzen

Die bmctl-Befehlszeile kann unabhängig von der Version des Administratorclusters keine Nutzercluster mit einer niedrigeren Nebenversion erstellen, aktualisieren oder zurücksetzen. Sie können beispielsweise bmctl mit einer Version von 1.N.X nicht verwenden, um einen Nutzercluster der Version 1.N-1.Y zurückzusetzen, selbst wenn sich der Administratorcluster auch in Version 1.N.X befindet.

Wenn Sie von diesem Problem betroffen sind, sollten Sie bei der Verwendung von bmctl ähnliche Logs sehen:

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 is not supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Workaround:

Mit kubectl können Sie die benutzerdefinierte Ressource des Nutzerclusters im Administratorcluster erstellen, bearbeiten oder löschen.

Die Möglichkeit, Nutzercluster zu aktualisieren, ist nicht betroffen.
Upgrades und Updates 1.12

Clusterupgrades auf Version 1.12.1 verzögern sich möglicherweise

Clusterupgrades auf Version 1.12.1 werden manchmal ausgesetzt, weil der API-Server nicht mehr verfügbar ist. Dieses Problem betrifft alle Clustertypen und alle unterstützten Betriebssysteme. Wenn dieses Problem auftritt, kann der Befehl bmctl upgrade cluster an mehreren Punkten fehlschlagen, auch während der zweiten Phase der Preflight-Prüfungen.


Problemumgehung

In Ihren Upgradelogs können Sie nachsehen, ob Sie von diesem Problem betroffen sind. Upgrade-Logs befinden sich standardmäßig in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP.

upgrade-cluster.log kann die folgenden Fehler enthalten:

Failed to upgrade cluster: preflight checks failed: preflight check failed
 Das Maschinenlog kann Fehler wie den folgenden enthalten (Wiederholte Fehler weisen darauf hin, dass Sie von diesem Problem betroffen sind): 
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

Clickserver und Keepalive müssen auf jedem Knoten der Steuerungsebene ausgeführt werden, bevor Sie noch einmal versuchen, den Cluster auf Version 1.12.1 zu aktualisieren. Mit der crictl-Befehlszeile auf jedem Knoten können Sie prüfen, ob die Container haproxy und keepalived ausgeführt werden:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Wenn HMAC oder Keepalive nicht auf einem Knoten ausgeführt wird, starten Sie kubelet auf dem Knoten neu:

systemctl restart kubelet
Upgrades und Updates, Anthos-VM-Laufzeit 1,11, 1,12

Das Upgrade von Clustern auf Version 1.12.0 oder höher schlägt fehl, wenn die Anthos-VM-Laufzeit aktiviert ist

In Anthos-Clustern auf Bare Metal-Release 1.12.0 werden alle Ressourcen im Zusammenhang mit der Anthos-VM-Laufzeit zum Namespace vm-system migriert, um den Release der GA-Version der Anthos-VM-Laufzeit besser zu unterstützen. Wenn Sie die Anthos-VM-Laufzeit in einem Cluster der Version 1.11.x oder niedriger aktiviert haben, schlägt das Upgrade auf Version 1.12.0 oder höher fehl, sofern Sie die Anthos-VM-Laufzeit nicht deaktivieren. Wenn Sie von diesem Problem betroffen sind, meldet der Upgradevorgang den folgenden Fehler:


Failed to upgrade cluster: cluster is not upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Problemumgehung

So deaktivieren Sie die Anthos VM-Laufzeit:

  1. Bearbeiten Sie die benutzerdefinierte VMRuntime-Ressource: 
    kubectl edit vmruntime
  2. Legen Sie enabled in der Spezifikation auf false fest: 
    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  ...
  3. Speichern Sie die benutzerdefinierte Ressource in Ihrem Editor.
  4. Aktivieren Sie nach Abschluss des Clusterupgrades die Anthos-VM-Laufzeit wieder.

Weitere Informationen finden Sie unter Mit VM-basierten Arbeitslasten arbeiten.

Upgrades und Updates 1.10, 1.11, 1.12

Upgrade hängt bei error during manifests operations fest

In einigen Situationen können Clusterupgrades nicht abgeschlossen werden und die bmctl-Befehlszeile reagiert nicht mehr. Dieses Problem kann durch eine falsch aktualisierte Ressource verursacht werden. Prüfen Sie in den anthos-cluster-operator-Logs nach Fehlern, die den folgenden Einträgen ähneln, um zu ermitteln, ob Sie von diesem Problem betroffen sind:

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

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


Problemumgehung

Wenn Sie diese Fehler in Ihren Protokollen finden, führen Sie die folgenden Schritte aus:

  1. Mit kubectl edit können Sie die Annotation kubectl.kubernetes.io/last-applied-configuration aus der Ressource in der Lognachricht entfernen.
  2. Speichern Sie die Änderungen und wenden Sie sie auf die Ressource an.
  3. Wiederholen Sie das Clusterupgrade.
Upgrades und Updates 1.10, 1.11, 1.12

Upgrades von Clustern, die Features von Anthos Network Gateway verwenden, werden blockiert.

Clusterupgrades von 1.10.x auf 1.11.x schlagen für Cluster fehl, die entweder ein ausgehendes NAT-Gateway oder ein gebündeltes Load-Balancing mit BGP verwenden. Beide Funktionen verwenden Anthos Network Gateway. Clusterupgrades hängen an der Waiting for upgrade to complete...-Befehlszeile fest und die anthos-cluster-operator-Logfehler wie der folgende:


apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Problemumgehung

Führen Sie die folgenden Befehle für den Cluster aus, für den Sie ein Upgrade durchführen möchten:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Upgrades und Updates 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

bmctl update entfernt keine Wartungsblöcke

Mit dem Befehl bmctl update kann der Bereich maintenanceBlocks aus der Clusterressourcenkonfiguration nicht entfernt oder geändert werden.


Problemumgehung

Weitere Informationen, einschließlich Anleitungen zum Entfernen von Knoten aus dem Wartungsmodus, finden Sie unter Knoten in den Wartungsmodus versetzen.
Upgrades und Updates 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Knotenausgleich kann nicht gestartet werden, wenn sich der Knoten außerhalb der Reichweite befindet

Der Draining-Prozess für Knoten beginnt nicht, wenn der Knoten außerhalb der Anthos-Cluster auf Bare Metal liegt. Wenn ein Knoten beispielsweise während eines Clusterupgrades offline geht, kann es dazu führen, dass das Upgrade nicht mehr reagiert. Das kommt selten vor.


Problemumgehung

Achten Sie darauf, dass Ihre Knoten korrekt funktionieren, bevor Sie ein Upgrade starten, um die Wahrscheinlichkeit eines Problems zu minimieren.
Upgrades und Updates 1.12

containerd 1.5.13 erfordert libseccomp 2.5 oder höher

Anthos-Cluster auf Bare-Metal-Release 1.12.1 werden mit containerd-Version 1.5.13 ausgeliefert. Für diese containerd-Version ist libseccomp Version 2.5 oder höher erforderlich.

Wenn libseccomp auf Ihrem System nicht die Version 2.5 oder höher installiert ist, aktualisieren Sie diese vor dem Upgrade der vorhandenen Cluster auf Version 1.12.1. Andernfalls können in cplb-update-Pods Fehler für Load-Balancer-Knoten auftreten, z. B.:


runc did not terminate successfully: runc: symbol lookup error: runc: undefined
symbol: seccomp_notify_respond

Problemumgehung

Führen Sie den folgenden Befehl aus, um die neueste Version von libseccomp in Ubuntu zu installieren:

sudo apt-get install  libseccomp-dev

Führen Sie den folgenden Befehl aus, um die neueste Version von libseccomp in CentOS oder RHEL zu installieren:

sudo dnf -y install libseccomp-devel
Vorgang 1.10, 1.11, 1.12

Knoten, die nicht verwendet werden, wenn Sie das Verfahren für den Wartungsmodus nicht verwenden

Wenn Sie Anthos-Cluster auf Bare-Metal-Version 1.12.0 (anthosBareMetalVersion: 1.12.0) oder niedriger ausführen und kubectl cordon auf einem Knoten manuell verwenden, kann es passieren, dass Anthos-Cluster auf Bare Metal den Knoten trennen, bevor Sie bereit sind, den erwarteten Status abzugleichen.


Problemumgehung

Verwenden Sie für Anthos-Cluster auf Bare-Metal-Version 1.12.0 und niedriger den Wartungsmodus, um Knoten sicher zu sperren und zu leeren.

Ab Version 1.12.1 (anthosBareMetalVersion: 1.12.1) werden Knoten durch Anthos-Cluster auf Bare Metal nicht unerwartet gesperrt, wenn Sie kubectl cordon verwenden.
Vorgang 1.11

Cluster mit Version 11, die einen Registry-Spiegel verwenden, können Cluster mit Version 1.10 nicht verwalten

Wenn Ihr Administratorcluster Version 1.11 hat und einen Registrierungsspiegel verwendet, können keine Nutzercluster verwaltet werden, auf denen eine niedrigere Nebenversion verwendet wird. Dieses Problem wirkt sich auf das Zurücksetzen, Aktualisieren und Upgrade des Nutzerclusters aus.

Prüfen Sie die Logs auf Clustervorgänge wie Erstellen, Upgrade oder Zurücksetzen, um zu ermitteln, ob dieses Problem Sie betrifft. Diese Logs befinden sich standardmäßig im Ordner bmctl-workspace/CLUSTER_NAME/. Wenn Sie von dem Problem betroffen sind, enthalten Ihre Logs die folgende Fehlermeldung:


flag provided but not defined: -registry-mirror-host-to-endpoints
Vorgang 1,10, 1,11

kubeconfig-Secret überschrieben

Bei Ausführung in Nutzerclustern überschreibt der Befehl bmctl check cluster den Nutzercluster kubeconfig-Secret mit dem Administratorcluster kubeconfig. Das Überschreiben der Datei führt dazu, dass Standardclustervorgänge wie die Aktualisierung und das Upgrade für betroffene Nutzercluster fehlschlagen. Dieses Problem gilt für Anthos-Cluster auf Bare-Metal-Versionen 1.11.1 und niedriger.

Führen Sie den folgenden Befehl aus, um festzustellen, ob dieses Problem einen Nutzercluster betrifft:

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

Ersetzen Sie Folgendes:

  • ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
  • USER_CLUSTER_NAMESPACE ist der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Anthos-Cluster auf Bare Metal der Name des Clusters, dem das Präfix cluster- vorangestellt ist. Wenn Sie dem Cluster beispielsweise test nennen, ist der Standard-Namespace cluster-test.
  • USER_CLUSTER_NAME ist der Name des zu überprüfenden Nutzerclusters.

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

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Problemumgehung

Mit den folgenden Schritten wird die Funktion für einen betroffenen Nutzercluster (USER_CLUSTER_NAME) wiederhergestellt:

  1. Suchen Sie die kubeconfig-Datei des Nutzerclusters. Anthos-Cluster auf Bare Metal generieren beim Erstellen eines Clusters die kubeconfig-Datei auf der Administratorworkstation. Standardmäßig befindet sich die Datei im Verzeichnis bmctl-workspace/USER_CLUSTER_NAME.
  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. Die Antwort gibt Details zu den Knoten für den Nutzercluster zurück. Prüfen Sie, ob die Maschinennamen für Ihren Cluster korrekt sind.
  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
Vorgang 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Snapshot als angemeldeter Nutzer ohne Root-Berechtigung erstellen

Wenn Sie containerd als Containerlaufzeit verwenden, muss zum Ausführen von Snapshots als Nicht-Root-Nutzer /usr/local/bin im PATH des Nutzers sein. Andernfalls tritt ein crictl: command not found-Fehler auf.

Wenn Sie nicht als Root-Nutzer angemeldet sind, wird sudo zum Ausführen der Snapshot-Befehle verwendet. Der PATH (sudo) kann sich vom Stammprofil unterscheiden und darf nicht /usr/local/bin enthalten.


Problemumgehung

Aktualisieren Sie secure_path in /etc/sudoers, um /usr/local/bin einzuschließen. Alternativ können Sie einen symbolischen Link für crictl in einem anderen /bin-Verzeichnis erstellen.
Vorgang, Anthos-VM-Laufzeit 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Anthos-VM-Laufzeit: Wenn Sie einen Pod neu starten, ändern die VMs im Pod IP-Adressen oder verlieren ihre IP-Adresse insgesamt.

Wenn sich die IP-Adresse einer VM ändert, wirkt sich das nicht auf die Erreichbarkeit der als Kubernetes-Dienst bereitgestellten VM-Anwendungen aus.


Problemumgehung

Wenn die IP-Adresse verloren geht, müssen Sie dhclient auf der VM ausführen, um eine IP-Adresse für die VM zu erhalten.
Logging und Monitoring 1.10

stackdriver-log-forwarder hat [parser:cri] invalid time format Warnungsprotokolle

Wenn der CRI-Parser für die Containerlaufzeit einen falschen regulären Ausdruck zum Parsen von Zeit verwendet, enthalten die Logs für den stackdriver-log-forwarder-Pod Fehler und Warnungen wie die folgenden:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Workaround:
Logging und Monitoring 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Unerwartete Monitoring-Abrechnung

Bei Anthos-Clustern auf Bare-Metal-Version 1.10 haben einige Kunden auf der Seite Abrechnung einen unerwartet hohen Preis für Metrics volume festgestellt. Dieses Problem betrifft Sie nur, wenn folgende Bedingungen erfüllt sind:

  • Anwendungsmonitoring ist aktiviert (enableStackdriverForApplications=true)
  • Managed Service for Prometheus ist nicht aktiviert (enableGMPForApplications)
  • Anwendungs-Pods haben die Annotation prometheus.io/scrap=true

Erstelle eine Liste deiner benutzerdefinierten Messwerte, um zu sehen, ob du von diesem Problem betroffen bist. Wenn Sie auf unerwünschte Kosten stoßen, trifft das Problem auf Sie zu.


Problemumgehung

Wenn Sie von diesem Problem betroffen sind, empfehlen wir Ihnen, Ihre Cluster auf Version 1.12 zu aktualisieren und zu einer neuen Lösung für das Anwendungsmonitoring managed-service-for-prometheus zu wechseln, die dieses Problem löst:

  • Separate Flags zum Steuern der Erfassung von Anwendungslogs und Anwendungsmesswerten
  • Gebündelter Google Cloud Managed Service for Prometheus

    • Wenn Sie kein Upgrade auf Version 1.12 ausführen können, gehen Sie so vor:

    1. Suchen Sie die Quell-Pods und -Dienste, die über die unerwünschte Abrechnung verfügen: 
      kubectl --kubeconfig KUBECONFIG \
    get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
    services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Entfernen Sie die Annotation prometheus.io/scrap=true aus dem Pod oder Dienst.
    Logging und Monitoring 1,11, 1,12, 1,13, 1,14, 1,15

    Änderungen an metrics-server-config werden nicht beibehalten

    Eine hohe Pod-Dichte kann in extremen Fällen zu einem übermäßigen Logging- und Monitoring-Aufwand führen, was dazu führen kann, dass der Metrics Server beendet und neu gestartet wird. Sie können die ConfigMap metrics-server-config bearbeiten, um mehr Ressourcen zuzuweisen, damit Metrics Server weiterhin ausgeführt wird. Aufgrund des Abgleichs können Änderungen, die an metrics-server-config vorgenommen werden, jedoch während eines Clusteraktualisierungs- oder Upgradevorgangs auf den Standardwert zurückgesetzt werden. Der Messwertserver ist nicht sofort betroffen. Beim nächsten Neustart wird jedoch die rückgängig gemachte ConfigMap abgerufen und ist dem übermäßigen Aufwand wieder ausgesetzt.


    Problemumgehung

    Bei Version 1.11.x können Sie ein Skript für die ConfigMap ausführen und diese zusammen mit Aktualisierungen oder Upgrades des Clusters ausführen. Ab Version 1.12 wenden Sie sich bitte an den Support.
    Logging und Monitoring 1,11, 1,12

    Eingestellte Messwerte wirken sich auf das Cloud Monitoring-Dashboard aus

    Einige Anthos-Messwerte wurden eingestellt. Ab Anthos-Cluster auf Bare-Metal-Release 1.11 werden für diese verworfenen Messwerte keine Daten mehr erhoben. Wenn Sie diese Messwerte in einer Ihrer Benachrichtigungsrichtlinien verwenden, sind keine Daten zum Auslösen der Benachrichtigungsbedingung vorhanden.

    In der folgenden Tabelle sind die einzelnen Messwerte, die eingestellt wurden, und der Messwert, der sie ersetzt, aufgeführt.

    Verworfene Messwerte Ersatzmesswert
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity

    In Anthos-Clustern auf Bare-Metal-Releases vor 1.11 werden für die Richtliniendefinitionsdatei für die empfohlene Benachrichtigung Anthos on baremetal node cpu usage exceeds 80 percent (critical) die verworfenen Messwerte verwendet. Die JSON-Definitionsdatei node-cpu-usage-high.json wird für Releases 1.11.0 und höher aktualisiert.


    Problemumgehung

    Führen Sie die folgenden Schritte aus, um zu den Ersatzmesswerten zu migrieren:

    1. Wählen Sie in der Google Cloud Console Monitoring aus oder klicken Sie auf die folgende Schaltfläche:
      Zu Monitoring
    2. Wählen Sie im Navigationsbereich Dashboards aus und löschen Sie das Dashboard Status des Anthos-Clusterknotens.
    3. Klicken Sie auf den Tab Beispielbibliothek und installieren Sie das Dashboard Status des Anthos-Clusterknotens neu.
    4. Folgen Sie der Anleitung unter Benachrichtigungsrichtlinien erstellen, um eine Richtlinie mit der aktualisierten Definitionsdatei von node-cpu-usage-high.json zu erstellen.
    Logging und Monitoring 1,10, 1,11

    stackdriver-log-forwarder enthält CrashloopBackOff -Fehler

    In einigen Fällen kann der Logging-Agent fluent-bit dazu führen, dass die Verarbeitung beschädigter Segmente nicht reagiert. Wenn der Logging-Agent keine beschädigten Teile umgehen kann, stellen Sie möglicherweise fest, dass stackdriver-log-forwarder immer wieder mit dem Fehler CrashloopBackOff abstürzt. Wenn dieses Problem auftritt, enthalten Ihre Logs Einträge wie die folgenden:

    
[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0

    Workaround:

    Bereinigen Sie die Pufferblöcke für den Stackdriver Log Forwarder.

    Hinweis: Ersetzen Sie in den folgenden Befehlen KUBECONFIG durch den Pfad zur kubeconfig-Datei des Administratorclusters.

    1. Beenden Sie alle stackdriver-log-forwarder-Pods: 
      kubectl --kubeconfig 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.
    2. Stellen Sie das folgende DaemonSet bereit, um fehlerhafte 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
    3. Prüfen Sie mit den folgenden Befehlen, ob das DaemonSet alle Knoten bereinigt hat: 
      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
       Die Ausgabe der beiden Befehle sollte der Anzahl der Knoten in Ihrem Cluster entsprechen.
    4. Löschen Sie das Bereinigungs-Daemonset: 
      kubectl --kubeconfig KUBECONFIG -n \
    kube-system delete ds fluent-bit-cleanup
    5. Starten Sie die Logweiterleitungs-Pods neu: 
      kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset \
    stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Unbekannte Messwertdaten in Cloud Monitoring

    Die Daten in Cloud Monitoring für Cluster der Version 1.10.x können irrelevante Einträge mit zusammenfassenden Messwerten wie die folgenden enthalten:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Weitere Messwerttypen mit irrelevanten Zusammenfassungsmesswerten sind:

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Diese Messwerte vom Typ „Zusammenfassung“ sind zwar in der Messwertliste enthalten, werden aber derzeit von gke-metrics-agent nicht unterstützt.
    Logging und Monitoring 1,10, 1,11

    Intermittierende Messwertexportunterbrechungen

    Anthos-Cluster auf Bare Metal können durch normale, kontinuierliche Export von Messwerten oder fehlende Messwerte auf einigen Knoten unterbrochen werden. Wenn dieses Problem Ihre Cluster betrifft, sehen Sie mindestens Datenlücken für die folgenden Messwerte:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Problemumgehung

    Führen Sie ein Upgrade Ihrer Cluster auf Version 1.11.1 oder höher aus.

    Wenn Sie kein Upgrade durchführen können, führen Sie die folgenden Schritte aus:

    1. Öffnen Sie die Ressource stackdriver zum Bearbeiten: 
      kubectl -n kube-system edit stackdriver stackdriver
    2. Fügen Sie dem Manifest stackdriver den folgenden resourceAttrOverride-Abschnitt hinzu, um die CPU-Anfrage für gke-metrics-agent von 10m auf 50m zu erhöhen: 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
       Ihre bearbeitete Ressource sollte in etwa so aussehen: 
      spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam wurden: 
      kubectl -n kube-system get daemonset \
    gke-metrics-agent -o yaml | grep "cpu: 50m"
       Der Befehl sucht nach cpu: 50m, sobald Ihre Änderungen wirksam wurden.
    Netzwerk 1.10

    Mehrere Standardgateways unterbrechen die Konnektivität zu externen Endpunkten

    Die Verwendung mehrerer Standardgateways in einem Knoten kann zu einer fehlerhaften Verbindung innerhalb eines Pods zu externen Endpunkten führen, z. B. zu google.com.

    Führen Sie den folgenden Befehl auf dem Knoten aus, um zu ermitteln, ob Sie von diesem Problem betroffen sind:

    ip route show

    Mehrere Instanzen von default in der Antwort weisen darauf hin, dass Sie betroffen sind.
    Netzwerk 1.12

    Änderungen von benutzerdefinierten Netzwerkressourcen in Nutzerclustern werden überschrieben

    Anthos-Cluster auf Bare-Metal-Version 1.12.x verhindern nicht, dass Sie benutzerdefinierte Ressourcen im Netzwerk manuell in Ihrem Nutzercluster bearbeiten. Anthos-Cluster auf Bare Metal gleichen benutzerdefinierte Ressourcen in den Nutzerclustern während der Clusterupgrades mit den benutzerdefinierten Ressourcen in Ihrem Administratorcluster ab. Dieser Abgleich überschreibt alle Änderungen, die direkt an den benutzerdefinierten Netzwerkressourcen im Nutzercluster vorgenommen werden. Die benutzerdefinierten Netzwerkressourcen sollten nur im Administratorcluster geändert werden, aber Anthos-Cluster auf Bare-Metal-Version 1.12.x erzwingen diese Anforderung nicht.

    Erweiterte Netzwerkfeatures wie Bundles mit Load-Balancing mit BGP, Ausgehendes NAT-Gateway, SR-IOV-Netzwerk, Flat-Modus mit BGP und Multi-NIC für Pods verwenden die folgenden benutzerdefinierten Ressourcen:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Sie bearbeiten diese benutzerdefinierten Ressourcen im Administratorcluster und der Schritt für den Abgleich wendet die Änderungen auf Ihre Nutzercluster an.


    Problemumgehung

    Wenn Sie eine der zuvor genannten benutzerdefinierten Ressourcen in einem Nutzercluster geändert haben, passen Sie die entsprechenden benutzerdefinierten Ressourcen im Administratorcluster vor dem Upgrade an. Mit diesem Schritt sorgen Sie dafür, dass Ihre Konfigurationsänderungen beibehalten werden. Anthos-Cluster auf Bare-Metal-Versionen ab 1.13.0 verhindern, dass Sie die benutzerdefinierten Netzwerkressourcen auf Ihren Nutzerclustern direkt ändern.
    Netzwerk 1,11, 1,12, 1,13, 1,14, 1,15

    NAT-Fehler mit zu vielen parallelen Verbindungen

    Für einen bestimmten Knoten in Ihrem Cluster bietet die Knoten-IP-Adresse eine Netzwerkadressübersetzung (Network Address Translation, NAT) für Pakete, die an eine Adresse außerhalb des Clusters weitergeleitet werden. Wenn eingehende Pakete in einen Load-Balancing-Knoten eingehen, der für die Verwendung des gebündelten Load-Balancings (spec.loadBalancer.mode: bundled) konfiguriert ist, werden die Pakete von der Quellnetzwerkadressübersetzung (SNAT) an die IP-Adresse des Knotens weitergeleitet, bevor sie an einen Back-End-Pod weitergeleitet werden.

    Der Portbereich für NAT, die von Anthos-Clustern auf Bare Metal verwendet wird, ist 32768–65535. Dieser Bereich begrenzt die Anzahl paralleler Verbindungen auf 32.767 pro Protokoll auf diesem Knoten. Für jede Verbindung ist ein Eintrag in der Conntrack-Tabelle erforderlich. Wenn zu viele kurzlebige Verbindungen vorhanden sind, werden in der Conntrack-Tabelle keine Ports für NAT mehr ausgeführt. Eine automatische Speicherbereinigung bereinigt die veralteten Einträge, die Bereinigung erfolgt jedoch nicht sofort.

    Wenn die Anzahl der Verbindungen auf Ihrem Knoten 32.767 erreicht, werden Sie für Paketverbindungen, die NAT benötigen, Paketverluste feststellen.

    Dieses Problem können Sie ermitteln, indem Sie den folgenden Befehl auf dem Pod anetd auf dem problematischen Knoten ausführen:

    kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

    Es sollten Fehler in folgender Form angezeigt werden:

    
No mapping for NAT masquerade DROPPED

    Problemumgehung

    Verteilen Sie Ihren Traffic auf andere Knoten.
    Netzwerk 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

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

    Wenn Sie die Richtlinie für externen Traffic auf Local festlegen, kann es zu Routingfehlern wie No route to host für ein gebündeltes Layer-2-Load-Balancing kommen. Die Richtlinie für externen Traffic ist standardmäßig auf Cluster (externalTrafficPolicy: Cluster) festgelegt. Mit dieser Einstellung verarbeitet Kubernetes den gesamten Cluster. Dienste vom Typ LoadBalancer oder NodePort können externalTrafficPolicy: Local verwenden, um die IP-Adresse der Clientquelle beizubehalten. Bei dieser Einstellung verarbeitet Kubernetes jedoch nur lokalen Knotentraffic.


    Problemumgehung

    Wenn Sie die IP-Adresse der Clientquelle beibehalten möchten, ist möglicherweise eine zusätzliche Konfiguration erforderlich, um sicherzustellen, dass Dienst-IP-Adressen erreichbar sind. Weitere Informationen zur Konfiguration finden Sie unter Quell-IP-Adresse des Clients beibehalten im Abschnitt „Gebündeltes Load-Balancing konfigurieren“.
    Netzwerk 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Wenn Sie firewalld ändern, werden Cilium iptable-Richtlinienketten gelöscht

    Wenn Sie Anthos-Cluster auf Bare Metal ausführen, wobei firewalld auf CentOS oder Red Had Enterprise Linux (RHEL) aktiviert ist, können Änderungen an firewalld die Cilium-iptables-Ketten im Hostnetzwerk entfernen. Die iptables-Ketten werden vom Pod anetd hinzugefügt, wenn er gestartet wird. Der Verlust der Cilium-iptables-Ketten führt dazu, dass der Pod auf dem Knoten die Netzwerkverbindung außerhalb des Knotens verliert.

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

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

    Problemumgehung

    Starten Sie anetd auf dem Knoten neu. Suchen und löschen Sie den anetd-Pod mit den folgenden Befehlen, um anetd neu zu starten:

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

    Ersetzen Sie ANETD_XYZ durch den Namen des Pods anetd.
    Netzwerk 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Doppelte egressSourceIP-Adressen

    Bei Verwendung der Vorschaufunktion für ausgehendes NAT-Gateway ist es möglich, Regeln für die Traffic-Auswahl festzulegen, die eine egressSourceIP-Adresse angeben, die bereits für ein anderes EgressNATPolicy-Objekt verwendet wird. Dies kann zu Konflikten mit dem ausgehenden Traffic-Routing führen.


    Problemumgehung

    Ermitteln Sie zusammen mit Ihrem Entwicklungsteam, welche Floating-IP-Adressen verfügbar sind, bevor Sie die egressSourceIP-Adresse in der benutzerdefinierten Ressource EgressNATPolicy angeben.
    Netzwerk 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

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

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

    Der Filter für den umgekehrten Pfad wird mit rp_filter-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all) festgelegt. Dieser Wert kann auch von sysctl überschrieben werden, wodurch die Einstellungen für den umgekehrten Pfadfilter in einer Netzwerksicherheitskonfigurationsdatei gespeichert werden, z. B. /etc/sysctl.d/60-gce-network-security.conf.


    Problemumgehung

    Wenn Sie die Pod-Konnektivität wiederherstellen möchten, setzen Sie net.ipv4.conf.all.rp_filter manuell auf 0 oder starten Sie den anetd-Pod neu, um net.ipv4.conf.all.rp_filter wieder auf 0 zurückzusetzen. Wenn Sie den anetd-Pod neu starten möchten, verwenden Sie die folgenden Befehle, um den anetd-Pod zu suchen und zu löschen. Stattdessen wird ein neuer anetd-Pod gestartet:

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

    Ersetzen Sie ANETD_XYZ durch den Namen des Pods anetd.
    Netzwerk 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Cluster-IP-Adressen von Bootstrap (Art) und IP-Adressen von Clusterknoten überschneiden sich

    192.168.122.0/24 und 10.96.0.0/27 sind die Standard-Pod- und Dienst-CIDRs, die vom Bootstrap-Typ (Typ) verwendet werden. Preflight-Prüfungen schlagen fehl, wenn sie sich mit IP-Adressen von Clusterknotenmaschinen überschneiden.


    Problemumgehung

    Um den Konflikt zu vermeiden, können Sie die Flags --bootstrap-cluster-pod-cidr und --bootstrap-cluster-service-cidr an bmctl übergeben und unterschiedliche Werte angeben.
    Betriebssystem 1.11

    Inkompatibilität mit Ubuntu 18.04.6 im GA-Kernel

    Anthos-Cluster auf Bare-Metal-Versionen 1.11.0 und 1.11.1 sind mit Ubuntu 18.04.6 im GA-Kernel (von 4.15.0-144-generic bis 4.15.0-176-generic) nicht kompatibel. Die Inkompatibilität führt dazu, dass der Netzwerk-Agent das Clusternetzwerk nicht mit dem Fehler „BPF-Programm ist zu groß“ in den anetd-Logs konfiguriert. Es kann sein, dass Pods im Status ContainerCreating hängen und im Ereignis-Log der Pods der Fehler networkPlugin cni failed to set up pod angezeigt wird. Dieses Problem gilt nicht für die Ubuntu-Kernel-Aktivierung (HWE).


    Problemumgehung

    Wir empfehlen, den HWE-Kernel herunterzuladen und auf die neueste unterstützte HWE-Version für Ubuntu 18.04 zu aktualisieren.
    Betriebssystem 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Clustererstellung oder Upgrade schlägt unter CentOS fehl

    Im Dezember 2020 haben die CentOS-Community und Red Hat den Sonnenuntergang von CentOS angekündigt. Am 31. Januar 2022 hat CentOS 8 sein End of Life (EOL) erreicht. In der End of Life funktioniert yum-Repositories nicht mehr für CentOS. Dadurch können die Clustererstellung und die Clusterupgrades fehlschlagen. Dies gilt für alle unterstützten Versionen von CentOS und alle Versionen von Anthos-Clustern auf Bare Metal.


    Problemumgehung
    Betriebssystem 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Einschränkungen des Betriebssystem-Endpunkts

    Auf RHEL und CentOS gibt es eine Beschränkung auf Clusterebene von 100.000 Endpunkten. Kubernetes-Dienst. Wenn zwei Dienste auf dieselben Pods verweisen, zählt dies als zwei separate Sätze von Endpunkten. Die zugrunde liegende nftable-Implementierung auf RHEL und CentOS verursacht diese Einschränkung; sie ist keine inhärente Einschränkung von Anthos-Clustern auf Bare Metal.
    Sicherheit 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Container kann in VOLUME, die im Dockerfile definiert ist, nicht mit containerd und SELinux schreiben

    Wenn Sie „containerd“ als Containerlaufzeit verwenden und in Ihrem Betriebssystem SELinux aktiviert ist, ist das im Anwendungs-Dockerfile definierte VOLUME möglicherweise nicht beschreibbar. Mit dem folgenden Dockerfile erstellte Container können beispielsweise nicht in den Ordner /tmp schreiben.

    
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp

    Führen Sie den folgenden Befehl auf dem Knoten aus, auf dem der problematische Container gehostet wird, um zu sehen, ob Sie von diesem Problem betroffen sind:

    ausearch -m avc

    Wenn Sie von diesem Problem betroffen sind, wird unter Umständen ein denied-Fehler wie der folgende angezeigt:

    time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0

    Problemumgehung

    Führen Sie eine der folgenden Änderungen aus, um dieses Problem zu umgehen:

    • Deaktivieren Sie SELinux.
    • Verwenden Sie die Funktion VOLUME nicht in Dockerfile.
    Sicherheit 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    SELinux-Fehler bei der Pod-Erstellung

    Die Pod-Erstellung schlägt manchmal fehl, wenn SELinux verhindert, dass die Containerlaufzeit Labels auf tmpfs-Bereitstellungen legt. Dieser Fehler tritt eher selten auf, kann aber auftreten, wenn sich SELinux im Modus Enforcing und in einigen Kernels befindet.

    Mit dem folgenden Befehl können Sie in den kubelet-Logs prüfen, ob SELinux die Ursache für Fehler beim Erstellen von Pods ist:

    journalctl -u kubelet

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

    
error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied

    Führen Sie den folgenden Befehl aus, um zu prüfen, ob das Problem mit der SELinux-Erzwingung zusammenhängt:

    ausearch -m avc

    Mit diesem Befehl werden die Audit-Logs nach Berechtigungsfehlern im Zugriffsvektorcache (AVC) durchsucht. Der avc: denied in der folgenden Beispielantwort bestätigt, dass die Fehler beim Erstellen des Pods mit der SELinux-Erzwingung zusammenhängen.

    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 Pod-Erstellungsproblems mit SELinux ist ein Kernel-Fehler, der in den folgenden Linux-Images gefunden wird:

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

    Problemumgehung

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

    Verwenden Sie RHEL 8.3 oder höher oder CentOS 8.3 oder höher, um zu verhindern, dass Fehler beim Erstellen von Pods auftreten, da diese Versionen den Kernel-Fehler behoben haben.
    Zurücksetzen/Löschen 1.10, 1.11, 1.12

    Namespace löschen

    Das Löschen eines Namespace verhindert, dass neue Ressourcen in diesem Namespace erstellt werden, einschließlich Jobs zum Zurücksetzen von Maschinen.


    Problemumgehung

    Zum Löschen eines Nutzerclusters müssen Sie zuerst das Clusterobjekt löschen, bevor Sie seinen Namespace löschen. Andernfalls können die Jobs zum Zurücksetzen von Maschinen nicht erstellt werden und der Löschvorgang wird übersprungen.
    Zurücksetzen/Löschen 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    containerd-Dienst

    Mit dem Befehl bmctl reset werden keine containerd-Konfigurationsdateien oder Binärdateien gelöscht. Der containerd systemd-Dienst bleibt aktiviert und wird ausgeführt. Mit dem Befehl werden die Container gelöscht, die die für den Knoten geplanten Pods ausführen.
    Upgrades und Updates 1.10, 1.11, 1.12

    Knotenproblemerkennung ist nach Clusterupgrades standardmäßig nicht aktiviert

    Wenn Sie Anthos-Cluster auf Bare Metal upgraden, ist Node Problem Detector standardmäßig nicht aktiviert. Dieses Problem gilt für Upgrades von Version 1.10 auf 1.12.1 und wurde in Version 1.12.2 behoben.


    Workaround:

    So aktivieren Sie den Knotenproblemdetektor:

    1. Prüfen Sie, ob der node-problem-detector systemd-Dienst auf dem Knoten ausgeführt wird.
      1. Verwenden Sie den SSH-Befehl und stellen Sie eine Verbindung zum Knoten her.
      2. Prüfen Sie, ob der node-problem-detector systemd-Dienst auf dem Knoten ausgeführt wird: 
        systemctl is-active node-problem-detector
         Wenn in dem Befehlsergebnis inactive angezeigt wird, wird der Knotenproblem-Detektor nicht auf dem Knoten ausgeführt.
    2. Verwenden Sie zum Aktivieren des Knotenproblemdetektors den Befehl kubectl edit und bearbeiten Sie die ConfigMap node-problem-detector-config. Weitere Informationen finden Sie unter Knotenproblemerkennung.
    Vorgang 1,9, 1,10

    Clustersicherung schlägt fehl, wenn eine Nicht-Root-Anmeldung verwendet wird

    Der Befehl bmctl backup cluster schlägt fehl, wenn nodeAccess.loginUser auf einen Nicht-Root-Nutzernamen festgelegt ist.]


    Workaround:

    Dieses Problem gilt für Anthos-Cluster auf Bare Metal 1.9.x, 1.10.0 und 1.10.1 und wurde in Version 1.10.2 und höher behoben.
    Netzwerk 1.10, 1.11, 1.12

    Load-Balancer-Dienste funktionieren nicht mit Containern im Steuerungsebenen-Hostnetzwerk

    Bei anetd tritt ein Fehler auf, bei dem Pakete für LoadBalancer-Dienste verworfen werden, wenn die Back-End-Pods auf dem Knoten der Steuerungsebene ausgeführt werden und das Feld hostNetwork: true in der Spezifikation des Containers verwenden.

    Der Fehler ist in Version 1.13 oder höher nicht vorhanden.


    Workaround:

    Die folgenden Problemumgehungen können helfen, wenn Sie einen LoadBalancer-Dienst verwenden, der von hostNetwork-Pods gesichert wird:

    1. Führen Sie sie auf Worker-Knoten aus (nicht auf Knoten der Steuerungsebene).
    2. Verwenden Sie externalTrafficPolicy: local in der Dienstspezifikation und sorgen Sie dafür, dass Ihre Arbeitslasten auf Load-Balancer-Knoten ausgeführt werden.
    Upgrades und Updates 1,12, 1,13

    Pod für verwaiste anthos-version-$version$ konnte das Image nicht abrufen

    Bei einem Clusterupgrade von 1.12.x auf 1.13.x kann ein fehlgeschlagener anthos-version-$version$-Pod mit ImagePullBackOff-Fehler auftreten. Dies geschieht aufgrund der Race-Bedingung des anthos-cluster-operators, das aktualisiert werden sollte, und sollte keine Auswirkungen auf die regulären Clusterfunktionen haben.

    Der Fehler ist nach Version 1.13 oder höher nicht mehr vorhanden.


    Workaround:

    Job des Dynamic-Installer von kubectl delete job anthos-version-$version$ -n kube-system löschen
    Upgrades und Updates 1.13

    1.12-Cluster, die von 1.11 aktualisiert wurden, können nicht auf 1.13.0 aktualisiert werden

    Cluster mit Version 1.12, die von Version 1.11 aktualisiert wurden, können nicht auf Version 1.13.0 aktualisiert werden. Dieses Upgradeproblem gilt nicht für Cluster, die in Version 1.12 erstellt wurden.

    In den Logs des Upgradejobs, der den upgrade-first-no*-String im Administratorcluster enthält, können Sie feststellen, ob Sie betroffen sind. Die folgende Fehlermeldung ist betroffen:

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
...

    Workaround:

    So umgehen Sie dieses Problem:

    1. Führen Sie auf der Administratorworkstation die folgenden Befehle aus: 
      echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'
    2. Versuchen Sie noch einmal, das Clusterupgrade durchzuführen.
    Wenn Sie weitere Hilfe benötigen, wenden Sie sich an den Google-Support.