Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Overview of node pools

Dernière mise à jour :Aug 11, 2026

Dans les scénarios de collaboration cloud-edge, les nœuds appartenant à différents groupes sont isolés les uns des autres. Par exemple, ces nœuds peuvent être déconnectés, ne pas partager les mêmes ressources, disposer de ressources hétérogènes ou exécuter des applications déployées de manière indépendante. Container Service for Kubernetes (ACK) Edge propose la fonctionnalité de pool de nœuds, qui regroupe les nœuds en pools selon des attributs spécifiques. Cela permet une gestion et une maintenance unifiées des nœuds de différents groupes au niveau du pool de nœuds. Cette rubrique présente les pools de nœuds, décrit les différents types de pools et explique comment les nœuds sont gérés par ces derniers.

Types de pools de nœuds

Dans les scénarios de collaboration cloud-edge, ACK Edge propose les types de pools de nœuds suivants : les pools de nœuds cloud et les pools de nœuds edge.

image
  • Pool de nœuds cloud : un pool de nœuds cloud gère les instances Elastic Compute Service (ECS) situées dans le même virtual private cloud (VPC) que le cluster. Les pools de nœuds cloud sont identiques aux pools de nœuds fournis par les clusters ACK Pro cluster.

    • Pool de nœuds cloud (par défaut) : lors de la création d'un cluster ACK Edge cluster, le système crée automatiquement un pool de nœuds cloud nommé default-nodepool, utilisé pour déployer les composants du plan de contrôle.

      Important

      Vous ne pouvez pas supprimer le pool de nœuds default-nodepool. Ce pool doit contenir au moins un nœud. Dans le cas contraire, le cluster ACK Edge ne peut pas fonctionner normalement.

    • Pool de nœuds cloud (élastique) : pool de nœuds cloud pour lequel la fonctionnalité mise à l'échelle automatique des nœuds est activée.

  • Pool de nœuds edge : un pool de nœuds edge gère des nœuds répartis dans différentes régions, tels que des nœuds ECS dans diverses régions, des nœuds déployés dans des centres de données, des nœuds provenant de différents fournisseurs de services cloud, ainsi que des serveurs situés dans des usines, des magasins, des véhicules et des navires.

Pools de nœuds cloud

Les attributs des pools de nœuds cloud sont identiques à ceux fournis par les clusters ACK Pro cluster et vous pouvez effectuer les mêmes opérations sur ces pools. Pour plus d'informations, consultez la rubrique Présentation des pools de nœuds cloud.

Pools de nœuds edge

  • Les pools de nœuds edge constituent des abstractions de groupes de nœuds edge. Lorsque vous créez un pool de nœuds edge, vous devez d'abord confirmer les attributs de base des nœuds du pool, tels que les connexions cloud-edge, la communication inter-nœuds et le réseau des pods. Nous vous recommandons également de répartir les nœuds edge dans plusieurs pools de nœuds edge en fonction d'autres attributs, tels que les CPU ou GPU, les régions et les architectures AMD64 ou ARM64.

  • Une fois le pool de nœuds créé, vous pouvez gérer par lot les libellés et les taints des nœuds du pool en modifiant le pool de nœuds edge. Après avoir supprimé tous les nœuds edge du cluster, vous pouvez supprimer le pool de nœuds edge.

  • Pour déployer une application dans plusieurs pools de nœuds, vous pouvez créer un objet YurtAppSet. Les objets YurtAppSet réagissent rapidement aux modifications des libellés des pools de nœuds. Ils permettent ainsi de gérer de manière centralisée les configurations d'une charge de travail distribuée sur plusieurs pools de nœuds, telles que le nombre de pods et les versions des applications.

  • Les endpoints backend des services Kubernetes sont répartis de manière aléatoire sur les nœuds. Par conséquent, si les réseaux de deux pools de nœuds edge sont déconnectés, la communication inter-services entre ces pools risque d'échouer ou de présenter une latence réseau élevée. Vous pouvez créer une topologie de service afin de restreindre la communication des services au même pool de nœuds edge ou au même nœud edge. Cela permet d'éviter les échecs de communication dans les scénarios de communication transdomaine.