Plan de contrôle provisionné Amazon EKS - Amazon EKS

Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Plan de contrôle provisionné Amazon EKS

Présentation de

Le plan de contrôle provisionné Amazon EKS est une fonctionnalité qui permet aux administrateurs de clusters de choisir parmi un ensemble de niveaux de dimensionnement et de désigner le niveau de leur choix pour des performances très élevées et prévisibles depuis le plan de contrôle du cluster. Cela permet aux administrateurs de clusters de s'assurer que le plan de contrôle est toujours approvisionné avec la capacité spécifiée.

Amazon EKS propose deux modes de fonctionnement pour le plan de contrôle de votre cluster. Par défaut, les clusters Amazon EKS utilisent le mode standard, dans lequel le plan de contrôle augmente ou diminue automatiquement en fonction des exigences de votre charge de travail. Le mode standard alloue de manière dynamique une capacité suffisante du plan de contrôle pour répondre aux besoins de votre charge de travail et constitue la solution recommandée dans la plupart des cas d'utilisation. Toutefois, pour les charges de travail spécialisées qui ne peuvent tolérer aucune variabilité des performances due à la mise à l'échelle du plan de contrôle ou celles qui nécessitent une très grande capacité du plan de contrôle, vous pouvez éventuellement utiliser le mode provisionné. Le mode provisionné vous permet de préallouer une capacité du plan de contrôle toujours prête à répondre aux exigences de charge de travail exigeantes.

Note

Le mode provisionné est un mode de fonctionnement du plan de contrôle supplémentaire en plus du mode standard par défaut. L'introduction du mode provisionné ne modifie pas le comportement du mode standard.

Avec le plan de contrôle provisionné EKS, les administrateurs du cluster peuvent préprovisionner la capacité du plan de contrôle souhaitée à l'avance, offrant ainsi des performances prévisibles et élevées à partir du plan de contrôle du cluster, qui est toujours disponible. Le plan de contrôle provisionné EKS permet également aux administrateurs de clusters de fournir la même capacité de plan de contrôle dans tous les environnements, qu'il s'agisse de sites de préparation, de production ou de reprise après sinistre. Cela est important pour garantir que les performances du plan de contrôle obtenues dans tous les environnements sont cohérentes et prévisibles. Enfin, EKS Provisioned Control Plane vous donne accès à de très hauts niveaux de performance du plan de contrôle, ce qui permet d'exécuter des charges de travail d'IA extrêmement évolutives, des calculs à haute performance et des charges de travail de traitement de données à grande échelle sur Kubernetes.

Tous les clusters Amazon EKS existants et nouveaux fonctionnent en mode standard par défaut. Pour les clusters nécessitant des performances élevées et prévisibles de la part du plan de contrôle, vous pouvez choisir d'utiliser la fonction EKS Provisioned Control Plane. Vous serez facturé au taux horaire correspondant au niveau de mise à l'échelle du plan de contrôle concerné, en plus des frais horaires EKS pour le support standard ou prolongé. Pour plus d'informations sur la tarification, consultez la section Tarification d'Amazon EKS.

Modes du plan de contrôle Amazon EKS

Cas d’utilisation

Le plan de contrôle provisionné EKS est conçu pour répondre à des scénarios spécifiques dans lesquels des performances élevées et prévisibles du plan de contrôle sont essentielles à vos opérations. La compréhension de ces cas d'utilisation peut vous aider à déterminer si EKS Provisioned Control Plane est la solution adaptée à vos charges de travail.

Charges de travail critiques pour les performances : pour les charges de travail qui nécessitent une latence minimale et des performances maximales de la part du plan de contrôle Kubernetes, le plan de contrôle provisionné EKS fournit une capacité qui élimine la variabilité des performances grâce à la mise à l'échelle du plan de contrôle.

Charges de travail extrêmement évolutives — Si vous exécutez des charges de travail hautement évolutives telles que la formation et l'inférence basées sur l'IA, le calcul haute performance ou le traitement de données à grande échelle nécessitant l'exécution d'un grand nombre de nœuds dans le cluster, le plan de contrôle provisionné fournit la capacité de plan de contrôle nécessaire pour prendre en charge ces charges de travail exigeantes.

Événements à forte demande prévus — Lorsque vous vous attendez à une augmentation soudaine du nombre de demandes de plans de contrôle en raison d'un événement à venir, tel que des ventes ou des promotions sur le commerce électronique, des lancements de produits, des périodes de shopping des fêtes ou des événements sportifs ou de divertissement majeurs, le plan de contrôle provisionné vous permet d'augmenter la capacité de votre plan de contrôle à l'avance. Cette approche proactive garantit que votre plan de contrôle est prêt à faire face à l'augmentation de la charge sans attendre le dimensionnement automatique pour répondre à la demande.

Cohérence de l'environnement : le plan de contrôle provisionné vous permet de faire correspondre la capacité et les performances du plan de contrôle entre les environnements de préparation et de production, ce qui vous aide à identifier les problèmes potentiels à un stade précoce avant le déploiement en production. En conservant le même niveau de plan de contrôle dans tous les environnements, vous pouvez vous assurer que les résultats des tests reflètent précisément le comportement de production, réduisant ainsi le risque de surprises liées aux performances lors du déploiement.

Reprise après sinistre et continuité des activités : pour les scénarios de reprise après sinistre, le plan de contrôle provisionné vous permet de fournir des environnements de basculement avec le même niveau de capacité que votre environnement principal. Cela garantit une interruption minimale et une restauration rapide en cas de basculement, car votre cluster de reprise après sinistre aura des caractéristiques de performance de plan de contrôle identiques à celles de votre cluster de production dès son activation.

Niveaux de dimensionnement du plan de contrôle

EKS Provisioned Control Plane propose des niveaux de scalabilité nommés selon les tailles de t-shirt (XL, 2XL, 4XL). Chaque niveau définit sa capacité par le biais de trois attributs Kubernetes clés qui déterminent les caractéristiques de performance du plan de contrôle de votre cluster. La compréhension de ces attributs vous permet de sélectionner le niveau adapté à vos exigences en matière de charge de travail.

La simultanéité des demandes d'API mesure le nombre de demandes que le serveur d'API du plan de contrôle Kubernetes peut traiter simultanément, ce qui est essentiel pour les charges de travail à haut débit.

Le taux de planification des pods indique la rapidité avec laquelle le planificateur Kubernetes par défaut peut planifier les pods sur les nœuds, mesurée en pods par seconde.

La taille de la base de données du cluster indique l'espace de stockage alloué à etcd, la base de données qui contient l'état et les métadonnées du cluster.

Lorsque vous configurez le plan de contrôle de votre cluster sur un certain niveau de scalabilité à l'aide du plan de contrôle provisionné, EKS garantit que le plan de contrôle de votre cluster maintient les limites correspondant à ce niveau. Les limites des niveaux de dimensionnement du plan de contrôle varient selon la version de Kubernetes, comme indiqué dans les tableaux suivants.

EKS v1.28 et v1.29

Niveau de mise à l'échelle du plan de contrôle provisionné Concurrence des demandes d'API (sièges) Débit de planification des pods (pods/sec) Taille de la base de données du cluster (Go)

XL

1700

100

16

2XL

3400

100

16

4XL

6800

100

16

EKS v1.30 et versions ultérieures

Niveau de mise à l'échelle du plan de contrôle provisionné Concurrence des demandes d'API (sièges) Débit de planification des pods (pods/sec) Taille de la base de données du cluster (Go)

XL

1700

167

16

2XL

3400

283

16

4XL

6800

400

16

Surveillance du plan de contrôle, échelonnement de l'utilisation des niveaux

Amazon EKS fournit plusieurs indicateurs pour vous aider à surveiller l'utilisation des niveaux de votre plan de contrôle. Ces métriques sont publiées sous forme de CloudWatch métriques Amazon et sont accessibles via la console EKS CloudWatch et EKS. De plus, ces métriques peuvent être extraites du point de terminaison Prometheus de votre cluster EKS (voir ici).

Prometheus Metric CloudWatch Métrique

Concurrence des demandes d'API

apiserver_flowcontrol_current_executing_seats

apiserver_flowcontrol_current_executing_seats

Taux de planification des pods

scheduler_schedule_attempts_total

scheduler_schedule_attempts total, Scheduler_Schedule_Attempts_Scheduled, Scheduler_Schedule_Attempts_Unschedulable

Taille de base de données du cluster

apiserver_storage_size_bytes

apiserver_storage_size_bytes

Comprendre la capacité du niveau Tier par rapport aux performances réelles

Lorsque vous sélectionnez un niveau de dimensionnement du plan de contrôle provisionné, les attributs du niveau représentent les configurations sous-jacentes qu'Amazon EKS applique à votre plan de contrôle. Cependant, les performances réelles que vous obtenez dépendent de vos modèles de charge de travail spécifiques, de vos configurations et du respect des meilleures pratiques de Kubernetes. Par exemple, alors qu'un niveau 4XL configure la priorité et l'équité des API (APF) avec 6 800 postes de requêtes simultanés, le débit de demandes réel que vous obtenez à partir du plan de contrôle dépend des types d'opérations effectuées. Par exemple, Kubernetes pénalise davantage les requêtes de liste que les requêtes de type get, de sorte que le nombre effectif de demandes de liste traitées simultanément par le plan de contrôle est inférieur à celui des demandes get (voir ici). De même, bien que le planificateur par défaut QPS soit défini sur 400 pour un niveau 4XL, le taux réel de planification de vos pods dépend de facteurs tels que la disponibilité des nœuds et leur état de santé pour la planification. Pour obtenir des performances optimales, assurez-vous que vos applications respectent les meilleures pratiques de Kubernetes (voir ici) et qu'elles sont correctement configurées en fonction des caractéristiques de votre charge de travail.

Considérations

  • Capacité du plan de contrôle standard — Le mode plan de contrôle standard d'EKS offre le meilleur rapport qualité/prix et constitue l'option recommandée pour la grande majorité des cas d'utilisation. Toutefois, pour les charges de travail spécialisées qui ne peuvent tolérer aucune variabilité des performances due à la mise à l'échelle du plan de contrôle ou celles qui nécessitent une très grande capacité du plan de contrôle, vous pouvez éventuellement envisager d'utiliser le mode provisionné.

  • Inscription requise : les clusters existants ne passeront pas automatiquement du plan de contrôle standard à un niveau plus onéreux du plan de contrôle provisionné EKS. Vous devez explicitement adhérer à l'un des nouveaux niveaux de dimensionnement du plan de contrôle provisionné par EKS.

  • Restriction de sortie : le mode plan de contrôle standard prend en charge jusqu'à 8 Go de taille de base de données de cluster (etcd). Si la taille de la base de données de votre cluster dépasse 8 Go en mode provisionné, vous ne pouvez pas revenir en mode standard tant que vous n'avez pas réduit la taille de la base de données à moins de 8 Go. Par exemple, si vous utilisez 14 Go de stockage de base de données en mode provisionné, vous devez d'abord réduire l'utilisation de votre base de données à moins de 8 Go avant de revenir en mode standard.

  • Pas de mise à l'échelle automatique des niveaux : le plan de contrôle provisionné EKS ne passe pas automatiquement d'un niveau à l'autre. Une fois que vous avez sélectionné un niveau de scalabilité, le plan de contrôle de votre cluster reste attaché à ce niveau, garantissant ainsi des performances constantes et prévisibles. Cependant, vous avez la possibilité de mettre en œuvre votre propre solution de dimensionnement automatique en surveillant les indicateurs d'utilisation des niveaux et en utilisant le plan de contrôle provisionné EKS APIs pour augmenter ou diminuer lorsque ces indicateurs dépassent les seuils que vous définissez, vous donnant ainsi un contrôle total sur votre stratégie de dimensionnement et l'optimisation des coûts.

  • Affichage du niveau actuel : vous pouvez utiliser la console Amazon EKS, la CLI Amazon Web Services ou l'API pour afficher le niveau de dimensionnement actuel du plan de contrôle. Dans la CLI, vous pouvez exécuter la describe-cluster commande suivante : aws eks describe-cluster --name cluster-name

  • Temps de transition entre les niveaux : vous pouvez utiliser la console Amazon EKS, Amazon EKS APIs ou la CLI pour quitter ou passer d'un niveau de dimensionnement à un autre. Amazon EKS a introduit un nouveau type de mise à jour de cluster appeléScalingTierConfigUpdate, que vous pouvez inspecter pour suivre la progression de la transition. Après avoir exécuté une commande de changement de niveau, vous pouvez répertorier les mises à jour sur le cluster pour voir une nouvelle mise à jour de type ScalingTierConfigUpdate avec statutUpdating. Le statut passe à Successful la fin de la mise à jour ou en Failed cas d'erreur. Le champ d'erreur de la mise à jour indique la raison de l'échec. Il n'y a aucune restriction quant à la fréquence à laquelle vous pouvez passer d'un niveau à l'autre. La modification du niveau du plan de contrôle prend plusieurs minutes.

  • Sélection du niveau optimal : pour déterminer le niveau de mise à l'échelle du plan de contrôle provisionné optimal pour votre cluster, vous pouvez effectuer des tests de charge en provisionnant votre cluster sur le niveau le plus élevé (4XL). Effectuez ensuite un test de charge pour simuler le pic de demande sur le plan de contrôle de votre cluster. Observez les mesures d'utilisation du niveau du plan de contrôle au pic de charge et utilisez ces observations comme facteur directeur pour sélectionner le niveau approprié pour le mode provisionné.

  • Tarification du plan de contrôle provisionné : vous serez facturé au taux horaire correspondant au niveau de dimensionnement du plan de contrôle provisionné auquel se trouve votre cluster. Cela s'ajoute aux frais horaires de support standard ou prolongé. Consultez la page de tarification d'Amazon EKS pour plus de détails.

  • Niveau de mise à l'échelle supérieur : si vous avez l'intention d'exécuter votre cluster sur un niveau de mise à l'échelle supérieur à 4XL, contactez l'équipe chargée de votre compte Amazon Web Services pour obtenir des informations supplémentaires sur les tarifs.

  • Support des versions et des régions de Kubernetes : le plan de contrôle provisionné par EKS est pris en charge dans toutes les régions commerciales d'Amazon Web Services GovCloud et en Chine. Le plan de contrôle provisionné fonctionne sur EKS v1.28 et versions ultérieures.