Ajout de groupes de noeuds pour agrandir des grappes

Pour augmenter le nombre de groupes de noeuds dans la grappe à l'aide de la console :

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 bouton Ajouter un groupe de noeuds et augmentez la grappe en ajoutant des groupes de noeuds.
4. Entrez les détails du nouveau groupe de noeuds :
   • Nom : Nom de votre choix pour le nouveau groupe de noeuds. Évitez d'entrer des informations confidentielles.
   • compartiment : compartiment dans lequel créer le nouveau groupe de noeuds.
   • Type de noeud : Si le type de réseau de la grappe est Réseau de pod natif du réseau VCN, spécifiez le type des noeuds de travail dans ce groupe de noeuds (voir Noeuds virtuels et noeuds gérés). Sélectionnez une des options suivantes :
     • Géré : Sélectionnez cette option lorsque vous souhaitez être responsable de la gestion des noeuds de travail dans le groupe de noeuds. Noeuds gérés, exécutés sur des instances de calcul (sans système d'exploitation ou sur machine virtuelle) dans votre location. En tant que responsable de la gestion des nœuds gérés, vous avez la possibilité de les configurer en fonction de vos besoins spécifiques. Vous êtes responsable de la mise à niveau de Kubernetes sur les nœuds gérés et de la gestion de la capacité des grappes.
     • Virtuel : Sélectionnez cette option pour bénéficier d'une expérience Kubernetes sans serveur. Les noeuds virtuels vous permettent d'exécuter des pods Kubernetes à grande échelle sans la surcharge opérationnelle liée à la mise à niveau de l'infrastructure de plan de données et à la gestion de la capacité des grappes.

     Pour plus d'informations, voir Comparaison des noeuds virtuels avec des noeuds gérés.

   • Version : (Groupes de noeuds gérés uniquement) Version de Kubernetes à exécuter sur chaque noeud géré d'un groupe de noeuds géré. Par défaut, la version de Kubernetes spécifiée pour les noeuds de plan de contrôle est sélectionnée. 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 moteur Kubernetes (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.

5. Si le type de réseau de la grappe est Réseau de pod natif du réseau VCN et que vous avez sélectionné Géré comme Type de noeud ou si le type de réseau de la grappe est Surcouche de canal :

   1. Spécifiez les détails de configuration pour le groupe de noeuds gérés :

      • Configuration du positionnement des noeuds :
        • 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é, assurez-vous que la forme du noeud, le domaine de disponibilité et le domaine d'erreur dans la configuration de positionnement du groupe de noeuds correspondent 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 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 : La forme à 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 à 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 par défaut, 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.

      • Nombre de noeuds : Nombre de noeuds de travail à créer dans le groupe de noeuds, 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é.
      • 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 : Configurez la taille et les options de chiffrement pour le 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. Voir Chiffrement en transit pour plus d'informations sur le chiffrement en transit. 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, spécifiez comment 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.
        • 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.

        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 par défaut des options de groupe de noeuds avancés ou sélectionnez Afficher les options avancées et spécifiez les options de remplacement comme suit :

      • Cordon et drain : Spécifiez quand et comment cordoner et drainer les 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 : Script pour cloud-init à exécuter sur chaque instance 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).
      • Marqueurs de groupe de noeuds et Marqueurs de noeud : (Facultatif) Un ou plusieurs marqueurs à ajouter au groupe de noeuds et à calculer les instances 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.
      • Clé SSH publique : Partie de clé publique de la paire de clés à utiliser pour l'accès au moyen de SSH à chaque noeud 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)
6. Si vous avez sélectionné Virtuel comme type de noeud :
   1. Spécifiez les détails de configuration pour le groupe de noeuds virtuels :
      • 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 des domaines et des sous-réseaux supplémentaires 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.

      • Nombre de noeuds : Nombre 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 spécifique à un domaine de disponibilité spécifié pour chaque domaine de disponibilité.

      • Forme de pod : Forme à utiliser pour les pods s'exécutant sur des noeuds virtuels du groupe de noeuds virtuels. La forme détermine le type de processeur sur lequel exécuter le pod.

        Seules les formes disponibles dans votre location qui sont prises en charge par le moteur Kubernetes sont affichées. Voir Images (y compris les images personnalisées) et formes prises en charge pour les noeuds de travail.

        Notez que vous spécifiez explicitement les exigences en matière de ressources d'UC et de mémoire pour les noeuds virtuels dans la spécification des pods (voir Affecter des ressources de mémoire aux conteneurs et aux pods et Affecter des ressources d'UC aux conteneurs et aux pods dans la documentation sur Kubernetes).

      • Communication des noeuds virtuels :
        • Sous-réseau : Sous-réseau régional (recommandité) ou sous-réseau propre à un domaine de disponibilité configuré pour héberger les 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é). Voir Configuration des sous-réseaux.
        • 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 avec les pods : Les pods s'exécutant sur des noeuds virtuels utilisent le réseau de pods natif du VCN. Spécifiez comment les pods du groupe de noeuds communiquent entre eux à l'aide d'un sous-réseau de pods :
        • Sous-réseau : Sous-réseau régional 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é). Voir Configuration des sous-réseaux.
        • 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.

   2. Acceptez les valeurs par défaut des options de groupe de noeuds virtuels avancés ou sélectionnez Afficher les options avancées et spécifiez les options de remplacement comme suit :

      • Marqueurs de groupe de noeuds : (Facultatif) Un ou plusieurs marqueurs à ajouter au groupe de noeuds virtuels. 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.
      • É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, garantissant ainsi que les pods ne s'exécutent pas sur les nœuds virtuels d'un groupe de nœuds virtuels particulier. Notez que 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.

7. Sélectionnez Ajouter pour créer le nouveau groupe de noeuds.