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 et les limites de CPU et de mémoire pour les conteneurs dans les pods.
Sur cette page, vous découvrirez le fonctionnement de l'autoscaling vertical des pods, ses avantages et ses limites, les bonnes pratiques pour l'utiliser, et vous aurez accès aux références de l'API pour la ressource personnalisée VerticalPodAutoscaler et les types associés.
Cette page s'adresse aux opérateurs et aux développeurs qui provisionnent et configurent des ressources cloud, déploient des charges de travail et gèrent la mise à l'échelle 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 demandes et limites de ressources dans Kubernetes.
Pour les besoins d'évolutivité 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.
Fonctionnement de l'autoscaling de pods vertical
L'autoscaling de pods vertical vous permet d'analyser et de définir les ressources de processeur et de mémoire requises par les pods. Plutôt que d'avoir à configurer des demandes et limites de ressources de processeur et des demandes et limites de ressources de mémoire à jour pour les conteneurs de vos pods, vous pouvez configurer l'autoscaling de pods vertical pour qu'il fournisse les valeurs recommandées pour les demandes et limites de ressources de processeur et de mémoire pouvant vous permettre de mettre à jour manuellement vos pods, ou pour mettre à jour automatiquement les valeurs.
L'autoscaling de pods vertical est activé par défaut dans les clusters Autopilot.
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 ses demandes de ressources. L'éviction est nécessaire, car en raison des limitations de Kubernetes dans les versions antérieures à 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 de pods vertical 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 de pod sans recréer le pod. Bien que ce mode ne garantisse pas l'absence de perturbations, il peut contribuer à les réduire tout en bénéficiant de l'autoscaling de pods vertical.
Pour utiliser le mode InPlaceOrRecreate, définissez le champ spec.updatePolicy.updateMode sur "InPlaceOrRecreate" dans votre objet VerticalPodAutoscaler.
Si l'autoscaling vertical des pods détermine qu'une mise à jour sur place n'est pas possible, il revient au comportement du mode Auto, qui évince et recrée le pod pour appliquer les modifications.
Le mode InPlaceOrRecreate est disponible avec Kubernetes 1.34.0-gke.1709000 et versions ultérieures.
Pour en savoir plus sur le comportement et les limites existantes du mode InPlaceOrRecreate, consultez l'annonce Kubernetes concernant les mises à jour sur place.
Avantages
L'autoscaling de pods vertical 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.
- Le temps de maintenance est réduit, 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 de pods vertical 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 de l'historique, en fournissant des métriques recueillies avant l'activation de l'autoscaling de pods vertical.
- Il exécute les pods de l'autoscaling de pods verticaux en tant que processus de plan de contrôle, au lieu de déploiements sur vos nœuds de calcul.
Limites
- Pour utiliser l'autoscaling de pods vertical avec l'autoscaling horizontal de pods, utilisez l'autoscaling de pods multidimensionnels. Vous pouvez également utiliser l'autoscaling de pods vertical avec l'autoscaling horizontal de pods sur les métriques personnalisées et externes.
- L'autoscaling de pods vertical 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.
- L'autoscaling de pods vertical a un paramètre par défaut correspondant à deux instances dupliquées au minimum pour les déploiements visant à remplacer des pods en utilisant des valeurs de ressources révisées. Dans GKE 1.22 et dans les versions ultérieures, vous pouvez remplacer ce paramètre en spécifiant une valeur pour
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, lorsque vous augmentez la taille du pod au-delà de la capacité du nœud), l'autoscaling vertical des pods évince et recrée le pod pour appliquer la recommandation. L'expulsion et la recréation se produisent même pour les pods dont la spécification contient unresizePolicypour éviter les recréations.
Bonnes pratiques
- Pour éviter toute perturbation dans la mise à jour des clusters, nous vous recommandons de limiter à moins de 1 000 le nombre d'objets
VerticalPodAutoscalerpar cluster. - L'autoscaling de pods vertical fonctionne mieux avec des charges de travail homogènes de longue durée.
Documentation de référence sur 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 souhaité 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 répliquées qui doivent être actives pour que l'outil de mise à jour puisse 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 | |
|---|---|
containerRecommendation |
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 une violation de ContainerResourcePolicy par la cible, cette dernière 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 qui donne des détails au sujet de la dernière transition d'un état à un autre. |
Étape suivante
- Apprenez à effectuer un scaling des demandes et des limites de ressources des conteneurs.
- Apprenez les bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE.
- Obtenez des informations sur l'autoscaler de cluster.