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 horizontal des pods

Ce document explique comment configurer l'autoscaling horizontal des pods pour les charges de travail sans état existantes exécutées dans votre cluster. L'autoscaling horizontal des pods ajuste automatiquement le nombre de pods (instances dupliquées) en cours d'exécution pour une application en fonction de la demande en temps réel. Il supprime les pods lorsque la charge diminue et en ajoute lorsque la charge augmente. Ce scaling (augmentation et diminution) est essentiel pour garantir la disponibilité des applications, une utilisation efficace des ressources et des économies en adaptant précisément la capacité au trafic utilisateur sans intervention manuelle. À mesure que les exigences de votre charge de travail de conteneur évoluent, l'autoscaling des pods élimine la nécessité pour les opérateurs de surveiller constamment les performances et d'ajuster manuellement le nombre de pods.

Cette page est destinée aux administrateurs, aux architectes et aux opérateurs qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu, consultez Rôles utilisateur et tâches courantes de GKE. Google Cloud

Effectuer le scaling d'un déploiement

Utilisez la fonctionnalité de scaling de Kubernetes pour ajuster de manière appropriée le nombre de pods exécutés dans votre déploiement.

Effectuer l'autoscaling des pods d'un déploiement

Kubernetes propose l'autoscaling pour éviter d'avoir à mettre à jour manuellement votre déploiement lorsque la demande évolue. Pour effectuer l'autoscaling des pods de votre déploiement, procédez comme suit :

Pour vous assurer que l'autoscaler horizontal de pods peut mesurer correctement le pourcentage d'utilisation du processeur, définissez la demande de ressources de processeur sur votre déploiement.
Définissez l'autoscaler horizontal de pods dans votre déploiement :
```
kubectl --kubeconfig CLUSTER_KUBECONFIG \
    -n NAMESPACE \
    autoscale deployment DEPLOYMENT_NAME \
    --cpu-percent=CPU_PERCENT \
    --min=MIN_NUMBER_REPLICAS \
    --max=MAX_NUMBER_REPLICAS
```
Remplacez les éléments suivants :
- CLUSTER_KUBECONFIG: fichier kubeconfig du cluster.
- NAMESPACE : espace de noms. Pour les clusters partagés, il doit s'agir d'un espace de noms de projet. Pour les clusters standards, il peut s'agir de n'importe quel espace de noms.
- DEPLOYMENT_NAME: nom du déploiement à autoscaler.
- CPU_PERCENT: utilisation moyenne cible du processeur à demander, représentée en pourcentage, pour l'ensemble des pods.
- MIN_NUMBER_REPLICAS: limite inférieure du nombre de pods que l'autoscaler peut provisionner.
- MAX_NUMBER_REPLICAS: limite supérieure du nombre de pods que l'autoscaler peut provisionner.

Vérifiez l'état actuel de l'autoscaler horizontal de pods :

kubectl get hpa

Le résultat ressemble à ce qui suit :

NAME              REFERENCE                          TARGET    MINPODS   MAXPODS   REPLICAS   AGE
DEPLOYMENT_NAME   Deployment/DEPLOYMENT_NAME/scale   0% / 50%  1         10        1          18s

Effectuer manuellement le scaling des pods d'un déploiement

Si vous préférez effectuer manuellement le scaling d'un déploiement, exécutez la commande suivante :

kubectl --kubeconfig CLUSTER_KUBECONFIG \
    -n NAMESPACE \
    scale deployment DEPLOYMENT_NAME \
    --replicas NUMBER_OF_REPLICAS

Remplacez les éléments suivants :

CLUSTER_KUBECONFIG: fichier kubeconfig du cluster.
NAMESPACE : espace de noms. Pour les clusters partagés, il doit s'agir d'un espace de noms de projet. Pour les clusters standards, il peut s'agir de n'importe quel espace de noms.
DEPLOYMENT_NAME: nom du déploiement dans lequel effectuer l'autoscaling.
DEPLOYMENT_NAME: nombre d'objets Pod dupliqués dans le déploiement.

Utiliser des métriques personnalisées de Prometheus pour l'autoscaling

Par défaut, l'autoscaling horizontal des pods utilise des métriques de ressources standards, telles que l'utilisation du processeur et de la mémoire. Les métriques standards fonctionnent pour le scaling général, mais ne sont pas utiles pour les charges d'application spécialisées.

Lorsque vous utilisez l'autoscaling horizontal des pods avec des métriques personnalisées de Prometheus, vous pouvez effectuer le scaling des charges de travail en fonction de métriques spécifiques à l'application, telles que les taux de requêtes HTTP, la profondeur de la file d'attente et la latence de traitement. Votre cluster peut répondre plus précisément à la demande réelle en exploitant les informations enrichies déjà collectées par votre pile de surveillance Prometheus.

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

Avant d'activer la fonctionnalité, les conditions suivantes doivent être remplies :

Serveur Prometheus existant : un serveur Prometheus doit déjà être déployé et accessible sur le réseau depuis le cluster (le contrôleur AHP ne gère pas l'instance Prometheus elle-même). Pour en savoir plus, consultez Déployer et configurer l'opérateur Prometheus dans Kubernetes.
Autorisations administratives : vous devez disposer des autorisations nécessaires pour modifier la ressource personnalisée du cluster.
Aucun conflit d'API : une vérification préliminaire permet de s'assurer qu'aucun autre composant n'a déjà enregistré d'APIService pour custom.metrics.k8s.io. En cas de conflit, l'adaptateur ne peut pas être activé.

Activer et configurer Prometheus

Le processus implique de définir des règles de métriques et de mettre à jour la configuration du cluster :

Créez un ou plusieurs ConfigMaps de règles de métriques.

Définissez les règles basées sur PromQL pour vos métriques personnalisées dans un ou plusieurs ConfigMaps au sein de l'espace de noms du cluster cible. Le contrôleur surveille ces ConfigMaps, les fusionne et les applique automatiquement à l'adaptateur.

Pour en savoir plus sur la définition des règles, consultez Configuration de la découverte et de la présentation des métriques dans kubernetes-sigs/prometheus-adapter.

L'exemple suivant montre un ConfigMap avec des règles définies pour http_requests_per_second dans le champ data :
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-rules
  namespace: <cluster-namespace>
data:
  config.yaml: |
    rules:
    - seriesQuery: 'http_requests_total'
      resources:
        overrides:
          namespace_name: {resource: "namespace"}
          pod_name: {resource: "pod"}
      name:
        matches: "^(.*)_total$"
        as: "${1}_per_second"
      metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[5m])) by (<<.GroupBy>>)'
```
Si votre serveur Prometheus nécessite une authentification, telle que la sécurité mutuelle de la couche de transport (mTLS), créez un secret Kubernetes au format kubeconfig contenant les identifiants nécessaires.

L'exemple suivant montre un secret qui prend en charge l'authentification de base :
```
apiVersion: v1
kind: Secret
metadata:
  name: prometheus-auth-secret
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  config: authentication-credentials
```

Mettez à jour la ressource personnalisée du cluster :

Ajoutez l'preview.baremetal.cluster.gke.io/metrics-adapter: "true" annotation aux metadata de la ressource personnalisée du cluster.

Ajoutez la section spec.metricsAdapter pour définir l'URL Prometheus et référencer vos ConfigMaps de règles.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: <cluster-name>
  namespace: <cluster-namespace>
  annotations:
    preview.baremetal.cluster.gke.io/metrics-adapter: "true"
spec:
  # ... other existing cluster configurations ...
  metricsAdapter:
    prometheus:
      url: "http://prometheus-k8s.monitoring.svc.cluster.local:9090"
      orgID: "production-environment"
      auth:
        configSecretRef:
          name: prometheus-auth-secret
          key: config # This is the key within the Secret's 'data' field
    rules:
      configMapKeyRefs:
        - name: my-app-rules
          key: config.yaml # This is the key within the ConfigMap's 'data' field
        # - name: base-system-rules
        #   key: config.yaml

Si votre instance Prometheus ne nécessite pas d'authentification, vous pouvez omettre la section metricsAdapter.prometheus.auth de la spécification du cluster.

Appliquez la ressource personnalisée du cluster mise à jour.

Le contrôleur déploie automatiquement l'adaptateur Prometheus dans l'espace de noms kube-system.

Utilisez les métriques personnalisées dans pour l'autoscaling horizontal des pods en créant une ressource HorizontalPodAutoscaler qui cible les métriques personnalisées définies dans les champs rules des ConfigMaps.

L'exemple de ConfigMap d'une étape précédente a défini une métrique personnalisée http_requests_per_second. Pour utiliser cette métrique, la ressource HorizontalPodAutoscaler doit ressembler à l'exemple suivant :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: <name>
  namespace: <namespace>
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: <workload-name>
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 10

Désactiver Prometheus

Pour désactiver l'utilisation de Prometheus avec l'autoscaling horizontal des pods, supprimez la section spec.metricsAdapter de la ressource personnalisée du cluster.

Configurer l'autoscaling horizontal des pods Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.