Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Configurer l'autoscaling vertical des pods

L'autoscaling vertical des pods automatise la définition des demandes et des limites de ressources de processeur et de mémoire pour les conteneurs dans les pods Kubernetes. L'autoscaling vertical des pods analyse l'utilisation des ressources passée et actuelle pour fournir des recommandations, qu'il peut afficher ou appliquer automatiquement en mettant à jour les pods. Cette fonctionnalité améliore la stabilité et la rentabilité en ajustant les allocations de ressources.

Avant de commencer

Avant de configurer l'autoscaling de pods vertical, assurez-vous de respecter les prérequis suivants :

Vous disposez d'un cluster Bare Metal en cours d'exécution.
Vous disposez d'un accès kubectl au cluster.
Metrics Server est disponible dans le cluster. Les clusters Bare Metal incluent Metrics Server par défaut.

Activer l'autoscaling vertical des pods

Activez l'autoscaling vertical des pods sur votre cluster Bare Metal en configurant la spécification du cluster :

Modifiez la spec de la ressource personnalisée du cluster pour inclure le champ verticalPodAutoscaling et spécifiez les modes enableUpdater et enableMemorySaver :

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other cluster spec fields
  verticalPodAutoscaling:
    enableUpdater: true       # Set to true for automated updates
    enableMemorySaver: true   # Set to true to reduce recommender memory usage

Si vous avez modifié le fichier de configuration du cluster, appliquez les modifications à l'aide de la commande suivante :
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster
- KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster

Créer une ressource personnalisée `VerticalPodAutoscaler`

Après avoir activé l'autoscaling vertical des pods sur votre cluster, définissez une ressource personnalisée VerticalPodAutoscaler pour cibler des charges de travail spécifiques :

Définissez une ressource VerticalPodAutoscaler dans le même espace de noms que la charge de travail cible.

Cette ressource personnalisée spécifie les pods qu'elle cible à l'aide de targetRef et de toutes les règles de ressources.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
    containerPolicies:
      -   containerName: '*'
        minAllowed:
          cpu: 100m
          memory: 50Mi
        maxAllowed:
          cpu: 1
          memory: 500Mi
        controlledResources: ["cpu", "memory"]

Appliquez le fichier manifeste VerticalPodAutoscaler à l'aide de la commande suivante :
```
kubectl apply -f VPA_MANIFEST \
    --kubeconfig KUBECONFIG
```
Remplacez les éléments suivants :
- VPA_MANIFEST : chemin d'accès au fichier manifeste VerticalPodAutoscaler
- KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster

Comprendre les modes d'autoscaling vertical des pods

L'autoscaling vertical des pods fonctionne dans différents modes qui contrôlent la manière dont il applique les recommandations de ressources.

En mode Recommandation, l'autoscaling vertical des pods installe l'outil de recommandation. Ce composant analyse l'utilisation des ressources et publie les valeurs recommandées pour les demandes et les limites de ressources de processeur et de mémoire dans la section d'état des ressources personnalisées VerticalPodAutoscaler que vous créez.

Pour afficher les recommandations concernant les demandes et les limites de ressources, exécutez la commande suivante :

kubectl describe vpa VPA_NAME \
    --kubeconfig KUBECONFIG \
    -n CLUSTER_NAMESPACE

Replace the following:

*   `VPA_NAME`: the name of the `VerticalPodAutoscaler`
    that's targeting the workloads for which you are considering resource
    adjustments.

*   `KUBECONFIG`: the path of the cluster kubeconfig
    file.

*   `CLUSTER_NAMESPACE`: the name of the cluster that's
    running vertical Pod autoscaling.

La réponse doit contenir une section Status semblable à l'exemple suivant :

Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi

Les pods ne sont pas mis à jour automatiquement dans ce mode. Utilisez ces recommandations pour mettre à jour manuellement les configurations de vos pods. Il s'agit du comportement par défaut si enableUpdater n'est pas défini ou est false.

Mode de mise à jour automatique

Lorsque vous définissez enableUpdater enableUpdater sur true, les contrôleurs de cycle de vie bare metal déploient les composants de mise à jour et de contrôleur d'admission de l'autoscaling vertical des pods en plus de l'outil de recommandation. Le composant de mise à jour surveille les pods dont les demandes de ressources actuelles s'écartent considérablement des recommandations.

La règle de mise à jour dans la ressource VerticalPodAutoscaler spécifie comment le composant de mise à jour applique les recommandations. Par défaut, le mode de mise à jour est Auto, ce qui signifie que le composant de mise à jour attribue des paramètres de ressources mis à jour lors de la création du pod. L'exemple VerticalPodAutoscaler suivant montre comment définir le mode de mise à jour sur Initial :

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
  updatePolicy:
    updateMode: "Initial"
    ...

Le composant de mise à jour est compatible avec les cinq modes suivants :

Auto : le composant de mise à jour évince le pod. Le contrôleur d'admission intercepte la requête de création du nouveau pod et la modifie pour utiliser les valeurs de processeur et de mémoire recommandées fournies par le composant de recommandation. La mise à jour des ressources nécessite de recréer le pod, ce qui peut entraîner des interruptions. Utilisez les budgets d'interruptions de pods, que le composant de mise à jour respecte, pour gérer le processus d'éviction. Ce mode est équivalent à Recreate.
Recreate: le composant de mise à jour évince les pods et attribue les demandes et les limites de ressources recommandées lors de la recréation du pod.
InPlaceOrRecreate(alpha) : le composant de mise à jour tente d'effectuer des mises à jour sur place, mais peut revenir à la recréation du pod si les mises à jour sur place ne sont pas possibles. Pour en savoir plus, consultez la documentation sur le redimensionnement sur place des pods.
Initial: le composant de mise à jour n'attribue des demandes de ressources que lors de la création du pod et ne les modifie jamais ultérieurement.
Off: le composant de mise à jour ne modifie pas automatiquement les exigences de ressources des pods. Les recommandations sont calculées et peuvent être inspectées dans l'objet VerticalPodAutoscaler.

Pour en savoir plus sur la ressource personnalisée VerticalPodAutoscaler, utilisez kubectl pour récupérer la définition de ressource personnalisée verticalpodautoscalercheckpoints.autoscaling.k8s.io installée sur le cluster version 1.33.0 ou ultérieure.

L'exemple suivant montre comment les recommandations de ressources peuvent apparaître dans la section Status du conteneur hamster. L'exemple montre également un événement d'éviction de pod, qui se produit lorsque le composant de mise à jour évince un pod avant d'attribuer automatiquement la configuration de ressources recommandée au pod recréé :

Spec:
  Resource Policy:
    Container Policies:
      Container Name:  *
      Controlled Resources:
        cpu
        memory
      Max Allowed:
        Cpu:     1
        Memory:  500Mi
      Min Allowed:
        Cpu:     100m
        Memory:  50Mi
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         hamster
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi
Events:
  Type    Reason      Age   From         Message
  ----    ------      ----  ----         -------
  Normal  EvictedPod  49s   vpa-updater  VPA Updater evicted Pod hamster-7cb59fb657-lkrk4 to apply resource recommendation.

Mode Économiseur de mémoire

Le mode Économiseur de mémoire réduit l'empreinte mémoire du composant de recommandation de l'autoscaling de pods vertical. Lorsque vous définissez enableMemorySaver sur true, le composant de recommandation ne suit et ne calcule les agrégations que pour les pods qui disposent d'une ressource personnalisée VerticalPodAutoscaler correspondante.

L'inconvénient est que lorsque vous créez une ressource personnalisée VerticalPodAutoscaler pour une charge de travail existante, le composant de recommandation met un certain temps (jusqu'à 24 heures) à collecter suffisamment d'historique pour fournir des recommandations précises. Ce mode est false par défaut pour la plupart des types de clusters, mais il est true par défaut pour les clusters périphériques.

Utiliser Prometheus comme fournisseur d'historique persistant

Par défaut, le composant de recommandation conserve l'historique de consommation des ressources des charges de travail exécutées sur le cluster en mémoire et enregistre périodiquement son état dans une ressource personnalisée VerticalPodAutoscalerCheckpoint dans etcd pour assurer la résilience en cas de redémarrage.

À partir de Google Distributed Cloud version 1.34, vous pouvez utiliser votre propre instance de Prometheus comme fournisseur d'historique persistant pour les données de consommation de ressources, à savoir les métriques d'utilisation du processeur et de la mémoire. Lorsque cette intégration est activée, le composant de recommandation peut interroger le serveur Prometheus au démarrage ou au redémarrage pour récupérer les données historiques d'utilisation des ressources à long terme pour tous les pods gérés. La récupération de ces données permet au composant de recommandation de créer immédiatement son état interne avec un ensemble de données enrichi, ce qui permet de fournir des recommandations plus éclairées et plus précises dès le début.

L'utilisation de Prometheus comme fournisseur d'historique persistant offre les avantages suivants :

Optimisation de l'utilisation des ressources : génère des recommandations éclairées et précises dès le démarrage, ce qui vous permet d'optimiser l'utilisation des ressources du cluster.
Prévention des erreurs de mémoire insuffisante (OOM) : Prometheus élimine le besoin de stocker l'état interne de l'outil de recommandation dans des ressources personnalisées VerticalPodAutoscalerCheckpoint (CR), ce qui rend l'utilisation de la mémoire ETCD plus efficace. Lorsque le composant de recommandation redémarre, il perd les données historiques en mémoire. Lorsque vous utilisez Prometheus comme fournisseur d'historique, le composant de recommandation récupère les métriques historiques de Prometheus au redémarrage, ce qui élimine le besoin de la ressource personnalisée VerticalPodAutoscalerCheckpoint et économise la mémoire ETCD.

Vous pouvez activer et désactiver l'utilisation de Prometheus comme fournisseur d'historique persistant à tout moment.

Prérequis pour utiliser Prometheus avec l'autoscaling vertical des pods

Pour utiliser votre propre instance Prometheus comme fournisseur d'historique pour l'autoscaling de pods vertical, vous devez la configurer pour qu'elle récupère les métriques nécessaires. Pour cela, procédez comme suit :

Si nécessaire, déployez l'opérateur Prometheus dans le cluster pour lequel vous souhaitez l'utiliser comme fournisseur d'historique persistant pour l'autoscaling de pods vertical. Pour en savoir plus, consultez Déployer et configurer l' opérateur Prometheus dans Kubernetes.

Configurez les autorisations pour récupérer les métriques.

Pour autoriser Prometheus à récupérer les métriques de cAdvisor à l'aide d'un fichier de configuration, vous devez accorder des autorisations supplémentaires au compte de service utilisé par le serveur Prometheus. Créez ou mettez à jour un ClusterRole contenant ces règles et assurez-vous qu'il est lié au compte de service Prometheus approprié à l'aide d'un ClusterRoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
   name: prometheus-role
   labels:
      app: prometheus-server
rules:
   - apiGroups: [""]
     resources:
       - nodes
     verbs:
       - get
       - list
       - watch
   - apiGroups: [""]
     resources:
       - nodes/proxy
       - nodes/metrics
     verbs:
       - get
    ---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-binding
  labels:
    app: prometheus-server
subjects:
  - kind: ServiceAccount
    name: prometheus-server        # Service account being used by prometheus
    namespace: prometheus          # Service account's namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-role            # Name of the ClusterRole created above

Mettez à jour le fichier de configuration Prometheus pour récupérer les métriques suivantes de cAdvisor :

container_cpu_usage_seconds_total
container_memory_working_set_bytes

Les lignes suivantes définissent les détails de récupération des métriques cAdvisor :

- job_name: 'kubernetes-cadvisor'
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  kubernetes_sd_configs:
    - role: node
  relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - target_label: __address__
      replacement: kubernetes.default.svc:443
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

  metric_relabel_configs:
  # Keep only the metrics VPA uses to save disk space
    - source_labels: [__name__]
      regex: (container_cpu_usage_seconds_total|container_memory_working_set_bytes)
      action: keep

Mettez à jour le fichier de configuration Prometheus pour récupérer la métrique suivante du service kube-state-metrics :
- kube_pod_labels
1. Déployez un service kube-state-metrics sur votre cluster.
  
  Remarque : Bien qu'un service kube-state-metrics soit installé par défaut sur les clusters Bare Metal, il n'expose pas la métrique kube_pod_labels requise.
  
  Vous pouvez utiliser les commandes Helm suivantes pour installer le nouveau service :
```
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
```
2. Créez un fichier ksm-values.yaml avec le contenu suivant :
```
fullnameOverride: vpa-kube-state-metrics
metricAllowlist:
  - kube_pod_labels
metricLabelsAllowlist:
  - "pods=[*]"
```
3. Installez un chart Helm basé sur le fichier de valeurs de l'étape précédente :
```
helm install vpa-ksm prometheus-community/kube-state-metrics \
    -f ksm-values.yaml --namespace kube-system
```
4. Ajoutez les lignes suivantes au fichier de configuration Prometheus pour récupérer la métrique kube_pod_labels du service kube-state-metrics installé :
```
- job_name: 'kube-state-metrics'
  static_configs:
    - targets: ['vpa-kube-state-metrics.kube-system.svc.cluster.local:8080']
  metric_relabel_configs:
    - source_labels: [ __name__ ]
      regex: 'kube_pod_labels'
      action: keep
```

Activer et utiliser Prometheus

L'autoscaling vertical des pods est compatible avec l'authentification de base et l'authentification basée sur un jeton porteur pour la connexion à Prometheus. Lorsque vous utilisez l'authentification, vous devez créer un Secret contenant les identifiants nécessaires dans l'espace de noms du cluster. Le contrôleur transfère ce secret au cluster cible et le monte en tant que volume ou variable d'environnement dans le pod du composant de recommandation. Vous pouvez également utiliser Prometheus sans authentification.

Pour activer et utiliser votre propre instance Prometheus avec l'autoscaling vertical des pods, vous devez configurer la section verticalPodAutoscaling dans la spécification de votre cluster avec les détails de connexion à votre instance Prometheus.

Voici un exemple de configuration dans la spécification du cluster à utiliser avec un jeton porteur :

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vertical Pod autoscaling configurations ...
    # Add this new section to configure the vpa to use prometheus using bearer token authentication as history provider
    prometheus:
      url: "http://prometheus.prometheus.monitoring.svc.cluster.local:9090"
      auth:
        bearerTokenAuth:
            name: prom-bearer-creds
            key: bearertoken

Pour activer Prometheus afin de l'utiliser avec l'autoscaling vertical des pods :

Assurez-vous que votre instance Prometheus est configurée pour récupérer les métriques requises, comme décrit dans Prérequis pour utiliser Prometheus avec l'autoscaling de pods vertical.
Mettez à jour la ressource personnalisée du cluster spec afin que le verticalPodAutoscaling.prometheus champ spécifie les paramètres de connexion de votre serveur Prometheus.

Ajoutez l'url à la section prometheus et définissez-la sur le nom de domaine complet pour vous connecter à Prometheus depuis le cluster :

spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vpa configurations ...
    # Add this new section to configure the vpa to use prometheus as history provider
    prometheus:
      # Required: The URL of the Prometheus server
      url: "http://prometheus.prometheus.svc.cluster.local:9090"

Spécifiez les détails de la connexion :

L'autoscaling vertical des pods est compatible avec les trois méthodes de connexion suivantes :
- Pas d'authentification
- Authentification de base (nom d'utilisateur, mot de passe)
- Authentification par jeton porteur
Pas d'authentification
Si votre instance Prometheus ne nécessite pas d'authentification, vous avez terminé. La section prometheus ne doit inclure qu'un champ url.
Authentification de base
Procédez comme suit pour spécifier l'authentification de base pour Prometheus :
1. Créez un secret contenant un nom d'utilisateur et un mot de passe dans la stringData section et l'baremetal.cluster.gke.io/mark-source: "true" annotation.
  
  L'exemple suivant montre un secret compatible avec l'authentification de base :
  
  apiVersion: v1 kind: Secret metadata: name: prom-basic-creds namespace: <cluster-namespace> annotations: baremetal.cluster.gke.io/mark-source: "true" type: Opaque stringData: username: admin password: pwd
  
  L'annotation est requise pour s'assurer que le secret source et le secret du cluster cible sont toujours synchronisés. Le secret est mis à jour lorsque le secret source est mis à jour.
  
  **Remarque** : Chaque fois que vous faites pivoter les identifiants, vous devez mettre à jour ce secret.
2. Mettez à jour la section prometheus.auth.basicAuth de la spécification du cluster pour référencer le nom d'utilisateur et le mot de passe du champ data du secret.
  
  L'exemple suivant montre une section basicAuth qui référence le nom d'utilisateur et le mot de passe du secret de l'étape précédente :
  
  # ... other vpa configurations ... prometheus: url: "http://prometheus.prometheus.svc.cluster.local:9090" auth: basicAuth: usernameRef: name: prom-basic-creds key: username passwordRef: name: prom-basic-creds key: password
  
  Le nom d'utilisateur et le mot de passe doivent figurer dans le même secret. Les clés doivent être des clés valides du champ data du secret.
L'instance Prometheus doit commencer à fonctionner comme fournisseur d'historique pour l'autoscaler de pods vertical lorsque la ressource personnalisée du cluster est mise à jour.
Authentification par jeton porteur
Procédez comme suit pour spécifier l'authentification par jeton porteur pour Prometheus :
1. Créez un secret contenant un jeton porteur dans la stringData section et l'baremetal.cluster.gke.io/mark-source: "true" annotation.
  
  L'exemple suivant montre un secret compatible avec l'authentification par jeton porteur :
  
  apiVersion: v1 kind: Secret metadata: name: prom-bearer-creds namespace: <cluster-namespace> annotations: baremetal.cluster.gke.io/mark-source: "true" type: Opaque stringData: bearertoken: "SAMPLE_TOKEN"
  
  L'annotation est requise pour s'assurer que le secret source et le secret du cluster cible sont toujours synchronisés. Le secret est mis à jour lorsque le secret source est mis à jour.
  
  **Remarque** : Chaque fois que vous faites pivoter les identifiants, vous devez mettre à jour ce secret.
2. Mettez à jour la section prometheus.auth.bearerTokenAuth de la spécification du cluster pour référencer le jeton porteur du champ data du secret.
  
  L'exemple suivant montre une section bearerTokenAuth qui référence le jeton de support dans le Secret de l'étape précédente :
  
  # ... other vertical Pod autoscaling configurations ... prometheus: url: "http://prometheus.prometheus.svc.cluster.local:9090" auth: bearerTokenAuth: name: prom-bearer-creds key: bearertoken
  
  La clé doit être une clé valide du champ data du secret.
L'instance Prometheus doit commencer à fonctionner comme fournisseur d'historique pour l'autoscaling vertical des pods lorsque la ressource personnalisée du cluster est mise à jour.

Désactiver l'utilisation de Prometheus

Pour désactiver l'utilisation de Prometheus avec l'autoscaling vertical des pods, supprimez la section prometheus de la section verticalPodAutoscaling de la ressource personnalisée du cluster.

Désactiver l'autoscaling vertical des pods

Désactivez l'autoscaling vertical des pods en supprimant ses ressources personnalisées et sa configuration de votre cluster :

Supprimez toutes les ressources personnalisées VerticalPodAutoscaler que vous avez créées.
Modifiez la ressource personnalisée du cluster et supprimez l'intégralité de la section verticalPodAutoscaling de la spec.

Vous pouvez modifier directement la ressource personnalisée du cluster ou modifier le fichier de configuration du cluster et utiliser bmctl update.
Supprimez l'annotation preview.baremetal.cluster.gke.io/vertical-pod-autoscaler de la ressource personnalisée du cluster.

Limites

Tenez compte des limites suivantes lorsque vous utilisez l'autoscaling de pods vertical :

L'autoscaling vertical des pods n'est pas prêt à être utilisé 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.
Le composant de mise à jour nécessite au moins deux instances dupliquées de pod pour que les déploiements remplacent les pods par des valeurs de ressources révisées.
Le composant de mise à jour ne met pas rapidement à jour les pods qui sont en boucle de plantage en raison d'erreurs de mémoire saturée (OOM, Out Of Memory).
La règle de mise à jour InPlaceOrRecreate pour les pods est une fonctionnalité alpha dans l'autoscaling vertical des pods. Elle tente d'effectuer des mises à jour sur place, mais peut revenir à la recréation du pod si les mises à jour sur place ne sont pas possibles.

Étape suivante

Découvrez les budgets d'interruptions de pods.