Problèmes connus pour Kubernetes Engine (OKE)

Les propriétés des nouveaux noeuds de processus actifs commençant dans un pool de noeuds ne reflètent pas les dernières modifications apportées aux propriétés du pool de noeuds. La cause probable est l'utilisation des attributs quantityPerSubnet et subnetIds en phase d'abandon lors de l'utilisation de l'opération d'API UpdateNodePoolDetails pour mettre à jour les propriétés du pool de noeuds.

Effectuez l'une des opérations suivantes :

• Commencez à utiliser l'attribut nodeConfigDetails lors de l'utilisation de l'opération d'API UpdateNodePoolDetails. Tout d'abord, redimensionnez le pool de noeuds sur 0 à l'aide de quantityPerSubnet. Ensuite, arrêtez d'utiliser les attributs subnetIds et quantityPerSubnet, et utilisez l'attribut nodeConfigDetails à la place.
• Contactez le support technique Oracle pour redémarrer le composant back-end responsable de la synchronisation (composant locataire-agent).

Lorsque vous lancez le tableau de bord Kubernetes, des messages d'erreur tels que "net/http : TLS handshake timeout" et "connection reset by peer" peuvent apparaître dans le navigateur Web. Ce problème n'a été observé que dans les clusters récemment créés exécutant Kubernetes version 1.11. Pour plus d'informations sur un problème lié à Kubernetes, reportez-vous à la page https://github.com/kubernetes/dashboard/issues/3038.

1. Dans une fenêtre de terminal, saisissez le code suivant :

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

2. Dans le navigateur Web, accédez à https://localhost:8443.

Si vous utilisez un jeton Kubeconfig version 2.0.0 pour accéder à des versions de Helm/Tiller antérieures à la version 2.11, vous recevez l'erreur suivante :

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

Mettez à niveau Helm/Tiller comme suit :

1. Dans une fenêtre de terminal, téléchargez un jeton Kubeconfig version 1.0.0 en saisissant la commande suivante :

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

2. Identifiez la clé de région à utiliser pour indiquer le registre Oracle Cloud Infrastructure Registry dans la région du cluster (reportez-vous à Disponibilité par région). Par exemple, si le cluster se trouve dans la région Est des Etats-Unis (Ashburn), iad est la clé de région à utiliser pour indiquer le registre dans cette région.

3. Mettez à niveau Tiller en entrant la commande suivante :

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

   où <region-key> est la clé que vous avez identifiée au cours de l'étape précédente.

4. Dans un navigateur, accédez à la page https://helm.sh/docs/using_helm/#installing-the-helm-client et suivez les instructions de téléchargement et d'installation du fichier binaire client Helm.

5. Une fois Helm/Tiller mis à niveau, téléchargez un jeton Kubeconfig version 2.0.0 en saisissant la commande suivante :

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

La version 1.8.0 de Kubernetes Engine a fait l'objet d'une amélioration de sécurité visant à améliorer l'efficacité du cryptage sur le kubelet exécuté sur les noeuds de processus actif client. Les noeuds de processus actif créés entre le 20 août 2019 et le 16 septembre 2019 incluent cette configuration. Le nouvel ensemble de cryptages n'autorise pas les connexions au kubelet via http/2. Cette restriction a un impact sur la fonctionnalité Metrics Server, ainsi que sur Horizontal Pod Autoscaler, qui dépend de Metrics Server.

Pour chaque noeud de processus actif existant, procédez comme suit :

1. Pour empêcher les nouveaux pods de démarrer et supprimer les pods existants sur le noeud de processus actif, entrez kubectl drain <node_name>. Pour plus d'informations :

   • Pour en savoir plus sur l'utilisation de kubectl, reportez-vous à Accès à un cluster à l'aide de kubectl.
   • Pour en savoir plus sur la commande drain, reportez-vous à drain dans la documentation Kubernetes.

   Recommandation : si besoin, utilisez les budgets alloués en cas de perturbation de pod pour votre application afin de garantir qu'un nombre suffisant de pods de réplique est exécuté pendant toute l'opération de purge.

2. Supprimez le noeud de processus actif (par exemple, en y mettant fin dans la console).
3. Attendez qu'un noeud de processus actif de remplacement démarre.

Les noeuds de processus actif de remplacement incluent de nouveaux paramètres pour permettre la communication avec le kubelet.

Lorsqu'un nouveau pod démarre sur un noeud de processus actif dans un cluster, dans certaines situations, ce dernier ne parvient pas à monter tous les volumes attachés au noeud en raison de délais d'expiration. Vous voyez alors un message tel que le suivant :

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

L'une des causes possibles de ce problème a été identifiée : il peut survenir si les spécifications du pod incluent un champ fsGroup dans le champ securityContext. Si le conteneur est exécuté sur un noeud de processus actif en tant qu'utilisateur non root, la définition du champ fsGroup dans le champ securityContext peut générer des délais d'expiration en raison du nombre de fichiers dans lesquels Kubernetes doit apporter des modifications de propriété (reportez-vous à https://github.com/kubernetes/kubernetes/issues/67014).

Si les spécifications du pod n'incluent pas de champ fsgroup dans securityContext, la cause est inconnue.

Si les spécifications du pod incluent le champ fsgroup dans securityContext et que le conteneur exécute un utilisateur non root, envisagez les solutions de contournement suivantes :

• Enlevez le champ fsgroup de securityContext.
• Utilisez le champ supplementalGroups dans securityContext (au lieu de fsgroup) et définissez supplementalGroups sur l'identificateur de volume.
• Modifiez les spécifications du pod pour que le conteneur soit exécuté en tant qu'utilisateur root.

Si les spécifications du pod n'incluent pas le champ fsgroup dans securityContext ou si le conteneur est déjà exécuté en tant qu'utilisateur root, vous devez redémarrer ou remplacer le noeud de processus actif. Par exemple, en arrêtant et en démarrant l'instance, en redémarrant l'instance ou en mettant fin à l'instance afin qu'une nouvelle instance démarre. Suivez les instructions indiquées dans Arrêt, démarrage ou redémarrage d'une instance ou Terminaison d'une instance, selon le cas, pour utiliser la console ou l'API. Vous pouvez également utiliser des commandes d'interface de ligne de commande, comme dans l'exemple suivant, pour mettre fin à une instance :

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

où <name> est le nom du noeud de processus actif, dérivé de la propriété Adresse IP privée de l'instance (par exemple, 10.0.10.5).

Lorsque vous utilisez le service OS Management pour gérer les patches et les mises à jour du système d'exploitation sur les instances Oracle Cloud Infrastructure, dans certains cas, la mise en ligne des pools de noeuds de cluster créés par Kubernetes Engine échoue.

Vous avez le choix entre deux solutions de contournement :

• Solution de contournement 1 : si vous voulez utiliser OS Management pour gérer les instances Oracle Cloud Infrastructure, activez Oracle Enterprise Linux dans OS Management. Reportez-vous à Gestion des sources logicielles.
• Solution de contournement 2 : si vous ne voulez pas utiliser OS Management pour gérer les instances Oracle Cloud Infrastructure, assurez-vous qu'il n'existe aucune stratégie autorisant l'exécution d'OS Management. En particulier, supprimez la stratégie qui accorde à un groupe dynamique d'instances un accès au service OS Management. Reportez-vous à Configuration de stratégies pour OS Management.

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

Pour vérifier ce problème, ouvrez une fenêtre de terminal sur l'instance et exécutez la commande suivante :

sudo /usr/sbin/lsmod | grep br_netfilter 

Si aucun résultat n'est renvoyé, le module de noyau Bridge NetFilter n'est pas activé. Le module de noyau Bridge NetFilter est requis afin de masquer le trafic VxLAN pour les pods Kubernetes.

Activez le module de noyau Bridge NetFilter. Ouvrez une fenêtre de terminal sur l'instance et exécutez les commandes suivantes :

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

Lors de l'utilisation de la mise en réseau de pod natif VCN, l'adresse IP du client source des demandes entrantes vers un pod peut ne pas être conservée comme prévu. A la place, les demandes entrantes reçues via un service Kubernetes de type LoadBalancer pour lequel le paramètre externalTrafficPolicy: Local est défini dans le fichier manifeste peuvent être affichées comme provenant de l'adresse IP du noeud de processus actif.

Pour les demandes TCP entrantes reçues via un service Kubernetes de type LoadBalancer avec l'annotation oci.oraclecloud.com/load-balancer-type: "lb" dans le fichier manifeste, obtenez l'adresse IP du client source à partir de l'en-tête X-Forwarded-For ou X-Real-IP.

Lors de l'utilisation d'une mise en réseau de pod native VCN, les pods peuvent ne pas pouvoir communiquer sur le réseau si vous avez spécifié une forme Bare Metal pour les noeuds de processus actif dans un ou plusieurs pools de noeuds du cluster.

Indiquez une forme de machine virtuelle pour les noeuds de processus actif dans chaque pool de noeuds du cluster lors de l'utilisation d'un réseau de pod natif VCN.

Lorsque vous utilisez une mise en réseau de pod native VCN, le nombre maximal de pods par noeud de processus actif dans un pool de noeuds peut être limité à 31, quel que soit le nombre d'OCPU que vous indiquez pour la forme flexible que vous avez sélectionnée pour le pool de noeuds.

Si vous voulez plus de 31 pods par noeud de travail dans un pool de noeuds, sélectionnez une autre forme pour les noeuds de travail du pool.

Lors de l'utilisation d'un réseau de pod natif VCN, les pods exécutés sur des noeuds de processus actif connectés à un sous-réseau de pod avec un bloc CIDR en dehors du premier bloc CIDR indiqué pour le VCN peuvent ne pas pouvoir communiquer avec les services Kubernetes.

Créez des sous-réseaux de pod avec des blocs CIDR dans le premier bloc CIDR spécifié pour le VCN.

Lorsque vous utilisez le script Node Doctor pour résoudre les problèmes de noeud, il peut afficher un message d'erreur d'exception semblable au suivant :

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

Le script Node Doctor continuera probablement à s'exécuter et, après avoir affiché le message Generating node doctor bundle, il générera une sortie de dépannage.

Nous avons connaissance du problème et travaillons à sa résolution. En attendant, si le script Node Doctor affiche le message Generating node doctor bundle, la sortie de dépannage reste valide.

Si vous ne voulez pas que le script Node Doctor affiche le message d'erreur d'exception FileNotFoundError: [Errno 2]..., mettez-le à jour en saisissant la commande suivante :

node-doctor.sh --update

Pour plus d'informations sur le script Node Doctor et sa mise à jour, reportez-vous à Dépannage des problèmes de noeud pour les clusters Kubernetes à l'aide du script Node Doctor.

Si un cluster utilise un réseau de pod natif VCN et dispose à la fois d'un pod de charge globale et du pod CoreDNS exécuté sur le même noeud de processus actif, la résolution DNS échoue parfois car le trafic est incorrectement NATed.

Sur 2023-03-21, une mise à jour du module d'extension CNI OCI VCN-Native Pod Networking a été publiée pour résoudre ce problème. Suivez les instructions indiquées dans Mise à jour du module d'extension CNI de fonctions de réseau de pod natif de réseau cloud virtuel OCI pour déployer la mise à jour.

Si un cluster utilise un réseau de pod natif VCN et que des noeuds de processus actif exécutent Oracle Linux 8 (OL8), il arrive que les pods ne parviennent pas à démarrer sur l'un des noeuds de processus actif. Le problème présente les caractéristiques suivantes :

• Le noeud de processus actif exécute une image OL8.
• Les pods liés au réseau hôte sont exécutés comme prévu sur le noeud de processus actif mais tous les autres pods ne parviennent pas à démarrer.
• Les journaux crictl contiennent le message Adding address to IPVLAN parent device (indiquant qu'une adresse IP est attachée à la carte d'interface réseau virtuelle secondaire du noeud de processus actif), suivi du message d'erreur Error adding secondary VNIC IP.
• L'exécution de la commande Linux ip address sur le noeud de processus actif montre qu'aucune adresse IP n'est attachée aux cartes d'interface réseau virtuelles secondaires.
• Tous les autres noeuds de processus actif (ou la plupart d'entre eux) fonctionnent comme prévu.

La cause probable identifiée pour ce problème est liée à NetworkManager, qui gère les connexions et les périphériques réseau. Dans certains cas, NetworkManager détache l'adresse IP attachée aux cartes d'interface réseau virtuelles secondaires du noeud de processus actif, ce qui entraîne l'échec du module d'extension CNI de fonctions de réseau de pod natif de réseau cloud virtuel OCI.

Sur 2023-03-21, une mise à jour du module d'extension CNI OCI VCN-Native Pod Networking a été publiée pour résoudre ce problème. Suivez les instructions indiquées dans Mise à jour du module d'extension CNI de fonctions de réseau de pod natif de réseau cloud virtuel OCI pour déployer la mise à jour.

Si vous avez spécifié Oracle Linux 8.7 ou Oracle Linux 8.8 pour un pool de noeuds (en sélectionnant une image de plate-forme Oracle Linux 8.7 ou Oracle Linux 8.8, ou une image de noeud de travail OKE reposant sur Oracle Linux 8.7 ou Oracle Linux 8.8), le statut des noeuds de travail du pool de noeuds peut passer de manière inattendue à NotReady. Le problème présente les caractéristiques suivantes :

• Les noeuds de processus actif exécutent Oracle Linux 8.7 ou Oracle Linux 8.8.
• Les noeuds de processus actif exécutent Kubernetes version 1.24.1, 1.25.4 ou 1.26.2. (Les noeuds de processus actif exécutant Kubernetes versions 1.25.12, 1.26.7 et 1.27 ne sont pas affectés.)
• Les pods à courte durée de vie sont fréquemment déployés sur les noeuds de processus actif.
• Les pods déployés sur les noeuds de processus actif du pool de noeuds peuvent également rester au statut ContainerCreating plus longtemps que prévu.

Nous avons connaissance du problème et travaillons à sa résolution.

En attendant, si vous rencontrez ce problème, utilisez l'une des solutions de contournement suivantes selon vos exigences :

• Indiquez une image Oracle Linux 7 pour le pool de noeuds.
• Indiquez une image Oracle Linux 8.6 (ou une image Oracle Linux 8 antérieure) pour le pool de noeuds.
• Indiquez une version ultérieure de Kubernetes pour le pool de noeuds. (Les noeuds de processus actif exécutant Kubernetes versions 1.25.12, 1.26.7 et 1.27 ne sont pas affectés.)

Pour obtenir les OCID des images qui n'apparaissent plus dans la console, procédez comme suit :

• Images de plate-forme : reportez-vous à toutes les images Oracle Linux 7.x et à toutes les images Oracle Linux 8.x.
• Images de noeud de processus actif OKE : reportez-vous à Toutes les images Oracle Linux 7.x de noeud de processus actif OKE et à Toutes les images Oracle Linux 8.x de noeud de processus actif OKE

Dans les clusters créés avant le 26 juin 2023 qui utilisent un réseau de pod natif VCN, le provisionnement des nouveaux noeuds de processus actifs peut être retardé.

Lors de l'initialisation des noeuds de processus actif avec le module d'extension CNI OCI VCN-Native Pod Networking, Kubernetes Engine déploie une ressource personnalisée Kubernetes (ressource NativePodNetwork ou NPN) sur chaque instance de calcul. Lorsqu'un noeud de processus actif a été initialisé, Kubernetes Engine attribue le statut SUCCESS à la ressource NPN associée à l'instance de calcul.

Dans certains cas, si une instance de calcul prend fin avant que Kubernetes Engine n'attribue le statut SUCCESS à la ressource NPN associée, la ressource NPN reste dans un statut BACKOFF ou IN_PROGRESS indéfiniment. L'existence de telles ressources obsolètes peut retarder le provisionnement de nouveaux noeuds de processus actif.

Le problème est résolu dans les clusters créés après 2023-06-26. Pour résoudre le problème dans les clusters créés avant 2023-06-26, effectuez une action unique pour supprimer les ressources obsolètes en suivant les instructions de cette section.

Avant de commencer, assurez-vous que votre système répond aux prérequis suivants :

• l'interface de ligne de commande OCI est installée (reportez-vous à Installation de l'interface de ligne de commande)
• l'interface de ligne de commande OCI est configurée (reportez-vous à Configuration de l'interface de ligne de commande)
• jq a été téléchargé et installé (voir https://jqlang.github.io/jq/download/)
• Il existe une stratégie IAM qui accorde au moins le droit d'accès INSTANCE_READ, tel que Allow group <group-name> to manage instance-family in <location> (reportez-vous à Création d'une stratégie requise pour les groupes)
• les fichiers kubeconfig appropriés sont accessibles pour vous permettre d'utiliser kubectl afin de gérer les clusters qui utilisent le module d'extension CNI de mise en réseau de pod natif OCI VCN (reportez-vous à Accès à un cluster à l'aide de Kubectl)

Identifiez et supprimez les ressources obsolètes comme suit :

1. Vérifiez que votre système répond à tous les prérequis :
   1. Enregistrez le script suivant dans un fichier nommé 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. Exécutez le script pre-req-check.sh en saisissant la commande suivante :

      sh pre-req-check.sh

2. Identifiez les ressources NPN susceptibles d'être supprimées car elles n'ont pas le statut SUCCESS :
   1. Affichez la liste des ressources NPN qui n'ont pas le statut SUCCESS dans un fichier texte nommé potential_stale_resources.txt en saisissant la commande suivante :

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

   2. Vous pouvez éventuellement afficher la liste des ressources NPN candidates dans potential_stale_resources.txt en saisissant ce qui suit :

      cat potential_stale_resources.txt

      Par exemple, potential_stale_resources.txt peut contenir :

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

3. Identifiez les ressources NPN obsolètes à supprimer en déterminant quelles ressources NPN candidates sont associées à des instances de calcul qui ne sont pas disponibles ou qui ont pris fin :
   1. Enregistrez le script suivant dans un fichier nommé 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. Exécutez le script get_stale_resources.sh en saisissant la commande suivante :

      sh get_stale_resources.sh potential_stale_resources.txt

      Le script get_stale_resources.sh identifie les ressources NPN obsolètes à supprimer, génère des messages à l'écran et écrit les noms des ressources NPN obsolètes dans un fichier nommé stale_resources.txt. Par exemple :

      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. Vous pouvez éventuellement afficher la liste des ressources NPN obsolètes dans stale_resources.txt en saisissant ce qui suit :

      cat stale_resources.txt

      Par exemple, stale_resources.txt peut contenir :

      anyhqljth4...snq
      anyhqljth4...qhq

4. Supprimez les ressources NPN obsolètes répertoriées dans le fichier stale_resources.txt :
   1. Enregistrez le script suivant dans un fichier nommé 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. Exécutez le script delete_stale_resources.sh en saisissant la commande suivante :

      sh delete_stale_resources.sh stale_resources.txt

      Le script delete_stale_resources.sh supprime les ressources NPN obsolètes répertoriées dans le fichier stale_resources.txt et génère des messages de traitement à l'écran. Par exemple :

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

5. En tant que bonne pratique de gestion interne, supprimez les fichiers stale_resources.txt et potential_stale_resources.txt que vous avez créés précédemment.

Lorsque vous spécifiez une forme Arm pour un noeud virtuel, les pods programmés sur le noeud s'exécutent sur les processeurs Arm comme prévu. Toutefois, si vous examinez le noeud virtuel à l'aide de la commande kubectl describe node ou de l'API Kubernetes, la propriété Architecture du noeud indique AMD64, même si les pods programmés sur le noeud sont exécutés sur des processeurs Arm.

Nous avons connaissance du problème et travaillons à sa résolution.

En attendant, si vous rencontrez ce problème, ignorez la valeur de la propriété Architecture du noeud virtuel.

Lorsque le moteur Kubernetes provisionne un équilibreur de charge OCI pour un service Kubernetes de type LoadBalancer, la protection de suppression n'est pas activée pour l'équilibreur de charge.

Si vous utilisez ensuite la console, l'interface de ligne de commande ou l'API pour activer la protection de suppression pour l'équilibreur de charge, Cloud-controller-manager est non seulement empêché de supprimer l'équilibreur de charge, mais ne peut pas mettre à jour les propriétés de l'équilibreur de charge.

Nous avons connaissance du problème et travaillons à sa résolution.

En attendant, n'utilisez pas la console, l'interface de ligne de commande ou l'API pour activer la protection de suppression pour un équilibreur de charge.

L'utilisation de la console, de l'interface de ligne de commande ou de l'API pour modifier les équilibreurs de charge OCI provisionnés par Kubernetes Engine n'est pas recommandée (pour plus d'informations, reportez-vous à Définition de services Kubernetes de type LoadBalancer).

Les nouvelles versions du module d'extension CNI de mise en réseau de pod natif OCI VCN sont normalement publiées dans les domaines OC1, OC2 et OC3.

Cependant, le 3 septembre 2024, le module d'extension CNI OCI VCN-Native Pod Networking version 2.2.0, contenant des améliorations en matière de sécurité et de performances, a été publié dans le domaine OC1 uniquement.

Le 4 octobre 2024, le module d'extension CNI OCI VCN-Native Pod Networking version 2.2.2 a été publié dans les domaines OC1, OC2 et OC3, contenant d'autres améliorations.

Par conséquent, entre le 3 septembre 2024 et le 4 octobre 2024 :

• Les nouveaux clusters que vous avez créés dans les domaines OC2 et OC3 ont utilisé la version précédente du module d'extension CNI OCI VCN-Native Pod Networking, à savoir la version 2.1.0.
• Dans le cas de clusters existants dans les domaines OC2 et OC3, même si vous aviez indiqué qu'Oracle devait déployer automatiquement des mises à jour vers le module d'extension CNI OCI VCN-Native Pod Networking sur un cluster, la version 2.2.0 n'a pas été déployée sur ces clusters.

Que vous ou Oracle soyez responsable du déploiement des mises à jour du module d'extension CNI OCI VCN-Native Pod Networking, les mises à jour sont appliquées uniquement lors du prochain redémarrage des noeuds de processus actif.

Par conséquent, vous pouvez avoir des clusters dans les domaines OC2 et OC3 qui exécutent encore le module d'extension CNI OCI VCN-Native Pod Networking version 2.1.0.

Pour bénéficier des améliorations apportées aux versions 2.2.0 et 2.2.2 du module d'extension CNI de mise en réseau de pod natif OCI VCN, nous vous recommandons vivement de mettre à jour n'importe quel cluster dans OC2 ou OC3 pour utiliser la version 2.2.2.

Le module d'extension CNI de mise en réseau de pod natif OCI VCN version 2.2.0 ne sera pas publié dans les domaines OC2 et OC3, même si vous pouvez sélectionner la version 2.2.0 dans la console.

Si vous activez le module d'extension CNI OCI VCN-Native Pod Networking pour un cluster amélioré dans le domaine OC2 ou OC3 et que vous indiquez que vous souhaitez choisir la version de l'extension à déployer, ne sélectionnez pas la version 2.2.0. Sélectionnez plutôt la version 2.2.2 (ou ultérieure). Si vous sélectionnez la version 2.2.0 pour un cluster amélioré dans les domaines OC2 et OC3, sachez que les noeuds de processus actif ne s'afficheront pas et que le cluster ne fonctionnera pas.

Pour plus d'informations, reportez-vous à Utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN pour le réseau de pod.

Lorsque vous travaillez avec un cluster Kubernetes créé par Kubernetes Engine, vous pouvez remarquer des retards inattendus lorsque le cluster interagit avec le serveur d'API Kubernetes (tels que des réponses lentes aux commandes kubectl).

Si vous utilisez un ordinateur client avec une ancienne version de l'interface de ligne de commande OCI et/ou Python installée, ces pics intermittents de latence kube-apiserver peuvent être dus à un problème connu de performances de l'interface de ligne de commande OCI. Ce problème de performance a été observé avec Python version 3.6 spécifiquement.

Par défaut, le fichier kubeconfig créé par Kubernetes Engine pour un cluster contient une commande d'interface de ligne de commande OCI permettant de générer un jeton (commande OCI ce cluster generate-token). Le jeton est utilisé pour authentifier les demandes à l'adaptateur kube. Actuellement, chaque demande kube-apiserver déclenche un appel de l'interface de ligne de commande OCI pour exécuter la commande de génération du jeton. C'est cet appel de l'interface de ligne de commande OCI qui peut être affecté par le problème connu de performances de l'interface de ligne de commande OCI.

Pour vérifier que la latence de kube-apiserver est due au problème connu de performances de l'interface de ligne de commande OCI, localisez et affichez le fichier kubeconfig utilisé par le client. Dans la section users du fichier kubeconfig, localisez l'utilisateur associé au cluster en question. En supposant qu'aucune modification n'a été apportée au fichier kubeconfig pour utiliser un compte de service (reportez-vous à Ajout d'un jeton d'authentification de compte de service à un fichier Kubeconfig), la section user contient la commande de génération de jeton d'interface de ligne de commande OCI au format yaml suivant :

- 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: []

Pour vérifier que la latence de kube-apiserver est due au problème de performances connu, utilisez la commande suivante pour renvoyer le temps nécessaire à l'interface de ligne de commande OCI pour exécuter la commande de génération de jeton :

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

Si le temps nécessaire à l'exécution de la commande est proche de la latence kube-apiserver que vous avez observée, vous rencontrez peut-être le problème de performances connu.

Assurez-vous que vous utilisez la dernière version stable de l'interface de ligne de commande OCI, ainsi qu'une version prise en charge de Python (reportez-vous à Installation manuelle dans la documentation de l'interface de ligne de commande OCI).

Si vous utilisez Python version 3.6, nous vous recommandons de mettre à niveau vers une version plus récente de Python.

Si vous ne pouvez pas effectuer la mise à niveau vers une version plus récente de Python, désactivez l'import de tous les services (comportement par défaut) et importez plutôt de manière sélective uniquement les services et modules individuels requis. L'importation sélective de services est connue pour améliorer les performances de Python version 3.6. Pour plus d'informations, reportez-vous à Activation des imports de service sélectif pour Python 3.6.

Lorsque vous mettez à niveau un pool de noeuds existant vers la version 1.33.1 de Kubernetes dans un cluster que vous avez créé à l'aide de Kubernetes Engine, vous pouvez constater que les charges globales précédemment exécutées rencontrent désormais des problèmes et renvoient des messages d'erreur tels que Too many open files.

Une cause possible est que dans les pools de noeuds exécutant Kubernetes version 1.33.1, la limite logicielle par défaut pour les fichiers ouverts (ulimit nofile) dans les conteneurs a été réduite à 1024. Les charges de travail qui dépendent implicitement d'une limite par défaut précédemment plus élevée peuvent donc rencontrer des problèmes.

La limite ajustable par défaut pour les fichiers ouverts (ulimit nofile) dans les conteneurs a été réduite à 1024 en raison d'une modification de l'exécution du conteneur CRI-O. Kubernetes version 1.33.1 utilise CRI-O version 1.33. Dans la version 1.33 de CRI-O, le paramètre LimitNOFILE n'est plus explicitement défini dans le fichier de service systemd CRI-O. Par conséquent, la limite logicielle par défaut systemd (généralement 1024) s'applique désormais aux fichiers ouverts dans les conteneurs. Pour plus d'informations, reportez-vous à https://github.com/cri-o/cri-o/pull/8962.

Nous avons connaissance du problème et travaillons à son résolution. En attendant, deux solutions de contournement sont possibles :

• Solution 1 : créez un script cloud-init personnalisé pour augmenter ulimit nofile. Par exemple :

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

  Notez que nofile=262144:262144 est un exemple. Définissez nofile sur une valeur appropriée pour la charge globale. Pour plus d'informations sur la création de scripts d'initialisation cloud-init personnalisé, reportez-vous à Utilisation de scripts d'initialisation cloud-init personnalisé pour configurer des noeuds gérés.

• Solution 2 : réduisez temporairement la version de Kubernetes exécutée sur le pool de noeuds à la version 1.32 de Kubernetes, jusqu'à ce qu'une résolution permanente soit disponible.