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 (répliques) 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. Cette mise à l'échelle est essentielle pour garantir la disponibilité des applications, l'utilisation efficace des ressources et les économies de coûts 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 de pods évite aux opérateurs de devoir surveiller en permanence 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 Google Cloud , consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Effectuer le scaling d'un déploiement

Utilisez la fonctionnalité de scaling de Kubernetes pour adapter le nombre de pods exécutés dans votre déploiement.

Autoscaler les pods d'un déploiement

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

Pour vous assurer que l'autoscaler horizontal de pods peut mesurer correctement le pourcentage de 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 : le 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, exprimé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 le scaling d'un déploiement manuellement, 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 : le 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 répliqués dans le déploiement.

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

L'autoscaling horizontal des pods utilise par défaut 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 de pods avec des métriques personnalisées de Prometheus, vous pouvez faire évoluer les charges de travail en fonction de métriques spécifiques aux applications, 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 données riches déjà collectées par votre pile de surveillance Prometheus.

Conditions préalables à l'utilisation de 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 d'administration : 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 consiste à définir des règles de métriques et à mettre à jour la configuration du cluster :

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

Définissez les règles basées sur PromQL pour vos métriques personnalisées dans une 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é de la couche de transport mutuelle (mTLS), créez un secret Kubernetes au format kubeconfig contenant les identifiants nécessaires.

L'exemple suivant montre un secret compatible avec 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'annotation preview.baremetal.cluster.gke.io/metrics-adapter: "true" à metadata pour 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 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 pour l'autoscaling horizontal des pods en créant une ressource HorizontalPodAutoscaler qui cible les métriques personnalisées définies dans les champs ConfigMaps rules.

L'exemple 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 de 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.