Utilisation de plusieurs mécanismes d'autoscaling pour mettre à l'échelle automatiquement un cluster K8s

Aug 20 2020

Dans une expérience récente, j'ai essayé de mettre à l'échelle automatiquement mon cluster K8 en utilisant deux mécanismes: KEDA et HPA (voir ci-dessous). Je voulais utiliser les métriques de ressources HPA OOB pour mettre à l'échelle mon cluster en fonction de l'utilisation des ressources du pod (mémoire et processeur) et KEDA pour une mise à l'échelle automatique en fonction de métriques personnalisées.

Même si mon déploiement réussit et que le cluster était sain et fonctionnel. Lorsque l'autoscaling a démarré, le cluster s'est détraqué! Les pods étaient constamment provisionnés puis déprovisionnés, cet état a continué même après que j'ai arrêté le trafic contre le cluster. J'ai dû attendre les périodes de récupération avant de redevenir sain d'esprit.

Je n'ai trouvé aucune documentation officielle sur ce sujet, donc, demandant ici.

Mes questions:

  • Un cluster k8s peut-il être configuré pour une mise à l'échelle automatique à l'aide de plusieurs mécanismes?
  • Si oui, qu'est-ce que j'ai fait de mal?

C'était sur K8s version 1.15.11 et KEDA 1.4.1

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: {{ $fullName }} labels: deploymentName: {{ $fullName }}
    {{- include "deployment.labels" . | nindent 4 }}
spec:
  scaleTargetRef:
    deploymentName: {{ $fullName }} pollingInterval: {{ .Values.scaleobject.pollingInterval }} cooldownPeriod: {{ .Values.scaleobject.cooldownPeriod }} minReplicaCount: {{ .Values.scaleobject.minReplicaCount }} maxReplicaCount: {{ .Values.scaleobject.maxReplicaCount }} triggers: - type: prometheus metadata: serverAddress: {{ tpl .Values.scaleobject.serverAddress . | quote }} metricName: access_frequency threshold: "{{ .Values.scaleobject.threshold }}" query: {{ tpl .Values.scaleobject.query . | quote }} --- apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: resource-utilization-scaling namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: {{ $fullName }}
  minReplicas: {{ .Values.scaleobject.minReplicaCount }}
  maxReplicas: {{ .Values.scaleobject.maxReplicaCount }}
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: {{ .Values.scaleobject.cpuUtilization }}
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: {{ .Values.scaleobject.memUtilization }}

Réponses

3 Rico Aug 20 2020 at 06:26

KEDA n'a pas encore de prise en charge directe de l'autoscaler de cluster , vous aurez donc une certaine imprévisibilité. Essentiellement, vous avez deux informations qui ne sont pas partagées, celle de KEDA et celle de l'autoscaler du cluster et certaines peuvent ne pas être d'accord à un moment donné.

Le mieux à mon avis est de ralentir votre autoscaling global de tout afin que cela permette à tout l'autoscaler de rattraper tout écart. Par exemple, vous pouvez utiliser des éléments tels que le temps de recharge dans un groupe de mise à l'échelle automatique pour éviter un manque de ressources.

✌️