Bekannte Probleme bei der Kubernetes Engine (OKE)

Details

Die Eigenschaften neuer Worker-Knoten, die in einem Knotenpool gestartet werden, reflektieren die neuesten Änderungen an den Eigenschaften des Knotenpools nicht. Wahrscheinlich wurden beim Aktualisieren der Knotenpooleigenschaften mit dem UpdateNodePoolDetails-API-Vorgang veraltete quantityPerSubnet- und subnetIds-Attribute verwendet.

Zwischenlösung

Führen Sie einen der folgenden Schritte aus:

• Verwenden Sie ab jetzt das nodeConfigDetails-Attribut beim Ausführen des UpdateNodePoolDetails-API-Vorgangs. Skalieren Sie zunächst den Knotenpool mit quantityPerSubnet auf 0. Stoppen Sie dann die Verwendung der Attribute subnetIds und quantityPerSubnet, und verwenden Sie stattdessen das nodeConfigDetails-Attribut.
• Wenden Sie sich an Oracle Support, um die für die Synchronisierung zuständige Backend-Komponente (die Mandanten-Agent-Komponente) neu zu starten.

Details

Wenn Sie das Kubernetes-Dashboard starten, werden in bestimmten Fällen möglicherweise die Fehlermeldungen "net/http: Timeout beim TLS-Handshake" und "Verbindung von Peer zurückgesetzt" in Ihrem Webbrowser angezeigt. Dieses Problem wurde nur in neu erstellten Clustern beobachtet, auf denen die Kubernetes-Version 1.11 ausgeführt wird. Weitere Informationen zu einem zugehörigen Kubernetes-Problem finden Sie unter https://github.com/kubernetes/dashboard/issues/3038.

Zwischenlösung

1. Geben Sie in einem Terminalfenster Folgendes ein:

   $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443

2. Navigieren Sie im Webbrowser zu https://localhost:8443

Details

Wenn Sie mit einer Kubeconfig-Tokenversion 2.0.0 auf Helm/Tiller-Versionen vor Version 2.11 zugreifen, erhalten Sie einen der folgenden Fehler:

• Error: Unauthorized
• Error: could not get Kubernetes client: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

Zwischenlösung

Führen Sie ein Upgrade von Helm/Tiller wie folgt aus:

1. Laden Sie in einem Terminalfenster eine Kubeconfig-Tokenversion 1.0.0 herunter, indem Sie den folgenden Befehl eingeben:

   $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>

2. Ermitteln Sie den Regionsschlüssel, mit dem die Oracle Cloud Infrastructure Registry-Registry in der Region des Clusters angegeben wird (siehe Verfügbarkeit nach Region). Beispiel: Wenn sich das Cluster in "US East (Ashburn)," befindet, ist iad der Regionsschlüssel, mit dem die Registry in dieser Region angegeben wird.

3. Führen Sie ein Tiller-Upgrade aus, indem Sie den folgenden Befehl eingeben:

   $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

   Dabei ist <region-key> der im vorherigen Schritt ermittelte Schlüssel.

4. Navigieren Sie in einem Browser zu https://helm.sh/docs/using_helm/#installing-the-helm-client, und befolgen Sie die Anweisungen zum Herunterladen und Installieren der Helm-Clientbinärdatei.

5. Nach dem Upgrade von Helm/Tiller laden Sie eine Kubeconfig-Tokenversion 2.0.0 herunter, indem Sie den folgenden Befehl eingeben:

   $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

Details

Das Kubernetes-Engine-Release 1.8.0 enthielt eine Sicherheitsverbesserung, um die Cipher-Stärke auf dem Kubelet zu verbessern, das auf Kunden-Worker-Knoten ausgeführt wird. Neue Worker-Knoten, die zwischen dem 20. August und dem 16. September 2019 erstellt wurden, umfassen diese Konfiguration. Die neue Cipher-Gruppe lässt keine Verbindungen zum Kubelet über http/2 zu. Diese Einschränkung wirkt sich auch auf den Metrikserver und auf den Horizontal Pod Autoscaler aus, der vom Metrikserver abhängig ist.

Zwischenlösung

Führen Sie für jeden vorhandenen Worker-Knoten nacheinander die folgenden Schritte aus:

1. Verhindern Sie, dass neue Pods gestartet werden, und löschen Sie vorhandene Pods auf dem Worker-Knoten, indem Sie kubectl drain <node_name> eingeben. Weitere Informationen:

   • Informationen zur Verwendung von kubectl finden Sie unter Mit kubectl auf ein Cluster zugreifen
   • Informationen zum Drain-Befehl finden Sie in der Kubernetes-Dokumentation unter Drain

   Empfohlen: Nutzen Sie gegebenenfalls die zulässige Höchstanzahl von Podunterbrechungen (Pod Disruption Budget, PDB) für Ihre Anwendung, um sicherzustellen, dass eine ausreichende Anzahl von Replikatpods während des Drain-Vorgangs ausgeführt wird.

2. Löschen Sie den Worker-Knoten (z.B. indem Sie ihn in der Konsole beenden).
3. Warten Sie, bis ein Ersatz-Worker-Knoten gestartet wird.

Die Ersatz-Worker-Knoten umfassen neue Einstellungen, um die Kommunikation mit dem Kubelet zu ermöglichen.

Details

Wenn ein neuer Pod auf einem Worker-Knoten in einem Cluster gestartet wird, kann der Pod in einigen Fällen aufgrund von Timeouts nicht alle an den Knoten angehängten Volumes mounten, und es wird eine Meldung wie die folgende angezeigt:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

Eine mögliche Ursache für dieses Problem ist, dass die Podspezifikation ein fsGroup-Feld im Feld securityContext enthält. Wenn der Container als Nicht-Root-Benutzer auf einem Worker-Knoten ausgeführt wird, kann die Einstellung des Feldes fsGroup in securityContext aufgrund der Anzahl der Dateien, an denen Kubernetes Eigentümeränderungen vornehmen muss, Timeouts verursachen (siehe https://github.com/kubernetes/kubernetes/issues/67014).

Wenn die Podspezifikation kein fsgroup-Feld in securityContext enthält, ist die Ursache unbekannt.

Zwischenlösung

Wenn die Podspezifikation das Feld fsgroup in securityContext enthält und der Container einen Nicht-Root-Benutzer ausführt, ziehen Sie folgende Workarounds in Betracht:

• Entfernen Sie das Feld fsgroup aus securityContext.
• Verwenden Sie das Feld supplementalGroups in securityContext (statt fsgroup), und setzen Sie supplementalGroups auf die Volume-ID.
• Ändern Sie die Podspezifikation so, dass der Container als Root ausgeführt wird.

Wenn die Podspezifikation das Feld fsgroup nicht in securityContext enthält oder der Container bereits als Root ausgeführt wird, müssen Sie den Worker-Knoten neu starten oder ersetzen. Dies ist z.B. möglich durch Stoppen und Starten der Instanz, durch Neustart der Instanz oder durch Beenden der Instanz, damit eine neue Instanz gestartet wird. Befolgen Sie die Anweisungen unter Instanz stoppen, starten oder neu starten bzw. Instanz beenden, um die Konsole oder die API zu verwenden. Alternativ können Sie CLI-Befehle wie im folgenden Beispiel verwenden, um eine Instanz zu beenden:

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

Dabei ist <name> der Name des Worker-Knotens, der von der Eigenschaft "Private IP-Adresse" der Instanz abgeleitet wird (Beispiel: 10.0.10.5).

Details

Wenn Sie mit dem OS Management-Service Betriebssystemupdates und Patches auf Oracle Cloud Infrastructure-Instanzen verwalten, können in bestimmten Situationen Clusterknotenpools, die von der Kubernetes-Engine erstellt wurden, nicht online gesetzt werden.

Zwischenlösung

Es gibt zwei mögliche Workarounds:

• Workaround 1: Wenn Sie OS Management zur Verwaltung von Oracle Cloud Infrastructure-Instanzen verwenden möchten, aktivieren Sie Oracle Enterprise Linux in OS Management. Siehe Softwarequellen verwalten.
• Workaround 2: Wenn Sie OS Management nicht zur Verwaltung von Oracle Cloud Infrastructure-Instanzen verwenden möchten, stellen Sie sicher, dass keine Policys vorhanden sind, mit denen OS Management ausgeführt werden kann. Entfernen Sie insbesondere die Policy, die einer dynamischen Gruppe von Instanzen Zugriff auf den OS Management-Service erteilt. Siehe Policys für OS Management einrichten.

Details

Wenn das Bridge Netfilter-Kernelmodul nicht aktiviert ist, wird die Traffickommunikation mit localhost nicht korrekt weitergeleitet. Beispiel:

/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 

Um dieses Problem zu prüfen, öffnen Sie ein Terminalfenster auf der Instanz und führen den folgenden Befehl aus:

sudo /usr/sbin/lsmod | grep br_netfilter 

Wenn keine Ergebnisse übermittelt werden, ist das Bridge-Netfilter-Kernelmodul nicht aktiviert. Das Bridge-Netfilter-Kernelmodul ist erforderlich, um den VxLAN-Datenverkehr für Kubernetes-Pods zu maskieren.

Zwischenlösung

Aktivieren Sie das Bridge-Netfilter-Kernelmodul. Öffnen Sie ein Terminalfenster auf der Instanz, und führen Sie die folgenden Befehle aus.

sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

Details

Bei Verwendung von VCN-nativen Podnetzwerken wird die Quellclient-IP-Adresse eingehender Anforderungen an einen Pod möglicherweise nicht wie erwartet beibehalten. Stattdessen wird für eingehende Anforderungen, die über einen Kubernetes-Service des Typs LoadBalancer empfangen werden, für den externalTrafficPolicy: Local in der Manifestdatei festgelegt ist, als Ursprung möglicherweise die IP-Adresse des Worker-Knotens angezeigt.

Zwischenlösung

Bei eingehenden TCP-Anforderungen, die über einen Kubernetes-Service des Typs LoadBalancer mit der Annotation oci.oraclecloud.com/load-balancer-type: "lb" in der Manifestdatei empfangen wurden, ermitteln Sie die IP-Adresse des Quellclients aus dem Header X-Forwarded-For oder X-Real-IP.

Details

Wenn Sie ein VCN-natives Podnetzwerk verwenden, können Pods möglicherweise nicht über das Netzwerk kommunizieren, wenn Sie eine Bare-Metal-Ausprägung für Worker-Knoten in einem oder mehreren Knotenpools im Cluster angegeben haben.

Zwischenlösung

Geben Sie eine VM-Ausprägung für Worker-Knoten in jedem Knotenpool im Cluster an, wenn Sie VCN-native Podnetzwerke verwenden.

Details

Wenn Sie ein VCN-natives Podnetzwerk verwenden, kann die maximale Anzahl der Pods pro Worker-Knoten in einem Knotenpool auf 31 begrenzt sein, unabhängig von der Anzahl der OCPUs, die Sie für die flexible Ausprägung angeben, die Sie für den Knotenpool ausgewählt haben.

Zwischenlösung

Wenn Sie mehr als 31 Pods pro Worker-Knoten in einem Knotenpool benötigen, wählen Sie eine andere Ausprägung für Worker-Knoten im Knotenpool aus.

Details

Wenn Sie ein VCN-natives Podnetzwerk verwenden, können Pods, die auf Worker-Knoten ausgeführt werden, die mit einem Podsubnetz mit einem CIDR-Block außerhalb des ersten für das VCN angegebenen CIDR-Blocks verbunden sind, möglicherweise nicht mit Kubernetes-Services kommunizieren.

Zwischenlösung

Erstellen Sie Podsubnetze mit CIDR-Blocks im ersten CIDR-Block, der für das VCN angegeben ist.

Details

Wenn Sie das Node Doctor-Skript zur Fehlerbehebung von Knotenproblemen verwenden, kann das Skript eine Ausnahmefehlermeldung wie die folgende anzeigen:

FileNotFoundError: [Errno 2] No such file or directory: '/home/opc/vendor/pip…

Das Node Doctor-Skript wird wahrscheinlich weiter ausgeführt und erzeugt nach der Anzeige der Meldung Generating node doctor bundle die Ausgabe der Fehlerbehebung.

Zwischenlösung

Dieses Problem ist bekannt, und wir arbeiten an einer Lösung. Beachten Sie, dass die Ausgabe der Fehlerbehebung noch gültig ist, wenn das Node Doctor-Skript die Meldung Generating node doctor bundle anzeigt.

Wenn das Node Doctor-Skript die Fehlermeldung FileNotFoundError: [Errno 2]... nicht anzeigen soll, aktualisieren Sie das Node Doctor-Skript, indem Sie Folgendes eingeben:

node-doctor.sh --update

Weitere Informationen zum Node Doctor-Skript und dessen Aktualisierung finden Sie unter Fehler bei Knotenproblemen für Kubernetes-Cluster mit dem Node Doctor-Skript beheben.

Details

Wenn ein Cluster VCN-natives Podnetworking verwendet und sowohl ein Workload-Pod als auch der CoreDNS-Pod auf demselben Worker-Knoten ausgeführt werden, verläuft die DNS-Auflösung möglicherweise nicht erfolgreich, weil der Traffic falsch NATed ist.

Lösung

Unter 2023-03-21 wurde ein Update des CNI-Plug-ins für das OCI-VCN-natives Podnetzwerk veröffentlicht, mit dem dieses Problem behoben wurde. Befolgen Sie die Anweisungen unter CNI-Plug-in für OCI-VCN-natives Podnetworking aktualisieren, um das Update bereitzustellen.

Details

Wenn ein Cluster VCN-natives Podnetworking verwendet und Worker-Knoten enthält, auf denen Oracle Linux 8 (OL8) ausgeführt wird, können Pods auf einem der Worker-Knoten manchmal nicht gestartet werden. Das Problem weist folgende Merkmale auf:

• Auf dem Worker-Knoten wird ein OL8-Image ausgeführt.
• Hostnetzwerkbezogene Pods werden wie erwartet auf dem Worker-Knoten ausgeführt, aber alle anderen Pods können nicht gestartet werden.
• Die crictl-Logs enthalten die Meldung Adding address to IPVLAN parent device (die angibt, dass eine IP-Adresse an die sekundäre VNIC des Worker-Knotens angehängt wird), gefolgt von der Fehlermeldung Error adding secondary VNIC IP.
• Wenn Sie den Linux-Befehl ip address auf dem Worker-Knoten ausführen, wird angezeigt, dass eine (oder mehrere) sekundäre VNICs keine angehängte IP-Adresse aufweisen.
• Alle (oder die meisten) anderen Worker-Knoten arbeiten wie erwartet.

Eine wahrscheinliche Ursache für dieses Problem hängt mit NetworkManager zusammen, der Netzwerkgeräte und Verbindungen verwaltet. In einigen Fällen hebt NetworkManager die Zuordnung der IP-Adresse zu mindestens einer der sekundären VNICs des Worker-Knotens auf, wodurch beim CNI-Plug-in für OCI-VCN-natives Podnetworking ein Fehler auftritt.

Lösung

Unter 2023-03-21 wurde ein Update des CNI-Plug-ins für das OCI-VCN-natives Podnetzwerk veröffentlicht, mit dem dieses Problem behoben wurde. Befolgen Sie die Anweisungen unter CNI-Plug-in für OCI-VCN-natives Podnetworking aktualisieren, um das Update bereitzustellen.

Details

Wenn Sie Oracle Linux 8.7 oder Oracle Linux 8.8 für einen Knotenpool angegeben haben (indem Sie ein Oracle Linux 8.7 oder Oracle Linux 8.8-Plattformimage oder ein OKE-Workerknotenimage auswählen, das auf Oracle Linux 8.7 oder Oracle Linux 8.8 basiert), kann sich der Status der Worker-Knoten des Knotenpools unerwartet in NotReady ändern. Das Problem weist folgende Merkmale auf:

• Auf den Worker-Knoten wird Oracle Linux 8.7 oder Oracle Linux 8.8 ausgeführt.
• Auf den Worker-Knoten werden Kubernetes-Versionen 1.24.1, 1.25.4 oder 1.26.2 ausgeführt. (Worker-Knoten, auf denen Kubernetes-Version 1.25.12, 1.26.7 und 1.27 ausgeführt werden, sind davon nicht betroffen.)
• Pods mit kurzer Nutzungsdauer werden häufig auf den Worker-Knoten bereitgestellt.
• Pods, die auf Worker-Knoten im Knotenpool bereitgestellt werden, bleiben möglicherweise länger als erwartet im Status ContainerCreating.

Zwischenlösung

Dieses Problem ist bekannt, und wir arbeiten an einer Lösung.

Wenn dieses Problem auftritt, verwenden Sie in der Zwischenzeit denjenigen der folgenden Workarounds, der Ihre Anforderungen am besten erfüllt:

• Geben Sie ein Oracle Linux 7-Image für den Knotenpool an.
• Geben Sie ein Oracle Linux 8.6-Image (oder ein früheres Oracle Linux 8-Image) für den Knotenpool an.
• Geben Sie eine spätere Version von Kubernetes für den Knotenpool an. (Worker-Knoten, auf denen Kubernetes-Version 1.25.12, 1.26.7 und 1.27 ausgeführt werden, sind davon nicht betroffen.)

So rufen Sie die OCIDs von Images ab, die nicht mehr in der Konsole angezeigt werden:

• Plattformimages: Weitere Informationen finden Sie unter Alle Oracle Linux 7.x-Images und Alle Oracle Linux 8.x-Images
• OKE-Worker-Knotenimages: Siehe Alle Oracle Linux 7.x-Images für OKE-Worker-Knoten und Alle Oracle Linux 8.x-Images für OKE-Worker-Knoten

Details

In Clustern, die vor dem 26. Juni 2023 erstellt wurden und VCN-natives Podnetzwerk verwenden, wird das Provisioning neuer Worker-Knoten möglicherweise verzögert.

Beim Bootstrapping von Worker-Knoten mit dem CNI-Plug-in für OCI-VCN-native Podnetworking stellt Kubernetes Engine eine benutzerdefinierte Kubernetes-Ressource (NativePodNetwork oder NPN, Ressource) auf jeder Compute-Instanz bereit. Wenn ein Worker-Knoten erfolgreich mit Bootstrapping gestartet wurde, gibt Kubernetes Engine der mit der Compute-Instanz verknüpften NPN-Ressource den Status SUCCESS.

Wenn eine Compute-Instanz in einigen Fällen beendet wird, bevor die Kubernetes-Engine der verknüpften NPN-Ressource den Status "Erfolgreich" gibt, bleibt die NPN-Ressource unbegrenzt im Status "Zurückgestellt" oder "IN_PROGRESS". Das Vorhandensein solcher "veralteten" Ressourcen kann das Provisioning neuer Worker-Knoten verzögern.

Lösung

Das Problem wird in Clustern behoben, die nach 2023-06-26 erstellt wurden. Um das Problem in Clustern zu lösen, die vor 2023-06-26 erstellt wurden, führen Sie eine einmalige Aktion aus, um die veralteten Ressourcen zu löschen, indem Sie die Anweisungen in diesem Abschnitt befolgen.

Bevor Sie beginnen, stellen Sie sicher, dass Ihr System die folgenden Voraussetzungen erfüllt:

• die OCI-CLI installiert ist (siehe CLI installieren)
• die OCI-CLI konfiguriert ist (siehe CLI konfigurieren)
• jq wurde heruntergeladen und installiert (siehe https://jqlang.github.io/jq/download/)
• Es ist eine IAM-Policy vorhanden, die mindestens die Berechtigung INSTANCE_READ erteilt, z.B. Allow group <group-name> to manage instance-family in <location> (siehe Erforderliche Policy für Gruppen erstellen)
• auf die entsprechenden kubeconfig-Dateien kann zugegriffen werden, damit Sie mit kubectl Cluster verwalten können, die das OCI-CNI-Plug-in für VCN-natives Podnetzwerk verwenden (siehe Mit Kubectl auf ein Cluster zugreifen)

Identifizieren und löschen Sie die veralteten Ressourcen wie folgt:

1. Stellen Sie sicher, dass Ihr System alle Voraussetzungen erfüllt:
   1. Speichern Sie das folgende Skript in einer Datei mit dem Namen pre-req-check.sh:

      #!/bin/bash
      echo Validating cluster access to get npn resources
      ACTIVE_RESOURCES=($(kubectl get npn -o json | jq '[.items[] | select(.status.state == "SUCCESS")]' | jq -r '.[] | .metadata.name'))
      if [[ -z "$ACTIVE_RESOURCES" ]] || [ ${#ACTIVE_RESOURCES[@]} == 0 ]
      then
        echo No active NPN resources found. Make sure you have cluster access and this is an OCI VCN-Native CNI cluster. '\'nPlease check prerequisites and retry.
        exit
      fi
       
      cr_name=${ACTIVE_RESOURCES[0]}
      echo Validating access to get compute instance
      INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
      INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
       
      if [[ -z "$INSTANCE_STATE" ]]
      then
        echo Unable to get instance details, please check prerequisites and retry.
      else
        echo All prerequisites in place, please proceed to cleaning up stale resources.
      fi

   2. Führen Sie das Skript pre-req-check.sh aus, indem Sie Folgendes eingeben:

      sh pre-req-check.sh

2. Identifizieren Sie NPN-Ressourcen, die gelöscht werden können, da sie nicht den Status SUCCESS aufweisen:
   1. Geben Sie eine Liste der NPN-Ressourcen, die nicht den Status SUCCESS aufweisen, in eine Textdatei namens potential_stale_resources.txt aus, indem Sie Folgendes eingeben:

      kubectl get npn -o json | jq '[.items[] | select(.status.state != "SUCCESS")]' | jq -r '.[] | .metadata.name' >> potential_stale_resources.txt

   2. Zeigen Sie optional die Liste der NPN-Kandidatenressourcen in potential_stale_resources.txt an, indem Sie Folgendes eingeben:

      cat potential_stale_resources.txt

      Beispiel: potential_stale_resources.txt kann Folgendes enthalten:

      anyhqljth4...trq
      anyhqljth4...snq
      anyhqljth4...qhq

3. Identifizieren Sie die veralteten zu löschenden NPN-Ressourcen, indem Sie bestimmen, welche Kandidaten-NPN-Ressourcen Compute-Instanzen zugeordnet sind, die nicht verfügbar sind oder beendet wurden:
   1. Speichern Sie das folgende Skript in einer Datei mit dem Namen get_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read  -r cr_name
      do
        echo verifying NPN resource $cr_name
        INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
        if [  -z $INSTANCE_ID ]
        then
          echo Unable to get npn resource details. Please check prerequisites and retry from step 2.
          exit
        fi
        echo Associated instance is $INSTANCE_ID
        INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
        if [  -z $INSTANCE_STATE ]
        then
          # check for 404 for tombstoned instances
          STATUS=$(oci compute instance get --instance-id $INSTANCE_ID 2>&1 | tail -n +2 | jq .status)
          if [ $STATUS == 404 ]
          then
            echo 404 getting instance $INSTANCE_ID, Instance has been tombstoned. Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          fi
        else
          echo Instance $INSTANCE_ID in $INSTANCE_STATE state
          if [ $INSTANCE_STATE == "TERMINATED" ]
          then
            echo Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          else
            echo Instance $INSTANCE_ID not terminated. '\'nSkipping resource $cr_name '\'n
          fi
        fi
      done < $1

   2. Führen Sie das Skript get_stale_resources.sh aus, indem Sie Folgendes eingeben:

      sh get_stale_resources.sh potential_stale_resources.txt

      Das Skript get_stale_resources.sh identifiziert die veralteten zu löschenden NPN-Ressourcen, gibt Nachrichten auf dem Bildschirm aus und schreibt die Namen veralteter NPN-Ressourcen in eine Datei mit dem Namen stale_resources.txt. Beispiel:

      Reading resources from potential_stale_resources.txt
      verifying NPN resource anyhqljth4...trq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...trq
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq in RUNNING state
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq not terminated.
      Skipping resource anyhqljth4...trq
       
      verifying NPN resource anyhqljth4...snq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...snq
      Instance ocid1.instance.oc1.phx.anyhqljth4...snq in TERMINATED state
      Adding resource anyhqljth4...snq to stale_resources
       
      verifying NPN resource anyhqljth4...qhq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...qhq
      ServiceError:
      {
          "client_version": "Oracle-PythonSDK/2.104.2, Oracle-PythonCLI/3.29.0",
          "code": "NotAuthorizedOrNotFound",
          "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
          "message": "instance ocid1.instance.oc1.phx.anyhqljth4...qhq not found",
          "opc-request-id": "CCB8D1925...38ECB8",
          "operation_name": "get_instance",
          "request_endpoint": "GET https://iaas.us-phoenix-1.oraclecloud.com/20160918/instances/ocid1.instance.oc1.phx.anyhqljth4...qhq",
          "status": 404,
          "target_service": "compute",
          "timestamp": "2023-06-27T20:24:28.992241+00:00",
          "troubleshooting_tips": "See [https://docs.oracle.com/iaas/Content/API/References/apierrors.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
      }
      404 getting instance ocid1.instance.oc1.phx.anyhqljth4...qhq, Instance has been tombstoned
      Adding resource anyhqljth4...qhq to stale_resources

   3. Zeigen Sie optional die Liste der veralteten NPN-Ressourcen in stale_resources.txt an, indem Sie Folgendes eingeben:

      cat stale_resources.txt

      Beispiel: stale_resources.txt kann Folgendes enthalten:

      anyhqljth4...snq
      anyhqljth4...qhq

4. Löschen Sie die veralteten NPN-Ressourcen, die in der Datei stale_resources.txt aufgeführt sind:
   1. Speichern Sie das folgende Skript in einer Datei mit dem Namen delete_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read -r cr_name
      do
          echo Deleting $cr_name
          kubectl delete npn $cr_name
      done < $1

   2. Führen Sie das Skript delete_stale_resources.sh aus, indem Sie Folgendes eingeben:

      sh delete_stale_resources.sh stale_resources.txt

      Das Skript delete_stale_resources.sh löscht die veralteten NPN-Ressourcen, die in der Datei stale_resources.txt aufgeführt sind, und gibt Verarbeitungsmeldungen auf dem Bildschirm aus. Beispiel:

      Reading resources from stale_resources.txt
      Deleting anyhqljth4...snq
      nativepodnetwork.oci.oraclecloud.com "anyhqljth4...snq" deleted

5. Löschen Sie als gute Housekeeping-Praxis die zuvor erstellten Dateien stale_resources.txt und potential_stale_resources.txt.

Details

Wenn Sie eine Arm-Ausprägung für einen virtuellen Knoten angeben, werden Pods, die auf dem Knoten geplant sind, wie beabsichtigt auf Arm-Prozessoren ausgeführt. Wenn Sie den virtuellen Knoten jedoch mit dem Befehl kubectl describe node oder der Kubernetes-API untersuchen, gibt die Architektureigenschaft des Knotens AMD64 an, obwohl Pods, die auf dem Knoten geplant sind, auf Arm-Prozessoren ausgeführt werden.

Zwischenlösung

Dieses Problem ist bekannt, und wir arbeiten an einer Lösung.

Wenn dieses Problem auftritt, ignorieren Sie in der Zwischenzeit den Wert der Architektureigenschaft des virtuellen Knotens.

Details

Wenn die Kubernetes-Engine einen OCI-Load Balancer für einen Kubernetes-Service des Typs LoadBalancer bereitstellt, ist der Löschschutz für den Load Balancer nicht aktiviert.

Wenn Sie anschließend die Konsole, die CLI oder die API verwenden, um den Löschschutz für den Load Balancer zu aktivieren, wird der Cloud-Controller-Manager nicht nur daran gehindert, den Load Balancer zu löschen, sondern kann auch keine der Eigenschaften des Load Balancers aktualisieren.

Workaround

Dieses Problem ist bekannt, und wir arbeiten an einer Lösung.

Verwenden Sie in der Zwischenzeit nicht die Konsole, die CLI oder die API, um den Löschschutz für einen Load Balancer zu aktivieren.

Beachten Sie, dass die Verwendung der Konsole, der CLI oder der API zum Ändern von OCI-Load Balancern, die von Kubernetes Engine bereitgestellt werden, nicht empfohlen wird (weitere Informationen finden Sie unter Kubernetes-Services vom Typ LoadBalancer definieren).

Details

Neue Versionen des CNI-Plug-ins für OCI-VCN-native Podnetworking werden normalerweise in den Realms OC1, OC2 und OC3 veröffentlicht.

Am 3. September 2024 wurde das OCI-VCN-native Pod Networking-CNI-Plug-in Version 2.2.0, das Sicherheits- und Performanceverbesserungen enthält, jedoch nur in der OC1-Realm veröffentlicht.

Am 4. Oktober 2024 wurde das OCI-VCN-native Podnetworking-CNI-Plug-in Version 2.2.2 in den Realms OC1, OC2 und OC3 veröffentlicht, die weitere Verbesserungen enthalten.

Daher zwischen dem 3. September 2024 und dem 4. Oktober 2024:

• Neue Cluster, die Sie in den Realms OC2 und OC3 erstellt haben, verwendeten die frühere Version des CNI-Plug-ins für OCI-VCN-native Podnetworking, nämlich Version 2.1.0.
• Bei vorhandenen Clustern in den Realms OC2 und OC3 wurde Version 2.2.0 in diesen Clustern nicht bereitgestellt, selbst wenn Sie angegeben haben, dass Oracle Updates für das OCI-VCN-native Podnetzwerk-CNI-Plug-in automatisch in einem Cluster bereitstellen soll.

Unabhängig davon, ob Sie oder Oracle für das Deployment von Updates für das OCI-VCN-native Podnetworking-CNI-Plug-in verantwortlich sind, werden die Updates nur angewendet, wenn Worker-Knoten das nächste Mal neu gestartet werden.

Daher können Cluster in den Realms OC2 und OC3 vorhanden sein, in denen das OCI-VCN-native Podnetworking-CNI-Plug-in Version 2.1.0 noch ausgeführt wird.

Workaround

Um von den Verbesserungen in den CNI-Plug-in-Versionen 2.2.0 und 2.2.2 des OCI-VCN-nativen Podnetzwerks zu profitieren, wird dringend empfohlen, jedes Cluster in OC2 oder OC3 zu aktualisieren, um Version 2.2.2 zu verwenden.

OCI-VCN-native Podnetworking-CNI-Plug-in-Version 2.2.0 wird in den Realms OC2 und OC3 nicht freigegeben, auch wenn Sie Version 2.2.0 in der Konsole auswählen können.

Wenn Sie das CNI-Plug-in für OCI-VCN-native Podnetworking für ein erweitertes Cluster in der Realm OC2 oder OC3 aktivieren und angeben, dass Sie die Version des bereitzustellenden Add-ons auswählen möchten, wählen Sie Version 2.2.0 nicht aus. Wählen Sie stattdessen Version 2.2.2 (oder höher) aus. Wenn Sie Version 2.2.0 für ein erweitertes Cluster in den Realms OC2 und OC3 auswählen, beachten Sie, dass Worker-Knoten nicht hochgefahren werden und das Cluster nicht funktioniert.

Weitere Informationen finden Sie unter OCI-VCN-natives Podnetworking-CNI-Plug-in für Podnetworking.

Details

Wenn Sie mit einem von der Kubernetes-Engine erstellten Kubernetes-Cluster arbeiten, können unerwartete Verzögerungen auftreten, wenn das Cluster mit dem Kubernetes-API-Server interagiert (z.B. langsame Antworten auf kubectl-Befehle).

Wenn Sie einen Clientrechner verwenden, auf dem eine ältere Version der OCI-CLI und/oder Python installiert ist, können diese intermittierenden Spitzen bei der Latenz von kube-apiserver auf ein bekanntes OCI-CLI-Performanceproblem zurückzuführen sein. Dieses Leistungsproblem wurde speziell bei Python Version 3.6 beobachtet.

Standardmäßig enthält die kubeconfig-Datei, die Kubernetes Engine für ein Cluster erstellt, einen OCI-CLI-Befehl, um ein Token zu generieren (den Befehl OCI ce cluster generate-token). Mit dem Token werden Anforderungen an den kube-apiserver authentifiziert. Derzeit löst jede kube-apiserver-Anforderung einen Aufruf der OCI-CLI aus, um den Befehl zum Generieren des Tokens auszuführen. Dieser OCI-CLI-Aufruf kann sich auf das bekannte OCI-CLI-Performanceproblem auswirken.

Um zu bestätigen, dass die kube-apiserver-Latenz durch das bekannte OCI-CLI-Performanceproblem verursacht wird, suchen Sie die vom Client verwendete kubeconfig-Datei, und zeigen Sie sie an. Suchen Sie im Abschnitt users der kubeconfig-Datei den Benutzer, der mit dem betreffenden Cluster verknüpft ist. Angenommen, an der kubeconfig-Datei wurden keine Änderungen zur Verwendung eines Serviceaccounts vorgenommen (siehe Authentifizierungstoken eines Serviceaccounts zu einer Kubeconfig-Datei hinzufügen), enthält der Abschnitt user den Befehl zur Generierung des OCI-CLI-Tokens im folgenden YAML-Format:

- name: <user-name>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - ce
      - cluster
      - generate-token
      - --cluster-id
      - <your-cluster-ocid>
      - --region
      - <your-region>
      command: oci
      env: []

Um zu bestätigen, dass die Kube-apiserver-Latenz durch das bekannte Performanceproblem verursacht wird, geben Sie mit dem folgenden Befehl die Zeit zurück, die OCI-CLI zur Ausführung des Tokengenerierungsbefehls benötigt:

time oci ce cluster generate-token --cluster-id <your-cluster-ocid> --region <your-region>

Wenn die zur Ausführung des Befehls benötigte Zeit nahe der von Ihnen beobachteten kube-apiserver-Latenz liegt, tritt möglicherweise das bekannte Performanceproblem auf.

Workaround

Stellen Sie sicher, dass Sie die neueste stabile Version der OCI-CLI zusammen mit einer unterstützten Version von Python verwenden (siehe Manuelle Installation in der OCI-CLI-Dokumentation).

Wenn Sie Python Version 3.6 verwenden, wird empfohlen, ein Upgrade auf eine neuere Python-Version durchzuführen.

Wenn Sie kein Upgrade auf eine neuere Python-Version durchführen können, deaktivieren Sie den Import aller Services (das Standardverhalten) und importieren Sie stattdessen nur die einzelnen erforderlichen Services und Module selektiv. Das selektive Importieren von Services verbessert die Performance von Python Version 3.6. Weitere Informationen finden Sie unter Selektive Serviceimporte für Python 3.6 aktivieren.

Details

Wenn Sie ein vorhandenes Knotenpool auf Kubernetes-Version 1.33.1 in einem Cluster upgraden, das Sie mit Kubernetes Engine erstellt haben, stellen Sie möglicherweise fest, dass Workloads, die zuvor erfolgreich ausgeführt wurden, jetzt Probleme aufweisen und Fehlermeldungen wie Too many open files zurückgeben.

Eine mögliche Ursache ist, dass in Knotenpools, auf denen Kubernetes-Version 1.33.1 ausgeführt wird, der standardmäßige Soft-Limit für geöffnete Dateien (ulimit nofile) in Containern auf 1024 reduziert wurde. Workloads, die implizit von einem zuvor höheren Standardlimit abhängen, können daher zu Problemen führen.

Der standardmäßige Soft-Limit für geöffnete Dateien (ulimit nofile) in Containern wurde aufgrund einer Änderung der CRI-O-Containerlaufzeit auf 1024 reduziert. Kubernetes-Version 1.33.1 verwendet CRI-O-Version 1.33. In CRI-O Version 1.33 ist der Parameter LimitNOFILE nicht mehr explizit in der CRI-O-Systemd-Servicedatei festgelegt. Infolgedessen gilt der systemd default soft limit (normalerweise 1024) jetzt für geöffnete Dateien in Containern. Weitere Informationen finden Sie unter https://github.com/cri-o/cri-o/pull/8962.

Workaround

Dieses Problem ist bekannt, und es wird an einer Lösung gearbeitet. In der Zwischenzeit gibt es zwei mögliche Workarounds:

• Problemumgehung 1: Erstellen Sie ein benutzerdefiniertes Cloud-Init-Skript, um ulimit nofile zu erhöhen. Beispiel:

  #!/bin/bash
  mkdir -p /etc/crio/crio.conf.d
  echo "[crio]" > /etc/crio/crio.conf.d/11-default.conf
  echo "  [crio.runtime]" >> /etc/crio/crio.conf.d/11-default.conf
  echo "    default_ulimits=[\"nofile=262144:262144\"]" >> /etc/crio/crio.conf.d/11-default.conf
  curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
  sudo bash /var/run/oke-init.sh

  Beachten Sie, dass nofile=262144:262144 ein Beispiel ist. Setzen Sie nofile auf einen Wert, der für die Workload geeignet ist. Weitere Informationen zum Erstellen benutzerdefinierter Cloud-init-Initialisierungsskripte für die Einrichtung verwalteter Knoten finden Sie unter Benutzerdefinierte Cloud-init-Initialisierungsskripte verwenden.

• Problemumgehung 2: Führen Sie ein vorübergehendes Downgrade der im Knotenpool ausgeführten Kubernetes-Version auf Kubernetes-Version 1.32 durch, bis eine dauerhafte Auflösung verfügbar ist.

Details

Wenn Sie einen Kubernetes-Service vom Typ LoadBalancer oder einen Persistent Volume Claim (PVC) für ein von der Kubernetes Engine erstelltes Kubernetes-Cluster definieren, verläuft das Provisioning des entsprechenden Load Balancers oder Volumes möglicherweise nicht erfolgreich, wenn das Kubernetes-API-Endpunktsubnetz oder das Worker-Knotensubnetz die erforderlichen OCI-Serviceendpunkte nicht erreichen kann. Dieses Problem wird häufig durch eine falsche oder unvollständige VCN-Konfiguration verursacht, wie falsch konfigurierte Routentabellen, Sicherheitslisten oder Gateways (Internetgateways, NAT-Gateways, Servicegateways).

In einem von der Kubernetes Engine erstellten Cluster wird der Zugriff auf die Kubernetes-API über einen Kubernetes-API-Endpunkt bereitgestellt, der sich in einem Subnetz befindet, das Sie beim Erstellen des Clusters angeben. Dieser Endpunkt kann als öffentlich (mit einer öffentlichen IP-Adresse, die ihn über das Internet zugänglich macht) oder privat (ohne öffentliche IP-Adresse, sodass er nur über das VCN oder verbundene Netzwerke zugänglich ist) konfiguriert werden.

Bei Workloads, die von einer falschen Netzwerkkonfiguration betroffen sind, können Ereignisse wie:

Error syncing load balancer: failed to ensure load balancer: Get "https://network-load-balancer-api...": dial tcp ...:443: i/o timeout

oder

failed to provision volume with StorageClass "oci-bv": rpc error: code = Internal desc = failed to check existence of volume Get "https://iaas...": dial tcp ...:443: i/o timeout

Weitere Symptome können sein:

• Es konnte kein externer Load Balancer für einen Service vom Typ LoadBalancer bereitgestellt werden.
• Persistentes Volume für einen PVC mit dem CSI-Volume-Plug-in konnte nicht bereitgestellt werden.
• Fehler beim Starten von Cloud-Controller-Manager-(CCM-)Containern oder persistente Taints, die auf Knoten verbleiben (was die Planung von Workloads verhindern kann).

Weitere Informationen finden Sie in den relevanten Servicelogs (siehe Kubernetes Engine-(OKE-)Servicelogs anzeigen).

Hintergrund

Jedes VCN erfordert die korrekte Gatewaykonfiguration, um die Kommunikation zwischen Worker-Knoten (Compute-Instanzen) und anderen Netzwerken oder Services zu ermöglichen. Im Kontext von Kubernetes Engine stellt die richtige Gatewayauswahl sicher, dass sowohl der Kubernetes-API-Endpunkt als auch die Worker-Knoten Netzwerkzugriff für Cluster-Provisioning, Knotenvorgänge und Integration mit anderen OCI-Services haben.

Der Kubernetes-API-Endpunkt für ein Kubernetes-Cluster befindet sich in einem Subnetz, das Sie bei der Clustererstellung angeben, sodass Sie den Netzwerkzugriff auf den Endpunkt kontrollieren können. Die zugrunde liegende Kubernetes-Control Plane wird von Oracle außerhalb des Mandanten verwaltet und gehostet. In OCI wird ein Subnetz als öffentlich betrachtet, wenn die verknüpfte Routentabelle eine Regel enthält, die Traffic, der für 0.0.0.0/0 bestimmt ist, an ein Internetgateway weiterleitet. Wenn die Routentabelle eine solche Regel nicht enthält, wird das Subnetz als privat betrachtet.

Die primären Gatewayoptionen in einem VCN sind:

• Internetgateway (IGW): Ermöglicht Compute-Instanzen in öffentlichen Subnetzen den Zugriff auf das öffentliche Internet. Die Instanz muss eine öffentliche IP-Adresse aufweisen, und die Routentabelle des Subnetzes muss eine Regel enthalten, die 0.0.0.0/0 an das Internetgateway leitet.
• NAT-Gateway: Ermöglicht es Compute-Instanzen in privaten Subnetzen, ausgehende Internetverbindungen (z.B. für Betriebssystemupdates oder Packageinstallationen) zu initiieren, ohne dass sie eingehenden Internettraffic ausgesetzt werden. Instanzen, die das NAT-Gateway verwenden, benötigen keine öffentlichen IP-Adressen.
• Servicegateway (SGW): Ermöglicht Compute-Instanzen in privaten Subnetzen den Zugriff auf andere OCI-Services (wie Object Storage, Container Registry, Autonomous AI Database, Streaming und andere ausgewählte Services) über das interne Netzwerk von Oracle, ohne das öffentliche Internet zu durchlaufen.

Verwenden Sie kein Internetgateway und kein Servicegateway gemeinsam für dieselben OCI-Zielservices. Wenn Sie ein Internetgateway und ein Servicegateway als Routingoptionen zu demselben OCI-Service in einem VCN mischen, kann dies dazu führen, dass Traffic über den falschen Netzwerkpfad gesendet wird. Beispielsweise können Anforderungen für private OCI-Services über das öffentliche Internet über das Internetgateway und nicht über das Servicegateway weitergeleitet werden. Wenn Sie sowohl ein Internetgateway als auch ein Servicegateway als mögliche Routen verwenden, können Sie verhindern, dass der Kubernetes-API-Endpunkt oder die Worker-Knoten die erforderlichen privaten, sicheren Verbindungen zu OCI-Endpunkten herstellen. Dies führt zu Provisioning-Ausfällen, persistenten Verschmutzungen oder anderen Konnektivitätsproblemen innerhalb eines Clusters.

Stellen Sie daher sicher, dass Routentabellen für Subnetze, die von Worker-Knoten und dem Kubernetes-API-Endpunkt verwendet werden, Traffic eindeutig basierend auf dem Ziel an das entsprechende Gateway leiten. Stellen Sie für den Zugriff auf OCI-Services von privaten Subnetzen sicher, dass Routen Traffic explizit über ein Servicegateway und nicht über ein Internetgateway senden.

Beispiel: Wenn Sie ein Cluster erstellen und ein Subnetz für den Kubernetes-API-Endpunkt angeben und dem Endpunkt keine öffentliche IP-Adresse zuweisen, können Konnektivitätsprobleme auftreten. Wenn die Routentabelle auf einem Internetgateway basiert, greifen Worker-Knoten möglicherweise nicht auf wichtige OCI-Services zu. Infolgedessen kann der Container "cloud-controller-manager" möglicherweise nicht initialisiert werden, und Taints können auf den Knoten verbleiben. Sie können das Problem beheben, indem Sie ein NAT-Gateway oder ein Servicegateway konfigurieren, um den ordnungsgemäßen Zugriff auf OCI-Services sicherzustellen.

Workaround

Um Probleme bei der falschen Netzwerkkonfiguration zu beheben, stellen Sie sicher, dass Worker-Knoten mit OCI-Serviceendpunkten kommunizieren können, indem Sie Folgendes prüfen:

1. Überprüfen der Netzwerkkonfiguration. Prüfen Sie, ob VCN, Subnetze, Routentabellen und Sicherheitslisten den Anforderungen für das Deployment-Szenario entsprechen. Lesen Sie Beispielkonfigurationen für Netzwerkressourcen.

2. Gatewaykonfiguration prüfen:
   • Für öffentliche Kubernetes-API-Endpunkte (Kubernetes-API-Endpunkte mit einer öffentlichen IP-Adresse): Prüfen Sie, ob öffentliche IP-Adressen zugewiesen sind und ob erforderliche Routen zum Internetgateway vorhanden sind.
   • Für private Kubernetes-API-Endpunkte (Kubernetes-API-Endpunkte ohne öffentliche IP-Adresse): Prüfen Sie, ob ein Servicegateway für die Verbindung zu OCI-Services verwendet wird. Wenn von privaten Subnetzen aus Internetzugriff erforderlich ist, konfigurieren Sie ein NAT-Gateway (kein Internetgateway).
   • Vermeiden Sie doppelte Pfade: Leiten Sie nicht denselben OCI-Servicetraffic über ein Internetgateway und ein Servicegateway weiter.
3. Prüfen Sie die Routentabellenkonfiguration:
   • Prüfen Sie, ob die richtigen Routentabellen mit Worker-Knoten- und Kubernetes-API-Endpunktsubnetzen verknüpft sind.
   • Prüfen Sie, ob alle erforderlichen Routingregeln für Gateways vorhanden sind.
4. Prüfen Sie die Sicherheitslistenkonfiguration:
   • Prüfen Sie, ob die Regeln den erforderlichen Traffic zulassen.
   • Empfohlen: Verwenden Sie zustandsbehaftete statt zustandslose Regeln für Endpunktsubnetze.
5. Überprüfen Sie die DHCP-Optionen. Wenn Sie benutzerdefinierte DNS-Resolver verwenden, prüfen Sie, ob 169.254.169.254 als Eintrag in den DHCP-Optionen enthalten ist. Weitere Informationen finden Sie unter DHCP-Optionen.

Wenn das Problem durch Konfigurationsänderungen nicht behoben wird, prüfen Sie das Netzwerk anhand von Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment.

In Kubernetes-Version 1.34.1 wurden eine Reihe von Upstreamproblemen identifiziert, wie in diesem Abschnitt beschrieben. Diese Upstreamprobleme werden in Kubernetes-Version 1.34.2 behoben.

Bevor Sie Kubernetes-Cluster von einer früheren Version auf Version 1.34.1 upgraden, sollten Sie überlegen, ob sich Ihre Kubernetes-Umgebung auf die Upstreamprobleme auswirkt:

• Wenn Ihre Kubernetes-Umgebung Workloads ausführt, auf denen StatefulSets ausgeführt wird, prüfen Sie Kube-Controller-Manager: StatefulSet Spurious Rollout, das bei Control-Plane-Upgrades ausgelöst wird.
• Wenn Ihre Kubernetes-Umgebung auf Kubelet-Metriken basiert, lesen Sie Fehlende Metriken für kubelet_volume_stats_*.
• Wenn Ihre Kubernetes-Umgebung DRA-Ressourcen verwendet, prüfen Sie Kubelet Deadlock, wenn die DRA-Treiberverbindung im Leerlauf ist.

Wenn das Upgrade Ihrer Kubernetes-Umgebung von diesen Upstreamproblemen in Kubernetes-Version 1.34.1 betroffen wäre, wird in einigen Fällen empfohlen, das Upgrade nicht auszuführen. Führen Sie stattdessen Cluster mit Kubernetes-Version 1.33 (oder früher) aus, bis wir das Produktionsrelease von Kubernetes Engine, die Kubernetes-Version 1.34.2 unterstützt, bekannt geben, und dann Cluster auf Kubernetes-Version 1.34.2 upgraden.