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 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

Amazon EKS Provisioned Control Plane est une fonctionnalité qui permet aux administrateurs de cluster de choisir parmi un ensemble de niveaux de dimensionnement et de désigner le niveau de leur choix pour des performances prévisibles et très élevées à partir du plan de contrôle du cluster. Cela permet aux administrateurs du cluster 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 est automatiquement redimensionné vers le haut et vers le bas en fonction de vos demandes de charge de travail. Le mode standard alloue de manière dynamique une capacité de plan de contrôle suffisante pour répondre à vos besoins en matière de 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é de performances due à la mise à l'échelle du plan de contrôle ou celles qui nécessitent de très grandes capacités du plan de contrôle, vous pouvez éventuellement utiliser le mode Provisioned. Le mode provisionné vous permet de préallouer la capacité du plan de contrôle qui est toujours prête à faire face à des exigences de charge de travail exigeantes.

Avec EKS Provisioned Control Plane, les administrateurs du cluster peuvent préprovisionner à l'avance la capacité du plan de contrôle souhaitée, fournissant 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, des sites de préparation aux sites de production et de reprise après sinistre. Ceci 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 à des niveaux de performances de plan de contrôle très élevés, permettant l'exécution de charges de travail d'IA extrêmement évolutives, de calculs hautes performances et de charges 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 depuis le plan de contrôle, vous pouvez choisir d'utiliser la fonctionnalité EKS Provisioned Control Plane. Vous serez facturé au taux horaire pour le niveau de mise à l'échelle du plan de contrôle concerné, en plus des frais horaires EKS standard ou de support étendu. Pour plus d'informations sur la tarification, consultez la rubrique Tarification 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.

Performance-critical charges de travail  : pour les charges de travail qui exigent 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 en matière d'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 anticipés à forte demande — Lorsque vous vous attendez à une augmentation soudaine des demandes de plan 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 saisons de shopping 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 à gérer la charge accrue sans attendre la mise à l'échelle automatique pour répondre à la demande.

Mission-critical haute disponibilité - Pour les charges de travail qui exigent les niveaux de disponibilité les plus élevés, Provisioned Control Plane propose un accord de niveau de service (SLA) de 99,99 %, mesuré à intervalles d'une minute. Ce SLA amélioré fournit un engagement de disponibilité plus strict par rapport au SLA de 99,95 % du mode plan de contrôle standard, mesuré à intervalles de 5 minutes.

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 production et de production, ce qui vous permet d'identifier les problèmes potentiels 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 fidèlement 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, Provisioned Control Plane vous permet de provisionner des environnements de basculement avec le même niveau de capacité que votre environnement principal. Cela garantit un minimum de perturbations et une reprise 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 d'échelle nommés en fonction des tailles de t-shirts (XL, 2XL, 4XL et 8XL). Chaque niveau définit ses capacités grâce à quatre attributs 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 des pods sur les nœuds, mesuré 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 le cluster state/metadata.

Le SLA (Service Level Agreement) indique l'engagement de disponibilité mensuel du terminal Kubernetes du cluster EKS

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

EKS v1.30 à v1.33

EKS v1.34 et versions ultérieures

Surveillance de l'utilisation des niveaux de dimensionnement du plan de contrôle

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 en tant que CloudWatch métriques Amazon et sont accessibles via la CloudWatch console EKS. En outre, ces métriques peuvent être extraites depuis le point de terminaison Prometheus de votre cluster EKS (voir ici).

Vous pouvez consulter l'utilisation du plan de contrôle dans la console Amazon EKS. Sur la page de présentation de votre cluster, choisissez Surveiller le cluster pour accéder au tableau de bord d'observabilité, puis sélectionnez l'onglet Surveillance du plan de contrôle pour afficher l'utilisation du plan de contrôle dans la section Mise à l'échelle du plan de contrôle.

Comprendre la capacité des niveaux par rapport aux performances réelles

Lorsque vous sélectionnez un niveau de mise à l'échelle 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 atteignez dépendent de vos modèles de charge de travail spécifiques, de vos configurations et de votre 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 places de requêtes simultanées, le débit de demandes réel que vous obtenez depuis le plan de contrôle dépend des types d'opérations effectuées. Par exemple, Kubernetes pénalise davantage les demandes de liste que les requêtes get, et par conséquent, le nombre effectif de demandes de liste traitées simultanément par le plan de contrôle est inférieur à celui des requêtes get. Pour plus d'informations, consultez la section Priorité et équité des API dans le guide des meilleures pratiques d'EKS. De même, bien que le planificateur par défaut QPS soit défini sur 400 pour un niveau 4XL, le taux de planification réel de vos pods dépend de facteurs tels que la disponibilité et l'état de santé des nœuds pour la planification. Pour obtenir des performances optimales, assurez-vous que vos applications suivent les meilleures pratiques de Kubernetes et sont correctement configurées en fonction des caractéristiques de votre charge de travail. Pour plus d'informations, consultez les meilleures pratiques en matière d'évolutivité dans le guide des meilleures pratiques EKS.

Synchronisation simultanée du pod Autoscaler horizontal

Outre les attributs du niveau Control Plane Scaling, les clusters EKS Provisioned Control Plane sont réglés avec une simultanéité de synchronisation HPA (Horizontal Pod Autoscaler) plus élevée. La simultanéité de synchronisation HPA est le nombre d'objets HPA que le gestionnaire de contrôleurs Kubernetes traite en parallèle. La valeur par défaut de Kubernetes en amont est 5. Une simultanéité plus élevée permet au plan de contrôle de réconcilier un plus grand nombre d'objets HPA simultanément, ce qui réduit le temps entre un changement de charge et l'action de dimensionnement correspondante. Cela est avantageux pour les clusters qui exécutent un grand nombre d'objets HPA, car leur traitement en série peut retarder la mise à l'échelle automatique.

Chaque niveau de dimensionnement du plan de contrôle provisionné est configuré avec la simultanéité de synchronisation HPA suivante.

Vous pouvez observer l'effet d'une augmentation de la simultanéité de synchronisation HPA grâce à la métrique de file de travail du gestionnaire de contrôleurs Kubernetes pour le contrôleur HPA :

La réactivité réelle de la mise à l'échelle automatique que vous observez dépend également de facteurs extérieurs au plan de contrôle. Chaque rapprochement HPA extrait les métriques qui sous-tendent sa décision de dimensionnement, généralement à partir du serveur Kubernetes Metrics pour l'utilisation du processeur et de la mémoire, ou à partir d'un adaptateur de métriques personnalisé ou externe. Le nombre d'objets HPA dans votre cluster et la latence de ces recherches de métriques ont tous deux une incidence sur la rapidité avec laquelle le contrôleur peut fonctionner dans la file d'attente. Si votre source de métriques ne peut pas traiter les demandes assez rapidement, les rapprochements ralentissent, quel que soit le nombre de demandes traitées en parallèle. L'exécution d'un nombre suffisant de répliques de Metrics Server pour répondre au volume de demandes et la définition efficace de la portée des requêtes métriques vous permettent de tirer pleinement parti de la plus grande simultanéité de synchronisation HPA. Pour plus d'informations sur le fonctionnement du Horizontal Pod Autoscaler et sur l'endroit où il extrait les métriques, consultez la section Horizontal Pod Autoscaling sur le site Web de Kubernetes.

Considérations