2.5. Mise à l'échelle automatique des pods en fonction de mesures personnalisées

Procédure

1. Dans la console Web OpenShift Container Platform, cliquez sur Operators OperatorHub.
2. Choisissez Custom Metrics Autoscaler dans la liste des opérateurs disponibles et cliquez sur Install.
3. Sur la page Install Operator, assurez-vous que l'option All namespaces on the cluster (default) est sélectionnée pour Installation Mode. Cela permet d'installer l'opérateur dans tous les espaces de noms.
4. Assurez-vous que l'espace de noms openshift-keda est sélectionné pour Installed Namespace. OpenShift Container Platform crée l'espace de noms, s'il n'est pas présent dans votre cluster.
5. Cliquez sur Install.

6. Vérifiez l'installation en listant les composants de Custom Metrics Autoscaler Operator :

   1. Navigate to Workloads Pods.
   2. Sélectionnez le projet openshift-keda dans le menu déroulant et vérifiez que le module custom-metrics-autoscaler-operator-* est en cours d'exécution.
   3. Naviguez jusqu'à Workloads Deployments pour vérifier que le déploiement custom-metrics-autoscaler-operator est en cours.

7. Facultatif : Vérifiez l'installation dans le CLI OpenShift à l'aide des commandes suivantes :

   $ oc get all -n openshift-keda

   Le résultat ressemble à ce qui suit :

   Exemple de sortie

   NAME                                                      READY   STATUS    RESTARTS   AGE
   pod/custom-metrics-autoscaler-operator-5fd8d9ffd8-xt4xp   1/1     Running   0          18m
   
   NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/custom-metrics-autoscaler-operator   1/1     1            1           18m
   
   NAME                                                            DESIRED   CURRENT   READY   AGE
   replicaset.apps/custom-metrics-autoscaler-operator-5fd8d9ffd8   1         1         1       18m

8. Installez la ressource personnalisée KedaController, qui crée les CRD nécessaires :

   1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators Installed Operators.
   2. Cliquez sur Custom Metrics Autoscaler.
   3. Sur la page Operator Details, cliquez sur l'onglet KedaController.

   4. Dans l'onglet KedaController, cliquez sur Create KedaController et modifiez le fichier.

      kind: KedaController
      apiVersion: keda.sh/v1alpha1
      metadata:
        name: keda
        namespace: openshift-keda
      spec:
        watchNamespace: '' 1
        operator:
          logLevel: info 2
          logEncoder: console 3
        metricsServer:
          logLevel: '0' 4
          auditConfig: 5
            logFormat: "json"
            logOutputVolumeClaim: "persistentVolumeClaimName"
            policy:
              rules:
              - level: Metadata
              omitStages: "RequestReceived"
              omitManagedFields: false
            lifetime:
              maxAge: "2"
              maxBackup: "1"
              maxSize: "50"
        serviceAccount: {}

      1 1

      Spécifie les espaces de noms que l'autoscaler personnalisé doit surveiller. Saisissez les noms dans une liste séparée par des virgules. Omettre ou définir empty pour surveiller tous les espaces de noms. La valeur par défaut est empty.

      2

      Spécifie le niveau de verbosité des messages du journal de l'opérateur Autoscaler de Custom Metrics. Les valeurs autorisées sont debug, info, error. La valeur par défaut est info.

      3

      Spécifie le format de consignation des messages de consignation de l'opérateur Autoscaler de Custom Metrics. Les valeurs autorisées sont console ou json. La valeur par défaut est console.

      4

      Spécifie le niveau de journalisation pour le serveur Autoscaler Metrics de Custom Metrics. Les valeurs autorisées sont 0 pour info et 4 ou debug. La valeur par défaut est 0.

      5

      Active la journalisation des audits pour l'opérateur Custom Metrics Autoscaler et spécifie la politique d'audit à utiliser, comme décrit dans la section "Configuration de la journalisation des audits".

   5. Cliquez sur Create pour créer le contrôleur KEDAC.

Procédure

1. Passez au projet contenant l'objet que vous souhaitez mettre à l'échelle :

   $ oc project my-project

2. Utilisez la commande suivante pour créer un compte de service, si votre cluster n'en possède pas :

   oc create serviceaccount <service_account> $ oc create serviceaccount <service_account>

   où :

   -YRFFGUNA_compte_de_service>

   Spécifie le nom du compte de service.

3. Utilisez la commande suivante pour localiser le jeton attribué au compte de service :

   oc describe serviceaccount <service_account> $ oc describe serviceaccount <service_account>

   où :

   -YRFFGUNA_compte_de_service>

   Spécifie le nom du compte de service.

   Exemple de sortie

   Name:                thanos
   Namespace:           my-project
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  thanos-dockercfg-nnwgj
   Mountable secrets:   thanos-dockercfg-nnwgj
   Tokens:              thanos-token-9g4n5 1
   Events:              <none>

   1

   Utilisez ce jeton dans l'authentification du déclencheur.

4. Créer un déclencheur d'authentification avec le jeton de compte de service :

   1. Créez un fichier YAML similaire au suivant :

      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
      spec:
        secretTargetRef: 1
        - parameter: bearerToken 2
          name: thanos-token-9g4n5 3
          key: token 4
        - parameter: ca
          name: thanos-token-9g4n5
          key: ca.crt

      1

      Spécifie que cet objet utilise un secret pour l'autorisation.

      2

      Spécifie le paramètre d'authentification à fournir en utilisant le jeton.

      3

      Spécifie le nom du jeton à utiliser.

      4

      Spécifie la clé du jeton à utiliser avec le paramètre spécifié.

   2. Créer l'objet CR :

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

5. Créer un rôle pour lire les métriques de Thanos :

   1. Créez un fichier YAML avec les paramètres suivants :

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch

   2. Créer l'objet CR :

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

6. Créer un lien de rôle pour la lecture des métriques de Thanos :

   1. Créez un fichier YAML similaire au suivant :

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: thanos-metrics-reader 1
        namespace: my-project 2
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: thanos-metrics-reader
      subjects:
      - kind: ServiceAccount
        name: thanos 3
        namespace: my-project 4

      1

      Spécifie le nom du rôle que vous avez créé.

      2

      Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.

      3

      Spécifie le nom du compte de service à lier au rôle.

      4

      Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.

   2. Créer l'objet CR :

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

Procédure

1. Utilisez la commande suivante pour éditer le ScaledObject CR pour votre charge de travail :

   $ oc edit ScaledObject scaledobject

2. Ajouter l'annotation autoscaling.keda.sh/paused-replicas avec n'importe quelle valeur :

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     annotations:
       autoscaling.keda.sh/paused-replicas: "4" 1
     creationTimestamp: "2023-02-08T14:41:01Z"
     generation: 1
     name: scaledobject
     namespace: my-project
     resourceVersion: "65729"
     uid: f5aec682-acdf-4232-a783-58b5b82f5dd0

   1

   Spécifie que l'opérateur de mise à l'échelle automatique des métriques personnalisées doit mettre à l'échelle les répliques jusqu'à la valeur spécifiée et arrêter la mise à l'échelle automatique.

Procédure

1. Modifiez la ressource personnalisée KedaController pour ajouter la strophe auditConfig:

   kind: KedaController
   apiVersion: keda.sh/v1alpha1
   metadata:
     name: keda
     namespace: openshift-keda
   spec:
    ...
     metricsServer:
    ...
       auditConfig:
         logFormat: "json" 1
         logOutputVolumeClaim: "pvc-audit-log" 2
         policy:
           rules: 3
           - level: Metadata
           omitStages: "RequestReceived" 4
           omitManagedFields: false 5
         lifetime: 6
           maxAge: "2"
           maxBackup: "1"
           maxSize: "50"

   1

   Spécifie le format de sortie du journal d'audit, soit legacy ou json.

   2

   Spécifie une revendication de volume persistant existante pour le stockage des données de journalisation. Toutes les demandes adressées au serveur API sont consignées dans cette revendication de volume persistant. Si vous laissez ce champ vide, les données du journal sont envoyées à stdout.

   3

   Spécifie quels événements doivent être enregistrés et quelles données doivent être incluses :

   • None: Ne pas enregistrer les événements.
   • Metadata: N'enregistrez que les métadonnées de la demande, telles que l'utilisateur, l'horodatage, etc. Ne pas enregistrer le texte de la demande et le texte de la réponse. Il s'agit de la valeur par défaut.
   • Request: Enregistrer uniquement les métadonnées et le texte de la demande, mais pas le texte de la réponse. Cette option ne s'applique pas aux demandes ne portant pas sur des ressources.
   • RequestResponse: Métadonnées de l'événement, texte de la demande et texte de la réponse. Cette option ne s'applique pas aux demandes ne portant pas sur des ressources.

   4

   Spécifie les étapes pour lesquelles aucun événement n'est créé.

   5

   Indique s'il faut omettre les champs gérés des corps de demande et de réponse dans le journal d'audit de l'API, soit true pour omettre les champs, soit false pour les inclure.

   6

   Spécifie la taille et la durée de vie des journaux d'audit.

   • maxAge: Nombre maximal de jours pendant lesquels les fichiers journaux d'audit doivent être conservés, sur la base de l'horodatage encodé dans leur nom de fichier.
   • maxBackup: Nombre maximal de fichiers journaux d'audit à conserver. La valeur 0 permet de conserver tous les fichiers journaux d'audit.
   • maxSize: Taille maximale en mégaoctets d'un fichier journal d'audit avant qu'il ne fasse l'objet d'une rotation.

Vérification

1. Consulter directement le fichier journal de l'audit :

   1. Obtenir le nom du pod keda-metrics-apiserver-*:

      oc get pod -n openshift-keda

      Exemple de sortie

      NAME                                                  READY   STATUS    RESTARTS   AGE
      custom-metrics-autoscaler-operator-5cb44cd75d-9v4lv   1/1     Running   0          8m20s
      keda-metrics-apiserver-65c7cc44fd-rrl4r               1/1     Running   0          2m55s
      keda-operator-776cbb6768-zpj5b                        1/1     Running   0          2m55s

   2. Affichez les données du journal à l'aide d'une commande similaire à la suivante :

      oc logs keda-metrics-apiserver-<hash>|grep -i metadata 1

      1

      Facultatif : vous pouvez utiliser la commande grep pour spécifier le niveau de journal à afficher : Metadata, Request, RequestResponse.

      Par exemple :

      $ oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata

      Exemple de sortie

       ...
      {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"4c81d41b-3dab-4675-90ce-20b87ce24013","stage":"ResponseComplete","requestURI":"/healthz","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.1"],"userAgent":"kube-probe/1.26","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-02-16T13:00:03.554567Z","stageTimestamp":"2023-02-16T13:00:03.555032Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
       ...

2. Vous pouvez également consulter un journal spécifique :

   1. Utilisez une commande similaire à la suivante pour vous connecter au pod keda-metrics-apiserver-*:

      oc rsh pod/keda-metrics-apiserver-<hash> -n openshift-keda

      Par exemple :

      $ oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n openshift-keda

   2. Allez dans le répertoire /var/audit-policy/:

      sh-4.4$ cd /var/audit-policy/

   3. Liste des journaux disponibles :

      sh-4.4$ ls

      Exemple de sortie

      log-2023.02.17-14:50  policy.yaml

   4. Consulter le journal, si nécessaire :

      sh-4.4$ cat <log_name>/<pvc_name>|grep -i <log_level> 1

      1

      Facultatif : vous pouvez utiliser la commande grep pour spécifier le niveau de journal à afficher : Metadata, Request, RequestResponse.

      Par exemple :

      sh-4.4$ cat log-2023.02.17-14:50/pvc-audit-log|grep -i Request

      Exemple de sortie

       ...
      {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Request","auditID":"63e7f68c-04ec-4f4d-8749-bf1656572a41","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.1"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-02-17T13:12:55.035478Z","stageTimestamp":"2023-02-17T13:12:55.038346Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""}}
       ...

Procédure

1. Accédez au répertoire dans lequel vous souhaitez stocker les données must-gather.

   Note

   Si votre cluster utilise un réseau restreint, vous devez prendre des mesures supplémentaires. Si votre registre miroir dispose d'une autorité de certification approuvée, vous devez d'abord ajouter cette dernière au cluster. Pour tous les clusters sur des réseaux restreints, vous devez importer l'image par défaut must-gather en tant que flux d'images en exécutant la commande suivante.

   $ oc import-image is/must-gather -n openshift

2. Effectuez l'une des opérations suivantes :

   • Pour obtenir uniquement les données Custom Metrics Autoscaler Operator must-gather, utilisez la commande suivante :

     $ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
     -n openshift-marketplace \
     -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

     L'image personnalisée de la commande must-gather est tirée directement des manifestes du paquet Operator, de sorte qu'elle fonctionne sur n'importe quel cluster où l'opérateur Custom Metric Autoscaler est disponible.

   • Pour collecter les données par défaut must-gather en plus des informations de l'opérateur Autoscaler de métriques personnalisées :

     1. Utilisez la commande suivante pour obtenir l'image Custom Metrics Autoscaler Operator et la définir comme variable d'environnement :

        $ IMAGE="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
          -n openshift-marketplace \
          -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

     2. Utilisez le site oc adm must-gather avec l'image Custom Metrics Autoscaler Operator :

        $ oc adm must-gather --image-stream=openshift/must-gather --image=${IMAGE}

   Exemple 2.1. Exemple de sortie de collecte obligatoire pour le Custom Metric Autoscaler :

   └── openshift-keda
       ├── apps
       │   ├── daemonsets.yaml
       │   ├── deployments.yaml
       │   ├── replicasets.yaml
       │   └── statefulsets.yaml
       ├── apps.openshift.io
       │   └── deploymentconfigs.yaml
       ├── autoscaling
       │   └── horizontalpodautoscalers.yaml
       ├── batch
       │   ├── cronjobs.yaml
       │   └── jobs.yaml
       ├── build.openshift.io
       │   ├── buildconfigs.yaml
       │   └── builds.yaml
       ├── core
       │   ├── configmaps.yaml
       │   ├── endpoints.yaml
       │   ├── events.yaml
       │   ├── persistentvolumeclaims.yaml
       │   ├── pods.yaml
       │   ├── replicationcontrollers.yaml
       │   ├── secrets.yaml
       │   └── services.yaml
       ├── discovery.k8s.io
       │   └── endpointslices.yaml
       ├── image.openshift.io
       │   └── imagestreams.yaml
       ├── k8s.ovn.org
       │   ├── egressfirewalls.yaml
       │   └── egressqoses.yaml
       ├── keda.sh
       │   ├── kedacontrollers
       │   │   └── keda.yaml
       │   ├── scaledobjects
       │   │   └── example-scaledobject.yaml
       │   └── triggerauthentications
       │       └── example-triggerauthentication.yaml
       ├── monitoring.coreos.com
       │   └── servicemonitors.yaml
       ├── networking.k8s.io
       │   └── networkpolicies.yaml
       ├── openshift-keda.yaml
       ├── pods
       │   ├── custom-metrics-autoscaler-operator-58bd9f458-ptgwx
       │   │   ├── custom-metrics-autoscaler-operator
       │   │   │   └── custom-metrics-autoscaler-operator
       │   │   │       └── logs
       │   │   │           ├── current.log
       │   │   │           ├── previous.insecure.log
       │   │   │           └── previous.log
       │   │   └── custom-metrics-autoscaler-operator-58bd9f458-ptgwx.yaml
       │   ├── custom-metrics-autoscaler-operator-58bd9f458-thbsh
       │   │   └── custom-metrics-autoscaler-operator
       │   │       └── custom-metrics-autoscaler-operator
       │   │           └── logs
       │   ├── keda-metrics-apiserver-65c7cc44fd-6wq4g
       │   │   ├── keda-metrics-apiserver
       │   │   │   └── keda-metrics-apiserver
       │   │   │       └── logs
       │   │   │           ├── current.log
       │   │   │           ├── previous.insecure.log
       │   │   │           └── previous.log
       │   │   └── keda-metrics-apiserver-65c7cc44fd-6wq4g.yaml
       │   └── keda-operator-776cbb6768-fb6m5
       │       ├── keda-operator
       │       │   └── keda-operator
       │       │       └── logs
       │       │           ├── current.log
       │       │           ├── previous.insecure.log
       │       │           └── previous.log
       │       └── keda-operator-776cbb6768-fb6m5.yaml
       ├── policy
       │   └── poddisruptionbudgets.yaml
       └── route.openshift.io
           └── routes.yaml

3. Créez un fichier compressé à partir du répertoire must-gather qui a été créé dans votre répertoire de travail. Par exemple, sur un ordinateur utilisant un système d'exploitation Linux, exécutez la commande suivante :

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   Remplacez must-gather-local.5421342344627712289/ par le nom du répertoire.

4. Joignez le fichier compressé à votre demande d'assistance sur le portail client de Red Hat.

Procédure

1. Sélectionnez la perspective Administrator dans la console web de OpenShift Container Platform.
2. Sélectionnez Observe Metrics.
3. Pour créer une requête personnalisée, ajoutez votre requête PromQL au champ Expression.
4. Pour ajouter plusieurs requêtes, sélectionnez Add Query.

Procédure

1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators Installed Operators.
2. Passez au projet openshift-keda.

3. Supprimer la ressource personnalisée KedaController.

   1. Trouvez l'opérateur CustomMetricsAutoscaler et cliquez sur l'onglet KedaController.
   2. Recherchez la ressource personnalisée, puis cliquez sur Delete KedaController.
   3. Cliquez sur Uninstall.

4. Supprimez l'opérateur Autoscaler de métriques personnalisées :

   1. Cliquez sur Operators Installed Operators.
   2. Trouvez l'opérateur CustomMetricsAutoscaler et cliquez sur le menu Options et sélectionnez Uninstall Operator.
   3. Cliquez sur Uninstall.

5. Optionnel : Utilisez le CLI OpenShift pour supprimer les composants autoscaler des métriques personnalisées :

   1. Supprimez les CRD de métriques personnalisées autoscaler :

      • clustertriggerauthentications.keda.sh
      • kedacontrollers.keda.sh
      • scaledjobs.keda.sh
      • scaledobjects.keda.sh
      • triggerauthentications.keda.sh

      $ oc delete crd clustertriggerauthentications.keda.sh kedacontrollers.keda.sh scaledjobs.keda.sh scaledobjects.keda.sh triggerauthentications.keda.sh

      La suppression des CRD supprime les rôles associés, les rôles de cluster et les liaisons de rôles. Toutefois, il se peut que quelques rôles de cluster doivent être supprimés manuellement.

   2. Liste des rôles de cluster autoscaler de métriques personnalisées :

      $ oc get clusterrole | grep keda.sh

   3. Supprimez les rôles de cluster autoscaler de métriques personnalisées répertoriés. Par exemple :

      $ oc delete clusterrole.keda.sh-v1alpha1-admin

   4. Liste de toutes les liaisons de rôles de cluster autoscaler de métriques personnalisées :

      $ oc get clusterrolebinding | grep keda.sh

   5. Supprimez les liaisons de rôles de cluster autoscaler de métriques personnalisées répertoriées. Par exemple :

      $ oc delete clusterrolebinding.keda.sh-v1alpha1-admin

6. Supprimez le projet custom metrics autoscaler :

   $ oc delete project openshift-keda

7. Supprimez l'opérateur Autoscaler de métrique de cluster :

   $ oc delete operator/openshift-custom-metrics-autoscaler-operator.openshift-keda