Le Vertical Pod Autoscaler (VPA) ajuste la taille de vos pods en modifiant automatiquement les réservations de CPU et de mémoire selon l'utilisation réelle. Cette approche libère des ressources pour d'autres pods et élimine le besoin de régler manuellement les requêtes et les limites. Le VPA convient particulièrement aux applications avec état qui nécessitent une disponibilité stable des ressources.
Le VPA est en version bêta et n'a pas été testé à grande échelle. Utilisez-le avec prudence. Pour signaler des problèmes, soumettez un ticket.
Pour obtenir une vue d'ensemble de toutes les options de mise à l'échelle dans ACK, y compris la mise à l'échelle horizontale des pods et la mise à l'échelle des nœuds, consultez la vue d'ensemble de la mise à l'échelle automatique. Pour plus d'informations sur les fonctionnalités du VPA, les notes d'utilisation et les limites connues, reportez-vous à l'introduction au VPA de la communauté Kubernetes.
Fonctionnement
Le VPA est implémenté sous forme de composant ack-vertical-pod-autoscaler et se compose de trois contrôleurs :
| Composant | Rôle |
|---|---|
recommender |
Surveille l'utilisation actuelle et passée des ressources des conteneurs et génère des recommandations de ressources |
updater |
Vérifie si les configurations de ressources des pods sont correctes ; expulse les pods dont la configuration est obsolète afin qu'ils puissent être recréés avec les valeurs mises à jour |
admission-controller |
Intercepte les nouvelles demandes de création de pods et définit les requêtes de ressources recommandées avant le démarrage du pod. Avant d'installer l'admission-controller, vous devez utiliser un script pour générer un certificat TLS pour le webhook. |
Le VPA maintient le ratio entre les requêtes et les limites de ressources que vous avez défini dans la configuration initiale du conteneur.
Notes d'utilisation
La mise à jour des configurations de ressources redémarre les pods. Lorsque le VPA applique des modifications à un pod en cours d'exécution, le pod est arrêté puis recréé, potentiellement sur un nœud différent. Un mécanisme de mise à jour sur place (sans redémarrage) existe, mais il est encore en phase de test.
Le VPA n'expulse pas les pods situés en dehors des contrôleurs de réplication. Pour ces pods, le mode
Autose comporte comme le modeInitial: le VPA définit les ressources pour les nouveaux pods, mais ne touche pas à ceux qui sont déjà en cours d'exécution.N'assignez pas plusieurs VPA à la même charge de travail. Si plusieurs VPA correspondent simultanément à un pod, le comportement devient imprévisible.
Les recommandations du VPA peuvent dépasser les ressources disponibles. Si la requête recommandée dépasse la capacité du nœud, les ressources inactives ou les quotas de ressources, le pod passe à l'état Pending. L'activation de la mise à l'échelle automatique des nœuds peut résoudre ce problème en provisionnant des nœuds supplémentaires.
N'utilisez pas le VPA et le HPA pour gérer la même métrique de CPU ou de mémoire. L'utilisation conjointe du VPA et du Horizontal Pod Autoscaler (HPA) sur la même métrique de ressource entraîne des conflits. Pour utiliser les deux simultanément, configurez le HPA afin qu'il suive uniquement des métriques personnalisées ou externes.
Le VPA utilise un webhook d'admission. Si d'autres webhooks d'admission existent dans le cluster, assurez-vous qu'ils n'entrent pas en conflit avec le VPA. Les paramètres de configuration du serveur API définissent l'ordre d'exécution des contrôleurs d'admission.
Le VPA gère la plupart des événements d'épuisement de la mémoire (OOM), mais ne peut pas garantir la récupération dans tous les cas.
Pour la liste complète des limitations en amont, consultez les limitations connues du VPA.
Étape 1 : Installer ack-vertical-pod-autoscaler
La méthode d'installation dépend de la version Kubernetes de votre cluster :
| Version Kubernetes | Méthode d'installation |
|---|---|
| 1,26 ou ultérieure | Console (recommandé) |
| Antérieure à 1,26 | kubectl |
Installer via la console (Kubernetes 1,26 ou ultérieure)
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Un cluster géré ACK exécutant Kubernetes 1,26 ou une version ultérieure. Pour en créer un, consultez Créer un cluster géré ACK. Pour mettre à niveau un cluster existant, consultez Mettre à jour manuellement un cluster ACK.
kubectl configuré pour se connecter au cluster. Consultez Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour s'y connecter.
Si vous avez précédemment installé le VPA à l'aide de kubectl, désinstallez-le d'abord, puis réinstallez-le via la console. Consultez Migrer de la gestion par kubectl vers la gestion par console .
Étapes d'installation
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster que vous souhaitez gérer. Dans le volet de navigation de gauche, choisissez Operations > Add-ons.
Sur la page Add-ons, recherchez ack-vertical-pod-autoscaler et terminez l'installation selon les instructions affichées.
Installer via kubectl (Kubernetes antérieur à 1,26)
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Un cluster géré ACK exécutant une version de Kubernetes antérieure à 1,26. Pour en créer un, consultez Créer un cluster géré ACK.
kubectl configuré pour se connecter au cluster. Consultez Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour s'y connecter.
Toute installation existante du VPA supprimée du cluster afin d'éviter les conflits.
Étapes d'installation
Étape 1 : Créer les permissions RBAC
Enregistrez le code YAML suivant sous le nom rbac.yaml, puis appliquez-le :
kubectl apply -f rbac.yaml
Étape 2 : Créer les CustomResourceDefinitions (CRD)
Enregistrez le YAML CRD correspondant à votre version Kubernetes sous le nom crd.yaml, puis appliquez-le :
kubectl apply -f crd.yaml
Les CRD étendent l'API Kubernetes pour prendre en charge les ressources VPA. Pour plus d'informations, consultez Étendre l'API Kubernetes avec des CustomResourceDefinitions .
Étape 3 : Installer les composants VPA
Installez les composants admission-controller, recommender et updater. Utilisez le YAML correspondant à votre version Kubernetes.
Étape 2 : Vérifier que le VPA fonctionne
Déployez une charge de travail de test et vérifiez que le VPA génère des recommandations pour celle-ci.
1. Créez un Deployment de test.
Enregistrez le contenu suivant sous le nom nginx-deployment-basic.yaml et appliquez-le. Laissez les champs requests et limits vides : le VPA recommandera des valeurs basées sur l'utilisation observée.
kubectl apply -f nginx-deployment-basic.yaml
2. Créez une ressource VPA ciblant le Deployment.
Enregistrez le contenu suivant sous le nom nginx-deployment-basic-vpa.yaml et appliquez-le. Le champ updateMode contrôle la manière dont le VPA applique ses recommandations :
| Mode | Comportement |
|---|---|
Off (recommandé) |
Génère des recommandations basées sur la consommation de ressources du cluster, mais ne met pas automatiquement à jour les configurations de ressources des pods |
Auto |
Génère des recommandations et met automatiquement à jour les ressources des pods |
kubectl apply -f nginx-deployment-basic-vpa.yaml
3. Consultez les recommandations.
Exécutez la commande suivante. Les recommandations apparaissent généralement dans un délai de deux minutes, le temps que le recommender analyse l'utilisation des ressources des pods :
kubectl describe vpa nginx-deployment-basic-vpa
La sortie inclut une section Recommendation similaire à celle-ci :
Les valeurs Target correspondent aux requêtes de ressources recommandées par le VPA pour le conteneur nginx. La valeur Lower Bound représente l'allocation minimale sûre, tandis que Upper Bound indique le seuil au-delà duquel les ressources sont probablement gaspillées. Utilisez les valeurs Target comme point de départ lors de la définition explicite des requests dans la configuration de votre Deployment. Le VPA continue de surveiller l'utilisation et affine ses recommandations au fil du temps.
Migrer de la gestion par kubectl vers la gestion par console
Pour les clusters exécutant Kubernetes 1,26 ou une version ultérieure, migrez vers le VPA géré par la console afin de simplifier les opérations et de réduire la charge de maintenance. Cette procédure nécessite la désinstallation du VPA installé via kubectl, suivie d'une réinstallation via la console.
Étape 1 : Sauvegarder la configuration VPA existante
Avant la désinstallation, exportez le YAML VPA actuel pour préserver votre configuration. Dans le fichier exporté, conservez uniquement les champs name et namespace sous metadata et supprimez entièrement le champ status. Enregistrez le fichier nettoyé pour une utilisation ultérieure.
kubectl get vpa nginx-deployment-basic-vpa -oyaml
Le YAML exporté ressemble à ceci :
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling.k8s.io/v1","kind":"VerticalPodAutoscaler","metadata":{"annotations":{},"name":"nginx-deployment-basic-vpa","namespace":"default"},"spec":{"targetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx-deployment-basic"},"updatePolicy":{"updateMode":"Off"}}}
creationTimestamp: "2024-02-29T06:03:35Z"
generation: 1
name: nginx-deployment-basic-vpa
namespace: default
resourceVersion: "56264"
uid: 9f128737-d12e-46f6-b254-c1a7505c19c6
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment-basic
updatePolicy:
updateMode: "Off"
status:
conditions:
- lastTransitionTime: "2024-02-29T06:03:55Z"
status: "True"
type: RecommendationProvided
recommendation:
containerRecommendations:
- containerName: nginx
lowerBound:
cpu: 25m
memory: 262144k
target:
cpu: 25m
memory: 262144k
uncappedTarget:
cpu: 25m
memory: 262144k
upperBound:
cpu: 25m
memory: 262144k
Étape 2 : Supprimer l'installation VPA existante
Supprimez toutes les ressources installées par le VPA existant afin d'éviter les conflits avec la nouvelle installation :
# Delete Deployments and Service
kubectl delete deployment vpa-admission-controller vpa-recommender vpa-updater -n kube-system
kubectl delete svc vpa-webhook -n kube-system
# Delete ClusterRoles
kubectl delete clusterrole system:metrics-reader system:vpa-actor system:vpa-status-actor system:vpa-checkpoint-actor system:evictioner system:vpa-target-reader system:vpa-admission-controller system:vpa-status-reader
# Delete ClusterRoleBindings
kubectl delete clusterrolebinding system:metrics-reader system:vpa-actor system:vpa-status-actor system:vpa-checkpoint-actor system:vpa-target-reader-binding system:vpa-evictioner-binding system:vpa-admission-controller system:vpa-status-reader-binding
# Delete ServiceAccounts
kubectl delete sa vpa-admission-controller vpa-recommender vpa-updater -n kube-system
# Delete Secret
kubectl delete secret vpa-tls-certs -n kube-system
# Delete CRDs
kubectl delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io verticalpodautoscalers.autoscaling.k8s.io
Étape 3 : Installer ack-vertical-pod-autoscaler via la console
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster que vous souhaitez gérer. Dans le volet de navigation de gauche, choisissez Operations > Add-ons.
Sur la page Add-ons, recherchez ack-vertical-pod-autoscaler et terminez l'installation selon les instructions affichées.
Étape 4 : Redéployer vos ressources VPA
Appliquez le fichier YAML nettoyé enregistré à l'étape 1 pour restaurer votre configuration VPA :
kubectl apply -f nginx-deployment-basic-vpa.yaml
Étapes suivantes
Pour mettre à l'échelle les pods en fonction de l'utilisation du processeur, de la mémoire ou de métriques personnalisées, consultez Mettre en œuvre la mise à l'échelle horizontale des pods.
Pour mettre à l'échelle les pods selon un calendrier fixe, consultez Utiliser CronHPA pour la mise à l'échelle horizontale planifiée.
Pour détecter automatiquement les cycles d'utilisation des ressources et effectuer une mise à l'échelle basée sur des modèles historiques, consultez la vue d'ensemble d'AHPA.
Pour créer des politiques de mise à l'échelle pilotées par des événements basées sur des files d'attente de messages, des métriques personnalisées ou des événements Kubernetes, consultez ACK KEDA.