Bekannte Probleme bei der Kubernetes Engine (OKE)

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.

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.

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.

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

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"

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>

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.

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.

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.

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

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.

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.

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

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'

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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)
• Die entsprechenden kubeconfig-Dateien sind zugänglich, damit Sie mit kubectl Cluster verwalten können, die das CNI-Plug-in für OCI-VCN-native Podnetworking verwenden (siehe Mit Kubectl auf 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.

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.

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.

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.

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 zur Änderung von OCI-Load Balancern, die von der Kubernetes-Engine bereitgestellt werden, nicht empfohlen wird (weitere Informationen finden Sie unter Kubernetes-Services vom Typ LoadBalancer definieren).

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.

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 CNI-Plug-in für OCI-VCN-natives Podnetworking für Podnetworking verwenden.

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 und zeigen Sie die vom Client verwendete kubeconfig-Datei an. Suchen Sie im Abschnitt users der kubeconfig-Datei den Benutzer, der mit dem betreffenden Cluster verknüpft ist. Unter der Annahme, dass keine Änderungen an der kubeconfig-Datei zur Verwendung eines Serviceaccounts vorgenommen wurden (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.

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.

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.

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.