Ajout de pools de noeuds pour augmenter les clusters

Pour augmenter un cluster existant en augmentant le nombre de pools de noeuds dans le cluster à l'aide de la console, procédez comme suit :

1. Ouvrez le menu de navigation et sélectionnez Services de développeur. Sous Conteneurs et artefacts, sélectionnez Clusters Kubernetes (OKE).
2. Choisissez un compartiment sur lequel vous êtes autorisé à travailler.
3. Sur la page Liste des clusters, cliquez sur le nom du cluster à modifier.
4. Sous Ressources, cliquez sur Pools de noeuds.
5. Cliquez sur le bouton Ajouter un pool de noeuds et augmentez le cluster en ajoutant des pools de noeuds.
6. Entrez les détails du nouveau pool de noeuds :
   • Nom : nom de votre choix pour le nouveau pool de noeuds. Evitez de saisir des informations confidentielles.
   • compartiment : compartiment dans lequel créer le pool de noeuds.
   • Type de noeud : si le type de réseau du cluster est Réseau de pod natif VCN, indiquez le type de noeud de processus actif dans ce pool de noeuds (reportez-vous à Noeuds virtuels et noeuds gérés). Sélectionnez l'une des options suivantes :
     • Géré : sélectionnez cette option pour être responsable de la gestion des noeuds de processus actif dans le pool de noeuds. Noeuds gérés, exécutés sur des instances de calcul (bare metal ou machine virtuelle) dans votre location. En tant que responsable de la gestion des noeuds gérés, vous avez la possibilité de les configurer pour répondre à vos besoins spécifiques. Vous êtes responsable de la mise à niveau de Kubernetes sur les noeuds gérés et de la gestion de la capacité du cluster.
     • 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 clusters.

     Pour plus d'informations, reportez-vous à Comparaison de noeuds virtuels avec des noeuds gérés.

   • Version : (pools de noeuds gérés uniquement) version de Kubernetes à exécuter sur chaque noeud géré d'un pool de noeuds gérés. Par défaut, la version de Kubernetes indiquée pour les noeuds de plan de contrôle est sélectionnée. La version de Kubernetes sur les noeuds de processus actif doit être identique à celle sur les noeuds de plan de contrôle ou être une version antérieure toujours compatible. Reportez-vous à Versions Kubernetes et moteur Kubernetes (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.

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

   1. Indiquez les détails de configuration du pool de noeuds gérés :

      • Configuration de placement de noeud :
        • Domaine de disponibilité : domaine de disponibilité dans lequel les noeuds de processus actifs doivent être placés.
        • Sous-réseau de noeud de processus actif : sous-réseau régional (recommandé) ou sous-réseau propre à un domaine de disponibilité configuré pour héberger les noeuds de processus actifs. 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 que vous indiquez peuvent être privés (recommandé) ou publics. Reportez-vous à Configuration des services.
        • Domaines de pannes : (facultatif) domaines de pannes du domaine de disponibilité dans lesquels placer les noeuds de processus actif.

        Vous pouvez éventuellement cliquer sur 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é, assurez-vous que la forme de noeud, le domaine de disponibilité et le domaine de pannes dans la configuration de placement du pool de noeuds correspondent 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 cliquer sur Une autre ligne pour sélectionner des domaines et sous-réseaux supplémentaires dans lesquels placer les noeuds de processus actifs.

        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 à utiliser pour les noeuds de processus actif dans le pool de noeuds. 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 : image à utiliser sur les noeuds de processus actifs du pool de noeuds. 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 par défaut, cliquez sur 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 actif, avec toutes les configurations nécessaires et les logiciels requis. Sélectionnez une image OKE si vous voulez 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 voulez que Kubernetes Engine télécharge, installe et configure le logiciel 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

      • Nombre de noeuds : nombre de noeuds de processus actifs à créer dans le pool de noeuds. Ils sont placés dans les domaines de disponibilité sélectionnés, 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 les règles de sécurité dans le groupe de sécurité réseau : contrôlez l'accès au pool de noeuds à l'aide des règles de sécurité définies pour les groupes de sécurité réseau que vous indiquez (cinq au maximum). Vous pouvez utiliser les règles de sécurité définies pour les groupes de sécurité réseau plutôt que 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.

      • Volume d'initialisation : configurez les options de taille et de cryptage pour le 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 en transit. Si vous utilisez votre propre clé de cryptage du 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 du service Vault pour crypter les données de ce volume. Afin d'utiliser le service Vault pour répondre à vos besoins de cryptage, sélectionnez la case à cocher Crypter ce volume avec une clé gérée par vous-même. Sélectionnez le compartiment et le coffre contenant la clé de cryptage maître à utiliser, puis le compartiment et 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, indiquez comment 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 noeuds de processus actif 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é réseau plutôt que dans les listes de sécurité). Reportez-vous à Configuration des sous-réseaux.
        • Utiliser les règles de sécurité dans le 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 (cinq au maximum). Vous pouvez utiliser les règles de sécurité définies pour les groupes de sécurité réseau plutôt que 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 également cliquer sur 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 de 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 au moins trois cartes d'interface réseau virtuelles (une carte d'interface réseau virtuelle pour la connexion au sous-réseau de noeud de processus actif et au moins deux cartes d'interface réseau virtuelles pour la connexion 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 par défaut pour les options avancées de pool de noeuds, ou sélectionnez Afficher les options avancées et indiquez d'autres valeurs pour les paramètres suivants :

      • Cordon et purge : indiquez quand et comment connecter et purger les noeuds de processus actif avant de les mettre fin.

        • Délai de grâce d'expulsion (minutes) : durée de connexion et de purge des noeuds de processus actif avant leur terminaison. Acceptez la valeur par défaut (60 minutes) ou spécifiez une autre valeur. 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 pour connecter les noeuds de processus actifs et les vider de leurs charges globales. Pour mettre fin immédiatement aux noeuds de processus actif, sans les cordonner 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 section Monitoring Clusters.

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

      • Script d'initialisation : (facultatif) script cloud-init à exécuter sur chaque instance hébergeant des noeuds de processus actif lors du premier démarrage 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 faites-le glisser dans la zone.
        • Coller le script Cloud-Init : copiez le contenu d'un script cloud-init, puis collez-le dans la zone.

        Si vous n'avez pas encore écrit de scripts cloud-init pour initialiser les noeuds de processus actif dans les clusters créés par Kubernetes Engine, il peut être utile de cliquer sur 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 obtenir des exemples, reportez-vous à Exemples d'utilisation pour les 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).
      • Balises de pool de noeuds et Balises de noeud : (facultatif) balises à ajouter au pool de noeuds et 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 entre différents compartiments, ainsi que d'annoter des ressources avec vos propres métadonnées. Reportez-vous à Balisage des ressources liées à un cluster Kubernetes.
      • Clé SSH publique : (facultatif) partie clé publique de la paire de clés à utiliser pour l'accès SSH à chaque noeud dans le 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 fournit 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 de processus actifs dans les sous-réseaux privés (reportez-vous à Connecting to Managed Nodes in Private Subnets Using SSH).
8. Si vous avez sélectionné Virtuel comme type de noeud :
   1. Indiquez les détails de configuration du pool de noeuds virtuels :
      • Configuration de placement de noeud :
        • Domaine de disponibilité : domaine de disponibilité dans lequel les noeuds virtuels doivent être placés.
        • Domaines de pannes : (facultatif) domaines de pannes du domaine de disponibilité dans lesquels placer les noeuds virtuels.

        Vous pouvez également cliquer sur Une autre ligne pour sélectionner des domaines et des sous-réseaux supplémentaires 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é.

      • Nombre de noeuds : nombre de noeuds virtuels à créer dans le pool de noeuds virtuels. Ils sont placés dans les domaines de disponibilité sélectionnés, 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é.

      • Forme de pod : forme à utiliser pour les pods exécutés sur des noeuds virtuels dans le pool 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 Kubernetes Engine sont affichées. Reportez-vous à Images (images personnalisées comprises) et formes prises en charge pour les noeuds de processus actifs

        Notez que vous indiquez explicitement les besoins en ressources d'UC et de mémoire pour les noeuds virtuels dans la spécification de pod (reportez-vous à Affectation de ressources de mémoire aux conteneurs et pods et à Affectation de ressources d'UC aux conteneurs et pods dans la documentation Kubernetes).

      • Communication de noeud virtuel :
        • Sous-réseau : sous-réseau régional (recommandé) ou sous-réseau propre à un AD configuré pour héberger les noeuds virtuels. Si vous avez indiqué des sous-réseaux d'équilibreur de charge, les sous-réseaux de noeuds virtuels doivent être différents. Les sous-réseaux que vous indiquez peuvent être privés (recommandé) ou publics, régionaux (recommandé) ou propres à un AD. Nous recommandons que le sous-réseau de pod et le sous-réseau de noeuds virtuels soient le même sous-réseau (auquel cas, le sous-réseau de noeuds virtuels doit être privé). Reportez-vous à Configuration des services.
        • Utilisation de 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 des groupes de sécurité réseau que vous indiquez (jusqu'à cinq). Vous pouvez utiliser les règles de sécurité définies pour les groupes de sécurité réseau plutôt que 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 pods et les noeuds de processus actif.
      • Communication de pod : les pods exécutés sur des noeuds virtuels utilisent un réseau de pod natif VCN. Indiquez comment les pods du pool de noeuds communiquent entre eux à 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 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é). Reportez-vous à Configuration des services.
        • Utiliser les règles de sécurité dans le 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 (cinq au maximum). Vous pouvez utiliser les règles de sécurité définies pour les groupes de sécurité réseau plutôt que 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.

   2. Acceptez les valeurs par défaut pour les options avancées de pool de noeuds virtuels, ou cliquez sur Afficher les options avancées et indiquez d'autres valeurs pour les paramètres suivants :

      • Balises de pool de noeuds : (facultatif) balises à ajouter au pool de noeuds virtuels. Le balisage vous permet de regrouper des ressources disparates entre différents compartiments, ainsi que d'annoter des ressources avec vos propres métadonnées. Reportez-vous à Balisage des ressources liées à un cluster Kubernetes.
      • Libellés et taches Kubernetes : (facultatif) activez le ciblage des charges globales sur des pools de noeuds spécifiques en ajoutant des libellés et des taches aux noeuds virtuels :
        • Libellés : libellés (en plus du libellé par défaut) à ajouter aux noeuds virtuels du pool de noeuds virtuels pour permettre le ciblage des charges globales sur des pools de noeuds spécifiques.
        • Taches : taches à ajouter aux noeuds virtuels du pool de noeuds virtuels. Les peintures permettent aux nœuds virtuels de repousser les pods, ce qui garantit que les pods ne s'exécutent pas sur les nœuds virtuels d'un pool de nœuds virtuels particulier. Notez que vous pouvez uniquement appliquer des tâches aux noeuds virtuels.

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

9. Cliquez sur Ajouter pour créer le pool de noeuds.