Problèmes connus pour le moteur Kubernetes (OKE)

Détails

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.

Solution de rechange

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

Détails

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.

Solution de rechange

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

Détails

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"

Solution de rechange

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>

Détails

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.

Solution de rechange

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.

Détails

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.

Solution de rechange

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

Détails

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.

Solution de rechange

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.

Détails

Si le module de noyau Bridge Netfilter n'est pas activé, la communication du trafic avec localhost n'est pas acheminée correctement. Par exemple :

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

Solution de rechange

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'

Détails

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.

Solution de rechange

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.

Détails

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.

Solution de rechange

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.

Détails

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.

Solution de rechange

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.

Détails

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.

Solution de rechange

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

Détails

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.

Solution de rechange

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.

Détails

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.

Résolution

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.

Détails

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.

Résolution

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.

Détails

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.

Solution de rechange

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

Détails

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.

Résolution

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.

Détails

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.

Solution de rechange

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.

Détails

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.

Solution de rechange

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

Détails

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.

Solution de rechange

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.

Détails

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.

Solution de rechange

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.

Détails

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.

Solution de rechange

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.

Détails

Lorsque vous définissez un service Kubernetes de type LoadBalancer ou une revendication de volume persistant (PVC) pour une grappe Kubernetes créée par Kubernetes Engine, le provisionnement de l'équilibreur de charge ou du volume correspondant peut échouer si le sous-réseau de point d'extrémité de l'API Kubernetes ou le sous-réseau de noeuds de travail ne peut pas atteindre les points d'extrémité de service OCI requis. Ce problème est souvent causé par une configuration de VCN incorrecte ou incomplète, telle que des tables de routage mal configurées, des listes de sécurité ou des passerelles (passerelles Internet, passerelles NAT, passerelles de service).

Dans une grappe créée par Kubernetes Engine, l'accès à l'API Kubernetes est fourni au moyen d'un point d'extrémité d'API Kubernetes, qui réside dans un sous-réseau que vous spécifiez lors de la création de la grappe. Ce point d'extrémité peut être configuré en tant que point public (avec une adresse IP publique, ce qui le rend accessible à partir d'Internet) ou privé (sans adresse IP publique, ce qui le rend accessible uniquement à partir du VCN ou des réseaux connectés).

Les charges de travail affectées par une mauvaise configuration du réseau peuvent afficher des événements tels que :

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

ou

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

D'autres symptômes peuvent inclure :

• Échec du provisionnement d'un équilibreur de charge externe pour un service de type LoadBalancer.
• Échec du provisionnement d'un volume persistant pour une revendication de volume persistant à l'aide du plugiciel de volume CSI.
• Échecs de démarrage du conteneur Cloud-controller-manager (CCM) ou tentes persistantes restantes sur les noeuds (ce qui pourrait empêcher la programmation des charges de travail).

Pour plus d'informations, consultez les journaux de service pertinents (voir Consultation des journaux de service du moteur Kubernetes (OKE)).

Contexte

Chaque VCN nécessite une configuration de passerelle correcte pour permettre la communication entre les noeuds de travail (instances de calcul) et d'autres réseaux ou services. Dans le contexte du moteur Kubernetes, une sélection de passerelle appropriée garantit que le point d'extrémité de l'API Kubernetes et les noeuds de travail ont un accès réseau pour le provisionnement des grappes, les opérations de noeud et l'intégration avec d'autres services OCI.

Le point d'extrémité de l'API Kubernetes pour une grappe Kubernetes réside dans un sous-réseau que vous spécifiez lors de la création de la grappe, ce qui vous permet de contrôler l'accès réseau au point d'extrémité. Le plan de contrôle Kubernetes sous-jacent est géré et hébergé par Oracle en dehors de la location. Dans OCI, un sous-réseau est considéré comme public lorsque la table de routage associée contient une règle qui dirige le trafic destiné à 0.0.0.0/0 vers une passerelle Internet. Si la table de routage n'inclut pas une telle règle, le sous-réseau est considéré comme privé.

Les options de passerelle principale d'un VCN sont les suivantes :

• Passerelle Internet (IGW) : Permet aux instances de calcul des sous-réseaux publics d'accéder à l'Internet public. L'instance doit avoir une adresse IP publique et la table de routage du sous-réseau doit inclure une règle dirigeant 0.0.0.0/0 vers la passerelle Internet.
• Passerelle NAT : Permet aux instances de calcul de sous-réseaux privés de lancer des connexions Internet sortantes (par exemple, pour les mises à jour du système d'exploitation ou les installations d'ensemble) sans s'exposer au trafic Internet entrant. Les instances utilisant la passerelle NAT ne nécessitent pas d'adresses IP publiques.
• Passerelle de service (SGW) : Permet aux instances de calcul dans des sous-réseaux privés d'accéder à d'autres services OCI (tels que Stockage d'objets, Registre de conteneurs, Base de données d'IA autonome, Diffusion en continu et autres services sélectionnés) sur le réseau interne d'Oracle, sans passer par le réseau Internet public.

N'utilisez pas une passerelle Internet et une passerelle de service ensemble pour les mêmes services OCI cibles. La combinaison d'une passerelle Internet et d'une passerelle de service en tant qu'options de routage vers le même service OCI dans un VCN peut entraîner l'envoi du trafic sur un chemin réseau incorrect. Par exemple, les demandes destinées aux services OCI privés peuvent être acheminées sur le réseau Internet public au moyen de la passerelle Internet plutôt qu'au moyen de la passerelle de service. Le fait de disposer à la fois d'une passerelle Internet et d'une passerelle de service comme acheminements possibles peut empêcher le point d'extrémité de l'API Kubernetes ou les noeuds de travail d'établir les connexions privées et sécurisées nécessaires vers les points d'extrémité OCI, ce qui entraîne des échecs de provisionnement, des tintements persistants ou d'autres problèmes de connectivité au sein d'une grappe.

Par conséquent, assurez-vous que les tables de routage pour les sous-réseaux utilisés par les noeuds de travail et le point d'extrémité de l'API Kubernetes dirigent sans ambiguïté le trafic vers la passerelle appropriée en fonction de la destination. Pour accéder aux services OCI à partir de sous-réseaux privés, assurez-vous que les routes envoient le trafic explicitement au moyen d'une passerelle de service, et non d'une passerelle Internet.

Par exemple, si vous créez une grappe et spécifiez un sous-réseau pour le point d'extrémité de l'API Kubernetes et que vous n'affectez pas d'adresse IP publique au point d'extrémité, vous pourriez rencontrer des problèmes de connectivité. Si la table de routage repose sur une passerelle Internet, les noeuds de travail risquent de ne pas accéder aux services OCI essentiels. Par conséquent, le conteneur cloud-controller-manager peut ne pas s'initialiser et les taints peuvent rester sur les noeuds. Vous pouvez résoudre le problème en configurant une passerelle NAT ou une passerelle de service pour garantir un accès approprié aux services OCI.

Solution de rechange

Pour résoudre les problèmes de configuration incorrecte du réseau, assurez-vous que les noeuds de travail peuvent communiquer avec les points d'extrémité du service OCI en vérifiant les éléments suivants :

1. Vérifiez la configuration du réseau. Vérifiez que le VCN, les sous-réseaux, les tables de routage et les listes de sécurité respectent les exigences du scénario de déploiement. Voir Exemples de configurations de ressources de réseau.

2. Vérifiez la configuration de la passerelle :
   • Pour les points d'extrémité d'API Kubernetes publics (points d'extrémité d'API Kubernetes avec une adresse IP publique) : Vérifiez que les adresses IP publiques sont affectées et que les routes requises vers la passerelle Internet sont présentes.
   • Pour les points d'extrémité d'API Kubernetes privés (points d'extrémité d'API Kubernetes sans adresse IP publique) : Vérifiez qu'une passerelle de service est utilisée pour se connecter aux services OCI. Si un accès Internet est nécessaire à partir de sous-réseaux privés, configurez une passerelle NAT (et non une passerelle Internet).
   • Éviter les chemins doubles : N'achemine pas le même trafic de service OCI au moyen d'une passerelle Internet et d'une passerelle de service.
3. Vérifiez la configuration de la table de routage :
   • Vérifiez que les tables de routage appropriées sont associées aux sous-réseaux de noeuds de travail et de points d'extrémité d'API Kubernetes.
   • Vérifiez que toutes les règles de routage requises pour les passerelles sont présentes.
4. Vérifiez la configuration des listes de sécurité :
   • Vérifiez que les règles autorisent le trafic nécessaire.
   • Recommandé : Utilisez des règles avec état plutôt que sans état pour les sous-réseaux de point d'extrémité.
5. consultation des options DHCP; Lorsque vous utilisez des résolveurs DNS personnalisés, vérifiez que 169.254.169.254 est inclus en tant qu'entrée dans les options DHCP. Pour plus d'informations, voir Options DHCP.

Si les modifications de configuration ne résolvent pas le problème, vérifiez le réseau par rapport à la configuration des ressources de réseau pour la création et le déploiement de grappes.

Un certain nombre de problèmes en amont ont été identifiés dans Kubernetes version 1.34.1, comme décrit dans cette section. Ces problèmes en amont sont résolus dans Kubernetes version 1.34.2.

Avant de mettre à niveau des grappes Kubernetes vers la version 1.34.1 à partir d'une version antérieure, nous vous recommandons d'examiner si votre environnement Kubernetes sera touché par les problèmes en amont :

• Si votre environnement Kubernetes exécute des charges de travail exécutant StatefulSets, consultez Kube-Controller-Manager : déploiement non autorisé StatefulSet déclenché lors des mises à niveau du plan de contrôle.
• Si votre environnement Kubernetes repose sur des mesures de kubelet, consultez Mesures kubelet_volume_stats_* manquantes.
• Si votre environnement Kubernetes utilise des ressources d'évaluation du risque de livraison, consultez le blocage du cubelet lorsque la connexion au pilote d'évaluation du risque de livraison est inactive.

Si la mise à niveau de votre environnement Kubernetes est touchée par ces problèmes en amont dans Kubernetes version 1.34.1, dans certains cas, nous vous recommandons de ne pas effectuer la mise à niveau. Conservez plutôt les grappes exécutant Kubernetes version 1.33 (ou antérieure) jusqu'à ce que nous annonçons la version de production de Kubernetes Engine prenant en charge Kubernetes version 1.34.2, puis mettez à niveau les grappes vers Kubernetes version 1.34.2.