Utilizzo di più meccanismi di scalabilità automatica per scalare automaticamente un cluster K8s

Aug 20 2020

In un recente esperimento, ho provato a scalare automaticamente il mio cluster K8 utilizzando due meccanismi: KEDA e HPA (vedi sotto). Volevo utilizzare le metriche delle risorse HPA OOB per ridimensionare il mio cluster in base all'utilizzo delle risorse pod (memoria e CPU) e KEDA per la scalabilità automatica in base a metriche personalizzate.

Anche se la mia distribuzione ha esito positivo e il cluster era integro e funzionante. Quando è iniziata la scalabilità automatica, il cluster è andato in tilt! I pod venivano costantemente sottoposti a provisioning e quindi annullati, questo stato è continuato anche dopo che ho interrotto il traffico sul cluster. Ho dovuto aspettare i periodi di raffreddamento prima che diventasse di nuovo sano.

Non ho trovato alcuna documentazione ufficiale su questo argomento, quindi chiedendo qui.

Le mie domande:

  • È possibile configurare un cluster k8s per la scalabilità automatica utilizzando più meccanismi?
  • In caso affermativo, cosa ho fatto di sbagliato?

Questo era nella versione K8 1.15.11 e 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 }}

Risposte

3 Rico Aug 20 2020 at 06:26

KEDA non ha ancora il supporto per il programma di scalabilità automatica del cluster diretto, quindi avrai un po 'di imprevedibilità. In sostanza, hai due informazioni che non vengono condivise quella di KEDA e quella del programma di scalabilità automatica del cluster e alcune di queste potrebbero non essere d'accordo in un determinato momento.

Secondo me, è meglio rallentare la scalabilità automatica di tutto in modo che consenta a tutto il programma di scalabilità automatica di recuperare qualsiasi discrepanza. Ad esempio, puoi utilizzare cose come il cooldown in un gruppo di scalabilità automatica per evitare la carenza di risorse.

✌️