Problèmes connus pour le moteur Kubernetes (OKE)

Les propriétés des nouveaux noeuds de travail démarrant dans un groupe de noeuds ne reflètent pas les dernières modifications apportées aux propriétés du groupe de noeuds. La cause probable est l'utilisation des attributs quantityPerSubnet et subnetIds obsolètes lors de l'utilisation de l'opération d'API UpdateNodePoolDetails permettant de mettre à jour les propriétés du groupe de noeuds.

Effectuez l'une des actions suivantes :

• Commencez par utiliser l'attribut nodeConfigDetails lors de l'utilisation de l'opération d'API UpdateNodePoolDetails. Premièrement, réglez le groupe de noeuds à 0 à l'aide de quantityPerSubnet. Puis, arrêtez d'utiliser les attributs subnetIds et quantityPerSubnet et utilisez plutôt l'attribut nodeConfigDetails.
• Communiquez avec Oracle Support pour redémarrer le composant dorsal responsable de la synchronisation (composant agent locataire).

Lorsque vous lancez le tableau de bord Kubernetes, les messages d'erreur "net/http : Temporisation d'établissement d'une liaison TLS" et "connexion réinitialisée par un pair" apparaissent parfois dans votre navigateur Web. Ce problème a été observé uniquement dans les grappes nouvellement créées exécutant la version1.11. de Kubernetes Pour plus d'informations sur un problème Kubernetes connexe, voir https://github.com/kubernetes/dashboard/issues/3038.

1. Dans une fenêtre de terminal, entrez :

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

2. Dans votre navigateur Web, allez à https://localhost:8443

Lorsque vous utilisez un jeton Kubeconfig version 2.0.0 pour accéder aux versions Helm/Tiller antérieures à 2.11, un des messages d'erreur suivants apparaît :

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

Mettez à niveau Helm/Tiller de la façon suivante :

1. Dans une fenêtre de terminal, téléchargez un jeton Kubeconfig version1.0.0 en entrant 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 spécifier le registre Oracle Cloud Infrastructure Registry dans la région de la grappe (voir Disponibilité par région). Par exemple, si la grappe se trouve dans la région États-Unis - Est (Ashburn), iad est la clé de la région à utiliser pour spécifier 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 à l'étape précédente.

4. Dans un navigateur, accédez à https://helm.sh/docs/using_helm/#installing-the-helm-client et suivez les instructions pour télécharger et installer le fichier binaire du client Helm.

5. Après avoir mis à niveau Helm/Tiller, téléchargez un jeton Kubeconfig version2.0.0 en entrant 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 incluait une amélioration de sécurité pour améliorer le chiffrement sur le kubelet s'exécutant sur les noeuds de travail du client. Les noeuds de travail créés entre le 20août2019 et le 16septembre2019 incluent cette configuration. Le nouveau jeu de chiffrements ne permet pas de se connecter au kubelet au moyen de http/2. Cette restriction a une incidence sur le serveur de mesures, ainsi que sur l'ajustement horizontal automatique de module de réseautage qui en dépend.

Pour chaque noeud de travail l'un après l'autre:

1. Empêchez les nouveaux modules de réseautage de démarrer et supprimez les modules de réseautage existants du noeud de travail en entrant kubectl drain <node_name>. Pour plus d'informations :

   • sur l'utilisation de kubectl, voir Accès à une grappe à l'aide de Kubectl
   • sur la commande drain, voir drain dans la documentation sur Kubernetes

   Recommandation : Utilisez les budgets d'interruption de pods de l'application pour faire en sorte qu'un nombre suffisant de répliques de pod s'exécutent pendant l'opération de drainage.

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

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

Lorsqu'un nouveau pod démarre sur un noeud de travail dans une grappe, dans certains cas, il ne peut pas monter tous les volumes attachés au noeud en raison de temporisations. Vous voyez un message similaire au 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 >]

Une des causes possibles identifiées pour ce problème est que la spécification de pod inclut un champ fsGroup dans le champ securityContext. Si le conteneur s'exécute sur un noeud de travail en tant qu'utilisateur non-racine, le réglage du champ fsGroup dans securityContext peut entraîner des temporisations en raison du nombre de fichiers auxquels Kubernetes doit apporter des modifications de propriété (voir https://github.com/kubernetes/kubernetes/issues/67014).

Si la spécification de pod n'inclut pas de champ fsgroup dans securityContext, la cause est inconnue.

Si la spécification de pod inclut le champ fsgroup dans securityContext et que le conteneur s'exécute comme utilisateur non-racine, envisagez les solutions de rechange suivantes :

• Supprimez le champ fsgroup de securityContext.
• Utilisez le champ supplementalGroups dans securityContext (au lieu de fsgroup), et réglez supplementalGroups sur l'identificateur de volume.
• Modifiez la spécification de pod pour que le conteneur s'exécute en tant que racine.

Si la spécification de pod n'inclut pas le champ fsgroup dans securityContext, ou si le conteneur est déjà en cours d'exécution en tant que racine, vous devez redémarrer ou remplacer le noeud de travail. 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 soit démarrée. Suivez les instructions sous Arrêt, démarrage ou redémarrage d'une instance ou sous Fin d'une instance, selon le cas, pour utiliser la console ou l'API. Vous pouvez également utiliser des commandes de l'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 travail, dérivé de la propriété Adresse IP privée de l'instance (par exemple, 10.0.10.5).

Lorsque vous utilisez le service de gestion du système d'exploitation pour gérer les mises à jour et les correctifs du système d'exploitation sur les instances Oracle Cloud Infrastructure, il existe des situations dans lesquelles les groupes de noeuds de grappe créés par Kubernetes Engine ne peuvent pas être mis en ligne.

Il existe deux solutions de rechange possibles :

• Solution de rechange 1 : Si vous voulez utiliser le service de gestion du système d'exploitation pour gérer les instances Oracle Cloud Infrastructure, activez Oracle Enterprise Linux dans le service de gestion du système d'exploitation. Voir Gestion des sources de logiciels.
• Solution de rechange 2 : Si vous ne voulez pas utiliser le service de gestion du système d'exploitation pour gérer les instances Oracle Cloud Infrastructure, assurez-vous qu'il n'existe aucune politique permettant l'exécution du service de gestion du système d'exploitation. Supprimez en particulier la politique qui accorde à un groupe dynamique d'instances l'accès au service de gestion du système d'exploitation. Voir Configuration des politiques pour le service de gestion de système d'exploitation.

/ # 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 si ce problème existe, ouvrez une fenêtre de terminal dans l'instance et exécutez la commande suivante :

sudo /usr/sbin/lsmod | grep br_netfilter 

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

Activez le module de noyau Bridge Netfilter. Ouvrez une fenêtre de terminal dans 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 du réseau de pod natif du VCN, l'adresse IP du client source des demandes entrantes à un pod peut ne pas être conservée comme prévu. En fait, les demandes entrantes reçues au moyen d'un service Kubernetes de type LoadBalancer pour lesquelles le fichier manifeste contient externalTrafficPolicy: Local peuvent être affichées comme provenant de l'adresse IP du noeud de travail.

Pour les demandes TCP entrantes reçues d'un service Kubernetes de type LoadBalancer qui comporte 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 du réseau de pods natif du VCN, les pods pourraient ne pas pouvoir communiquer sur le réseau si vous avez spécifié une forme sans système d'exploitation pour les noeuds de travail dans un ou plusieurs groupes de noeuds de la grappe.

Spécifiez une forme de machine virtuelle pour les noeuds de travail de chaque groupe de noeuds de la grappe lors de l'utilisation du réseau de pods natif de VCN.

Lors de l'utilisation du réseau de pods natif du VCN, le nombre maximal de pods par noeud de travail dans un groupe de noeuds peut être limité à 31, quel que soit le nombre d'OCPU que vous spécifiez pour la forme flexible que vous avez sélectionnée pour le groupe de noeuds.

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

Lors de l'utilisation du réseau de pods natif du VCN, les pods s'exécutant sur des noeuds de travail connectés à un sous-réseau de pod avec un bloc CIDR en dehors du premier bloc CIDR spécifié pour le VCN peuvent être incapables de communiquer avec les services Kubernetes.

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

Lors de l'utilisation du script Node Doctor pour résoudre les problèmes de noeud, le script peut afficher un message d'erreur d'exception similaire à ce qui suit :

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, produira une sortie de dépannage.

Nous sommes conscients du problème et travaillons à le résoudre. En attendant, si le script Node Doctor affiche le message Generating node doctor bundle, notez que la sortie de dépannage est toujours valide.

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

node-doctor.sh --update

Pour plus d'informations sur le script Node Doctor et sur la façon de le mettre à jour, voir Dépannage des problèmes de noeud pour les grappes Kubernetes à l'aide du script Node Doctor.

Si une grappe utilise un réseau de pod natif du VCN et a un pod de charge de travail et le pod CoreDNS s'exécutant sur le même noeud de travail, la résolution du DNS échoue parfois, car le trafic est incorrect sur NATed.

Sur 2023-03-21, une mise à jour du plugiciel CNI de réseau de pods natif du VCN OCI a été publiée pour résoudre ce problème. Suivez les instructions sous Mise à jour du plugiciel CNI de réseau de pods natif du réseau en nuage virtuel pour OCI pour déployer la mise à jour.

Si une grappe utilise un réseau de pods natif du VCN et comporte des noeuds de travail exécutant Oracle Linux 8 (OL8), les pods échouent parfois à démarrer sur l'un des noeuds de travail. Le problème présente les caractéristiques suivantes :

• Le noeud de travail exécute une image OL8.
• Les pods liés au réseau hôte s'exécutent comme prévu sur le noeud de travail, mais le démarrage de tous les autres pods échoue.
• Les journaux crictl contiennent le message Adding address to IPVLAN parent device (indiquant qu'une adresse IP est attachée à la carte vNIC secondaire du noeud de travail), suivi du message d'erreur Error adding secondary VNIC IP.
• L'exécution de la commande Linux ip address sur le noeud de travail montre qu'une ou plusieurs cartes vNIC secondaires n'ont pas d'adresse IP attachée.
• Tous les autres noeuds de travail (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 appareils et les connexions réseau. Dans certains cas, NetworkManager détache l'adresse IP attachée à une ou plusieurs cartes vNIC secondaires du noeud de travail, provoquant l'échec du plugiciel CNI de réseau de pods natif du réseau en nuage virtuel pour OCI.

Sur 2023-03-21, une mise à jour du plugiciel CNI de réseau de pods natif du VCN OCI a été publiée pour résoudre ce problème. Suivez les instructions sous Mise à jour du plugiciel CNI de réseau de pods natif du réseau en nuage virtuel pour OCI pour déployer la mise à jour.

Si vous avez spécifié Oracle Linux 8.7 ou Oracle Linux 8.8 pour un groupe 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 construite sur Oracle Linux 8.7 ou Oracle Linux 8.8), le statut des noeuds de travail du groupe de noeuds peut passer de manière inattendue à NotReady. Le problème présente les caractéristiques suivantes :

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

Nous sommes conscients du problème et travaillons à le résoudre.

En attendant, si vous rencontrez ce problème, utilisez les solutions de rechange suivantes qui répondent le mieux à vos besoins :

• Spécifiez une image Oracle Linux 7 pour le groupe de noeuds.
• Spécifiez une image Oracle Linux 8.6 (ou une image Oracle Linux 8 antérieure) pour le groupe de noeuds.
• Spécifiez une version ultérieure de Kubernetes pour le groupe de noeuds. (Les noeuds de travail exécutant Kubernetes version 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 :

• Images de plate-forme : Voir toutes les images Oracle Linux 7.x et toutes les images Oracle Linux 8.x
• Images de noeud de travail OKE : Voir Toutes les images Oracle Linux 7.x et Toutes les images Oracle Linux 8.x de noeud de travail OKE

Dans les grappes créées avant le 26 juin 2023 qui utilisent le réseau de pods natif du VCN, le provisionnement de nouveaux noeuds de travail peut être retardé.

Lors de l'amorçage des noeuds de travail avec le plugiciel CNI de réseau de pods natif du VCN OCI, Kubernetes Engine déploie une ressource personnalisée Kubernetes (ressource NativePodNetwork ou NPN) sur chaque instance de calcul. Lorsqu'un noeud de travail a été initialisé, le moteur Kubernetes donne le statut SUCCESS à la ressource NPN associée à l'instance de calcul.

Dans certains cas, si une instance de calcul est arrêtée avant que Kubernetes Engine ne donne le statut SUCCESS à la ressource NPN associée, la ressource NPN reste indéfiniment au statut BACKOFF ou IN_PROGRESS. L'existence de telles ressources " obsolètes " peut retarder le provisionnement de nouveaux noeuds de travail.

Le problème est résolu dans les grappes créées après 2023-06-26. Pour résoudre le problème dans les grappes créées avant 2023-06-26, effectuez une action ponctuelle pour supprimer les ressources périmées en suivant les instructions de cette section.

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

• l'interface de ligne de commande OCI est installée (voir Installation de l'interface de ligne de commande)
• l'interface de ligne de commande OCI est configurée (voir 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 politique IAM qui accorde au moins l'autorisation INSTANCE_READ, par exemple Allow group <group-name> to manage instance-family in <location> (voir Créer une politique requise pour les groupes)
• les fichiers kubeconfig appropriés sont accessibles pour vous permettre d'utiliser kubectl pour gérer les grappes qui utilisent le plugiciel CNI de réseau de pods natifs du VCN OCI (voir Accès à une grappe à l'aide de Kubectl)

Identifiez et supprimez les ressources périmées comme suit :

1. Vérifiez que votre système répond à tous les préalables :
   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 entrant :

      sh pre-req-check.sh

2. Identifiez les ressources NPN pouvant être supprimées car elles n'ont pas le statut SUCCESS :
   1. Générez une liste des ressources NPN qui n'ont pas le statut SUCCESS dans un fichier texte nommé potential_stale_resources.txt en entrant :

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

   2. Facultativement, consultez la liste des ressources NPN candidates dans potential_stale_resources.txt en entrant :

      cat potential_stale_resources.txt

      Par exemple, potential_stale_resources.txt peut contenir :

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

3. Identifiez les ressources NPN périmées à supprimer en déterminant quelles ressources NPN candidates sont associées à des instances de calcul qui ne sont pas disponibles ou qui ont été arrêtées :
   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 entrant :

      sh get_stale_resources.sh potential_stale_resources.txt

      Le script get_stale_resources.sh identifie les ressources NPN périmées à supprimer, retourne les messages de traitement à l'écran et écrit les noms des ressources NPN périmées 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. Facultativement, consultez la liste des ressources NPN obsolètes dans stale_resources.txt en entrant :

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

      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 retourne les messages de traitement à l'écran. Par exemple :

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

5. Comme bonne pratique d'entretien ménager, 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 s'exécutent sur les processeurs ARM.

Nous sommes conscients du problème et travaillons à le résoudre.

Dans l'intervalle, si vous rencontrez ce problème, ignorez la valeur de la propriété Architecture du noeud virtuel.

Lorsque Kubernetes Engine 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.

Par la suite, si vous utilisez la console, l'interface de ligne de commande ou l'API pour activer la protection de suppression pour l'équilibreur de charge, le gestionnaire cloud-controller-manager n'est pas seulement empêché de supprimer l'équilibreur de charge, mais ne peut pas non plus mettre à jour les propriétés de l'équilibreur de charge.

Nous sommes conscients du problème et travaillons à le résoudre.

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

Notez que 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, voir Définition des services Kubernetes de type LoadBalancer).

Les nouvelles versions du plugiciel CNI de réseau de pods natif du VCN OCI sont normalement publiées dans les domaines OC1, OC2 et OC3.

Toutefois, le 3 septembre 2024, le plugiciel CNI de réseau de pods OCI VCN-natif version 2.2.0, contenant des améliorations en matière de sécurité et de performance, a été publié dans le domaine OC1 uniquement.

Le 4 octobre 2024, le plugiciel CNI de réseau de pods OCI VCN-natif 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 nouvelles grappes que vous avez créées dans les domaines OC2 et OC3 ont utilisé la version antérieure du plugiciel CNI de réseau de pods natif du VCN OCI, à savoir la version 2.1.0.
• Dans le cas de grappes existantes dans les domaines OC2 et OC3, même si vous avez indiqué que vous vouliez qu'Oracle déploie automatiquement les mises à jour du plugiciel CNI de réseau de pods natif du VCN OCI sur une grappe, la version 2.2.0 n'a pas été déployée sur ces grappes.

Peu importe si vous ou Oracle êtes responsable du déploiement des mises à jour du plugiciel CNI de réseau de pods natif du VCN OCI, les mises à jour ne sont appliquées que lors du prochain redémarrage des noeuds de travail.

Par conséquent, vous pouvez avoir des grappes dans les domaines OC2 et OC3 qui exécutent toujours le plugiciel CNI de réseau de pods natif du VCN OCI version 2.1.0.

Pour bénéficier des améliorations apportées aux versions 2.2.0 et 2.2.2 du plugiciel CNI de réseau de pods natif du VCN OCI, nous vous recommandons fortement de mettre à jour toute grappe dans OC2 ou OC3 pour utiliser la version 2.2.2.

Le plugiciel CNI de réseau de pods OCI VCN-natif 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 plugiciel CNI de réseau de pods natif du VCN OCI pour une grappe améliorée dans le domaine OC2 ou OC3 et que vous spécifiez que vous voulez sélectionner la version du module complémentaire à 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 une grappe améliorée dans les domaines OC2 et OC3, sachez que les noeuds de travail ne seront pas affichés et que la grappe ne fonctionnera pas.

Pour plus d'informations, voir Utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI pour le service de réseau de pods.

Lorsque vous travaillez avec une grappe Kubernetes créée par Kubernetes Engine, vous remarquerez peut-être des retards inattendus lorsque la grappe interagit avec le serveur d'API Kubernetes (par exemple, des réponses lentes aux commandes kubectl).

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

Par défaut, le fichier kubeconfig créé par Kubernetes Engine pour une grappe contient une commande d'interface de ligne de commande OCI pour générer un jeton (commande OCI ce cluster generate-token). Le jeton est utilisé pour authentifier les demandes à kube-apiserver. 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 pourrait être touché par le problème connu de performance de l'interface de ligne de commande OCI.

Pour confirmer que la latence kube-apiserver est causée par le problème connu de performance 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é à la grappe en question. En supposant qu'aucune modification n'a été apportée au fichier kubeconfig pour utiliser un compte de service (voir 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 de l'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 confirmer que la latence kube-apiserver est causée par le problème de performance connu, utilisez la commande suivante pour retourner 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 performance connu.

Assurez-vous d'utiliser la dernière version stable de l'interface de ligne de commande OCI, ainsi qu'une version prise en charge de Python (voir Installation manuelle dans la documentation sur l'interface de ligne de commande OCI).

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

Si vous ne pouvez pas effectuer de mise à niveau vers une version Python plus récente, désactivez l'importation de tous les services (comportement par défaut) et n'importez sélectivement que 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, voir Activer les importations de services sélectifs pour Python 3.6.

Lorsque vous mettez à niveau un groupe de noeuds existant vers la version 1.33.1 de Kubernetes dans une grappe que vous avez créée à l'aide de Kubernetes Engine, vous remarquerez peut-être que les charges de travail précédemment exécutées avec succès rencontrent maintenant des problèmes et retournent des messages d'erreur tels que Too many open files.

Une cause possible est que dans les groupes de noeuds exécutant Kubernetes version 1.33.1, la limite ajustable par défaut pour les fichiers ouverts (ulimit nofile) dans les conteneurs a été réduite à 1024. Les charges de travail qui dépendaient implicitement d'une limite par défaut précédemment supérieure 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 CRI-O version 1.33, le paramètre LimitNOFILE n'est plus explicitement défini dans le fichier de service CRI-O systemd. Par conséquent, la limite ajustable par défaut systemd (généralement 1024) s'applique désormais aux fichiers ouverts dans les conteneurs. Pour plus de renseignements, consultez la page https://github.com/cri-o/cri-o/pull/8962.

Nous sommes conscients du problème et travaillons à le résoudre. En attendant, il existe deux solutions de rechange possibles :

• Solution de rechange 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. Réglez nofile à une valeur appropriée pour la charge de travail. Pour plus d'informations sur la création de scripts cloud-init personnalisés, voir Utilisation de scripts d'initialisation cloud-init personnalisés pour configurer des noeuds gérés.

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