Übung: Bereitstellen eines Skalierungsobjekts im Azure Kubernetes Service-Cluster
In dieser Übung stellen Sie eine benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD) für ein Skalierungsobjekt in Ihrem AKS-Cluster bereit. Das Skalierungsobjekt enthält den Trigger, der die bereitgestellte Anwendung mit KEDA verbindet. Nach der Bereitstellung in AKS überwacht KEDA die Redis-Liste und skaliert hoch, wenn die Listenlänge den definierten Schwellenwert übersteigt, und skaliert herunter, wenn die Listenlänge darunter liegt.
Übersicht über das ScaledObject-Manifest
scaleTargetRef: In diesem Abschnitt wird beschrieben, welche Workload KEDA überwacht.scaleTargetRef: apiVersion: apps/v1 # Optional. Default: apps/v1 kind: deployment # Optional. Default: Deployment name: contoso-microservice # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: contoso-microservice # Optional. Default: .spec.template.spec.containers[0]minReplicaCountundmaxReplicaCount: Diese beiden Attribute bestimmen den Bereich von Replikaten, den KEDA für die Skalierung verwendet. In diesem Fall wird KEDA angewiesen, von einem Minimum von 0 auf ein Maximum von 20 zu skalieren.minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 20 # Optional. Default: 100Hinweis
minReplicaCount: 0setzt die Standardreplikatanzahl der Bereitstellung von 1 auf 0. Dies tritt auf, wenn sich der Dienst im Leerlauf befindet und keine Ereignisse verarbeitet. Wenn in diesem Fall keine Elemente in der Redis-Liste enthalten sind und der Dienst im Leerlauf bleibt, skaliert KEDA auf 0.advanced: Dieser Abschnitt bezieht sich im Allgemeinen auf die erweiterte Anpassung von KEDA.restoreToOriginalReplicaCountweist KEDA an, die Replikatanzahl nach Hochskalierungsereignissen auf den ursprünglichen Wert zurückzusetzen. In diesem Fall legen Sie den Wert auffalsefest, was zu einer Herunterskalierung auf denminReplicaCount-Wert 0 führt.restoreToOriginalReplicaCount: false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15triggers: In diesem Abschnitt wirdscalersverwendet, um zu ermitteln, ob das Objekt aktiviert oder deaktiviert werden soll, und um benutzerdefinierte Metriken für bestimmte Ereignisquellen bereitzustellen. DielistLength-Metrik weist KEDA zum Hochskalieren an, wenn zehn Elemente in der Liste enthalten sind.triggers: - type: redis metadata: # address: # Format must be host:port passwordFromEnv: REDIS_KEY listName: keda # Required listLength: "10" # Required enableTLS: "false" # optional databaseIndex: "0" # optional hostFromEnv: REDIS_HOST portFromEnv: REDIS_PORT
Weitere Informationen finden Sie im Artikel zu KEDA-Skalierungen.
Erstellen des ScaledObject-Manifests
Erstellen Sie in Cloud Shell mithilfe des
touch-Befehls eine Manifestdatei für die Kubernetes-Bereitstellung namensscaled-object.yaml:touch scaled-object.yamlÖffnen Sie den integrierten Editor in Cloud Shell, indem Sie
code .eingeben.Öffnen Sie die
scaled-object.yaml-Datei, und fügen Sie den folgenden YAML-Codeabschnitt hinzu:apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaled-contoso spec: scaleTargetRef: apiVersion: apps/v1 # Optional. Default: apps/v1 kind: deployment # Optional. Default: Deployment name: contoso-microservice # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: contoso-microservice # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 120 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 20 # Optional. Default: 100 advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: - type: redis metadata: # address: # Format must be host:port passwordFromEnv: REDIS_KEY listName: keda # Required listLength: "10" # Required enableTLS: "false" # optional databaseIndex: "0" # optional hostFromEnv: REDIS_HOST portFromEnv: REDIS_PORTSpeichern Sie die Manifestdatei (STRG+S), und schließen Sie den Editor (STRG+Q).
Anwenden des Manifests
Stellen Sie das Manifest mithilfe des
kubectl apply-Befehls in Ihrem Cluster bereit:kubectl apply -f ./scaled-object.yamlIhre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:
scaledobject.keda.sh/scaled-contoso createdFühren Sie den Befehl
kubectl get podsaus, um die Anzahl der ausgeführten Pods zu überprüfen:kubectl get podsIhre Ausgabe sollte in etwa wie im folgenden Beispiel aussehen, und es sollte ein Pod ausgeführt werden:
NAME READY STATUS RESTARTS AGE contoso-microservice-794d98b5-4flvg 1/1 Running 0 2m1sFühren Sie den Befehl
kubectl get podsin regelmäßigen Abständen aus, um zu überprüfen, ob die Bereitstellung die Anzahl der Pods entsprechend dem Arbeitsbacklog skaliert.Hinweis
Wenn Sie die Linux-Hilfsprogrammüberwachung installiert haben, können Sie den Befehl
watch kubectl get podsverwenden, um die Pods zu sehen, um die Redis-Listenelemente zu verarbeiten. Wenn nicht, können Sie den Befehlkubectl get pods -wverwenden.Ihre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:
NAME READY STATUS RESTARTS AGE contoso-microservice-794d98b5-4flvg 1/1 Running 0 3m contoso-microservice-794d98b5-4jpxp 1/1 Running 0 3m contoso-microservice-794d98b5-4lw7b 1/1 Running 0 2m15s contoso-microservice-794d98b5-5fqj5 1/1 Running 0 3m contoso-microservice-794d98b5-5kdbw 1/1 Running 0 2m15s
Nachdem alle Elemente verarbeitet wurden und cooldownPeriod abgelaufen ist, sehen Sie, dass die Anzahl der Pods 0 ist. Dies liegt daran, dass KEDA alle ausgeführten Replikate entfernt hat und keine Elemente zum Verarbeiten mehr vorhanden sind.