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

Pour modifier les propriétés des groupes de noeuds et des noeuds de travail des grappes Kubernetes existantes :

1. Dans la page de liste Grappes, sélectionnez le nom de la grappe à modifier. Si vous avez besoin d'aide pour trouver la page de liste ou la grappe, voir Liste des grappes.
2. Sous Ressources, sélectionnez Groupes de noeuds.
3. Sélectionnez le nom du groupe de noeuds à modifier.

4. Utilisez l'onglet Détails du groupe de noeuds pour consulter des informations sur le groupe de noeuds, notamment les suivantes :

   • Statut du groupe de noeuds.
   • OCID du groupe de noeuds.
   • Type des noeuds de travail dans le groupe de noeuds (géré ou virtuel).
   • Configuration actuellement utilisée lors du démarrage de nouveaux noeuds de travail dans le groupe de noeuds, y compris :
     • La version de Kubernetes à exécuter sur les noeuds de travail
     • La forme à utiliser pour les noeuds de travail
     • L'image à utiliser pour les noeuds de travail
   • Domaines de disponibilité, domaines d'erreur et sous-réseaux régionaux ( recommandé) ou sous-réseaux propres à un domaine de disponibilité hébergeant des noeuds de travail.

   Le type de noeud de travail dans le groupe de noeuds (géré ou virtuel) détermine les propriétés que vous pouvez modifier.

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

   1. Sélectionnez Modifier et spécifiez :
      • Nom : Nom différent pour le groupe de noeuds. Évitez d'entrer des informations confidentielles.

      • Version : Autre version de Kubernetes à exécuter sur les nouveaux noeuds de travail du groupe de noeuds lors d'une mise à niveau sur place. La version de Kubernetes sur les noeuds de travail doit être la même que sur les noeuds de plan de contrôle, ou une version antérieure toujours compatible (voir Versions de Kubernetes et de Kubernetes Engine (OKE)).

        Notez que si vous spécifiez une image OKE pour les noeuds de travail, 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 travail exécutant la version de Kubernetes que vous spécifiez, exécutez la commande drain sur les noeuds de travail existants du groupe de noeuds (pour empêcher le démarrage de nouveaux pods et pour supprimer les pods existants), puis arrêtez chacun des noeuds de travail existants l'un après l'autre.

        Vous pouvez également spécifier une version différente de Kubernetes à exécuter sur les nouveaux noeuds de travail en effectuant une mise à niveau dans un nouveau répertoire de base. Pour plus d'informations sur la mise à niveau des noeuds de travail, voir Mise à niveau des noeuds gérés vers une nouvelle version de Kubernetes.

      • Nombre de noeuds : Nombre différent de noeuds dans le groupe de noeuds. Voir Ajustement des groupes de noeuds.
      • Configuration du positionnement du noeud :
        • Domaine de disponibilité : Domaine de disponibilité dans lequel placer les noeuds de travail.
        • sous-réseau de noeud de travail : Sous-réseau régional (recommandité) ou sous-réseau propre à un domaine de travail configuré pour héberger les noeuds de travail. Si vous avez spécifié des sous-réseaux d'équilibreurs de charge, les sous-réseaux de noeuds de travail doivent être différents. Les sous-réseaux que vous spécifiez peuvent être privés (recommandé) ou publics. Voir Configuration des sous-réseaux.
        • Domaines d'erreur : (Facultatif) Un ou plusieurs domaines d'erreur dans le domaine de disponibilité dans lequel placer les noeuds de travail.

        Facultativement, sélectionnez Afficher les options avancées pour spécifier un type de capacité à utiliser (voir Gestion des types de capacité des noeuds de travail). Si vous spécifiez une réservation de capacité, notez que la forme du noeud, le domaine de disponibilité et le domaine d'erreur dans la configuration de positionnement du groupe de noeuds gérés doivent correspondre respectivement au type d'instance, au domaine de disponibilité et au domaine d'erreur de la réservation de capacité. Voir Utilisation de réservations de capacité pour provisionner des noeuds gérés.

        Vous pouvez sélectionner Une autre rangée pour sélectionner des domaines et des sous-réseaux supplémentaires dans lesquels placer les noeuds de travail.

        Lorsque les noeuds de travail sont créés, ils sont répartis de manière aussi équitable que possible entre les domaines de disponibilité et les domaines d'erreur sélectionnés. Si vous ne sélectionnez aucun domaine d'erreur pour un domaine de disponibilité particulier, les noeuds de travail sont répartis de manière aussi équitable que possible entre tous les domaines d'erreur de ce domaine.

      • Forme de noeud : Forme différente à utiliser pour les noeuds de travail du groupe de noeuds. La forme détermine le nombre d'UC et la quantité de mémoire affecté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.

        Voir Images (y compris les images personnalisées) et formes prises en charge pour les noeuds de travail.

      • Image : Image différente à utiliser sur les noeuds de travail du groupe de noeuds. Une image est un modèle de disque dur virtuel qui détermine le système d'exploitation et les autres logiciels du noeud.

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

        • Images de noeud de travail 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 aux noeuds de travail, avec toutes les configurations et tous les logiciels requis. Sélectionnez une image OKE si vous voulez réduire le temps nécessaire au provisionnement des noeuds de travail au moment 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. Notez que si vous spécifiez une version de Kubernetes pour le groupe 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 groupe de noeuds.

        • Images de plate-forme : Fournies par Oracle et ne contiennent qu'un système d'exploitation Oracle Linux. Sélectionnez une image de plate-forme si vous voulez que Kubernetes Engine télécharge, installe et configure le logiciel requis lorsque l'instance de calcul hébergeant un noeud de travail démarre pour la première fois.

        Voir Images (y compris les images personnalisées) et formes prises en charge pour les noeuds de travail.

      • Utiliser des règles de sécurité dans le groupe de sécurité de réseau : Contrôlez l'accès au groupe de noeuds à l'aide de règles de sécurité définies pour un ou plusieurs groupes de sécurité de réseau que vous spécifiez (cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité de réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité de réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à spécifier pour le groupe de sécurité de réseau, voir Règles de sécurité pour les noeuds de travail.

      • Volume de démarrage : Modifiez la taille et les options de chiffrement du volume de démarrage du noeud de travail :

        • Pour spécifier une taille personnalisée pour le volume de démarrage, cochez la case Indiquer une taille de volume de démarrage personnalisée. Entrez ensuite une taille personnalisée comprise entre 50 Go et 32 To. La taille spécifiée doit être supérieure à la taille du volume de démarrage par défaut pour l'image sélectionnée. Pour plus d'informations, voir Tailles de volume de démarrage personnalisées.

          Notez que si vous augmentez la taille du volume de démarrage, vous devez également étendre la partition pour le volume de démarrage (partition racine) afin de tirer parti de la taille supérieure. Voir Extension de la partition pour un volume de démarrage. Les images de plate-forme Oracle Linux incluent l'ensemble oci-utils. Vous pouvez utiliser la commande oci-growfs de cet ensemble dans un script cloud-init personnalisé pour étendre la partition racine, puis développer le système de fichiers. Pour plus d'informations, voir Extension de la partition racine des noeuds de travail.

        • Pour les instances de machine virtuelle, vous pouvez facultativement cocher la case Utiliser le chiffrement en transit. Pour les instances sans système d'exploitation qui prennent en charge le chiffrement en transit, elles sont activées par défaut et ne sont pas configurables. Pour plus d'informations sur le chiffrement en transit, voir Chiffrement des volumes par blocs. Si vous utilisez votre propre clé de chiffrement du service Chambre forte pour le volume de démarrage, cette clé est alors également utilisée pour le chiffrement en transit. Sinon, la clé de chiffrement fournie par Oracle est utilisée.
        • Les volumes de démarrage sont chiffrés par défaut, mais vous pouvez utiliser votre propre clé de chiffrement du service Chambre forte pour chiffrer les données de ce volume. Pour utiliser le service de chambre forte pour vos besoins de chiffrement, sélectionnez la case à cocher Chiffrer ce volume avec une clé que vous gérez. Sélectionnez le compartiment de la chambre forte et la chambre forte qui contiennent la clé de chiffrement principale à utiliser, puis sélectionnez le compartiment de la clé de chiffrement principale et la clé de chiffrement principale. Si vous activez cette option, cette clé est utilisée à la fois pour le chiffrement des données au repos et le chiffrement en transit.
          Important
          
          Le service Volumes par blocs ne prend pas en charge le chiffrement des volumes avec des clés chiffrées à l'aide de l'algorithme RSA (Rivest-Shamir-Adleman). Lorsque vous utilisez vos propres clés, vous devez utiliser des clés chiffrées à l'aide de l'algorithme AES (Advanced Encryption Standard). Cela s'applique aux volumes par blocs et aux volumes de démarrage.

        Notez que pour utiliser votre propre clé de chiffrement du service de chambre forte pour chiffrer les données, une politique IAM doit accorder l'accès à la clé de chiffrement du service. Voir Créer une politique pour accéder aux clés de chiffrement gérées par l'utilisateur pour chiffrer les volumes de démarrage, les volumes par blocs ou les systèmes de fichiers.

      • Communication par pod : Lorsque le type de réseau de la grappe est Réseau de pod natif du VCN, modifiez la façon dont les pods du groupe 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 des pods. Le sous-réseau de pods que vous spécifiez doit être privé. Dans certaines situations, le sous-réseau du noeud de travail et le sous-réseau de pod peuvent être 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é de réseau plutôt que dans les listes de sécurité). Voir Configuration des sous-réseaux.
        • Groupe de sécurité de réseau : Contrôlez l'accès au sous-réseau de pods à l'aide des règles de sécurité définies pour un ou plusieurs groupes de sécurité de réseau que vous spécifiez (cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité de réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité de réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à spécifier pour le groupe de sécurité de réseau, voir Règles de sécurité pour les noeuds de travail et les pods.

        Facultativement, sélectionnez Afficher les options avancées pour spécifier le nombre maximal de pods à exécuter sur un seul noeud de travail d'un groupe de noeuds, jusqu'à une limite de 110. La limite de 110 est imposée par Kubernetes. Si vous voulez plus de 31 pods sur un seul noeud de travail, la forme que vous spécifiez pour le groupe de noeuds doit prendre en charge au moins trois cartes VNIC (une carte VNIC pour la connexion au sous-réseau du noeud de travail et au moins deux cartes VNIC pour la connexion au sous-réseau du pod). Voir Nombre maximal de cartes vNIC et de pods pris en charge par différentes formes.

        Pour plus d'informations sur la communication de pod, voir Réseau de pod.

   2. Acceptez les valeurs existantes pour les options de groupe de noeuds avancées ou sélectionnez Afficher les options avancées et spécifiez les autres options comme suit :

      • Cordon et drain : Modifiez le moment et le mode de cordon et de drainage des noeuds de travail avant de les mettre fin.

        • Période de grâce d'éviction (minutes) : Durée pendant laquelle vous pouvez cordonner et drainer les noeuds de travail avant de les mettre fin. Acceptez la valeur par défaut (60 minutes) ou spécifiez une autre valeur. Par exemple, lors de l'ajustement d'un groupe de noeuds ou de la modification de sa configuration de positionnement, vous pouvez accorder 30 minutes pour cordonner les noeuds de travail et les drainer de leurs charges de travail. Pour mettre fin immédiatement aux noeuds de travail, sans les cordonner et les drainer, spécifiez 0 minute.
        • Forcer la fin après le délai de grâce : Lors du remplacement ou de la suppression des noeuds du groupe de noeuds, indiquer s'il faut mettre fin aux noeuds de travail à la fin du délai de grâce d'expulsion, même s'ils n'ont pas été correctement cordonnés et drainés. Par défaut, cette option n'est pas sélectionnée.
        • Forcer l'action après le délai de grâce : Lors de l'exécution de tâches de maintenance sur les noeuds de travail (par exemple, redémarrage d'un noeud et remplacement du volume de démarrage d'un noeud), indiquer si l'action doit être effectuée à la fin du délai de grâce d'expulsion, même si le noeud de travail n'a pas été correctement cordonné et drainé. Par défaut, cette option n'est pas sélectionnée.

        Les groupes de noeuds contenant des noeuds de travail qui ne peuvent pas être arrêtés ou arrêtés au cours du délai de grâce d'expulsion ont le statut Attention requise. Le statut de la demande de travail qui a lancé l'opération d'arrêt est réglé à Échec et l'opération d'arrêt est annulée. Pour plus d'informations, voir Surveillance des grappes.

        Pour plus d'informations, voir Cordonage et drainage des noeuds gérés avant leur arrêt ou leur arrêt.

      • Script d'initialisation : (Facultatif) Script différent pour cloud-init à exécuter sur les instances hébergeant des noeuds de travail lorsque l'instance démarre pour la première fois. 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 :
        • Sélectionner le script Cloud-Init : Sélectionnez un fichier contenant le script cloud-init ou glissez-déposez 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 écrit auparavant de scripts cloud-init pour initialiser les noeuds de travail dans les grappes créées par Kubernetes Engine, il peut être utile de sélectionner Télécharger le modèle de script cloud-init personnalisé. 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 des exemples, voir Exemples de cas d'utilisation pour les scripts Cloud-init personnalisés.

      • Étiquettes Kubernetes : (Facultatif) Une ou plusieurs étiquettes (en plus d'une étiquette par défaut) à ajouter aux noeuds de travail du groupe de noeuds pour activer le ciblage des charges de travail sur des groupes de noeuds spécifiques. Par exemple, pour exclure tous les noeuds d'un groupe de noeuds de la liste des serveurs dorsaux d'un jeu dorsal d'équilibreur de charge, spécifiez node.kubernetes.io/exclude-from-external-load-balancers=true (voir node.kubernetes.io/exclude-from-external-load-balancers).
      • Clé SSH publique : Autre partie de la clé publique de la paire de clés à utiliser pour l'accès au moyen de SSH aux noeuds du groupe de noeuds (facultatif). La clé publique est installée sur tous les noeuds de travail de la grappe. Notez que si vous ne spécifiez pas de clé SSH publique, le moteur Kubernetes en fournira une. Cependant, comme vous ne disposerez pas de la clé privée correspondante, vous ne pourrez pas accéder aux noeuds de travail au moyen de SSH. Notez que vous ne pouvez pas utiliser SSH pour accéder directement aux noeuds de travail des sous-réseaux privés (voir Connexion aux noeuds gérés dans les sous-réseaux privés au moyen de SSH)
   3. Sélectionnez Enregistrer les modifications pour enregistrer les propriétés mises à jour.

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

   1. Sélectionnez Modifier et spécifiez :
      • Nom : Nom différent pour le groupe de noeuds. Évitez d'entrer des informations confidentielles.
      • Nombre de noeuds : Un nombre différent de noeuds virtuels à créer dans le groupe de noeuds virtuels, placés dans les domaines de disponibilité sélectionnés et dans le sous-réseau régional (recommandé) ou le sous-réseau propre à un domaine de disponibilité spécifié pour chaque domaine de disponibilité. Voir Ajustement des groupes de noeuds.
      • Configuration du positionnement des noeuds :
        • Domaine de disponibilité : Domaine de disponibilité dans lequel placer les noeuds virtuels.
        • Domaines d'erreur : (Facultatif) Un ou plusieurs domaines d'erreur dans le domaine de disponibilité dans lequel placer les noeuds virtuels.

        Facultativement, sélectionnez Autre rangée pour sélectionner d'autres domaines et sous-réseaux dans lesquels placer des noeuds virtuels.

        Lorsque les noeuds virtuels sont créés, ils sont répartis de manière aussi équitable que possible entre les domaines de disponibilité et les domaines d'erreur sélectionnés. Si vous ne sélectionnez aucun domaine d'erreur pour un domaine de disponibilité particulier, les noeuds virtuels sont répartis de manière aussi équitable que possible entre tous les domaines d'erreur de ce domaine.

      • Communication des noeuds virtuels :
        • Sous-réseau : Sous-réseau régional différent (recommandé) ou sous-réseau propre à un domaine de disponibilité configuré pour héberger des noeuds virtuels. Si vous avez spécifié des sous-réseaux d'équilibreurs de charge, les sous-réseaux de noeuds virtuels doivent être différents. Les sous-réseaux que vous spécifiez peuvent être privés (conseillé) ou publics, et être régionaux (conseillé) ou propres à un domaine de disponibilité. Nous recommandons que le sous-réseau de pod et le sous-réseau de noeud virtuel soient identiques (dans ce cas, le sous-réseau de noeud virtuel doit être privé). Pour plus d'informations, voir Configuration du sous-réseau.
        • Utiliser des règles de sécurité dans le groupe de sécurité de réseau : Contrôlez l'accès au sous-réseau de noeud virtuel à l'aide des règles de sécurité définies pour un ou plusieurs groupes de sécurité de réseau que vous spécifiez (cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité de réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité de réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à spécifier pour le groupe de sécurité de réseau, voir Règles de sécurité pour les noeuds de travail et les pods.
      • Communication des pods :
        • Sous-réseau : Sous-réseau régional différent configuré pour héberger des pods. Le sous-réseau de pods que vous spécifiez 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 identiques (dans ce cas, Oracle recommande de définir des règles de sécurité dans les groupes de sécurité de réseau plutôt que dans les listes de sécurité). Pour plus d'informations, voir Configuration du sous-réseau.
        • Utiliser des règles de sécurité dans le groupe de sécurité de réseau : Contrôlez l'accès au sous-réseau de pods à l'aide des règles de sécurité définies pour un ou plusieurs groupes de sécurité de réseau que vous spécifiez (cinq au maximum). Vous pouvez utiliser des règles de sécurité définies pour les groupes de sécurité de réseau au lieu de celles définies pour les listes de sécurité (les groupes de sécurité de réseau sont recommandés). Pour plus d'informations sur les règles de sécurité à spécifier pour le groupe de sécurité de réseau, voir Règles de sécurité pour les noeuds de travail et les pods.

        Pour plus d'informations sur la communication de pod, voir Réseau de pod.

      • Étiquettes et teintes Kubernetes : (Facultatif) Activez le ciblage des charges de travail sur des groupes de noeuds spécifiques en ajoutant des étiquettes et des teintes aux noeuds virtuels :
        • Étiquettes : Une ou plusieurs étiquettes (en plus d'une étiquette par défaut) à ajouter aux noeuds virtuels du groupe de noeuds virtuels pour activer le ciblage des charges de travail sur des groupes de noeuds spécifiques.
        • Taints : Une ou plusieurs teintes à ajouter aux noeuds virtuels du groupe de noeuds virtuels. Les couleurs permettent aux nœuds virtuels de repousser les pods, et ainsi de s'assurer que les pods ne s'exécutent pas sur les nœuds virtuels d'un groupe de nœuds virtuels particulier. Vous ne pouvez appliquer des teintes qu'aux noeuds virtuels.

        Pour plus d'informations, voir Affectation de pods à des noeuds dans la documentation sur Kubernetes.

   2. Sélectionnez Enregistrer les modifications pour enregistrer les propriétés mises à jour.
7. Utilisez l'onglet Marqueurs de groupe de noeuds et l'onglet Marqueurs de noeud pour ajouter ou modifier des marqueurs appliqués au groupe de noeuds, et des marqueurs appliqués aux instances de calcul hébergeant des noeuds de travail dans le groupe de noeuds. Le service de marquage vous permet de regrouper des ressources disparates dans différents compartiments et d'annoter des ressources avec vos propres métadonnées. Voir Marquage des ressources de grappe de Kubernetes.
8. Sous Ressources :
   • Sélectionnez Noeuds pour voir des informations sur des noeuds de travail spécifiques d'un groupe de noeuds gérés. Facultativement, modifiez les détails de configuration d'un noeud de travail donné en sélectionnant son nom.
   • Sélectionnez Noeuds virtuels pour voir des informations sur des noeuds de travail spécifiques dans un groupe de noeuds virtuels.
   • Sélectionnez Mesures pour surveiller l'état, la capacité et la performance d'un groupe de noeuds gérés. Pour plus d'informations, voir Mesures du moteur Kubernetes (OKE).
   • Sélectionnez Demandes de travail pour :
     • Obtenez les détails d'une demande de travail particulière pour la ressource de groupe de noeuds.
     • Répertoriez les demandes de travail pour la ressource de groupe de noeuds.

     Pour plus d'informations, voir Consultation des demandes de travail.