Configurer l'autoscaling vertical des pods

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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 de pods vertical analyse l'utilisation des ressources historiques et actuelles 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 dimensionnant correctement l'allocation des ressources.

Avant de commencer

Avant de configurer l'autoscaling de pods vertical, assurez-vous de remplir les conditions préalables suivantes :

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

Activer l'autoscaling vertical des pods

Activez l'autoscaling de pods vertical sur votre cluster Bare Metal en définissant une annotation d'aperçu et en configurant la spécification du cluster :

1. Ajoutez ou mettez à jour l'annotation d'aperçu sur la ressource personnalisée du cluster.

   Modifiez directement la ressource personnalisée du cluster ou modifiez le fichier de configuration du cluster et utilisez bmctl update.

   metadata:
     annotations:
       preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
   

2. Modifiez le spec de la ressource personnalisée du cluster pour inclure le champ verticalPodAutoscaling et spécifier 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
   

3. 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 de votre 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 :

1. 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"]
   

2. 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 de pods vertical fonctionne dans différents modes qui contrôlent la façon dont il applique les recommandations de ressources.

Mode de recommandation

En mode recommandation, l'autoscaling vertical des pods installe le composant 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 "Status" (État) des ressources personnalisées VerticalPodAutoscaler que vous créez.

Pour afficher les recommandations concernant les limites et les demandes de ressources, utilisez 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

Dans ce mode, les pods ne sont pas mis à jour automatiquement. Suivez ces recommandations pour mettre à jour manuellement vos configurations de pods. Il s'agit du comportement par défaut si enableUpdater n'est pas défini ou est défini sur 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 l'updater et du contrôleur d'admission de l'autoscaling vertical des pods en plus du composant de recommandation. Le programme de mise à jour surveille les pods dont les demandes de ressources actuelles s'écartent considérablement des recommandations.

La règle de mise à jour de la ressource VerticalPodAutoscaler spécifie la manière dont le programme de mise à jour applique les recommandations. Par défaut, le mode de mise à jour est Auto, qui indique que le programme de mise à jour attribue les 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"
    ...

L'outil de mise à jour est compatible avec les cinq modes suivants :

• Auto : le programme de mise à jour évince le pod. Le contrôleur d'admission intercepte la demande de création du nouveau pod et la modifie pour qu'elle utilise les valeurs de processeur et de mémoire recommandées par le recommander. La mise à jour des ressources nécessite de recréer le pod, ce qui peut entraîner des perturbations. Utilisez des budgets d'interruption de pod, que le programme de mise à jour respecte, pour gérer le processus d'éviction. Ce mode équivaut à Recreate.

• Recreate : le programme de mise à jour évince les pods et attribue les demandes et limites de ressources recommandées lorsque le pod est recréé.

• InPlaceOrRecreate(alpha) : le programme de mise à jour tente d'effectuer des mises à jour sur place au mieux, 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 des pods sur place.

• Initial : le programme 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 programme de mise à jour ne modifie pas automatiquement les besoins en 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 de version 1.33.0 ou ultérieure.

L'exemple suivant montre comment les recommandations de ressources peuvent s'afficher dans la section Status pour le conteneur hamster. L'exemple montre également un événement d'éviction de pod, qui se produit lorsque le programme 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 vertical des pods. Lorsque vous définissez enableMemorySaver sur true, le moteur 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 moteur 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 défini sur true pour les clusters périphériques.

Utiliser Prometheus comme fournisseur d'historique persistant

Par défaut, le composant Recommender 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 la version 1.34 de Google Distributed Cloud, 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 moteur de recommandation peut interroger le serveur Prometheus au démarrage ou au redémarrage pour récupérer les données historiques à long terme sur l'utilisation des ressources pour tous les pods gérés. La récupération de ces données permet au système de recommandation de créer immédiatement son état interne avec un ensemble de données riche, ce qui permet de générer des recommandations plus éclairées et plus précises dès le début.

L'utilisation de Prometheus comme fournisseur d'historique persistant présente les avantages suivants :

• Optimisation de l'utilisation des ressources : génère des recommandations pertinentes et précises dès le début, ce qui vous permet d'optimiser l'utilisation des ressources du cluster.

• Éviter les erreurs de mémoire insuffisante (OOM) : Prometheus élimine la nécessité de stocker l'état interne du moteur 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 moteur de recommandation récupère les métriques historiques de Prometheus au redémarrage, ce qui élimine le besoin de CR VerticalPodAutoscalerCheckpoint et économise la mémoire ETCD.

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

Conditions préalables à l'utilisation de Prometheus avec l'autoscaling de pods verticaux

Pour utiliser votre propre instance Prometheus comme fournisseur d'historique pour l'autoscaling vertical des pods, vous devez la configurer pour qu'elle récupère les métriques nécessaires. Pour ce faire, vous devez suivre les étapes suivantes :

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

2. Configurez les autorisations pour scraper les métriques.

   Pour permettre à Prometheus d'extraire des 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
   

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

   • container_cpu_usage_seconds_total
   • container_memory_working_set_bytes

   Les lignes suivantes définissent les détails du scraping pour les 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
   

4. Mettez à jour le fichier de configuration Prometheus pour récupérer la métrique suivante à partir 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 graphique 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 du 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 transmet ce secret au cluster cible et l'installe en tant que volume ou variable d'environnement dans le pod du recommandateur. 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 du 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 de pods vertical :

1. Assurez-vous que votre instance Prometheus est configurée pour scraper les métriques requises, comme indiqué dans Conditions préalables à l'utilisation de Prometheus avec l'autoscaling de pods vertical.

2. Mettez à jour la ressource personnalisée du cluster spec afin que le champ verticalPodAutoscaling.prometheus spécifie les paramètres de connexion de votre serveur Prometheus.

3. Ajoutez url à la section prometheus et définissez-le sur le nom de domaine complet (FQDN) 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"
   

4. 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 de support

   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

   Pour spécifier l'authentification de base pour Prometheus, procédez comme suit :

   1. Créez un secret contenant un nom d'utilisateur et un mot de passe dans la section stringData et l'annotation baremetal.cluster.gke.io/mark-source: "true".

      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 nécessaire 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 modifié.

      Remarque : Chaque fois que vous effectuez une rotation des identifiants, vous devez mettre à jour ce secret.

   2. Mettez à jour la section prometheus.auth.basicAuth de la spécification du cluster pour faire référence au nom d'utilisateur et au mot de passe du champ data dans le secret.

      L'exemple suivant montre une section basicAuth qui fait référence au nom d'utilisateur et au 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 provenant du champ data du secret.

   L'instance Prometheus devrait commencer à fonctionner comme fournisseur d'historique pour l'autoscaler vertical de pods lorsque la ressource personnalisée du cluster est mise à jour.

   Authentification par jeton de support

   Procédez comme suit pour spécifier l'authentification par jeton du porteur pour Prometheus :

   1. Créez un secret contenant un jeton du porteur dans la section stringData et l'annotation baremetal.cluster.gke.io/mark-source: "true".

      L'exemple suivant montre un secret compatible avec l'authentification par jeton du 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 nécessaire 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 modifié.

      Remarque : Chaque fois que vous effectuez une rotation des identifiants, vous devez mettre à jour ce secret.

   2. Mettez à jour la section prometheus.auth.bearerTokenAuth de la spécification du cluster pour faire référence au jeton du porteur à partir du champ data du Secret.

      L'exemple suivant montre une section bearerTokenAuth qui fait référence au jeton du porteur 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 devrait 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 :

1. Supprimez toutes les ressources personnalisées VerticalPodAutoscaler que vous avez créées.

2. Modifiez la ressource personnalisée du cluster et supprimez l'intégralité de la section verticalPodAutoscaling de spec.

   Vous pouvez modifier directement la ressource personnalisée du cluster ou modifier le fichier de configuration du cluster et utiliser bmctl update.

3. Supprimez l'annotation preview.baremetal.cluster.gke.io/vertical-pod-autoscaler de la ressource personnalisée Cluster.

Limites

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

• L'autoscaling de pods verticaux 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.
• Le programme de mise à jour nécessite au moins deux répliques de pod pour que les déploiements remplacent les pods par des valeurs de ressources révisées.
• Le programme de mise à jour ne met pas à jour rapidement 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 de l'autoscaling vertical des pods. Il tente d'effectuer des mises à jour sur place au mieux, mais peut revenir à la recréation du pod si les mises à jour sur place ne sont pas possibles.

Étapes suivantes

• Découvrez les budgets d'interruptions de pods.