Documentation Oracle Cloud Infrastructure

Mise à niveau des noeuds gérés vers Kubernetes version 1.35 (ou ultérieure)

Découvrez comment mettre à niveau des noeuds gérés qui utilisent actuellement une image OKE OL7, une image de plate-forme OL7 ou une image personnalisée basée sur une image OL7 pour exécuter Kubernetes version 1.35 (ou ultérieure) et OL8, à l'aide de Kubernetes Engine (OKE).

Remarque

Cette section s'applique uniquement aux noeuds gérés. Pour plus d'informations sur la mise à niveau de noeuds autogérés, reportez-vous à Mise à niveau de noeuds autogérés vers une version de plus récente de Kubernetes en remplaçant un noeud autogéré existant.

A partir de la version 1.35 de Kubernetes, Kubernetes requiert les cgroups v2 pour la gestion des ressources de conteneur.

Les groupes de contrôle (cgroups) est une fonctionnalité du noyau Linux qui fournit un mécanisme de gestion et de contrôle de l'allocation des ressources pour les processus ou les groupes de processus. Les groupes de contrôle version 2 (cgroups v2) fournissent une hiérarchie de groupes de contrôle unique par rapport à laquelle tous les contrôleurs de ressources sont montés. Dans cette hiérarchie, vous pouvez coordonner l'utilisation des ressources entre différents contrôleurs de ressources.

Oracle Linux 7 (OL7) prend en charge les cgroups v1, mais ne prend pas en charge les cgroups v2. Oracle Linux 8 (OL8) et les versions ultérieures prennent en charge à la fois les cgroups v1 et les cgroups v2, mais les cgroups v2 ne sont pas toujours activés par défaut dans OL8.

En résumé, la version 1.35 de Kubernetes requiert donc OL8 (ou version ultérieure) avec les cgroups v2 activés.

Les groupes v2 sont activés par défaut dans les images OKE OL8 dont le numéro de build est supérieur ou égal à 1367. Toutefois, dans les images OKE OL8 dont le numéro de build est inférieur à 1367 (et dans les images de plate-forme OL8), cgroups v1 est activé par défaut.

Pour les noeuds de processus actif sur les clusters exécutant Kubernetes version 1.35 (et ultérieure), Kubernetes Engine prend en charge les images suivantes :

Dans les clusters exécutant Kubernetes version 1.35 (et versions ultérieures), l'utilisation d'images de plate-forme (images de plate-forme OL7 et d'images de plate-forme OL8) n'est pas recommandée. Nous vous recommandons vivement d'utiliser des images OKE pour tous les nouveaux déploiements et mises à niveau. Si vous souhaitez continuer à utiliser une image de plate-forme, créez une image personnalisée basée sur l'image de plate-forme et indiquez l'OCID de l'image personnalisée lors de la création ou de la mise à jour d'un pool de noeuds (notez que nous ne recommandons pas cette approche).

Lors de la mise à niveau des noeuds gérés qui utilisent actuellement une image OL8 vers la version 1.35 de Kubernetes (et versions ultérieures), notez les points suivants :

  • Vous pouvez mettre à niveau les noeuds gérés qui utilisent actuellement une image OKE OL8 (ou une image personnalisée basée sur une image OKE OL8) avec un numéro de build inférieur à 1367, en effectuant une mise à niveau sur place et en spécifiant une image OKE OL8 avec un numéro de build supérieur ou égal à 1367.
  • Vous pouvez mettre à niveau les noeuds gérés qui utilisent actuellement une image de plate-forme OL8 en effectuant une mise à niveau sur place et en indiquant une image OKE OL8 avec un numéro de build supérieur ou égal à 1367.
  • Vous pouvez effectuer des mises à niveau sur place des noeuds gérés qui utilisent actuellement une image OL8, que les groupes v2 soient déjà activés pour les noyaux Linux des instances de calcul hébergeant les noeuds.
  • Pour obtenir des instructions sur l'exécution de mises à niveau sur place, reportez-vous à Mise à niveau des noeuds gérés vers une nouvelle version de Kubernetes.
  • Pour plus d'informations sur l'introduction de la prise en charge de Kubernetes version 1.35, reportez-vous à OKE accueille Kubernetes 1.35 : nouveautés, changements et prochaines étapes.

Valider les charges de travail pour cgroups v2

Avant de mettre à niveau les noeuds de processus actif de production, vérifiez que les applications et les agents de prise en charge sont compatibles avec cgroups v2.

cgroups v2 peut modifier la façon dont la mémoire du conteneur est prise en compte. Une augmentation de l'utilisation de la mémoire de conteneur signalée seule n'indique pas nécessairement la saturation de la mémoire. Examinez une augmentation lorsqu'elle est accompagnée d'une ou plusieurs des conditions suivantes :

  • Interruptions OOM (Container Out-of-memory).
  • Le conteneur ou le pod redémarre.
  • Les expulsions de pod.
  • Condition de noeud MemoryPressure.

Pour plus d'informations sur les exigences de cgroups v2, la comptabilisation de la mémoire, la compatibilité d'exécution et la détermination de la version de cgroups utilisée par un noeud, reportez-vous à A propos de cgroup v2 dans la documentation Kubernetes.

Les exécutions d'application plus anciennes peuvent ne pas détecter correctement les limites de ressources de conteneur sur les systèmes qui utilisent cgroups v2. Par exemple, une application Java peut calculer la portion de mémoire ou d'autres paramètres de mémoire à partir des ressources du noeud de processus actif au lieu de la limite de mémoire du conteneur. Par conséquent, le conteneur peut dépasser sa limite de mémoire configurée et être arrêté par le module de tiroir de disques Linux OOM.

Pour les charges globales Java, utilisez l'une des versions de JDK suivantes ou une version ultérieure :

  • JDK 15
  • JDK 11.0.16
  • JDK 8u381

Le kit JDK 8u372 a introduit la prise de conscience de cgroups v2. Le kit JDK 8u381 inclut d'autres améliorations apportées à la détection de limite de ressource de cgroups v1 et cgroups v2, aux mesures de conteneur et à la stabilité des applications. Pour d'autres distributions JDK et exécutions d'application, consultez la documentation du fournisseur pour identifier une version qui prend en charge les cgroups v2.

Vérifiez également la compatibilité des agents de surveillance, de sécurité et autres qui accèdent directement à /sys/fs/cgroup. Mettez à jour les agents incompatibles avec les versions qui prennent en charge les cgroups v2.

Avant de mettre à niveau les noeuds de processus actif de production, effectuez la validation suivante dans un environnement hors production :

  1. Testez les charges de travail représentatives et les agents de support sur les noeuds qui utilisent cgroups v2.
  2. Comparez les informations suivantes avant et après l'activation de cgroups v2 :
    • Utilisation déclarée de la mémoire de conteneur
    • Evénements OOM de conteneur
    • Redémarrages du conteneur et du pod
    • Expulsions de pod
    • Condition de noeud MemoryPressure
    • Limite de mémoire détectée par l'exécution de l'application

  3. Pour les charges globales Java :

    • Enregistrez la version de JDK en saisissant ce qui suit :

      java -version

    • Vérifiez les paramètres système et de conteneur détectés par la JVM en saisissant ce qui suit : 

      java -XshowSettings:system -version

    • Configurez des valeurs explicites -Xms et -Xmx, le cas échéant, pour la charge globale.

Mettre à niveau les noeuds gérés OL7 pour exécuter Kubernetes version 1.35 (ou ultérieure)

Pour mettre à niveau des noeuds gérés qui utilisent actuellement une image OKE OL7, une image de plate-forme OL7 ou une image personnalisée basée sur une image OL7, afin d'exécuter Kubernetes version 1.35 (ou ultérieure), effectuez une mise à niveau sans réutilisation de la mémoire afin de remplacer le pool de noeuds existant par un nouveau pool de noeuds :

  1. Identifiez les pools de noeuds existants qui utilisent OL7 à l'aide de la console ou de l'interface de ligne de commande comme suit :

    • Utilisation de la console:

      1. Dans la page de liste Clusters, sélectionnez le nom du cluster contenant les pools de noeuds à afficher. Si vous avez besoin d'aide pour trouver la page de liste ou le cluster, reportez-vous à Liste des clusters.
      2. Sélectionnez l'onglet Pools de noeuds.
      3. Utilisez la colonne Nom d'image pour identifier les pools de noeuds qui utilisent des images Oracle-Linux-7.9.x.

    • Utilisation de l'interface de ligne de commande : identifiez les pools de noeuds existants qui utilisent OL7 en saisissant une commande semblable à la suivante :

      oci ce node-pool list --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --query 'data[*].{name:"name", image:"node-source"."image-id"}'

  2. Créez un pool de noeuds de remplacement qui utilise une image OL8 à l'aide de la console ou de l'interface de ligne de commande, comme suit :

    • Utilisation de la console:

      1. Dans l'onglet Pools de noeuds, sélectionnez Ajouter un pool de noeuds et entrez les détails du nouveau pool de noeuds.
      2. Sélectionnez une image de noeud de processus actif OKE basée sur une image Oracle Linux 8.x.
      3. Configurez le nouveau pool de noeuds avec la même forme, la même taille et le même emplacement que le pool de noeuds OL7.
      4. Choisissez Créer.

    • Utilisation de l'interface de ligne de commande : créez un pool de noeuds de remplacement qui utilise une image OL8 en saisissant une commande similaire à la suivante :

      oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name "nodepool-ol8-workers" --node-shape "VM.Standard.E4.Flex" --kubernetes-version "v1.35.0" --node-image-id <ol8-image-ocid> --size 3 --placement-configs '[{"availabilityDomain":"AD-1","subnetId":"<subnet-ocid>"}]'

  3. Connectez-vous aux noeuds OL7 :

    1. Obtenez les noms des noeuds OL7 en saisissant ce qui suit :

      kubectl get nodes -l node.kubernetes.io/os=ol7

    2. Cordonnez chaque nœud en entrant :

      kubectl cordon <node-name>

  4. Purgez les noeuds OL7 pour migrer progressivement les charges globales :

    1. Videz chaque noeud OL7 en saisissant la commande suivante :
      kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force
    2. Vérifiez que les charges globales ont été replanifiées sur les nouveaux noeuds en saisissant la commande suivante :
      kubectl get pods -A -o wide | grep <node-name>

  5. Supprimez le pool de noeuds OL7 à l'aide de la console ou de la CLI, comme suit :

    • Utilisation de la console:

      1. Dans l'onglet Pools de noeuds, sélectionnez Supprimer le pool de noeuds dans le menu Actions (trois points) en regard du pool de noeuds OL7.
      2. Cliquez sur Supprimer.
      3. Confirmez que vous souhaitez supprimer le pool de noeuds, puis sélectionnez Supprimer.

    • Utilisation de l'interface de ligne de commande : supprimez le pool de noeuds OL7 :

      oci ce node-pool delete --node-pool-id <ol7-nodepool-ocid>

  6. Mettez à niveau le cluster (par exemple, vers la version 1.35 de Kubernetes) :

    oci ce cluster update --cluster-id <cluster-ocid> --kubernetes-version "v1.35.0"

Pour plus d'informations, reportez-vous à la section Performing an Out-of-Place Managed Node Kubernetes Upgrade by Replacing an Existing Node Pool with a New Node Pool.