SupportConsoleDéveloppeursCommencer un essaiContact

2.6. Ajustez automatiquement les niveaux de ressources des pods grâce à l'autoscaler vertical de pods

Le Vertical Pod Autoscaler Operator (VPA) d'OpenShift Container Platform examine automatiquement les ressources historiques et actuelles de CPU et de mémoire pour les conteneurs dans les pods et peut mettre à jour les limites de ressources et les demandes en fonction des valeurs d'utilisation qu'il apprend. Le VPA utilise des ressources personnalisées individuelles (CR) pour mettre à jour tous les pods associés à un objet de charge de travail, tel que Deployment, DeploymentConfig, StatefulSet, Job, DaemonSet, ReplicaSet, ou ReplicationController, dans un projet.

L'APV vous aide à comprendre l'utilisation optimale du CPU et de la mémoire pour vos pods et peut automatiquement maintenir les ressources des pods tout au long de leur cycle de vie.

2.6.1. À propos de l'opérateur de l'autoscaler à nacelle verticale

Le Vertical Pod Autoscaler Operator (VPA) est implémenté en tant que ressource API et ressource personnalisée (CR). La CR détermine les actions que le Vertical Pod Autoscaler Operator doit entreprendre avec les pods associés à un objet de charge de travail spécifique, tel qu'un ensemble de démons, un contrôleur de réplication, etc. dans un projet.

Vous pouvez utiliser le système de recommandation par défaut ou utiliser votre propre système de recommandation pour procéder à une mise à l'échelle automatique sur la base de vos propres algorithmes.

Le recommandeur par défaut calcule automatiquement l'utilisation historique et actuelle du processeur et de la mémoire pour les conteneurs de ces modules et utilise ces données pour déterminer des limites de ressources et des demandes optimisées afin de garantir que ces modules fonctionnent efficacement à tout moment. Par exemple, le recommandeur par défaut suggère de réduire les ressources pour les conteneurs qui demandent plus de ressources qu'ils n'en utilisent et d'augmenter les ressources pour les conteneurs qui n'en demandent pas assez.

L'APV supprime ensuite automatiquement tous les pods qui ne sont pas conformes à ces recommandations, un par un, afin que vos applications puissent continuer à répondre aux demandes sans interruption de service. Les objets de charge de travail redéploient ensuite les pods avec les limites de ressources et les demandes d'origine. L'APV utilise un webhook d'admission en mutation pour mettre à jour les modules avec des limites de ressources et des demandes optimisées avant que les modules ne soient admis sur un nœud. Si vous ne souhaitez pas que l'APV supprime des modules, vous pouvez afficher les limites de ressources et les demandes de l'APV et mettre à jour manuellement les modules si nécessaire.

Note

Par défaut, les objets de charge de travail doivent spécifier un minimum de deux répliques pour que l'APV supprime automatiquement leurs pods. Les objets de charge de travail qui spécifient moins de répliques que ce minimum ne sont pas supprimés. Si vous supprimez manuellement ces modules, lorsque l'objet de charge de travail redéploie les modules, l'APV met à jour les nouveaux modules avec ses recommandations. Vous pouvez modifier ce minimum en modifiant l'objet VerticalPodAutoscalerController comme indiqué à l'adresse Changing the VPA minimum value.

Par exemple, si vous avez un module qui utilise 50 % de l'UC mais n'en demande que 10 %, l'APV détermine que le module consomme plus d'UC que ce qui est demandé et le supprime. L'objet de charge de travail, tel que l'ensemble de répliques, redémarre les modules et l'APV met à jour le nouveau module avec les ressources recommandées.

Pour les développeurs, vous pouvez utiliser l'APV pour vous assurer que vos pods restent opérationnels pendant les périodes de forte demande en planifiant les pods sur des nœuds qui disposent des ressources appropriées pour chaque pod.

Les administrateurs peuvent utiliser l'APV pour mieux utiliser les ressources du cluster, par exemple en empêchant les pods de réserver plus de ressources CPU que nécessaire. L'APV surveille les ressources que les charges de travail utilisent réellement et ajuste les besoins en ressources afin que la capacité soit disponible pour d'autres charges de travail. L'APV maintient également les ratios entre les limites et les demandes qui sont spécifiés dans la configuration initiale du conteneur.

Note

Si vous arrêtez de faire fonctionner l'APV ou si vous supprimez un CR APV spécifique dans votre cluster, les demandes de ressources pour les pods déjà modifiés par l'APV ne changent pas. Tout nouveau module obtient les ressources définies dans l'objet de charge de travail, et non les recommandations précédentes faites par l'APPV.

2.6.2. Installation de l'opérateur Autoscaler Vertical Pod

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur Vertical Pod Autoscaler (VPA).

Procédure

  1. Dans la console Web OpenShift Container Platform, cliquez sur Operators OperatorHub.
  2. Choisissez VerticalPodAutoscaler dans la liste des opérateurs disponibles et cliquez sur Install.
  3. Sur la page Install Operator, assurez-vous que l'option Operator recommended namespace est sélectionnée. Cela permet d'installer l'opérateur dans l'espace de noms obligatoire openshift-vertical-pod-autoscaler, qui est automatiquement créé s'il n'existe pas.
  4. Cliquez sur Install.

  5. Vérifiez l'installation en dressant la liste des composants de l'opérateur VPA :

    1. Navigate to Workloads Pods.
    2. Sélectionnez le projet openshift-vertical-pod-autoscaler dans le menu déroulant et vérifiez que quatre pods sont en cours d'exécution.
    3. Naviguez jusqu'à Workloads Deployments pour vérifier que quatre déploiements sont en cours.

  6. Facultatif. Vérifiez l'installation dans le CLI de OpenShift Container Platform à l'aide de la commande suivante : 

    $ oc get all -n openshift-vertical-pod-autoscaler

    La sortie montre quatre pods et quatre déploiements :

    Exemple de sortie

    NAME                                                    READY   STATUS    RESTARTS   AGE
pod/vertical-pod-autoscaler-operator-85b4569c47-2gmhc   1/1     Running   0          3m13s
pod/vpa-admission-plugin-default-67644fc87f-xq7k9       1/1     Running   0          2m56s
pod/vpa-recommender-default-7c54764b59-8gckt            1/1     Running   0          2m56s
pod/vpa-updater-default-7f6cc87858-47vw9                1/1     Running   0          2m56s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/vpa-webhook   ClusterIP   172.30.53.206   <none>        443/TCP   2m56s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/vertical-pod-autoscaler-operator   1/1     1            1           3m13s
deployment.apps/vpa-admission-plugin-default       1/1     1            1           2m56s
deployment.apps/vpa-recommender-default            1/1     1            1           2m56s
deployment.apps/vpa-updater-default                1/1     1            1           2m56s

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/vertical-pod-autoscaler-operator-85b4569c47   1         1         1       3m13s
replicaset.apps/vpa-admission-plugin-default-67644fc87f       1         1         1       2m56s
replicaset.apps/vpa-recommender-default-7c54764b59            1         1         1       2m56s
replicaset.apps/vpa-updater-default-7f6cc87858                1         1         1       2m56s

2.6.3. À propos de l'utilisation de l'opérateur d'autoscaler de nacelles verticales

Pour utiliser l'opérateur Vertical Pod Autoscaler (VPA), vous créez une ressource personnalisée (CR) VPA pour un objet de charge de travail dans votre cluster. Le VPA apprend et applique les ressources optimales de CPU et de mémoire pour les pods associés à cet objet de charge de travail. Vous pouvez utiliser une APV avec un déploiement, un ensemble avec état, un travail, un ensemble de démons, un ensemble de réplicas ou un objet de charge de travail de contrôleur de réplication. L'APV CR doit se trouver dans le même projet que les modules que vous souhaitez surveiller.

La CR APV permet d'associer un objet de charge de travail et de spécifier le mode de fonctionnement de l'APV :

  • Les modes Auto et Recreate appliquent automatiquement les recommandations de l'APV en matière de CPU et de mémoire tout au long de la durée de vie du pod. L'APV supprime tous les modules du projet qui ne sont pas conformes à ses recommandations. Lorsqu'il est redéployé par l'objet de charge de travail, l'APV met à jour les nouveaux modules avec ses recommandations.
  • Le mode Initial applique automatiquement les recommandations de l'APV uniquement lors de la création d'un pod.
  • Le mode Off ne fournit que les limites de ressources et les demandes recommandées, ce qui vous permet d'appliquer manuellement les recommandations. Le mode off ne met pas à jour les pods.

Vous pouvez également utiliser le CR pour exclure certains conteneurs de l'évaluation et des mises à jour de l'APV.

Par exemple, un pod a les limites et les demandes suivantes : 

resources:
  limits:
    cpu: 1
    memory: 500Mi
  requests:
    cpu: 500m
    memory: 100Mi

Après la création d'une APV configurée sur auto, l'APV apprend l'utilisation des ressources et supprime le module. Lorsqu'il est redéployé, le module utilise les nouvelles limites et demandes de ressources : 

resources:
  limits:
    cpu: 50m
    memory: 1250Mi
  requests:
    cpu: 25m
    memory: 262144k

Vous pouvez afficher les recommandations de l'APV à l'aide de la commande suivante : 

$ oc get vpa <vpa-name> --output yaml

Après quelques minutes, l'écran affiche les recommandations pour les demandes de CPU et de mémoire, comme suit :

Exemple de sortie

...
status:
...
  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound:
        cpu: 25m
        memory: 262144k
      target:
        cpu: 25m
        memory: 262144k
      uncappedTarget:
        cpu: 25m
        memory: 262144k
      upperBound:
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"
...

Le résultat montre les ressources recommandées, target, les ressources minimales recommandées, lowerBound, les ressources les plus élevées recommandées, upperBound, et les recommandations de ressources les plus récentes, uncappedTarget.

L'APV utilise les valeurs lowerBound et upperBound pour déterminer si un module doit être mis à jour. Si un module a des demandes de ressources inférieures aux valeurs lowerBound ou supérieures aux valeurs upperBound, l'APV met fin au module et le recrée avec les valeurs target.

2.6.3.1. Modification de la valeur minimale de l'APV

Par défaut, les objets de charge de travail doivent spécifier un minimum de deux répliques pour que l'APV supprime et mette à jour automatiquement leurs pods. Par conséquent, les objets de charge de travail qui spécifient moins de deux répliques ne sont pas automatiquement pris en compte par l'APPV. L'APP met à jour les nouveaux modules de ces objets de charge de travail si les modules sont redémarrés par un processus externe à l'APP. Vous pouvez modifier cette valeur minimale à l'échelle du cluster en modifiant le paramètre minReplicas dans la ressource personnalisée (CR) VerticalPodAutoscalerController.

Par exemple, si vous définissez minReplicas sur 3, l'APV ne supprime pas et ne met pas à jour les pods pour les objets de charge de travail qui spécifient moins de trois répliques.

Note

Si vous définissez minReplicas sur 1, l'APV peut supprimer le seul module d'un objet de charge de travail qui ne spécifie qu'une seule réplique. Vous ne devez utiliser ce paramètre avec les objets à une réplique que si votre charge de travail peut tolérer des temps d'arrêt chaque fois que l'APV supprime un module pour ajuster ses ressources. Pour éviter les temps d'arrêt indésirables avec les objets à réplique unique, configurez les CR de l'APV avec le paramètre podUpdatePolicy défini sur Initial, qui met automatiquement à jour le module uniquement lorsqu'il est redémarré par un processus externe à l'APV, ou Off, qui vous permet de mettre à jour le module manuellement à un moment approprié pour votre application.

Exemple d'objet VerticalPodAutoscalerController 

apiVersion: autoscaling.openshift.io/v1
kind: VerticalPodAutoscalerController
metadata:
  creationTimestamp: "2021-04-21T19:29:49Z"
  generation: 2
  name: default
  namespace: openshift-vertical-pod-autoscaler
  resourceVersion: "142172"
  uid: 180e17e9-03cc-427f-9955-3b4d7aeb2d59
spec:
  minReplicas: 3 1
  podMinCPUMillicores: 25
  podMinMemoryMb: 250
  recommendationOnly: false
  safetyMarginFraction: 0.15

1
Spécifiez le nombre minimum de répliques d'un objet de charge de travail sur lequel l'APV doit agir. Les objets dont le nombre de répliques est inférieur au minimum ne sont pas automatiquement supprimés par l'APV.

2.6.3.2. Appliquer automatiquement les recommandations de l'APV

Pour utiliser l'APV afin de mettre à jour automatiquement les modules, créez un CR APV pour un objet de charge de travail spécifique avec updateMode défini sur Auto ou Recreate.

Lorsque les modules sont créés pour l'objet de charge de travail, l'APV surveille constamment les conteneurs pour analyser leurs besoins en CPU et en mémoire. L'APV supprime tous les modules qui ne répondent pas aux recommandations de l'APV en matière de CPU et de mémoire. Lors du redéploiement, les modules utilisent les nouvelles limites de ressources et les demandes basées sur les recommandations de l'APV, tout en respectant le budget de perturbation des modules défini pour vos applications. Les recommandations sont ajoutées au champ status du CR VPA pour référence.

Note

Par défaut, les objets de charge de travail doivent spécifier un minimum de deux répliques pour que l'APV supprime automatiquement leurs pods. Les objets de charge de travail qui spécifient moins de répliques que ce minimum ne sont pas supprimés. Si vous supprimez manuellement ces modules, lorsque l'objet de charge de travail redéploie les modules, l'APV met à jour les nouveaux modules avec ses recommandations. Vous pouvez modifier ce minimum en modifiant l'objet VerticalPodAutoscalerController comme indiqué à l'adresse Changing the VPA minimum value.

Exemple d'APV CR pour le mode Auto 

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 1
    name:       frontend 2
  updatePolicy:
    updateMode: "Auto" 3

1
Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.
2
Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.
3
Réglez le mode sur Auto ou Recreate:
  • Auto. L'APV attribue des demandes de ressources lors de la création d'un module et met à jour les modules existants en les supprimant lorsque les ressources demandées diffèrent sensiblement de la nouvelle recommandation.
  • Recreate. L'APV attribue des demandes de ressources lors de la création d'un pod et met à jour les pods existants en les terminant lorsque les ressources demandées diffèrent de manière significative de la nouvelle recommandation. Ce mode ne doit être utilisé que rarement, uniquement si vous devez vous assurer que les modules sont redémarrés chaque fois que la demande de ressources change.
Note

Il faut qu'il y ait des nacelles en fonctionnement dans le projet pour que l'APV puisse déterminer les ressources recommandées et appliquer les recommandations aux nouvelles nacelles.

2.6.3.3. Appliquer automatiquement les recommandations de l'APV lors de la création d'un pod

Pour utiliser l'APV afin d'appliquer les ressources recommandées uniquement lorsqu'un module est déployé pour la première fois, créez un APV CR pour un objet de charge de travail spécifique avec updateMode défini sur Initial.

Ensuite, supprimez manuellement tous les modules associés à l'objet de charge de travail pour lequel vous souhaitez utiliser les recommandations de l'APV. En mode Initial, l'APV ne supprime pas les modules et ne les met pas à jour lorsqu'il apprend de nouvelles recommandations de ressources.

Exemple d'APV CR pour le mode Initial 

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 1
    name:       frontend 2
  updatePolicy:
    updateMode: "Initial" 3

1
Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.
2
Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.
3
Définissez le mode sur Initial. L'APV attribue des ressources lors de la création des pods et ne modifie pas les ressources pendant la durée de vie du pod.
Note

Il faut qu'il y ait des nacelles en fonctionnement dans le projet pour qu'une APV puisse déterminer les ressources recommandées et appliquer les recommandations aux nouvelles nacelles.

2.6.3.4. Application manuelle des recommandations de l'APV

Pour utiliser l'APV afin de déterminer uniquement les valeurs recommandées pour l'unité centrale et la mémoire, créez un APV CR pour un objet de charge de travail spécifique avec updateMode défini sur off.

Lorsque les modules sont créés pour cet objet de charge de travail, l'APPV analyse les besoins en CPU et en mémoire des conteneurs et enregistre ces recommandations dans le champ status du CR de l'APPV. L'APV ne met pas à jour les modules au fur et à mesure qu'il détermine de nouvelles recommandations de ressources.

Exemple d'APV CR pour le mode Off 

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 1
    name:       frontend 2
  updatePolicy:
    updateMode: "Off" 3

1
Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.
2
Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.
3
Réglez le mode sur Off.

Vous pouvez consulter les recommandations à l'aide de la commande suivante. 

$ oc get vpa <vpa-name> --output yaml

Avec les recommandations, vous pouvez modifier l'objet de charge de travail pour ajouter des demandes de CPU et de mémoire, puis supprimer et redéployer les pods en utilisant les ressources recommandées.

Note

Pour qu'un APV puisse déterminer les ressources recommandées, il faut qu'il y ait des modules d'exploitation dans le projet.

2.6.3.5. Exempter les conteneurs de l'application des recommandations de l'APV

Si votre objet de charge de travail a plusieurs conteneurs et que vous ne voulez pas que l'APV évalue et agisse sur tous les conteneurs, créez une CR APV pour un objet de charge de travail spécifique et ajoutez une resourcePolicy pour exclure des conteneurs spécifiques.

Lorsque l'APV met à jour les pods avec les ressources recommandées, tous les conteneurs avec resourcePolicy ne sont pas mis à jour et l'APV ne présente pas de recommandations pour ces conteneurs dans le pod. 

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 1
    name:       frontend 2
  updatePolicy:
    updateMode: "Auto" 3
  resourcePolicy: 4
    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"
1
Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.
2
Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.
3
Définissez le mode sur Auto, Recreate ou Off. Le mode Recreate ne doit être utilisé que rarement, uniquement si vous devez vous assurer que les pods sont redémarrés à chaque fois que la demande de ressources change.
4
Spécifiez les conteneurs que vous souhaitez exclure et définissez mode comme Off.

Par exemple, un pod a deux conteneurs, les mêmes demandes de ressources et les mêmes limites : 

# ...
spec:
  containers:
  - name: frontend
    resources:
      limits:
        cpu: 1
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
  - name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
# ...

Après avoir lancé un VPA CR avec le conteneur backend en opt-out, le VPA se termine et recrée le pod avec les ressources recommandées appliquées uniquement au conteneur frontend: 

...
spec:
  containers:
    name: frontend
    resources:
      limits:
        cpu: 50m
        memory: 1250Mi
      requests:
        cpu: 25m
        memory: 262144k
...
    name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
...

2.6.3.6. Utilisation d'un autre système de recommandation

Vous pouvez utiliser votre propre recommandeur pour une mise à l'échelle automatique basée sur vos propres algorithmes. Si vous ne spécifiez pas de recommandation alternative, OpenShift Container Platform utilise la recommandation par défaut, qui suggère des demandes de CPU et de mémoire basées sur l'utilisation historique. Comme il n'existe pas de politique de recommandation universelle qui s'applique à tous les types de charges de travail, vous pouvez vouloir créer et déployer différents recommandeurs pour des charges de travail spécifiques.

Par exemple, le recommandeur par défaut peut ne pas prédire avec précision l'utilisation future des ressources lorsque les conteneurs présentent certains comportements en matière de ressources, tels que les modèles cycliques qui alternent entre les pics d'utilisation et la marche au ralenti, tels qu'utilisés par les applications de surveillance, ou les modèles récurrents et répétitifs utilisés avec les applications d'apprentissage en profondeur. L'utilisation de la recommandation par défaut avec ces comportements d'utilisation peut entraîner un surprovisionnement important et des pertes de mémoire (OOM) pour vos applications.

Note

Les instructions relatives à la création d'un recommandeur dépassent le cadre de cette documentation,

Procédure

Pour utiliser un recommandeur alternatif pour vos pods :

  1. Créez un compte de service pour le recommandeur alternatif et liez ce compte de service au rôle de cluster requis : 

    apiVersion: v1 1
kind: ServiceAccount
metadata:
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 2
kind: ClusterRoleBinding
metadata:
  name: system:example-metrics-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 3
kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-actor
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-actor
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 4
kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-target-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-target-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
    1
    Crée un compte de service pour le recommandeur dans l'espace de noms où le recommandeur est déployé.
    2
    Lier le compte du service de recommandation au rôle metrics-reader. Spécifier l'espace de noms dans lequel le service de recommandation doit être déployé.
    3
    Lier le compte du service de recommandation au rôle vpa-actor. Spécifier l'espace de noms dans lequel le service de recommandation doit être déployé.
    4
    Lier le compte du service de recommandation au rôle vpa-target-reader. Spécifier l'espace de noms dans lequel le service de recommandation doit être déployé.

  2. Pour ajouter le recommandeur alternatif au cluster, créez un objet de déploiement similaire au suivant : 

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: alt-vpa-recommender
  namespace: <namespace_name>
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alt-vpa-recommender
  template:
    metadata:
      labels:
        app: alt-vpa-recommender
    spec:
      containers: 1
      - name: recommender
        image: quay.io/example/alt-recommender:latest 2
        imagePullPolicy: Always
        resources:
          limits:
            cpu: 200m
            memory: 1000Mi
          requests:
            cpu: 50m
            memory: 500Mi
        ports:
        - name: prometheus
          containerPort: 8942
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL
          seccompProfile:
            type: RuntimeDefault
      serviceAccountName: alt-vpa-recommender-sa 3
      securityContext:
        runAsNonRoot: true
    1
    Crée un conteneur pour votre recommandeur alternatif.
    2
    Spécifie votre image de recommandation.
    3
    Associe le compte de service que vous avez créé pour le recommandeur.

    Un nouveau module est créé pour le recommandeur alternatif dans le même espace de noms. 

    $ oc get pods

    Exemple de sortie

    NAME                                        READY   STATUS    RESTARTS   AGE
frontend-845d5478d-558zf                    1/1     Running   0          4m25s
frontend-845d5478d-7z9gx                    1/1     Running   0          4m25s
frontend-845d5478d-b7l4j                    1/1     Running   0          4m25s
vpa-alt-recommender-55878867f9-6tp5v        1/1     Running   0          9s

  3. Configurez un CR APV qui inclut le nom de l'objet de recommandation alternatif Deployment.

    Exemple d'APV CR incluant le recommandeur alternatif

    apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
  namespace: <namespace_name>
spec:
  recommenders:
    - name: alt-vpa-recommender 1
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 2
    name:       frontend

    1
    Spécifie le nom de l'autre déploiement de recommandation.
    2
    Spécifie le nom d'un objet de charge de travail existant que l'APV doit gérer.

2.6.4. Utilisation de l'opérateur de l'autoscaler à nacelle verticale

Vous pouvez utiliser le Vertical Pod Autoscaler Operator (VPA) en créant une ressource personnalisée (CR) VPA. La CR indique les pods qu'elle doit analyser et détermine les actions que l'APV doit entreprendre avec ces pods.

Conditions préalables

  • L'objet de charge de travail que vous souhaitez mettre à l'échelle doit exister.
  • Si vous souhaitez utiliser un autre recommandeur, un déploiement incluant ce recommandeur doit exister.

Procédure

Pour créer un CR APV pour un objet de charge de travail spécifique :

  1. Passez au projet dans lequel se trouve l'objet de charge de travail que vous souhaitez mettre à l'échelle.

    1. Créer un fichier YAML VPA CR : 

      apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 1
    name:       frontend 2
  updatePolicy:
    updateMode: "Auto" 3
  resourcePolicy: 4
    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"
  recommenders: 5
    - name: my-recommender
      1
      Spécifiez le type d'objet de charge de travail que vous voulez que cette APV gère : Deployment, StatefulSet, Job, DaemonSet, ReplicaSet, ou ReplicationController.
      2
      Spécifiez le nom d'un objet de charge de travail existant que vous voulez que cette APV gère.
      3
      Spécifier le mode VPA :
      • auto pour appliquer automatiquement les ressources recommandées aux modules associés au contrôleur. L'APV met fin aux pods existants et crée de nouveaux pods avec les limites de ressources et les demandes recommandées.
      • recreate pour appliquer automatiquement les ressources recommandées aux modules associés à l'objet de charge de travail. L'APV met fin aux modules existants et en crée de nouveaux avec les limites et les demandes de ressources recommandées. Le mode recreate ne doit être utilisé que rarement, uniquement si vous devez vous assurer que les modules sont redémarrés chaque fois que la demande de ressources change.
      • initial pour appliquer automatiquement les ressources recommandées lorsque les modules associés à l'objet de charge de travail sont créés. L'APV ne met pas à jour les modules au fur et à mesure qu'il apprend de nouvelles recommandations de ressources.
      • off de ne générer des recommandations de ressources que pour les modules associés à l'objet de charge de travail. L'APV ne met pas à jour les modules au fur et à mesure qu'il apprend de nouvelles recommandations de ressources et n'applique pas les recommandations à de nouveaux modules.
      4
      Facultatif. Indiquez les conteneurs que vous souhaitez exclure et définissez le mode sur Off.
      5
      Optionnel. Indiquez un autre recommandeur.

    2. Créer l'APV CR : 

      oc create -f <nom-de-fichier>.yaml

      Après quelques instants, l'APV apprend l'utilisation des ressources des conteneurs dans les pods associés à l'objet de charge de travail.

      Vous pouvez afficher les recommandations de l'APV à l'aide de la commande suivante : 

      $ oc get vpa <vpa-name> --output yaml

      La sortie montre les recommandations pour les demandes de CPU et de mémoire, comme suit :

      Exemple de sortie

      ...
status:

...

  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound: 1
        cpu: 25m
        memory: 262144k
      target: 2
        cpu: 25m
        memory: 262144k
      uncappedTarget: 3
        cpu: 25m
        memory: 262144k
      upperBound: 4
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"

...

      1
      lowerBound est le niveau minimum de ressources recommandé.
      2
      target est le niveau de ressources recommandé.
      3
      upperBound est le niveau de ressources recommandé le plus élevé.
      4
      uncappedTarget est la recommandation la plus récente en matière de ressources.

2.6.5. Désinstallation de l'opérateur d'autoscaler de nacelles verticales

Vous pouvez supprimer l'opérateur Vertical Pod Autoscaler (VPA) de votre cluster OpenShift Container Platform. Après la désinstallation, les demandes de ressources pour les pods déjà modifiés par un VPA CR existant ne changent pas. Tout nouveau pod obtient les ressources définies dans l'objet de charge de travail, et non les recommandations précédentes faites par le Vertical Pod Autoscaler Operator.

Note

Vous pouvez supprimer un VPA CR spécifique à l'aide de la commande oc delete vpa <vpa-name>. Les mêmes actions s'appliquent aux demandes de ressources que la désinstallation de l'autoscaler de pods verticaux.

Après avoir retiré l'Opérateur VPA, il est recommandé de retirer les autres composants associés à l'Opérateur afin d'éviter tout problème potentiel.

Conditions préalables

  • L'opérateur Autoscaler Vertical Pod doit être installé.

Procédure

  1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators Installed Operators.
  2. Passez au projet openshift-vertical-pod-autoscaler.
  3. Pour l'opérateur VerticalPodAutoscaler, cliquez sur le menu Options kebab et sélectionnez Uninstall Operator.
  4. Facultatif : Pour supprimer tous les opérandes associés à l'opérateur, cochez la case Delete all operand instances for this operator dans la boîte de dialogue.
  5. Cliquez sur Uninstall.

  6. Optionnel : Utilisez la CLI d'OpenShift pour supprimer les composants de l'APV :

    1. Supprimer l'espace de noms de l'APV : 

      $ oc delete namespace openshift-vertical-pod-autoscaler

    2. Supprimer les objets de définition des ressources personnalisées (CRD) de l'APV : 

      $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io
      $ oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io
      $ oc delete crd verticalpodautoscalers.autoscaling.k8s.io

      La suppression des CRD supprime les rôles associés, les rôles de cluster et les liaisons de rôles.

      Note

      Cette action supprime du cluster tous les CR d'APV créés par l'utilisateur. Si vous réinstallez l'APV, vous devez à nouveau créer ces objets.

    3. Supprimer l'opérateur APV : 

      $ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.