Cette page explique comment analyser et optimiser l'allocation de vos ressources pour améliorer l'efficacité de vos charges de travail dans Google Kubernetes Engine (GKE) à l'aide de l'autoscaling vertical des pods. En analysant l'utilisation des ressources de votre charge de travail au fil du temps, vous pouvez obtenir des recommandations d'optimisation et ajuster automatiquement les demandes de CPU et de mémoire, ainsi que les limites pour les conteneurs des pods.
Sur cette page, vous allez découvrir le fonctionnement de l'autoscaling vertical des pods, ses avantages et ses limites, ainsi que les bonnes pratiques pour l'utiliser. Vous accéderez également à la documentation de référence de l'API pour la ressource personnalisée VerticalPodAutoscaler et les types associés.
Cette page est destinée aux opérateurs et aux développeurs qui provisionnent et configurent des ressources cloud, déploient des charges de travail et gèrent le scaling des applications. Pour en savoir plus sur les rôles courants, consultez Rôles utilisateur et tâches courantes de GKE.
Avant de lire cette page, assurez-vous de connaître les requêtes et limites de ressources dans Kubernetes.
Pour les besoins de scaling rapide en réponse à une utilisation soudaine des ressources, utilisez l'autoscaler horizontal de pods.
Pour découvrir les bonnes pratiques concernant l'autoscaling, consultez la page Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE.
Pourquoi utiliser l'autoscaling vertical des pods
L'autoscaling vertical des pods offre les avantages suivants :
- Si vous définissez des demandes et des limites de ressources adaptées à vos charges de travail, vous pouvez améliorer leur stabilité et réduire les coûts. Si la taille des ressources de vos pods est inférieure à celle requise par vos charges de travail, votre application peut être limitée ou échouer en raison d'erreurs de saturation de mémoire. Si la taille de vos ressources est trop importante, vous encourez un gaspillage, et donc des factures plus élevées.
- Les nœuds de cluster sont utilisés efficacement, car les pods utilisent exactement ce dont ils ont besoin.
- Les pods sont programmés sur des nœuds disposant des ressources appropriées.
- Il n'est pas nécessaire d'exécuter des tâches d'analyse comparative chronophages pour déterminer les valeurs adéquates pour les demandes de ressources mémoire et de processeur.
- Vous pouvez réduire le temps de maintenance, car l'autoscaler peut ajuster les demandes de ressources de processeur et de mémoire au fil du temps, sans intervention de votre part.
- L'autoscaling vertical des pods fonctionne mieux avec des charges de travail homogènes de longue durée.
L'autoscaling vertical des pods GKE offre les avantages suivants par rapport à l'autoscaler Open Source de Kubernetes :
- Il prend en compte la taille maximale des nœuds et les quotas de ressources lors de la détermination de l'objectif de recommandation.
- Il notifie l'autoscaler de cluster pour ajuster la capacité des clusters.
- Il utilise les données historiques, y compris les métriques recueillies avant l'activation de l'autoscaling de pods vertical.
- Il exécute les pods VerticalPodAutoscaler en tant que processus de plan de contrôle, au lieu de déploiements sur vos nœuds de calcul.
Fonctionnement de l'autoscaling vertical des pods
L'autoscaling vertical des pods vous permet d'analyser et de définir les ressources de processeur et de mémoire requises par les pods. Au lieu de définir des demandes et limites de processeur et des demandes et limites de mémoire à jour pour les conteneurs de vos pods, vous pouvez configurer l'autoscaling vertical des pods pour fournir des valeurs recommandées pour les demandes et limites de processeur et de mémoire que vous pouvez utiliser pour mettre à jour manuellement vos pods, ou vous pouvez configurer l'autoscaling vertical des pods pour mettre à jour automatiquement les valeurs.
L'autoscaling vertical des pods est activé par défaut dans les clusters Autopilot.
Relation avec l'objet VerticalPodAutoscaler Open Source de Kubernetes
L'autoscaling vertical des pods GKE est basé sur l'API Kubernetes Open Source VerticalPodAutoscaler, mais il s'agit d'une implémentation distincte propre à GKE. L'implémentation GKE est conçue pour le scaling avec son propre outil de recommandation, mais conserve les mêmes types et champs d'API VerticalPodAutoscaler que ceux définis dans la version Open Source.
Pour en savoir plus, consultez la documentation Kubernetes sur l'autoscaling vertical des pods.
Modes d'autoscaling vertical des pods
Vous pouvez configurer la façon dont l'autoscaling vertical des pods applique les modifications de ressources en appliquant différents modes de mise à jour.
Mode Auto (Recreate)
En mode Recreate, l'autoscaling vertical des pods évince un pod s'il doit modifier les demandes de ressources du pod. L'éviction est nécessaire, car en raison des limites de Kubernetes dans les versions antérieures à la version 1.33, le seul moyen de modifier les demandes de ressources d'un pod en cours d'exécution est de le recréer.
Pour limiter le nombre de recréations de pods, utilisez un budget d'interruption de pod . Pour vous assurer que votre cluster pourra gérer les charges de travail redimensionnées, utilisez l'autoscaler de cluster et le provisionnement automatique des nœuds.
L'autoscaling vertical des pods prévient l'autoscaler de cluster de la mise à jour et fournit les ressources dont la charge de travail redimensionnée a besoin en amont de sa recréation, de façon à minimiser le temps d'interruption.
Mode Initial
Lorsque Initial est activé, l'autoscaling vertical des pods n'attribue des demandes de ressources que lors de la création du pod et ne les modifie jamais ultérieurement.
Mode InPlaceOrRecreate
Le mode InPlaceOrRecreate vise à réduire les interruptions de service en tentant de mettre à jour les ressources des pods sans les recréer.
Pour utiliser le mode InPlaceOrRecreate, définissez le champ spec.updatePolicy.updateMode sur "InPlaceOrRecreate" dans votre objet VerticalPodAutoscaler. Ce mode s'appuie sur le champ resizePolicy défini dans le fichier manifeste de votre charge de travail pour déterminer si une modification de ressource nécessite un redémarrage. Si le champ resizePolicy n'est pas défini, il est défini par défaut sur NotRequired pour le processeur et la mémoire, ce qui signifie que des mises à jour sur place sont tentées.
Si un conteneur s'arrête en raison d'un événement OOM (Out of Memory, mémoire insuffisante), l'autoscaling vertical des pods en mode InPlaceOrRecreate agit de la même manière qu'en mode Auto : il tire des enseignements de l'échec. Lors de la recréation ultérieure du pod déclenchée par le plantage, l'autoscaling vertical des pods applique une recommandation qui inclut un tampon de sécurité (généralement 20% de mémoire supplémentaire ou 100 Mo, selon la valeur la plus élevée) pour éviter que l'erreur OOM ne se reproduise immédiatement.
Le mode InPlaceOrRecreate est disponible avec Kubernetes 1.34.0-gke.2201000 et versions ultérieures.
Scénarios de remplacement pour le mode InPlaceOrRecreate
Si l'autoscaling vertical des pods détermine qu'une mise à jour sur place n'est pas possible, il revient au comportement du mode Recreate, qui supprime et recrée le pod pour appliquer les modifications. Voici quelques scénarios courants dans lesquels l'autoscaling vertical des pods revient à la recréation :
- Capacité de nœud insuffisante : la requête de ressource mise à jour dépasse la capacité d'allocation du nœud actuel, et la mise à jour ne peut pas être planifiée sur place (état "impossible" ou "différé" pendant une durée supérieure au délai avant expiration).
- Modification de la classe QoS : la mise à jour des ressources modifierait la classe de qualité de service (QoS) du pod, par exemple de
BurstableàGuaranteed. - Règle
RestartContainer: le champresizePolicydu pod est défini surRestartContainerpour une ressource que l'autoscaling vertical des pods tente de modifier. - Expirations : une requête de mise à jour sur place reste en attente trop longtemps.
Mode Off
En mode Off, l'autoscaling vertical des pods n'applique automatiquement aucune modification à un pod.
Vous pouvez toujours afficher les valeurs recommandées pour les demandes et les limites de processeur et de mémoire en fonction de l'historique d'utilisation, mais ces recommandations ne sont pas appliquées pour vous. Si nécessaire, vous pouvez appliquer manuellement les valeurs recommandées à vos pods.
Optimisation du processeur au démarrage
L'optimisation du processeur au démarrage accélère le démarrage des applications et améliore la rentabilité en augmentant temporairement les demandes de processeur pendant l'initialisation, puis en les redimensionnant à leur niveau de référence.
Pour en savoir plus sur la configuration de l'optimisation du processeur au démarrage, consultez Accélérer le démarrage des applications avec l'optimisation du processeur au démarrage.
Fonctionnement de l'optimisation du CPU au démarrage
L'optimisation du processeur au démarrage calcule une augmentation temporaire des ressources en fonction de la demande de processeur de référence de votre conteneur. Le pod revient à ce niveau de requête de référence après la phase de démarrage.
La boost augmente cette requête de référence d'un multiplicateur ou d'une quantité fixe. Cette demande élevée reste active jusqu'à ce que le pod soit prêt. Ensuite, GKE rétablit la demande de processeur à son niveau de référence.
Comprendre le cycle de vie d'un boost
Le processus d'accélération du démarrage se compose de trois phases :
- Phase d'admission : lors de l'admission du pod, le webhook d'admission du VPA intercepte la requête et injecte les valeurs de processeur boostées avant que GKE ne planifie le pod.
- Phase de démarrage : l'application s'initialise à l'aide de l'allocation de processeur temporairement élevée pour éviter la limitation de l'initialisation.
- Phase de réduction de l'augmentation : une fois que le pod a atteint l'état
Readyet que la périodedurationSecondsest écoulée, le VPA réduit la demande de processeur sur place à la valeur de base.
Choisir un mode de mise à jour pour les charges de travail boostées
Vous pouvez configurer l'optimisation du processeur au démarrage avec ou sans la gestion continue des ressources du VPA. La gestion continue des ressources du VPA ajuste automatiquement les demandes de ressources de vos pods une fois la phase de démarrage terminée. Pour choisir votre préférence, définissez le champ updateMode dans l'objet VPA. Pour en savoir plus sur les modes de mise à jour de l'autoscaling vertical des pods, consultez Modes d'autoscaling vertical des pods.
updateMode: "Off": le VPA ne gère que l'optimisation initiale lors de l'admission du pod (une phase de la création du pod) et la réduction ultérieure après le démarrage. Il ne modifie pas les requêtes de ressources en régime permanent de votre conteneur.updateMode: "Auto","Recreate"ou"InPlaceOrRecreate": le VPA gère l'accélération du démarrage et continue d'ajuster automatiquement les requêtes de ressources de votre pod en fonction de son utilisation actuelle.
Calcul de l'allocation des ressources d'optimisation du processeur
GKE calcule la demande de CPU temporairement boostée de la manière suivante :
Déterminez le processeur de base : la demande de processeur de référence dépend du champ VPA
updateMode:Auto,RecreateouInPlaceOrRecreate: la demande de processeur de référence est la recommandation du VPA. Si aucune recommandation n'existe, GKE utilise la demande de processeur définie dans la spécification du pod.Off: la demande de processeur de référence est la valeur de la demande provenant de la spécification du pod.
Calculer le processeur boosté : le calcul dépend de la méthode de calcul que vous spécifiez dans le champ de configuration du boost
type:Factor: applique un multiplicateur à la demande de processeur de base :Processeur optimisé = processeur de base ×
factorQuantity: ajoute une quantité absolue de CPU à la demande de CPU de base :Processeur optimisé = processeur de base +
quantity
La demande de processeur finale dépend du mode de votre cluster :
- Clusters standards : la demande de processeur finale correspond à la valeur de processeur boostée.
- Clusters Autopilot : la demande de processeur finale correspond à la valeur de processeur boostée, plafonnée par le processeur maximal autorisé pour la mémoire de pod allouée.
Comprendre le comportement de la limite de processeur lors d'une optimisation
La façon dont GKE gère les limites de processeur dépend du paramètre controlledValues dans votre containerResourcePolicy :
RequestsAndLimits(par défaut) : GKE augmente à la fois la demande et la limite de processeur, en conservant leur ratio d'origine pour préserver la classe de qualité de service (QoS) du conteneur.RequestsOnly: GKE n'augmente que la demande de processeur. GKE plafonne la requête boostée juste en dessous de toute limite de processeur définie pour préserver la qualité de service.
Remarques concernant les clusters Autopilot
Étant donné que GKE Autopilot applique des plages de ratios processeur/mémoire et des tailles de pods minimales spécifiques, GKE évalue les boosts lors de l'admission des pods pour garantir la conformité. Un boost peut être modifié ou ignoré dans les scénarios suivants :
- Minimums Autopilot : si la requête boostée est inférieure aux exigences minimales de processeur pour les charges de travail Autopilot (par exemple, 50 m pour les pods à usage général), GKE n'applique pas le boost et applique les minimums standards.
- Plafonnement du ratio (boosts partiels ou ignorés) : si la demande de CPU boostée dépasse la plage de ratio CPU/mémoire requise, GKE plafonne le boost à la valeur la plus élevée qui respecte la mémoire allouée. Si la requête de pod d'origine utilise déjà le ratio processeur/mémoire maximal autorisé, GKE ignore l'augmentation pour éviter le redimensionnement de la mémoire.
- ComputeClass avec scaling horizontal : la ComputeClass avec scaling horizontal applique un ratio strict de 1:4 (processeur:mémoire). Si vous essayez de booster le processeur d'un pod de scaling horizontal sans augmenter sa mémoire, GKE risque d'ignorer le boost.
Règles de ressources
Vous pouvez utiliser ContainerResourcePolicy pour personnaliser la façon dont l'autoscaling vertical des pods génère des recommandations pour des conteneurs spécifiques. Cette règle vous permet de définir des contraintes et de contrôler les ressources qui sont mises à l'échelle.
Limites minimale et maximale
Vous pouvez spécifier les valeurs de ressources minimale (minAllowed) et maximale (maxAllowed) pour un conteneur.
minAllowed: l'autoscaling vertical des pods ne recommande pas de valeur inférieure à cette limite. Cette limite est utile, car elle permet de garantir un niveau de performances de référence ou de répondre aux exigences spécifiques de l'application.maxAllowed: l'autoscaling vertical des pods ne recommande pas de valeur supérieure à cette limite. Cette limite est utile pour contrôler les coûts ou empêcher un seul conteneur de consommer trop de ressources de nœud.
Ressources contrôlées
Par défaut, l'autoscaling vertical des pods calcule des recommandations pour le processeur et la mémoire. Vous pouvez utiliser le champ controlledResources pour spécifier les ressources à autoscaler. Par exemple, vous pouvez configurer l'autoscaler pour qu'il ne fournisse des recommandations que pour la mémoire, en laissant les demandes de processeur inchangées.
Limites
- Pour utiliser l'autoscaling vertical des pods avec l'autoscaling horizontal des pods sur le processeur, utilisez le redimensionnement HPA avec VPA (preview) ou l'autoscaling multidimensionnel des pods. Vous pouvez également utiliser l'autoscaling vertical des pods avec l'autoscaling horizontal des pods sur les métriques personnalisées et externes.
- L'autoscaling vertical des pods n'est pas encore prêt pour une utilisation avec des charges de travail basées sur JVM en raison d'une visibilité limitée sur l'utilisation réelle de la mémoire de la charge de travail.
- Dans GKE 1.35.1 et les versions antérieures, l'autoscaling vertical des pods a un paramètre par défaut correspondant à deux instances répliquées au minimum pour les déploiements visant à remplacer des pods en utilisant des valeurs de ressources révisées. Dans la version 1.35.2 et les versions ultérieures, la valeur par défaut est d'une instance répliquée minimale. Dans la version 1.22 et les versions ultérieures, vous pouvez remplacer ce paramètre en spécifiant une valeur pour le champ
minReplicasdans le champ PodUpdatePolicy. - Si vous utilisez le mode de mise à jour
InPlaceOrRecreatede l'autoscaling vertical des pods et qu'une mise à jour sur place n'est pas possible (par exemple, lors du scaling à la hausse du pod au-delà de la capacité du nœud), l'autoscaling vertical des pods supprime et recrée le pod pour appliquer la recommandation. L'éviction et la recréation se produisent même pour les pods dont le champresizePolicyest défini dans leur spécification pour éviter les recréations. Ce comportement se produit pour les requêtes de redimensionnement Autopilot, y compris lors de l'application des contraintes de ressources minimales et de ratio processeur/mémoire. - L'autoscaling vertical des pods nécessite un objet de charge de travail qui gère les pods, tel qu'un objet Deployment, StatefulSet, ReplicaSet ou ReplicationController. Vous ne pouvez pas utiliser l'autoscaling vertical des pods avec des pods autonomes, car un contrôleur de charge de travail est nécessaire pour gérer le processus de recréation des pods.
- L'autoscaling vertical des pods génère des recommandations et applique des mises à jour uniquement pour les demandes et les limites de ressources au niveau du conteneur (
spec.containers[].resources). L'autoscaling vertical des pods n'est pas compatible avec les spécifications de ressources au niveau du pod (spec.resources).
Bonnes pratiques
- Limitez le nombre d'objets
VerticalPodAutoscaler. Pour éviter toute perturbation dans la mise à jour des clusters, vous devez limiter à moins de 1 000 le nombre d'objetsVerticalPodAutoscalerpar cluster. - L'autoscaling vertical des pods fonctionne mieux avec des charges de travail homogènes de longue durée.
- Exécution de longue durée : charges de travail qui s'exécutent pendant au moins 24 heures. L'autoscaling vertical des pods nécessite une quantité importante de données historiques pour générer des recommandations fiables. En mode
AutoouRecreate, les mises à jour ont généralement lieu après qu'un pod a au moins 24 heures, ce qui permet d'éviter les redémarrages et les renouvellements fréquents de pods. - Homogènes : les pods ciblés par un seul objet
VerticalPodAutoscaler(par exemple, toutes les instances répliquées d'un déploiement) doivent présenter des modèles de consommation de ressources similaires. L'autoscaler vertical des pods génère des recommandations en agrégeant les données d'utilisation de tous les pods ciblés. Si vos instances répliquées ont une utilisation hétérogène (par exemple, certains pods sont inactifs et d'autres sont fortement chargés), l'autoscaler vertical des pods peut fournir une recommandation qui surprovisionne les pods inactifs ou sous-provisionne les pods occupés.
- Exécution de longue durée : charges de travail qui s'exécutent pendant au moins 24 heures. L'autoscaling vertical des pods nécessite une quantité importante de données historiques pour générer des recommandations fiables. En mode
- Utilisez l'autoscaling horizontal des pods pour les charges de travail présentant des pics de demande soudains. L'autoscaling vertical des pods est conçu pour un redimensionnement en régime permanent et ne constitue pas une solution pour les pics de ressources soudains et de courte durée. Pour les charges de travail présentant des fluctuations rapides du trafic ou de la demande de processeur ou de mémoire, utilisez plutôt l'autoscaler horizontal des pods.
- Exploitez la protection OOM. Bien que l'autoscaler vertical des pods soit réactif, il inclut une protection automatisée contre les événements de mémoire insuffisante (OOM). Si un pod est
OOMKilled, l'autoscaler vertical des pods observe immédiatement l'événement et augmente la recommandation de mémoire d'environ 20% (ou 100 Mo, selon la valeur la plus élevée) pour améliorer la stabilité lors de la recréation du pod. Pour en savoir plus sur les événements de mémoire insuffisante, consultez Résoudre les problèmes liés aux événements de mémoire insuffisante.
Documentation de référence de l'API
Il s'agit de la documentation de référence de l'API v1. Nous vous recommandons vivement d'utiliser cette version de l'API.
VerticalPodAutoscaler v1 autoscaling.k8s.io
| Champs | |
|---|---|
|
Groupe, version et type d'API. |
metadata |
Métadonnées d'objet standards. |
spec |
Comportement de |
status |
Dernier état observé de |
VerticalPodAutoscalerSpec v1 autoscaling.k8s.io
| Champs | |
|---|---|
targetRef |
Référence au contrôleur qui gère l'ensemble des pods que doit contrôler l'autoscaler, par exemple, un déploiement ou un StatefulSet.
Vous pouvez pointer un |
updatePolicy |
Indique si les mises à jour recommandées sont appliquées au démarrage d'un pod et pendant sa durée de vie. |
resourcePolicy |
Définit les stratégies concernant le traitement des demandes de ressources mémoire et de processeur pour des conteneurs individuels. La règle de ressources permet de définir des contraintes sur les recommandations pour des conteneurs individuels. S'il n'est pas spécifié, l'autoscaler calcule les ressources recommandées pour tous les conteneurs du pod, sans contraintes supplémentaires. |
recommenders |
Outil de recommandation responsable de la génération de recommandations pour cet objet autoscaler vertical de pods. Laissez ce champ vide pour utiliser l'outil de recommandation par défaut fourni par GKE. Sinon, la liste peut contenir exactement une entrée pour un outil de recommandation alternatif fourni par l'utilisateur. Compatibilité assurée depuis GKE 1.22. |
VerticalPodAutoscalerList v1 autoscaling.k8s.io
| Champs | |
|---|---|
|
Groupe, version et type d'API. |
metadata |
Métadonnées d'objet standards. |
items |
Liste d'objets |
PodUpdatePolicy v1 autoscaling.k8s.io
| Champs | |
|---|---|
updateMode |
Indique si les mises à jour recommandées sont appliquées au démarrage d'un pod et pendant sa durée de vie. Les valeurs possibles sont les suivantes :
|
minReplicas |
Nombre minimal d'instances dupliquées qui doivent être actives pour tenter d'évincer les pods (en attente d'autres vérifications telles que le budget d'interruption de pod).
Seules les valeurs positives sont autorisées. La valeur par défaut est |
PodResourcePolicy v1 autoscaling.k8s.io
| Champs | |
|---|---|
containerPolicies |
Tableau de stratégies relatives aux ressources pour des conteneurs individuels. Il peut y avoir au plus une entrée pour chaque conteneur nommé et, éventuellement, une seule entrée de caractère générique avec "containerName = '*'", qui gère tous les conteneurs dépourvus de règles individuelles. |
ContainerResourcePolicy v1 autoscaling.k8s.io
| Champs | |
|---|---|
containerName |
Nom du conteneur auquel s'applique la stratégie. S'il n'est pas spécifié, cette stratégie est celle par défaut. |
mode |
Indique si les mises à jour recommandées sont appliquées au démarrage d'un conteneur et pendant sa durée de vie. Les valeurs possibles sont "Off" et "Auto". La valeur par défaut est "Auto" si vous ne spécifiez pas de valeur. |
minAllowed |
Détermine le nombre minimum autorisé de demandes de ressources mémoire et de processeur pour le conteneur. Par défaut, aucun nombre minimum n'est appliqué. |
maxAllowed |
Détermine le nombre maximum autorisé de demandes de ressources mémoire et de processeur pour le conteneur. Par défaut, aucune limite n'est appliquée. |
controlledResources |
Spécifie le type de recommandations qui seront calculées (et éventuellement appliquées) par |
VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io
| Champs | |
|---|---|
name |
Nom de l'outil de recommandation responsable de la génération de recommandations pour cet objet. |
VerticalPodAutoscalerStatus v1 autoscaling.k8s.io
| Champs | |
|---|---|
recommendation |
Dernières demandes de ressources mémoire et de processeur recommandées. |
conditions |
Décrit l'état actuel de |
RecommendedPodResources v1 autoscaling.k8s.io
| Champs | |
|---|---|
containerRecommendations |
Tableau de recommandations de ressources pour des conteneurs individuels. |
RecommendedContainerResources v1 autoscaling.k8s.io
| Champs | |
|---|---|
containerName |
Nom du conteneur auquel s'applique la recommandation. |
target |
Demande de ressources mémoire et de processeur recommandée pour le conteneur. |
lowerBound |
Nombre minimum recommandé de demandes de ressources mémoire et de processeur pour le conteneur. Il n'est pas garanti que cette valeur soit suffisante pour la stabilité de l'application. Il est probable qu'une exécution avec un nombre plus faible de demandes de ressources mémoire et de processeur ait un impact important sur les performances ou la disponibilité. |
upperBound |
Nombre maximum recommandé de demandes de ressources mémoire et de processeur pour le conteneur. Les demandes de ressources mémoire et de processeur dépassant ces valeurs risquent d'être gaspillées. |
uncappedTarget |
Dernière recommandation de ressources calculée par l'autoscaler, basée sur l'utilisation réelle des ressources, sans tenir compte de ContainerResourcePolicy. Si l'utilisation réelle des ressources entraîne le non-respect de la règle ContainerResourcePolicy par la cible, cette valeur peut être différente de la recommandation limitée. Ce champ n'a pas d'incidence sur l'attribution réelle des ressources. Il n'est utilisé qu'à des fins d'indication d'état. |
VerticalPodAutoscalerCondition v1 autoscaling.k8s.io
| Champs | |
|---|---|
type |
Type de condition décrite. Les valeurs possibles sont "RecommendationProvided", "LowConfidence", "NoPodsMatched" et "FetchingHistory". |
status |
État de la condition. Les valeurs possibles sont "True", "False" et "Unknown". |
lastTransitionTime |
Dernière transition de la condition entre un état et un autre. |
reason |
Raison de la dernière transition d'un état à un autre. |
message |
Chaîne au format lisible par l'humain qui donne des détails au sujet de la dernière transition d'un état à un autre. |
Étapes suivantes
- Découvrez comment configurer l'autoscaling vertical des pods.
- Découvrez comment redimensionner les charges de travail AHP avec VPA.
- Découvrez comment accélérer le démarrage des applications à l'aide de l'optimisation du processeur au démarrage.
- En savoir plus sur l'autoscaling horizontal des pods
- Apprenez-en davantage sur l'autoscaler de cluster.