Extension et rétrécissement automatiques du pod de Kubernetes et principe HPA

Dans les scénarios commerciaux réels, nous rencontrons souvent des scénarios dans lesquels un service doit être étendu (par exemple: test de stress test, pic de commerce électronique, grande promotion, ou en raison de contraintes de ressources, réduction de la charge de travail, etc., nous devons vérifier le nombre d'instances de service. Opérations d'extension). Dans Kubernetes, le mécanisme de mise à l'échelle de Deployment / RC peut être utilisé pour faciliter les opérations de mise à l'échelle automatisées.

Mise à l'échelle de Kubernetes

L'expansion et la contraction du pod de Kubernetes sont divisées en deux types: manuel et automatique

1. Mode manuel

En mode manuel, le nombre de copies de pod est défini pour un déploiement / RC via la commande kubectl scale. Cela peut être fait en un seul clic.

Exemple:

chat scale.yaml

---
apiVersion: apps / v1
genre: déploiement
métadonnées:
  nom: ops-nginx
  espace de noms: ops
spec:
  sélecteur:
    matchLabels:
      application: ops-nginx
  répliques: 1 
  modèle:
    métadonnées:
      Étiquettes:
        application: ops-nginx
    spec:
      imagePullSecrets:
      - nom: cd-registry
      conteneurs:
      - image: port.ttsingops.com/nginx/nginx:1.16.0
        nom: ops-nginx

kubectl applique -f scale.yaml

kubectl obtenir po -n ops

#Développer

déploiement à l'échelle kubectl ops-nginx -n ops --replicas 5

# Opération de rétrécissement

déploiement à l'échelle kubectl ops-nginx -n ops --replicas 2

kubectl obtenir po -n ops

2. Mode automatique

L'utilisateur doit se développer et se contracter selon un certain indice de performance ou basé sur un index personnalisé Prometheus, et le système changera et s'ajustera automatiquement en fonction de l'indice de performance dans cette plage.

Introduction à HAP

HPA (Horizontal Pod Autoscaler, Pod horizontal autoscaler) a été introduit à partir de Kubernetes V1.1. Il est utilisé pour réaliser la fonction d'expansion et de contraction automatique du pod en fonction de l'utilisation du processeur. Le contrôleur HPA est basé sur la durée définie par le paramètre de démarrage du service kube-controller-manager du maître - horizontal-pod-autoscaler-sync-period, détecte périodiquement l'utilisation du processeur du pod cible et vérifie le RC ou le déploiement lorsque les conditions sont remplies. Le nombre de copies de pod est ajusté pour correspondre à l'utilisation moyenne du processeur du pod définie par l'utilisateur.

Evolution de la version de HPA:

HPA prend actuellement en charge trois versions principales: autoscaling / v1, autoscaling / v2beta1 et autuscaling / v2beta2.

Quelle est la différence entre ces trois versions?

La version autoscaling / v1 prend uniquement en charge la mise à l'échelle horizontale des pods avec un indicateur de processeur.

L'autoscaling / v2beta1 ajoute la prise en charge des indicateurs personnalisés. Outre les indicateurs exposés par cadvisor, il prend également en charge les indicateurs personnalisés, tels que QPS fourni par un tiers, ou l'expansion basée sur d'autres ressources, qui doit prendre en charge certains composants tiers. .

autoscaling / v2beta2 ajoute la prise en charge des indicateurs externes

Le principe de l'expansion et de la contraction automatiques HPA?

Le serveur de métriques de Kubernetes collecte en permanence les données métriques de toutes les copies de pod. Le contrôleur HPA obtient ces données via l'API Metrics Server (l'API de Heapster ou l'API d'agrégation, qui est lentement obsolète et utilise Metrice Server) et calcule en fonction des règles de mise à l'échelle définies pour obtenir le nombre de copies de pod cible. Lorsque le nombre de copies du pod cible est différent du nombre de copies actuelles, le contrôleur HPA lance une opération de mise à l'échelle vers le contrôleur de copie du pod (RC / déploiement) pour ajuster le nombre de copies du pod pour terminer l'opération de mise à l'échelle.

En pensant:

Si l'utilisation du processeur d'un pod augmente soudainement dans un certain laps de temps, puis diminue immédiatement, le pod ne se développera-t-il pas et ne rétrécira-t-il pas fréquemment? Autrement dit, le nombre de copies est constamment ajusté. Il y aura un cycle de refroidissement ici. Quel est le temps de refroidissement après chaque expansion et contraction.

Dans HPA, le cycle de refroidissement par extension par défaut est de 3 minutes et le cycle de refroidissement par rétraction est de 5 minutes.

Le temps de refroidissement peut être réglé en ajustant les paramètres de démarrage du composant kube-controller-manager:

- refroidissement d'expansion horizontal-pod-autoscaler-downscale-delay

- refroidissement horizontal-pod-autoscaler-upscale-delay shrink

Exemple:

Prenons un exemple, puis mettons la pression sur le pod pour une expansion automatique.

chat auto_scale.yaml

---
apiVersion: apps / v1
genre: déploiement
métadonnées:
  nom: auto-nginx
  espace de noms: ops
spec:
  sélecteur:
    matchLabels:
      application: auto-nginx
  répliques: 1
  modèle:
    métadonnées:
      Étiquettes:
        application: auto-nginx
    spec:
      imagePullSecrets:
      - nom: cd-registry
      conteneurs:
      - image: port.ttsingops.com/nginx/nginx:1.16.0
        nom: auto-nginx
        Ressources:
          demandes:
            processeur: 200m
        ports:
        - conteneurPort: 80
---
#Un service
apiVersion: v1
genre: Service
métadonnées:
  nom: auto-nginx
  espace de noms: ops
spec:
  type: NodePort
  ports:
  - port: 8088
    protocole: TCP
    targetPort: 80
    nodePort: 38088
  selector:
    app: auto-nginx

kubectl apply -f auto_scale.yaml

kubectl get svc,pod -n ops -o wide

cat auto_nginx_hpa.yaml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: auto-nginx-hpa
  namespace: ops
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: auto-nginx
  minReplicas: 1
  maxReplicas: 8
  targetCPUUtilizationPercentage: 50