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.
Configuration avancée du plan de contrôle de Kubernetes
Vue d’ensemble
Amazon EKS gère le plan de contrôle Kubernetes de votre cluster, y compris le serveur d'API, le planificateur et le gestionnaire de contrôleurs. EKS exécute ces composants avec les paramètres Kubernetes par défaut en amont qui fonctionnent bien pour la majorité des charges de travail, et vous n'avez pas besoin de les modifier pour la plupart des clusters. Certaines charges de travail bénéficient toutefois de différents paramètres du plan de contrôle. Vous souhaiterez peut-être que le planificateur regroupe les pods sur un plus petit nombre de nœuds afin de réduire les coûts de calcul, conserve les événements Kubernetes pendant une période plus courte afin de limiter la croissance de la base de données de cluster (etcd) ou évalue plus fréquemment les décisions de dimensionnement automatique.
Grâce à la configuration avancée du plan de contrôle de Kubernetes, vous pouvez définir ces paramètres directement sur votre cluster. EKS les applique au plan de contrôle et votre cluster continue de fonctionner avec les mêmes caractéristiques de disponibilité et de performances.
Il s'agit de configurations avancées. Chaque paramètre de configuration modifie le comportement d'un composant principal du plan de contrôle de Kubernetes pour les charges de travail exécutées sur le cluster, et la valeur correcte dépend de votre charge de travail. Avant de modifier un paramètre, lisez les considérations qui s'y rapportent dans les sections suivantes et testez la modification dans un cluster hors production.
Vous pouvez définir des paramètres de configuration avancés du plan de contrôle lorsque vous créez un cluster, ou les mettre à jour sur un cluster existant à tout moment. Cette fonctionnalité utilise les paramètres existants CreateCluster et les UpdateClusterConfig opérations avec de nouveaux paramètres. Vous pouvez donc la définir via l' AWS interface de ligne de commande Console de gestion AWS, AWS les SDK ou AWS CloudFormation. EKS valide chaque configuration avant de l'appliquer et enregistre les modifications dans AWS CloudTrail.
Les paramètres avancés du plan de contrôle s'appliquent à l'ensemble du cluster et à toutes les charges de travail qui y sont exécutées. Vous ne pouvez pas les étendre à des espaces de noms ou à des charges de travail individuels. EKS contraint chaque paramètre à une plage validée. Les valeurs prises en charge pour chaque paramètre sont répertoriées avec ce paramètre dans la section suivante.
Paramètres du plan de contrôle Kubernetes pris en charge
Amazon EKS prend en charge les paramètres suivants. Chaque paramètre appartient à un composant du plan de contrôle et est défini via le champ de configuration de ce composant : kubeSchedulerConfigkubeControllerManagerConfig, oukubeApiServerConfig.
| Composant | Paramètre | Valeurs prises en charge | Par défaut | Nécessite un plan de contrôle provisionné |
|---|---|---|---|---|
|
planificateur kube |
|
|
|
Non |
|
gestionnaire de contrôleurs Kube |
|
|
|
Oui |
|
gestionnaire de contrôleurs Kube |
|
|
|
Oui |
|
serveur kube-api |
|
|
|
Non |
|
serveur kube-api |
|
|
|
Non |
Les valeurs par défaut et les valeurs prises en charge dans cette rubrique s'appliquent à la version de Kubernetes (EKS v1.31 et versions supérieures) disponible lors de la publication et peuvent changer dans les versions ultérieures. L'DescribeClusterVersionsopération indique les valeurs par défaut actuelles et les valeurs prises en charge pour chaque paramètre et version de Kubernetes. Utilisez-la comme source de référence si vous gérez des clusters sur plusieurs versions ou si vous automatisez la configuration des clusters. Pour de plus amples informations, veuillez consulter Configurer les paramètres avancés du plan de contrôle de Kubernetes.
Les sections suivantes décrivent chaque paramètre, quand le modifier et les éléments à prendre en compte avant de le faire.
Planificateur : adaptation des ressources des nœuds
Le planificateur attribue des pods aux nœuds en deux phases. Il filtre d'abord les nœuds qui peuvent exécuter un pod, puis note les candidats restants et place le pod sur le nœud ayant le score le plus élevé. Le nodeResourcesFit plugin vérifie si un nœud possède les ressources demandées par un pod et note les nœuds selon une stratégie de notation.
| Champ | Description | Valeurs prises en charge | Par défaut |
|---|---|---|---|
|
|
Stratégie utilisée pour évaluer les nœuds en fonction de l'allocation de ressources. |
|
|
|
|
Les ressources prises en compte lors de la notation, chacune ayant un poids relatif. |
|
|
LeastAllocatedfavorise les nœuds dont l'allocation de ressources est plus faible, ce qui permet de répartir les pods entre les nœuds de votre cluster et de laisser une marge de manœuvre sur chaque nœud. Il s'agit du comportement par défaut de Kubernetes et constitue un bon choix lorsque vous souhaitez que la capacité disponible sur chaque nœud absorbe la croissance des pods existants.
MostAllocatedfavorise les nœuds qui ont déjà une allocation de ressources plus élevée, ce qui permet de regrouper les pods sur un moins grand nombre de nœuds. Comme vos charges de travail occupent une capacité totale moindre, vous pouvez les exécuter sur un nombre de nœuds réduit et réduire les dépenses de calcul. Au fil du temps, ce comportement d'empaquetage protège les nœuds peu utilisés de nouvelles charges de travail, de sorte que les pools de nœuds qui prennent en charge la consolidation peuvent les supprimer.
EKS soutient les MostAllocated stratégies LeastAllocated et. La RequestedToCapacityRatio stratégie Kubernetes en amont n'est pas prise en charge.
Pondération des ressources
Vous pouvez éventuellement spécifier un resources tableau avec des pondérations personnalisées afin d'influencer les ressources les plus importantes pour les décisions de notation. Cela est utile lorsqu'une ressource spécifique est la contrainte de votre cluster. Par exemple, sur les clusters où les accélérateurs (GPU) constituent la ressource la plus rare, la pondération nvidia.com/gpu au-dessus du processeur et de la mémoire concentre les modules demandant des accélérateurs sur des nœuds déjà partiellement occupés.
Les pondérations sont relatives et non absolues. cpu: 100Paramétrer et memory: 1 n'amène pas le planificateur à ignorer la mémoire. Il pèse 100 fois plus sur le processeur que la mémoire dans la formule de notation. Si chaque nœud candidat a une disponibilité de processeur identique, le processeur ne les distingue plus et la notation est effectivement transmise à la mémoire.
Le fait d'omettre une ressource est différent de lui donner un faible poids. Lorsque vous spécifiez un resources tableau, seules les ressources que vous répertoriez sont notées. Une ressource que vous omettez est totalement exclue du calcul. Par exemple, en memory l'absence cpu: 100 d'entrée, les nœuds sont évalués uniquement sur le processeur, et la disponibilité de la mémoire n'a aucune influence sur le résultat. Pour conserver une ressource dans le calcul tout en réduisant son influence, listez-la avec un faible poids plutôt que de l'omettre.
La pondération d'une ressource d'accélérateur nvidia.com/gpu n'affecte que le score des pods qui déclarent resources.requests réellement cette ressource. Les nacelles qui ne nécessitent pas d'accélérateur ne sont pas influencées par le poids de l'accélérateur.
Les trois ressources de l'accélérateur sont des ressources étendues de Kubernetes, c'est-à-dire des ressources au niveau des nœuds annoncées à Kubernetes par un plugin plutôt que intégrées. Ils ne sont évalués que lorsqu'un plug-in d'appareil les annonce sur le kubelet via l'API du plug-in de l'appareil. Les ressources mises à disposition sur un nœud par un seul pilote de périphérique ne sont pas visibles par le nodeResourcesFit plug-in et ne sont pas notées. Les ressources gérées via Dynamic Resource Allocation (DRA) sont planifiées par un plugin distinct et ne font pas partie de la nodeResourcesFit notation. L'activation de DRA ne modifie donc pas le comportement de ce paramètre. Pour plus d'informations sur la configuration des plug-ins de périphériques NVIDIA, consultez NVIDIA DRA et plug-in de périphérique. Pour plus d'informations sur la configuration des appareils Neuron, consultez la section Gestion des appareils Neuron.
La stratégie de notation est l'une des nombreuses entrées que le planificateur utilise pour calculer un score pour chaque nœud. Pour plus d'informations sur la façon dont le planificateur filtre et note les nœuds, consultez Scheduling Framework
Considérations relatives à la stratégie de notation
-
Les modules en cours d'exécution ne sont pas déplacés. Le planificateur Kubernetes ne déplace jamais un pod déjà en cours d'exécution. La modification de la stratégie de notation n'affecte que les décisions de planification futures, et le placement des modules existants est permanent. Pour rééquilibrer les pods qui fonctionnent déjà, expulsez-les ou redémarrez-les.
-
Le comportement de filtrage ne change pas. La stratégie de notation affecte uniquement la phase de notation, au cours de laquelle le planificateur classe les nœuds par préférence. La phase de filtrage, qui détermine si un pod peut fonctionner sur un nœud, reste inchangée. Un pod qui ne rentre pas dans un nœud n'y est toujours pas programmé dans le cadre de l'une ou l'autre des stratégies.
-
MostAllocatedconcentre le rayon d'explosion. Le regroupement des charges de travail sur un plus petit nombre de nœuds signifie que davantage de pods sont affectés en même temps si un nœud devient défectueux, si une instance est mise hors service ou si une zone de disponibilité est perturbée. Lorsque le taux de désabonnement des pods est élevé, les nœuds les plus denses se remplissent également plus rapidement, ce qui peut laisser les pods enPendingétat pendant que de nouvelles capacités sont mises en service. -
Le planificateur et la gestion des nœuds fonctionnent à différents niveaux. La stratégie de notation influence la position des pods parmi les nœuds qui peuvent déjà les exécuter. Cela ne change pas la façon dont EKS Auto Mode ou Karpenter provisionne ou supprime des nœuds. Validez le comportement combiné de votre charge de travail avant de modifier la configuration.
Gestionnaire de contrôleurs : période de synchronisation Horizontal Pod Autoscaler
Le gestionnaire de contrôleurs exécute les contrôleurs Kubernetes qui orientent l'état du cluster vers l'état souhaité, y compris le contrôleur HPA (Horizontal Pod Autoscaler). À chaque cycle, le contrôleur HPA extrait des métriques pour chaque HorizontalPodAutoscaler objet, calcule le nombre de répliques souhaité et met à jour la charge de travail cible si le nombre a changé.
| Champ | Description | Valeurs prises en charge | Par défaut |
|---|---|---|---|
|
|
Fréquence à laquelle le contrôleur HPA évalue les décisions de dimensionnement. |
|
|
En raccourcissant la période de synchronisation, vos charges de travail évoluent plus rapidement après une augmentation de charge, au lieu d'attendre un cycle complet avant d'ajouter de la capacité.
Pour configurer ce paramètre, votre cluster doit se trouver sur le plan de contrôle provisionné Amazon EKS. Le raccourcissement de l'intervalle augmente la vitesse à laquelle le contrôleur HPA réconcilie tous les HorizontalPodAutoscaler objets du cluster, ce qui génère davantage de demandes d'API. Chaque rapprochement consomme au moins une demande d'API, et un rapprochement qui modifie le nombre de répliques en consomme deux autres. Les clusters de plan de contrôle provisionnés préallouent la capacité du plan de contrôle qui est toujours prête à faire face aux charges de travail exigeantes. Ils sont donc dimensionnés pour absorber cette charge supplémentaire. Pour de plus amples informations, veuillez consulter Plan de contrôle provisionné Amazon EKS.
Effet sur le nombre d'objets HPA pris en charge par votre cluster
-
Le raccourcissement de la période de synchronisation réduit le nombre d'
HorizontalPodAutoscalerobjets que votre plan de contrôle peut réconcilier dans les délais prévus, car le contrôleur dispose de moins de temps pour parcourir la même file d'attente. La réduction de la période de15sà10sréduit le nombre d'objets pris en charge d'environ un tiers. Avant de raccourcir la période de synchronisation, comptez lesHorizontalPodAutoscalerobjets de votre cluster et vérifiez que la période la plus courte est toujours compatible avec votre niveau de mise à l'échelle :kubectl get hpa --all-namespaces --no-headers | wc -l -
EKS ne valide pas la période de synchronisation par rapport à votre nombre d'objets HPA. La modification de configuration est réussie même si votre cluster contient déjà plus d'
HorizontalPodAutoscalerobjets que ne le permet la période plus courte. Vérifiez vous-même le décompte avant de procéder à la modification. -
Le dépassement du nombre pris en charge entraîne une dégradation silencieuse de la mise à l'échelle automatique. Si le contrôleur ne peut pas traiter tous les objets au cours de cette période, cela signifie que certains objets ne sont pas réconciliés dans les délais. EKS n'émet pas d'alarme ni d'événement Kubernetes pour cette affection, et le symptôme est une mise à l'échelle automatique qui répond plus lentement que prévu, à l'opposé de l'effet escompté. Si vous observez un retard de mise à l'échelle après avoir raccourci la période de synchronisation, rétablissez la valeur par défaut du
15sparamètre. -
La période de synchronisation s'applique à tous les objets HPA du cluster. Vous ne pouvez pas définir des périodes de synchronisation différentes pour différents objets ou espaces de noms.
Gestionnaire du contrôleur : seuil de collecte des déchets des pods terminé
Le gestionnaire du contrôleur exécute le ramasse-miettes du pod terminé (le contrôleur GC du pod). Ce contrôleur supprime les modules terminés (les modules en Failed phase Succeeded ou) lorsque le nombre de modules terminés dans le cluster dépasse un certain seuil. Le terminatedPodGcThreshold paramètre définit ce seuil.
| Champ | Description | Valeurs prises en charge | Par défaut |
|---|---|---|---|
|
|
Le nombre de pods terminés qui peuvent exister avant que le ramasse-miettes des pods résiliés ne commence à supprimer les pods terminés. |
|
|
Le ramasse-miettes fonctionne selon un cycle fixe de 20 secondes. Lorsque vous abaissez le seuil, le collecteur commence à supprimer de force les pods les plus anciens fermés au cycle suivant jusqu'à ce que le nombre atteigne le nouveau seuil.
Pour configurer ce paramètre, votre cluster doit se trouver sur le plan de contrôle provisionné Amazon EKS. L'abaissement du seuil augmente le travail de collecte des déchets que le contrôleur effectue sur la base de données du cluster (etcd). Chaque passe de collecte permet d'interroger, de traiter et de supprimer d'autres pods résiliés. Les clusters de plan de contrôle provisionnés préallouent la capacité du plan de contrôle qui est toujours prête à faire face aux charges de travail exigeantes, afin qu'ils puissent absorber cette charge supplémentaire. Pour de plus amples informations, veuillez consulter Plan de contrôle provisionné Amazon EKS.
Considérations relatives au seuil de collecte des déchets dans les nacelles fermées
-
L'abaissement du seuil supprime immédiatement les pods terminés en excès. Si vous abaissez le seuil (par exemple, de
12500à10000), le contrôleur de collecte des déchets commence à supprimer de force les pods les plus anciens lors de son cycle suivant. Le contrôleur continue jusqu'à ce que le nombre de modules terminés atteigne le nouveau seuil. La réduction n'est pas progressive. -
Le seuil s'applique à tous les pods résiliés, quel que soit leur propriétaire. Cela affecte les pods en
FailedphaseSucceededou, qu'ils appartiennent à une tâche CronJob, à un déploiement ou qu'ils soient autonomes. Dans la pratique, Job et les CronJob pods sont les contributeurs les plus courants au nombre de pods interrompus. -
L'abaissement du seuil réduit la fenêtre de débogage. Les modules terminés et échoués disparaissent de
kubectl get podsetkubectl logsplus tôt. L'automatisation qui inspecte les codes de sortie ou les journaux des modules de tâches terminés dispose d'une fenêtre de fonctionnement plus petite. -
Le seuil est un paramètre de cluster global. Vous ne pouvez pas le configurer par espace de noms ou par Job. Pour contrôler le cycle de vie des modules d'un Job individuel,
ttlSecondsAfterFinishedutilisez-le pour ce Job.
Serveur API : conservation des événements
Le serveur API est l'interface du plan de contrôle Kubernetes. Il sert l'API Kubernetes et conserve l'état du cluster dans la base de données du cluster (etc.). Kubernetes enregistre les événements pour décrire ce qui se passe dans votre cluster, tels que les décisions relatives à la planification des pods, l'extraction d'images, les échecs de vérification de l'état et les actions de dimensionnement.
| Champ | Description | Valeurs prises en charge | Par défaut |
|---|---|---|---|
|
|
Durée pendant laquelle le serveur d'API conserve les événements Kubernetes avant de les supprimer. |
|
|
Les clusters exécutant des charges de travail à taux de désabonnement élevé, telles que des tâches par lots à grande échelle, des charges de travail basées sur l'IA, des CI/CD pipelines, etc. CronJobs, accumulent rapidement des milliers d'événements. Chaque événement retenu consomme de l'espace dans la base de données du cluster qui entre en concurrence avec les objets dont votre cluster a besoin pour fonctionner, et une collection d'événements importante rend les opérations de liste de serveurs d'API plus coûteuses à gérer.
La réduction de la durée de conservation des événements efface plus rapidement ces données de diagnostic éphémères, ce qui réduit la pression de stockage des bases de données du cluster et améliore les temps de réponse des serveurs API pour les requêtes comportant de nombreux événements.
Une période de conservation plus courte convient parfaitement lorsque :
-
Votre cluster exécute des charges de travail par lots CI/CD, de l'IA ou CronJob des charges de travail qui génèrent un volume élevé d'événements.
-
Vous constatez que le stockage des bases de données en cluster atteint ses limites.
-
Vous vous fiez à un système externe pour capturer les événements de manière durable, et vous n'en dépendez pas
kubectl get eventspour le débogage historique.
Considérations relatives à la conservation des événements
-
Une modification ne s'applique qu'aux nouveaux événements. Kubernetes définit l'expiration d'un événement lors de sa création. Les événements qui existent déjà conservent la période de conservation en vigueur au moment de leur création et expirent selon ce calendrier. Le raccourcissement
eventTtlne réduit pas la durée de vie des événements déjà présents dans la base de données du cluster. La réduction du stockage prend donc effet progressivement à mesure que les événements existants expirent. -
Les événements supprimés ne peuvent pas être récupérés. Une fois que Kubernetes a supprimé un événement, celui-ci est définitivement supprimé. Si vous réduisez la durée de conservation plus que prévu et que vous perdez l'historique des événements, il n'y a aucun moyen de le restaurer. Vérifiez que tout ce dont vous dépendez pour le dépannage est capturé en dehors du cluster avant de raccourcir cette valeur.
-
Les événements peuvent persister légèrement au-delà de la période configurée. Dans certaines conditions, l'expiration d'un événement peut être prolongée au-delà de la valeur que vous avez configurée en raison du renouvellement du bail ETCD qui peut avoir lieu lors de l'élection du leader du plan de contrôle.
-
Fenêtre de débogage réduite. Une période de rétention plus courte réduit la fenêtre indiquée par
kubectl get eventsetkubectl describe. Les outils de surveillance qui extraient les événements du cluster disposent de moins de données. Choisissez une valeur qui équilibre l'efficacité du stockage par rapport à votre flux de travail de débogage. -
Le paramètre s'applique à l'ensemble du cluster. La rétention s'applique à tous les événements, y compris la planification des pods, les conditions des nœuds et les événements de dimensionnement, dans tous les espaces de noms. Vous ne pouvez pas définir des périodes de conservation différentes par espace de noms.
Serveur API : plage de ports du nœud de service
Kubernetes alloue un port à partir de cette plage sur chaque nœud pour chaque service qui en a besoin. Cela inclut les services de type NodePort et, par défaut, les services de typeLoadBalancer.
| Champ | Description | Valeurs prises en charge | Par défaut |
|---|---|---|---|
|
|
Le port le plus bas de la gamme. |
|
|
|
|
Le port le plus haut de la gamme. |
|
|
minPortdoit être inférieur ou égal àmaxPort. Amazon EKS rejette une configuration dont la minPort valeur est supérieure àmaxPort.
En modifiant la plage, vous pouvez aligner l'allocation des ports des nœuds sur les politiques de réseau et de pare-feu que votre organisation applique déjà. L'élargissement de la gamme augmente également le nombre de services qu'un seul cluster peut prendre en charge. Ce paramètre est particulièrement utile lors des migrations. Les applications qui migrent vers Amazon EKS et les clients qui les appellent attendent souvent des services sur des ports fixes spécifiques. Lorsque ces ports se situent en dehors de la plage par défaut, les options habituelles consistent à modifier l'application ou à placer un proxy devant celle-ci. L'alignement de la plage avec les ports que vos applications utilisent déjà supprime ce travail. Vous pouvez donc déplacer des charges de travail vers EKS sans les réécrire ni ajouter des composants réseau à gérer.
Pourquoi la plage est limitée à 10260 et 32767
La limite inférieure de 10260 empêche l'NodePortallocation des ports que les composants du système Kubernetes de vos nœuds utilisent déjà, y compris le port d'état de kubelet () et le port de contrôle de santé de kube-proxy (10248). 10256
La limite supérieure de 32767 maintient la plage en dehors de la plage de ports éphémères Linux, qui commence généralement à. 32768 Si a NodePort tombait dans la plage éphémère, le noyau pourrait sélectionner ce port pour une connexion sortante depuis le nœud et entrer en conflit avec le service.
Considérations relatives à la plage de ports du nœud de service
-
Les services existants conservent les ports qui leur sont attribués. Si vous réduisez la plage, les services qui possèdent déjà un port en dehors de la nouvelle plage continuent de fonctionner et kube-proxy continue d'acheminer le trafic vers eux. Amazon EKS ne réaffecte pas les ports pour les services existants lorsque la plage change.
-
La recréation d'un service permet de réattribuer son port. Si un service contenant un port hors de portée est supprimé et recréé, ce port ne peut plus être attribué. Prévoyez cela avant de restreindre la gamme dont dépendent les services existants, en particulier si votre processus de déploiement recrée les services au lieu de les mettre à jour.
-
Les nouvelles allocations en dehors de la fourchette sont rejetées. La création ou la mise à jour d'un service qui nécessite un port en dehors de la plage configurée échoue en raison d'une erreur de validation provenant du serveur API.
-
Les ports explicitement spécifiés sont également validés. Si un service spécifie une
nodePortvaleur directement au lieu de laisser Kubernetes en attribuer une, ce port doit se situer dans la plage configurée. Une demande de port statique en dehors de la plage est rejetée, même si le même port était valide dans une plage plus large que vous avez configurée précédemment. -
La gamme s'étend à l'ensemble du cluster. Vous ne pouvez pas configurer différentes plages pour différents espaces de noms.
Avant de modifier ce paramètre, vérifiez que vos groupes de sécurité et vos ACL réseau autorisent le trafic sur la nouvelle plage et que celle-ci n'entre pas en conflit avec les ports utilisés par d'autres logiciels sur vos nœuds.
Considérations
Consultez les points suivants avant de configurer les paramètres avancés du plan de contrôle.
-
Cluster-wide scope : les paramètres du plan de contrôle s'appliquent à l'ensemble du cluster et à toutes les charges de travail qui y sont exécutées. Vous ne pouvez pas les étendre à des espaces de noms ou à des charges de travail individuels. Testez les modifications de paramètres dans un cluster hors production avant de les appliquer à la production.
-
Plan de contrôle provisionné requis pour la période de synchronisation de Horizontal Pod Autoscaler et le seuil de collecte des déchets du pod terminé — Les
terminatedPodGcThresholdparamètreshorizontalPodAutoscalerSyncPeriodet ne sont disponibles que sur les clusters utilisant le plan de contrôle provisionné Amazon EKS. Amazon EKS limite les paramètres qui augmentent sensiblement la consommation des ressources du plan de contrôle aux clusters dotés d'une capacité de plan de contrôle pré-allouée. La définition de l'un ou l'autre des paramètres sur un cluster en mode plan de contrôle standard échoue. Pour les utiliser, déplacez d'abord votre cluster vers un niveau de mise à l'échelle du plan de contrôle provisionné. Pour de plus amples informations, veuillez consulter Plan de contrôle provisionné Amazon EKS. -
Restriction de sortie pour la période de synchronisation de Horizontal Pod Autoscaler et le seuil de collecte des déchets des pods terminés — Si
horizontalPodAutoscalerSyncPeriodouterminatedPodGcThresholdest définie sur une valeur autre que la valeur par défaut, vous ne pouvez pas déplacer le plan de contrôle de votre cluster du mode provisionné vers le mode Standard. Pour revenir au mode Standard, rétablissez d'abord les valeurs par défaut des deux paramètres (15set12500), puis modifiez le niveau de mise àstandardl'échelle du plan de contrôle sur. -
Retour aux valeurs par défaut : Amazon EKS ne propose pas d'opération de réinitialisation dédiée, et l'omission d'un champ lors d'une mise à jour permet de conserver sa valeur actuelle au lieu de l'effacer. Pour rétablir la valeur par défaut d'un paramètre, définissez-lui explicitement la valeur par défaut. Récupérez la valeur par défaut
DescribeClusterVersionspour la version de Kubernetes exécutée par votre cluster. Pour de plus amples informations, veuillez consulter Configurer les paramètres avancés du plan de contrôle de Kubernetes. -
Sémantique des mises à jour : les mises à jour fusionnent avec votre configuration existante. Seuls les champs que vous spécifiez sont modifiés et les champs que vous omettez conservent leurs valeurs actuelles. Cela s'applique à la fois à tous les composants et au sein d'un seul composant. Par exemple, une mise à jour qui spécifie uniquement la configuration du planificateur laisse inchangée la configuration de votre gestionnaire de contrôleurs et de votre serveur d'API.
-
Affichage de la configuration actuelle — L'
describe-clusteropération renvoie la configuration complète exécutée sur votre plan de contrôle, y compris les paramètres que vous n'avez pas personnalisés et leurs valeurs par défaut. -
Les valeurs par défaut et les valeurs prises en charge peuvent changer entre les versions de Kubernetes. Les valeurs décrites dans cette rubrique s'appliquent aux versions de Kubernetes disponibles au moment de la publication. Permet
DescribeClusterVersionsde récupérer les valeurs par défaut actuelles et les valeurs prises en charge pour chaque paramètre et version de Kubernetes. Consultez Configurer les paramètres avancés du plan de contrôle de Kubernetes. -
Les clusters existants restent inchangés : Amazon EKS ne modifie pas le comportement des clusters existants. Tous les clusters continuent de fonctionner avec les valeurs de paramètres par défaut jusqu'à ce que vous définissiez explicitement un paramètre.
-
Les modifications ne sont pas appliquées instantanément — Une modification de configuration n'est pas effective lors des
UpdateClusterConfigretours. Amazon EKS applique la nouvelle configuration par le biais d'une mise à jour continue de votre plan de contrôle. Prévoyez donc quelques minutes avant que la modification ne prenne pleinement effet. Le cluster revient à sonACTIVEétat une fois la mise à jour terminée. Vous pouvez suivre la progression à l'aide de l'DescribeUpdateopération, ou bloquer jusqu'à ce que la modification soit terminée à l'aide deaws eks wait cluster-active. -
Auditabilité : Amazon EKS valide chaque configuration avant de l'appliquer et enregistre les modifications de configuration dans. AWS CloudTrail
-
Support des outils : la configuration avancée du plan de contrôle de Kubernetes est disponible via eksctl Console de gestion AWS, AWS CLI, AWS CloudFormation API Amazon EKS et CDK au lancement. AWS La prise en charge des AWS contrôleurs pour Kubernetes (ACK) et Terraform sera bientôt disponible.
-
Prise en charge de la version Kubernetes : la configuration avancée du plan de contrôle de Kubernetes est prise en charge sur les clusters nouveaux et existants exécutant Kubernetes version 1.31 ou ultérieure.
-
AWS Support régional : la configuration avancée du plan de contrôle Kubernetes est disponible dans toutes les régions AWS commerciales, les régions AWS GovCloud (États-Unis) et les régions de AWS Chine où Amazon EKS est disponible.
-
Tarification — La configuration des paramètres du plan de contrôle est gratuite. L'utilisation
horizontalPodAutoscalerSyncPeriodnécessite un plan de contrôle provisionné, qui est facturé au taux horaire correspondant à votre niveau de mise à l'échelle. Pour plus d’informations, consultez les tarifs Amazon EKS.
Étapes suivantes
-
Configurer les paramètres avancés du plan de contrôle de Kubernetes— Définissez et visualisez les paramètres du plan de contrôle à l'aide de l' AWS interface de ligne de commande et Console de gestion AWS.
-
Plan de contrôle provisionné Amazon EKS— capacité Pre-allocate du plan de contrôle pour des performances prévisibles et élevées.
