Laufzeitdienste skalieren/automatisch skalieren

Sie sehen sich gerade die Version 1.11 der Apigee Hybrid-Dokumentation an. Weitere Informationen finden Sie unter Unterstützte Versionen.

Version 1.11 

Unterstützte Versionen:

• v1.13 (aktuellste Version)                        
• v1.12                         
• v1.11                         
• Liste der unterstützten Versionen

Nicht unterstützte Versionen:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Sie können die meisten in Kubernetes ausgeführten Dienste über die Befehlszeile oder per Konfigurationsüberschreibung skalieren. Sie können Skalierungsparameter für Apigee Hybrid-Laufzeitdienste in der overrides.yaml-Datei festlegen.

Dienst	Implementierung als	Skalieren
Cassandra	ApigeeDatastore (CRD)	Weitere Informationen finden Sie unter Cassandra-Skalierung skalieren.
Ingress/LoadBalancer	Deployment	Anthos Service Mesh verwendet horizontales Pod-Autoscaling (HPAs).
Logger	DaemonSet	DaemonSets verwalten die Replikate eines Pods auf allen Knoten. Sie skalieren also, wenn Sie die Pods selbst skalieren.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Zur Skalierung über die Konfiguration erhöhen Sie den Wert des Konfigurationsattributs replicaCountMin der Bereitstellung für die Stanzas mart, watcher und/oder connectAgent. Beispiele: mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 Diese Bereitstellungen verwenden ein horizontales Pod-Autoscaling für das Autoscaling. Legen Sie für das Attribut targetCPUUtilizationPercentage des Bereitstellungsobjekts den Schwellenwert für das Hochskalieren fest. Wird dieser Wert überschritten, fügt Kubernetes Pods bis zum Wert von replicaCountMax hinzu. Weitere Informationen zum Festlegen von Konfigurationsattributen finden sich unter Komponenten der Laufzeitebene verwalten.
Laufzeit Synchronizer UDCA	ApigeeEnvironment (CRD)	Zur Skalierung über die Konfiguration erhöhen Sie den Wert des Attributs replicaCountMin für die Stanzas udca, synchronizer und/oder runtime in der Überschreibungsdatei. Beispiele: synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 Hinweis: Diese Änderungen gelten für ALLE Umgebungen in der Überschreibungendatei. Wenn Sie die Skalierung für jede Umgebung anpassen möchten, lesen Sie den Abschnitt Erweiterte Konfigurationen weiter unten. Bereitstellungen verwenden ein horizontales Pod-Autoscaling für das Autoscaling. Legen Sie für das Attribut targetCPUUtilizationPercentage des Bereitstellungsobjekts den Schwellenwert für das Hochskalieren fest. Wird dieser Wert überschritten, fügt Kubernetes Pods bis zum Wert von replicaCountMax hinzu. Weitere Informationen zum Festlegen von Konfigurationsattributen finden sich unter Komponenten der Laufzeitebene verwalten.

Erweiterte Konfigurationen

In einigen Szenarien müssen Sie eventuell erweiterte Skalierungsoptionen verwenden. Beispielszenarien:

• Unterschiedliche Skalierungsoptionen für jede Umgebung festlegen. Beispiel: env1 hat ein minReplica von 5 und env2 ein minReplica von 2.
• Unterschiedliche Skalierungsoptionen für jede Komponente in einer Umgebung festlegen. Beispiel: Die Komponente udca hat ein maxReplica von 5 und die Komponente synchronizer hat ein maxReplica von 2.

Das folgende Beispiel zeigt, wie Sie mit dem Befehl kubernetes patch das Attribut maxReplicas für die Komponente runtime ändern:

1. Erstellen Sie Umgebungsvariablen für die Verwendung mit dem Befehl:

   export ENV=my-environment-name
   export NAMESPACE=apigee  #the namespace where apigee is deployed
   export COMPONENT=runtime #can be udca or synchronizer
   export MAX_REPLICAS=2
   export MIN_REPLICAS=1

2. Wenden Sie den Patch an. In diesem Beispiel wird davon ausgegangen, dass sich kubectl in Ihrem PATH befindet:

   kubectl patch apigeeenvironment -n $NAMESPACE \
     $(kubectl get apigeeenvironments -n $NAMESPACE -o jsonpath='{.items[?(@.spec.name == "'$ENV'" )]..metadata.name}') \
     --patch "$(echo -e "spec:\n  components:\n    $COMPONENT:\n      autoScaler:\n        maxReplicas: $MAX_REPLICAS\n        minReplicas: $MIN_REPLICAS")" \
     --type merge

3. Prüfen Sie, ob die Änderung erfolgreich war:

   kubectl get hpa -n $NAMESPACE

Umgebungsbasierte Skalierung

Standardmäßig wird die Skalierung auf Organisationsebene beschrieben. Sie können die Standardeinstellungen überschreiben. Geben Sie dazu die umgebungsspezifische Skalierung in der Datei overrides.yaml an, wie im folgenden Beispiel gezeigt:

envs:
  # Apigee environment name
  - name: test
    components:
    # Environment-specific scaling override
    # Otherwise, uses scaling defined at the respective root component
     runtime:
      replicaCountMin: 2
      replicaCountMax: 20
  

Messwertbasierte Skalierung

Bei der messwertbasierten Skalierung kann die Laufzeit CPU- und Anwendungsmesswerte verwenden, um die apigee-runtime-Pods zu skalieren. Die Kubernetes Horizontal Pod Autoscaler (HPA) API verwendet das Feld hpaBehavior, um das Verhalten beim Hoch- und Herunterskalieren des Zieldienstes zu konfigurieren. Die messwertbasierte Skalierung ist für andere Komponenten in einer Hybridbereitstellung nicht verfügbar.

Hinweis: Es ist eine interne Verbindung zwischen Prometheus und dem Prometheus-Adapter an Port 6443 erforderlich, um Messwertdaten zu empfangen und die Skalierung zu aktivieren. Weitere Informationen zu erforderlichen Ports finden Sie unter Interne Verbindungen.

Die Skalierung kann anhand der folgenden Messwerte angepasst werden:

Messwert	Messen	Hinweise
serverNioTaskWaitTime	Durchschnittliche Wartezeit (in Pikosekunden) der Verarbeitungswarteschlange in Laufzeitinstanzen für Proxyanfragen in der HTTP-Schicht.	Dieser Messwert misst die Auswirkungen der Anzahl und Nutzlastgröße von Proxyanfragen und -antworten.
serverMainTaskWaitTime	Durchschnittliche Wartezeit (in Pikosekunden) der Verarbeitungswarteschlange in Laufzeitinstanzen für Proxyanfragen zur Verarbeitung von Richtlinien.	Dieser Messwert misst die Auswirkungen der Komplexität in den mit dem Proxy-Anfrageablauf verknüpften Richtlinien.

Das folgende Beispiel aus der runtime-Stanza in overrides.yaml veranschaulicht die Standardparameter (und die zulässigen Bereiche) für die Skalierung von apigee-runtime-Pods in einer Hybridimplementierung:

hpaMetrics:
      serverMainTaskWaitTime: 400M (300M to 450M)
      serverNioTaskWaitTime: 400M (300M to 450M)
      targetCPUUtilizationPercentage: 75
    hpaBehavior:
      scaleDown:
        percent:
          periodSeconds: 60 (30 - 180)
          value: 20 (5 - 50)
        pods:
          periodSeconds: 60 (30 - 180)
          value: 2 (1 - 15)
        selectPolicy: Min
        stabilizationWindowSeconds: 120 (60 - 300)
      scaleUp:
        percent:
          periodSeconds: 60 (30 - 120)
          value: 20 (5 - 100)
        pods:
          periodSeconds: 60 (30 - 120)
          value: 4 (2 - 15)
        selectPolicy: Max
        stabilizationWindowSeconds: 30 (30 - 120)
  

Aggressivere Skalierung konfigurieren

Das Erhöhen der Werte percent und pods der Hochskalierungsrichtlinie führt zu einer aggressiveren Richtlinie für die Hochskalierung. Entsprechend führt das Erhöhen der Werte percent und pods in scaleDown zu einer aggressiven Herunterskalierungsrichtlinie. Beispiele:

hpaMetrics:
    serverMainTaskWaitTime: 400M
    serverNioTaskWaitTime: 400M
    targetCPUUtilizationPercentage: 75
  hpaBehavior:
    scaleDown:
      percent:
        periodSeconds: 60
        value: 20
      pods:
        periodSeconds: 60
        value: 4
      selectPolicy: Min
      stabilizationWindowSeconds: 120
    scaleUp:
      percent:
        periodSeconds: 60
        value: 30
      pods:
        periodSeconds: 60
        value: 5
      selectPolicy: Max
      stabilizationWindowSeconds: 30

Im obigen Beispiel wird scaleDown.pods.value auf 5, scaleUp.percent.value auf 30 und scaleUp.pods.value auf 5 erhöht.

Hinweis: Der Wert von periodSeconds sollte nicht unter 30 liegen.

Weniger aggressive Skalierung konfigurieren

Die hpaBehavior-Konfigurationswerte können auch reduziert werden, um weniger aggressive Richtlinien zum Hoch- und Herunterskalieren zu implementieren. Beispiele:

hpaMetrics:
    serverMainTaskWaitTime: 400M
    serverNioTaskWaitTime: 400M
    targetCPUUtilizationPercentage: 75
  hpaBehavior:
    scaleDown:
      percent:
        periodSeconds: 60
        value: 10
      pods:
        periodSeconds: 60
        value: 1
      selectPolicy: Min
      stabilizationWindowSeconds: 180
    scaleUp:
      percent:
        periodSeconds: 60
        value: 20
      pods:
        periodSeconds: 60
        value: 4
      selectPolicy: Max
      stabilizationWindowSeconds: 30

Im obigen Beispiel wird scaleDown.percent.value auf 10 und scaleDown.pods.value auf 1 verringert. Außerdem wird scaleUp.stablizationWindowSeconds auf 180 erhöht.

Weitere Informationen zur messwertbasierten Skalierung mit dem Feld hpaBehavior finden Sie unter Skalierungsrichtlinien.

Messwertbasierte Skalierung deaktivieren

Auch wenn die messwertbasierte Skalierung standardmäßig aktiviert ist und nicht vollständig deaktiviert werden kann, können Sie die Schwellenwerte für Messwerte so konfigurieren, dass keine messwertbasierte Skalierung ausgelöst wird. Das resultierende Skalierungsverhalten entspricht dem CPU-basierten Autoscaling. Sie können beispielsweise die folgende Konfiguration verwenden, um die Auslösung der messwertbasierten Skalierung zu verhindern:

hpaMetrics:
      serverMainTaskWaitTime: 4000M
      serverNioTaskWaitTime: 4000M
      targetCPUUtilizationPercentage: 75
    hpaBehavior:
      scaleDown:
        percent:
          periodSeconds: 60
          value: 10
        pods:
          periodSeconds: 60
          value: 1
        selectPolicy: Min
        stabilizationWindowSeconds: 180
      scaleUp:
        percent:
          periodSeconds: 60
          value: 20
        pods:
          periodSeconds: 60
          value: 4
        selectPolicy: Max
        stabilizationWindowSeconds: 30

Fehlerbehebung

In diesem Abschnitt werden Methoden zur Fehlerbehebung für häufige Fehler beschrieben, die beim Konfigurieren der Skalierung und des Autoscalings auftreten können.

HPA zeigt unknown für Messwerte an

Wenn die messwertbasierte Skalierung nicht funktioniert und der HPA unknown für Messwerte anzeigt, verwenden Sie den folgenden Befehl, um die HPA-Ausgabe zu prüfen:

kubectl describe hpa HPA_NAME

Ersetzen Sie beim Ausführen des Befehls HPA_NAME durch den Namen des HPA, den Sie aufrufen möchten.

Die Ausgabe zeigt das CPU-Ziel und die Auslastung des Dienstes. Daran erkennen Sie, dass die CPU-Skalierung bei fehlender messwertbasierter Skalierung funktioniert. Informationen zum HPA-Verhalten mit mehreren Parametern finden Sie unter Skalierung für mehrere Messwerte.