Utilisation des noeuds autogérés
Découvrez comment configurer et utiliser des noeuds autogérés avec Kubernetes Engine.
Un noeud autogéré est un noeud de processus actif hébergé sur une instance de calcul (ou un pool d'instances) que vous avez créée vous-même dans le service Compute, plutôt que sur une instance de calcul que Kubernetes Engine a créée pour vous. Les noeuds autogérés sont souvent appelés BYON (Apportez vos propres noeuds). Contrairement aux noeuds gérés et aux noeuds virtuels (qui sont regroupés respectivement en pools de noeuds gérés et en pools de noeuds virtuels), les noeuds autogérés ne sont pas regroupés en pools de noeuds.
Vous utilisez le service Compute pour créer les instances de calcul sur lesquelles héberger des noeuds autogérés. Le service Compute vous permet de configurer des instances de calcul pour des charges globales spécialisées, y compris des combinaisons de forme et d'image de calcul qui ne sont pas disponibles pour les noeuds gérés et les noeuds virtuels. Par exemple, vous pouvez avoir besoin d'instances avec des formes conçues pour les charges globales accélérées par le matériel (comme les formes GPU) ou des formes conçues pour les charges globales de calcul hautes performances (HPC) qui nécessitent des coeurs de processeur haute fréquence (comme les formes HPC et Optimized). Vous pouvez connecter de nombreuses instances de ce type à un réseau à bande passante élevée à très faible latence pour former un réseau de cluster Oracle Cloud Infrastructure (reportez-vous à Utilisation des réseaux de cluster RDMA).
Si vous voulez simplifier l'administration et gérer plusieurs noeuds autogérés en tant que groupe, utilisez le service Compute pour créer un pool d'instances de calcul afin d'héberger des noeuds autogérés.
Lorsque vous créez une instance de calcul (ou un pool d'instances) pour héberger un noeud autogéré, vous indiquez le cluster Kubernetes auquel ajouter l'instance. Vous pouvez uniquement ajouter des noeuds autogérés à des clusters améliorés.
Le cluster auquel vous ajoutez un noeud autogéré et l'image que vous utilisez pour l'instance de calcul hébergeant le noeud autogéré doivent répondre à certaines exigences. Reportez-vous aux sections Cluster Requirements et Image Requirements, respectivement.
Pour créer une instance de calcul afin d'héberger un noeud autogéré et de l'ajouter à un cluster existant, procédez comme suit :
- Créez un groupe dynamique (avec une règle qui inclut l'instance de calcul à ajouter au cluster) et une stratégie pour le groupe dynamique (avec une instruction de stratégie permettant aux membres du groupe dynamique de rejoindre le cluster). Reportez-vous à la section Creating a Dynamic Group and a Policy for Self-Managed Nodes.
- Créez un script cloud-init contenant l'adresse privée d'API Kubernetes du cluster et le certificat d'autorité de certification encodé en base64. Reportez-vous à la section Creating Cloud-init Scripts for Self-managed Nodes.
- Créez la nouvelle instance de calcul sur la base d'une image OKE et fournissez le script cloud-init. Reportez-vous à la section Creating Self-Managed Nodes.
Lorsque l'instance de calcul est créée, elle est ajoutée au cluster en tant que noeud autogéré.
Tenez compte des éléments suivants :
- Si vous supprimez le cluster auquel vous avez ajouté des noeuds autogérés, les instances de calcul hébergeant les noeuds autogérés ne prennent pas fin. Les conteneurs en cours d'exécution sur les noeuds peuvent continuer à s'exécuter, à condition qu'ils ne dépendent pas du plan de contrôle Kubernetes. Si vous supprimez un cluster auquel vous avez ajouté des noeuds autogérés, il est de votre responsabilité de mettre fin aux instances de calcul hébergeant ces noeuds autogérés.
- En plus d'utiliser le service Compute pour créer des instances de calcul individuelles afin d'héberger des noeuds autogérés individuels, vous pouvez également utiliser le service Compute pour créer un pool d'instances de calcul afin d'héberger des noeuds autogérés. Tout d'abord, vous définissez une configuration d'instance qui inclut l'adresse privée d'API Kubernetes du cluster et le certificat d'autorité de certification encodé en base64 dans un script cloud-init (comme si vous créiez une instance de calcul individuelle). Vous utilisez ensuite la configuration d'instance pour créer des instances dans un pool, chacune pouvant héberger un noeud autogéré. Vous pouvez également utiliser la configuration d'instance comme modèle pour le lancement d'instances individuelles ne faisant pas partie d'un pool d'instances. Pour plus d'informations, reportez-vous à Création d'une configuration d'instance et à Création de pools d'instances.
- Pour mettre à niveau la version de Kubernetes exécutée sur un noeud autogéré, vous devez remplacer le noeud autogéré existant par un nouveau noeud autogéré. Reportez-vous à Mise à niveau de noeuds autogérés vers une version de plus récente de Kubernetes en remplaçant un noeud autogéré existant.
- Par défaut, les noeuds autogérés utilisent le module d'extension CNI flannel pour la mise en réseau de pod. Si vous souhaitez utiliser le module d'extension CNI OCI VCN-Native Pod Networking pour le réseau de pod, utilisez plutôt l'interface de ligne de commande ou l'API pour spécifier les paramètres nécessaires (reportez-vous à Création de noeuds autogérés). Afin d'utiliser le module d'extension CNI de mise en réseau de pod natif OCI VCN pour le réseau de pod (plutôt que le module d'extension CNI flannel), les noeuds de plan de contrôle du cluster doivent exécuter Kubernetes version 1.27.10 (ou ultérieure). Pour plus d'informations sur le module d'extension CNI de mise en réseau de pod natif OCI VCN et le module d'extension CNI flannel, reportez-vous à Mise en réseau de pod.
Utiliser des noeuds autogérés avec des réseaux de cluster
Lorsque vous utilisez le service Compute pour créer un pool d'instances de calcul afin d'héberger des noeuds autogérés, vous pouvez gérer le pool d'instances en tant que réseau de cluster Oracle Cloud Infrastructure (reportez-vous à Réseaux de cluster avec pools d'instances). Les instances de calcul au sein du réseau de cluster sont connectées par un réseau RDMA (Remote Direct Memory Access) à bande passante élevée et à très faible latence. Pour plus d'informations sur l'utilisation d'un réseau RDMA avec Kubernetes Engine, reportez-vous à Exécution de charges de travail GPU RDMA (accès direct à la mémoire distante) sur OKE sur github.
Fonctionnalités et fonctionnalités notables non prises en charge lors de l'utilisation de noeuds autogérés
Certaines fonctionnalités ne sont pas disponibles ou ne sont pas encore disponibles lors de l'utilisation de noeuds autogérés.
Notez que, comme les noeuds autogérés ne sont pas regroupés dans des pools de noeuds, toute fonctionnalité liée aux pools de noeuds ne s'applique pas.
| Caractéristique non prise en charge | Informations supplémentaires |
|---|---|
| Mesures de noeud autogérées sur la page Mesures de Kubernetes Engine dans la console | Les mesures Kubernetes pour les noeuds autogérés ne sont pas affichées sur la page Mesures du service Kubernetes Engine dans la console. Utilisez |
| Affichage des noeuds autogérés dans la console ou via l'API OKE OCI | Les noeuds autogérés ne sont pas visibles dans les pages de console du service Kubernetes Engine ou via l'API OKE OCI. Vous pouvez utiliser l'API Kubernetes pour répertorier les noeuds autogérés à l'aide de la commande kubectl get nodes. |
| Effectuer des opérations de maintenance sur des noeuds autogérés à l'aide de la console | Vous ne pouvez pas effectuer d'opérations de maintenance (telles que le redémarrage, le remplacement de volume d'initialisation, la terminaison et le remplacement) sur des noeuds autogérés à l'aide des pages de console du service Kubernetes Engine de la même manière que les noeuds gérés. Si vous effectuez des opérations de maintenance à l'aide des pages de console du service Compute, les configurations de disponibilité Kubernetes ne sont pas respectées. |
| Utilisation d'images autres que les images OKE OL7, OL8 et Ubuntu | Non encore disponible. |
| Application de la stratégie d'écart de Kubernetes | La stratégie d'écart de Kubernetes selon laquelle les noeuds de plan de contrôle d'un cluster ne doivent pas comporter plus de deux versions mineures (ou trois versions mineures, à partir de la version 1.28 de Kubernetes) avant les noeuds de processus actif n'est pas appliquée. |
| Outil de redimensionnement automatique de cluster Kubernetes | Non encore disponible. |
| Cycle de noeuds lors de la mise à niveau ou de la mise à jour de noeuds autogérés | Non encore disponible. |