Mise à jour d'un pool de noeuds gérés

Pour modifier les propriétés des pools de noeuds et des noeuds de processus actifs des clusters Kubernetes existants, procédez comme suit :

1. Sur la page de liste Clusters, sélectionnez le nom du cluster à modifier. Si vous avez besoin d'aide pour trouver la page de liste ou le cluster, reportez-vous à Liste des clusters.
2. Sous Ressources, sélectionnez Pools de noeuds.
3. Sélectionnez le nom du pool de noeuds à modifier.

4. L'onglet Détails du pool des noeuds permet d'afficher des informations relatives à ce pool, notamment :

   • statut du pool de noeuds,
   • OCID du pool de noeuds,
   • Type des noeuds de processus actif dans le pool de noeuds (gérés ou virtuels).
   • configuration actuellement utilisée lors du démarrage de nouveaux noeuds de processus actifs dans le pool de noeuds, dont les éléments suivants :
     • version de Kubernetes à exécuter sur les noeuds de processus actifs,
     • forme à utiliser pour les noeuds de processus actifs,
     • image à utiliser sur les noeuds de processus actifs.
   • domaines de disponibilité, domaines de pannes et différents sous-réseaux régionaux (recommandé) ou sous-réseaux propres à un domaine de disponibilité hébergeant des noeuds de processus actifs.

   Le type des noeuds de processus actifs dans le pool de noeuds (gérés ou virtuels) détermine les propriétés de pool de noeuds et de noeuds de processus actifs que vous pouvez modifier.

5. (Facultatif) Dans le cas d'un pool de noeuds gérés et de noeuds gérés, modifiez les propriétés comme suit :

   1. Sélectionnez Modifier et indiquez les éléments suivants :
      • Nom : autre nom pour le pool de noeuds. Evitez de saisir des informations confidentielles.

      • Version : autre version de Kubernetes à exécuter sur les nouveaux noeuds de processus actifs du pool de noeuds lors d'une mise à niveau avec réutilisation de la mémoire. La version de Kubernetes sur les noeuds d'processeur doit être identique sur celle des noeuds du plan de contrôle ou une version antérieure toujours compatible (reportez-vous àVersions deKubernetes et Kubernetes Engine (OKE)).

        Si vous indiquez une image OKE pour les noeuds de processus actif, la version de Kubernetes que vous sélectionnez ici doit être identique à la version de Kubernetes dans l'image OKE.

        Pour démarrer de nouveaux noeuds de processus actifs exécutant la version de Kubernetes indiquée, purgez les noeuds de processus actifs existants du pool de noeuds (afin d'empêcher le démarrage de nouveaux pods et de supprimer les pods existants), puis mettez fin à chacun d'entre eux successivement.

        Vous pouvez également spécifier une autre version de Kubernetes à exécuter sur les nouveaux noeuds de processus actifs en effectuant une mise à niveau sans réutilisation de la mémoire. Pour plus d'informations sur la mise à niveau des noeuds de processus actif, reportez-vous à Mise à niveau des noeuds gérés vers une version de Kubernetes plus récente.

      • Nombre de noeuds : nombre de noeuds différent dans le pool de noeuds. Reportez-vous à Redimensionnement de pools de noeuds.
      • Configuration de placement de noeud:
        • Domaine de disponibilité (Availability Domain) : domaine de disponible dans lequel les noeuds de processeurs doivent être placés.
        • Sous-réseau de noeud de processus actif : sous-réseau régional (recommandé) ou propre à un domaine de disponible configuré pour héberger les noeuds d'un processus actif. Si vous avez indiqué des sous-réseaux d'équilibreur de charge, les sous-réseaux de noeuds de processus actifs doivent être distincts. Les sous-réseaux spécifiés peuvent être privés (recommandé) ou publics. Reportez-vous à Configuration des sous-réseaux.
        • Domaines de pannes : (facultatif) domaines de pannes du domaine de disponibilité dans lesquels placer les noeuds de processus actif.

        Vous pouvez éventuellement sélectionner Afficher les options avancées pour indiquer le type de capacité à utiliser (reportez-vous à Gestion des types de capacité de noeud de processus actif). Si vous indiquez une réservation de capacité, notez que la forme du noeud, le domaine de disponibilité et le domaine de pannes dans la configuration de placement du pool de noeuds gérés doivent correspondre respectivement au type d'instance, au domaine de disponibilité et au domaine de pannes de la réservation de capacité. Reportez-vous à Utilisation de réservations de capacité pour provisionner des noeuds gérés.

        Vous pouvez éventuellement sélectionner Autre ligne pour sélectionner des domaines et sous-réseaux supplémentaires dans lesquels placer les nœuds de processus actif.

        Lors de la création des noeuds de processus actifs, ils sont répartis aussi uniformément que possible entre les domaines de disponibilité et les domaines de pannes sélectionnés. Si vous ne sélectionnez aucun domaine de pannes pour un domaine de disponibilité particulier, les noeuds de processus actifs sont répartis aussi uniformément que possible entre tous les domaines de pannes de ce domaine de disponibilité.

      • Forme de noeud : forme différente à utiliser pour les noeuds de processus actif du pool de noeud. La forme détermine le nombre d'UC et la quantité de mémoire alloués à chaque noeud.

        Seules les formes disponibles dans votre location qui sont prises en charge par Kubernetes Engine sont affichées.

        Si vous sélectionnez une forme flexible, vous pouvez spécifier explicitement le nombre d'UC et la quantité de mémoire.

        Reportez-vous à Images (images personnalisées comprises) et formes prises en charge pour les noeuds de processus actifs

      • Image : autre image à utiliser sur des noeuds de processus actif du pool de nœuds. Une image est un modèle de disque dur virtuel qui détermine le système d'exploitation et les autres logiciels pour un noeud.

        Pour modifier l'image, sélectionnez Modifier l'image. Dans la fenêtre Parcourir toutes les images, choisissez une source d'image et sélectionnez une image comme suit :

        • Images de noeud de processus actif OKE : recommandé. Fourni par Oracle et basé sur des images de plate-forme. Les images OKE sont optimisées pour servir d'images de base pour les noeuds de processus actifs, avec toutes les configurations nécessaires et les logiciels requis. Sélectionnez une image OKE pour réduire le temps nécessaire au provisionnement des noeuds de processus actif lors de l'exécution par rapport aux images de plate-forme et aux images personnalisées.

          Les noms d'image OKE incluent le numéro de version de la version de Kubernetes qu'ils contiennent. Si vous indiquez une version de Kubernetes pour le pool de noeuds, l'image OKE que vous sélectionnez ici doit avoir le même numéro de version que la version de Kubernetes du pool de noeuds.

        • Images de plate-forme : fournies par Oracle et contenant uniquement un système d'exploitation Oracle Linux. Sélectionnez une image de plate-forme si vous souhaitez que Kubernetes Engine télécharge, installe et configure les logiciels requis lors de la première initialisation de l'instance de calcul hébergeant un noeud de processus actif.

        Reportez-vous à Images (images personnalisées comprises) et formes prises en charge pour les noeuds de processus actifs

      • Utiliser des règles de sécurité dans le groupe de sécurité réseau : contrôlez l'accès au pool de noeuds à l'aide de règles de sécurité définies pour les groupes de sécurité réseau que vous indiquez (jusqu'à cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à spécifier pour le groupe de sécurité système, reportez-vous à la section Règles de sécurité pour les noeuds de processus actif.

      • Volume d'initialisation : modifiez la taille et les options de cryptage du volume d'initialisation du noeud de processus actif :

        • Afin de spécifier une taille personnalisée pour le volume d'initialisation, cochez la case Indiquer une taille personnalisée de volume d'initialisation. Ensuite, indiquez une taille personnalisée comprise entre 50 Go et 32 To. La taille indiquée doit être supérieure à la taille de volume d'initialisation par défaut de l'image sélectionnée. Pour plus d'informations, reportez-vous à Tailles de volume d'initialisation personnalisées.

          Notez que si vous augmentez la taille du volume d'initialisation, vous devez également étendre la partition du volume d'initialisation (partition racine) pour tirer parti de la taille supérieure. Reportez-vous à Extension de la partition pour un volume d'initialisation. Les images de plate-forme Oracle Linux incluent le package oci-utils. Vous pouvez utiliser la commande oci-growfs de ce package dans un script cloud-init personnalisé pour étendre la partition racine, puis développer le système de fichiers. Pour plus d'informations, reportez-vous à Extension de la partition racine des noeuds de processus actif.

        • Pour les instances de machine virtuelle, vous pouvez également cocher la case Utiliser le cryptage en transit. Pour les instances Bare Metal qui prennent en charge le cryptage en transit, ce dernier est activé par défaut et n'est pas configurable. Pour plus d'informations sur le cryptage en transit, reportez-vous à Cryptage de volume de blocs. Si vous utilisez votre propre clé de cryptage de service Vault pour le volume d'initialisation, celle-ci est également utilisée pour le cryptage en transit. Sinon, la clé de cryptage fournie par Oracle est utilisée.
        • Les volumes d'initialisation sont cryptés par défaut, mais vous pouvez éventuellement utiliser votre propre clé de cryptage de service Vault pour crypter les données de ce volume. Afin d'utiliser le service Vault pour répondre a vos besoins en matière de cryptage, cochez la case Crypter ce volume avec une clé administrée par vous-même. Sélectionnez le compartiment et le coffre de coffre contenant la clé de cryptage maître à utiliser, puis sélectionnez le compartiment et la clé de cryptage maître de la clé de cryptage maître. Si vous activez cette option, la clé est utilisée à la fois pour le cryptage des données au repos et pour le cryptage en transit.
          Important
          
          Le service Block Volume ne prend pas en charge le cryptage de volumes avec des clés cryptées à l'aide de l'algorithme RSA (Rivest-Shamir-Adleman). Lorsque vous utilisez vos propres clés, vous devez utiliser des clés cryptées à l'aide de l'algorithme AES (Advanced Encryption Standard). Cela s'applique aux volumes de blocs et d'initialisation.

        Pour utiliser votre propre clé de cryptage de service Vault afin de crypter les données, une stratégie IAM doit accorder l'accès à la clé de cryptage de service. Reportez-vous à Création d'une stratégie pour accéder aux clés de cryptage gérées par l'utilisateur pour le cryptage de volumes d'initialisation, de volumes de blocs et/ou de systèmes de fichiers.

      • Communication de pod : lorsque le type de réseau du cluster est réseau de pod natif VCN, modifiez la façon dont les pods du pool de noeuds communiquent les uns avec les autres à l'aide d'un sous-réseau de pod :
        • Sous-réseau : sous-réseau régional configuré pour héberger les pods. Le sous-réseau de pod que vous indiquez doit être privé. Dans certains cas, le sous-réseau de noeud de processus actif et le sous-réseau de pod peuvent être identiques (auquel cas, Oracle recommande de définir des règles de sécurité dans les groupes de sécurité réseau plutôt que dans les listes de sécurité). Reportez-vous à Configuration des sous-réseaux.
        • Groupe de sécurité réseau : contrôlez l'accès au sous-réseau de pod à l'aide de règles de sécurité définies pour des groupes de sécurité réseau que vous indiquez (jusqu'à cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à indiquer pour le groupe de sécurité réseau, reportez-vous à Règles de sécurité pour les noeuds de processus actif et les pods.

        Vous pouvez éventuellement sélectionner Afficher les options avancées pour indiquer le nombre maximal de pods à exécuter sur un seul noeud de processus actif dans un pool de noeuds, jusqu'à une limite de 110. La limite 110 est imposée par Kubernetes. Si vous voulez plus de 31 pods sur un seul noeud de processus actif, la forme que vous indiquez pour le pool de noeuds doit prendre en charge trois cartes d'interface réseau virtuelles ou plus (une carte d'interface réseau virtuelle pour se connecter au sous-réseau de noeud de processus actif et au moins deux cartes d'interface réseau virtuelles pour se connecter au sous-réseau de pod). Reportez-vous à Nombre maximal de cartes d'interface réseau virtuelles et de pods pris en charge par différentes formes.

        Pour plus d'informations sur la communication de pod, reportez-vous à la section Pod Networking.

   2. Acceptez les valeurs existantes pour les options de pool de noeuds avancées ou sélectionnez Afficher les options avancées et indiquez des alternatives comme suit :

      • Cordon et purge : modifiez le moment et le mode de saturation des noeuds de processus actif avant de les arrêter.

        • Délai de grâce d'éviction (minutes) : temps nécessaire pour autoriser le cordon et la purge des noeuds de processus actifs avant de les arrêter. Acceptez le paramètre par défaut (60 minutes) ou indiquez une autre option. Par exemple, lors de la réduction d'un pool de noeuds ou de la modification de sa configuration de placement, vous pouvez accorder 30 minutes aux noeuds de processus actif de cordon et les vider de leurs charges de travail. Pour mettre fin immédiatement aux noeuds de processus actifs, sans les raccorder ni les vider, indiquez 0 minute.
        • Forcer l'interruption après le délai de grâce : lors du remplacement de noeuds ou de la suppression de noeuds dans le pool de noeuds, si les noeuds de processus actif doivent être interrompus à la fin du délai de grâce d'expulsion, même s'ils n'ont pas été correctement cordonnés et purgés. Par défaut, cette option n'est pas sélectionnée.
        • Forcer l'action après la période de grâce : lors de l'exécution de tâches de maintenance sur les noeuds de processus actif (telles que la réinitialisation d'un noeud et le remplacement du volume d'initialisation d'un noeud), si l'action doit être effectuée à la fin de la période de grâce d'expulsion, même si le noeud de processus actif n'a pas été correctement cordonné et vidé. Par défaut, cette option n'est pas sélectionnée.

        Les pools de noeuds contenant des noeuds de processus actifs qui ne peuvent pas être arrêtés ou arrêtés pendant la période de grâce d'expulsion ont le statut Attention requise. Le statut de la demande de travail qui a lancé l'opération de fin de contrat est défini sur Echec et l'opération de fin de contrat est annulée. Pour plus d'informations, reportez-vous à la rubrique Surveillance des clusters.

        Pour plus d'informations, reportez-vous à la section Cordoning and Draining Managed Nodes Before Shut Down or Termination.

      • Script d'initialisation : (facultatif) script différent pour cloud-init à exécuter sur les instances hébergeant des noeuds de processus actif lors de la première initialisation de l'instance. Le script que vous spécifiez doit être écrit dans l'un des formats pris en charge par cloud-init (par exemple, cloud-config) et doit être un type de fichier pris en charge (par exemple, .yaml). Spécifiez le script comme suit :
        • Choisir un script Cloud-Init : sélectionnez un fichier contenant le script cloud-init, ou glissez-déplacez le fichier dans la zone.
        • Coller le script Cloud-Init : copiez le contenu d'un script cloud-init et collez-le dans la zone.

        Si vous n'avez pas encore écrit de scripts cloud-init pour l'initialisation des noeuds de processus actif dans les clusters créés par Kubernetes Engine, il peut être utile de sélectionner Télécharger le modèle de script cloud-init personnalisé en local. Le fichier téléchargé contient la logique par défaut fournie par Kubernetes Engine. Vous pouvez ajouter votre propre logique personnalisée avant ou après la logique par défaut, mais ne modifiez pas la logique par défaut. Pour obtenir des exemples, reportez-vous à Exemples d'utilisation de scripts Cloud-init personnalisés.

      • Libellés Kubernetes : (facultatif) libellés (en plus du libellé par défaut) à ajouter aux noeuds de processus actifs du pool de noeuds pour permettre le ciblage des charges globales sur des pools de noeuds spécifiques. Par exemple, pour exclure tous les noeuds d'un pool de noeuds de la liste des serveurs back-end d'un ensemble de back-ends d'équilibreur de charge, indiquez node.kubernetes.io/exclude-from-external-load-balancers=true (reportez-vous à node.kubernetes.io/exclude-from-external-load-balancers).
      • Clé SSH publique : (facultatif) autre partie clé publique de la paire de clés à utiliser pour l'accès SSH aux noeuds du pool de noeuds. La clé publique est installée sur tous les noeuds de processus actifs du cluster. Si vous n'indiquez pas de clé SSH publique, Kubernetes Engine en fournira une. Cependant, puisque vous n'aurez pas la clé privée correspondante, vous ne disposerez pas de l'accès SSH aux noeuds de processus actifs. Vous ne pouvez pas utiliser SSH pour accéder directement aux noeuds d'un processus actif dans des sous-réseaux privés (reportez-vous à la section Connexion aux noeuds gérés dans des sous-réseaux privés via SSH).
   3. Sélectionnez Enregistrer les modifications pour enregistrer les propriétés mises à jour.

6. (Facultatif) Dans le cas d'un pool de noeuds virtuels et de noeuds virtuels, modifiez les propriétés comme suit :

   1. Sélectionnez Modifier et indiquez les éléments suivants :
      • Nom : autre nom pour le pool de noeuds. Evitez de saisir des informations confidentielles.
      • Nombre de nœuds : nombre de nœuds virtuels à créer dans le pool des nœuds virtuels. Ils sont placés dans les domaines de disponibilités sélectionnés, dans le sous-réseau régional (recommandé) ou le Sous-réseau propre à un AD spécifié pour chaque domaine. Reportez-vous à Redimensionnement de pools de noeuds.
      • Configuration de placement de noeud:
        • Domaine de disponibilité : domaine de disponible dans lequel les noeuds virtuels doivent être placés.
        • Domaines de pannes : (facultatif) domaines de pannes dans le domaine de disponibilité dans lequel placer les noeuds virtuels.

        Vous pouvez éventuellement sélectionner Autre ligne pour sélectionner d'autres domaines et sous-réseaux dans lesquels placer des noeuds virtuels.

        Lors de la création des noeuds virtuels, ils sont répartis aussi uniformément que possible entre les domaines de disponibilité et les domaines de pannes sélectionnés. Si vous ne sélectionnez aucun domaine de pannes pour un domaine de disponibilité particulier, les noeuds virtuels sont répartis aussi uniformément que possible entre tous les domaines de pannes de ce domaine de disponibilité.

      • Communication de noeud virtuel:
        • Sous-réseau : sous-réseau régional différent (recommandé) ou propre à un domaine de disponibilité configuré pour héberger des noeuds virtuels. Si vous avez indiqué un sous-réseau d'équilibreur de charge, les sous-réseaux de noeuds virtuels doivent être distincts. Les sous-réseaux indiqués peuvent être privés (recommandé) ou publics, et peuvent être régionaux (recommandé) ou propres à un AD. Nous recommandons que le sous-réseau de pod et le sous-réseau de noeud virtuel soient le même sous-réseau (dans ce cas, le sous-réseau de noeud virtuel doit être privé). Pour plus d'informations, reportez-vous à Configuration de sous-réseau.
        • Utiliser des règles de sécurité dans le groupe de sécurité réseau : contrôlez l'accès au sous-réseau de noeud virtuel à l'aide de règles de sécurité définies pour les groupes de sécurité réseau que vous indiquez (jusqu'à cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à indiquer pour le groupe de sécurité réseau, reportez-vous à Règles de sécurité pour les noeuds de processus actif et les pods.
      • Communication de pod:
        • Sous-réseau : sous-réseau régional différent configuré pour héberger les pods. Le sous-réseau de pod que vous indiquez pour les noeuds virtuels doit être privé. Nous recommandons que le sous-réseau de pod et le sous-réseau de noeud virtuel soient le même sous-réseau (dans ce cas, Oracle recommande de définir des règles de sécurité dans les groupes de sécurité réseau plutôt que dans les listes de sécurité). Pour plus d'informations, reportez-vous à Configuration de sous-réseau.
        • Utilisation de règles de sécurité dans le groupe de sécurité réseau : contrôlez l'accès au sous-réseau du pod à l'aide de règles de sécurité définies pour les groupes de sécurité réseau que vous indiquez (jusqu'à cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à indiquer pour le groupe de sécurité réseau, reportez-vous à Règles de sécurité pour les noeuds de processus actif et les pods.

        Pour plus d'informations sur la communication de pod, reportez-vous à la section Pod Networking.

      • Etiquettes et taches Kubernetes : (facultatif) activez le ciblage des charges globales sur des pools de noeuds spécifiques en ajoutant des étiquettes et des taches aux noeuds virtuels :
        • Libellés : un ou plusieurs libellés (en plus d'un libellé par défaut) à ajouter aux noeuds virtuels du pool de noeuds virtuels pour permettre le ciblage des charges globales sur des pools de périphériques spécifiques.
        • Taches : une ou plusieurs taches à ajouter aux noeuds virtuels dans le pool de noeuds virtuels. Les taches permettent aux noeuds virtuels de repousser les pods, et ainsi de s'assurer que les pods ne s'exécutent pas sur les noeuds virtuels d'un pool de noeuds virtuels particulier. Vous ne pouvez appliquer des taches qu'aux noeuds virtuels.

        Pour plus d'informations, reportez-vous à Affectation de pods aux noeuds dans la documentation Kubernetes.

   2. Sélectionnez Enregistrer les modifications pour enregistrer les propriétés mises à jour.
7. Utilisez les onglets Balises de pool de noeuds et Balises de noeud pour ajouter ou modifier les balises appliquées au pool de noeuds, ainsi que les balises appliquées aux instances de calcul hébergeant des noeuds de processus actif dans le pool de noeuds. Le balisage vous permet de regrouper des ressources disparates dans différents compartiments et d'annoter les ressources avec vos propres métadonnées. Reportez-vous à Balisage des ressources liées à un cluster Kubernetes.
8. Sous Ressources :
   • Sélectionnez Noeuds pour visualiser des informations sur des noeuds des processus actifs spécifiques d'un pool de noeud géré. Eventuellement, modifiez les détails de configuration d'un noeud de processus actif spécifique, en sélectionnant son nom.
   • Sélectionnez Noeuds virtuels pour afficher des informations sur des noeuds de processus actifs spécifiques dans un pool de noeuds virtuels.
   • Sélectionnez Mesures pour surveiller l'état, la capacité et les performances d'un pool de noeuds gérés. Pour plus d'informations, reportez-vous à Mesures de Kubernetes Engine (OKE).
   • Sélectionnez Demandes de travail pour effectuer les opérations suivantes :
     • Obtenez les détails d'une demande de travail particulière pour la ressource de pool de noeuds.
     • Répertoriez les demandes de travail de la ressource de pool de noeuds.

     Pour plus d'informations, reportez-vous à la rubrique Affichage des demandes de travail.