Scalabilità e scalabilità automatica dei servizi di runtime

Stai visualizzando la versione 1.9 di Documentazione di Apigee hybrid. Per ulteriori informazioni, vedi Versioni supportate.

Version 1.9 (unsupported)

   Versioni supportate:

• v1.13 (più recente)                        
• v1.12                         
• v1.11                         
• Elenco delle versioni supportate

Versioni non supportate:

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

Puoi scalare la maggior parte dei servizi in esecuzione in Kubernetes alla riga di comando o in un override della configurazione. Puoi impostare i parametri di scalabilità per i servizi di runtime di Apigee hybrid nel file overrides.yaml.

Servizio	Implementata come	Scalabilità
Cassandra	ApigeeDatastore (CRD)	Consulta Scalabilità di Cassandra.
Ingress/LoadBalancer	Implementazione	Gestisci la scalabilità con ingressGateways.replicaCountMin e ingressGateways.replicaCountMax. Nota: il gateway Apigee in entrata utilizza Anthos Service Mesh, utilizza Scalabilità automatica orizzontale dei pod (HPA).
Registratore	DaemonSet	I DaemonSet gestiscono le repliche di un pod su tutti i nodi, quindi si adattano alle modifiche quando esegui lo scale dei pod stessi.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Per eseguire il ridimensionamento tramite configurazione, aumenta il valore della proprietà di configurazione replicaCountMin del deployment per le stanza mart, watcher e/o connectAgent. Ad esempio: mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 Questi deployment utilizzano Horizontal Pod Autoscaler per la scalabilità automatica. Imposta l'oggetto Deployment targetCPUUtilizationPercentage in base alla soglia per lo scale up; quando questo valore è superato, Kubernetes aggiunge i pod al valore replicaCountMax. Per ulteriori informazioni sull'impostazione delle proprietà di configurazione, consulta Gestire i componenti del piano di runtime.
Runtime Synchronizer UDCA	ApigeeEnvironment (CRD)	Per scalare tramite configurazione, aumenta il valore del parametro Proprietà replicaCountMin per udca, synchronizer, e/o runtime nel file di override. Ad esempio: synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 Nota: queste modifiche si applicano a TUTTI gli ambienti nel file delle sostituzioni. Se vuoi personalizzare la scalabilità per ciascun ambiente, consulta Configurazioni avanzate di seguito. Questi deployment utilizzano un Horizontal Pod Autoscaler per la scalabilità automatica. Imposta la proprietà targetCPUUtilizationPercentage dell'oggetto Deployment sulla soglia per l'aumento di scala. Quando questo valore viene superato, Kubernetes aggiunge i pod fino al valore di replicaCountMax. Per ulteriori informazioni sull'impostazione delle proprietà di configurazione, consulta Gestire i componenti del piano di runtime.

Configurazioni avanzate

In alcuni scenari, potrebbe essere necessario utilizzare opzioni di scalabilità avanzate. Ecco alcuni scenari di esempio:

• Impostazione di opzioni di scalabilità diverse per ogni ambiente. Ad esempio, env1 ha un valore minReplica pari a 5 e env2 ha un valore minReplica pari a 2.
• Impostazione di opzioni di scalabilità diverse per ciascun componente all'interno di un ambiente. Ad esempio: in cui il componente udca ha un valore maxReplica pari a 5 e Il componente synchronizer ha un valore maxReplica pari a 2.

L'esempio seguente mostra come utilizzare il comando kubernetes patch per modificare la proprietà maxReplicas del componente runtime:

1. Crea le variabili di ambiente da utilizzare con il comando:

   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. Applica la patch. Tieni presente che in questo esempio si presuppone che kubectl sia in PATH:

   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. Verifica la modifica:

   kubectl get hpa -n $NAMESPACE

Scalabilità basata sull'ambiente

Per impostazione predefinita, la scalabilità è descritta a livello di organizzazione. Puoi sostituire le impostazioni predefinite specificando la scalabilità specifica per l'ambiente nel file overrides.yaml, come mostrato nell'esempio seguente:

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

Scalabilità basata sulle metriche

Con la scalabilità basata sulle metriche, il runtime può utilizzare le metriche di CPU e applicazione per scalare i pod apigee-runtime. L'API Horizontal Pod Autoscaler (HPA) di Kubernetes, utilizza il campo hpaBehavior per configurare i comportamenti di scale up e scale down del servizio di destinazione. La scalabilità basata sulle metriche non è disponibile per altri componenti in un deployment ibrido.

Nota: per ricevere i dati delle metriche e abilitare il ridimensionamento, deve essere aperta una connessione interna tra Prometheus e Prometheus-Adapter sulla porta 6443. Per ulteriori informazioni sulle porte richieste, consulta la sezione Connessioni interne.

La scalabilità può essere regolata in base alle seguenti metriche:

Metrica	Misura	Considerazioni
serverNioTaskWaitTime	Tempo di attesa medio (in picosecondi) di elaborazione della coda nelle istanze di runtime per le richieste proxy a livello http.	Questa metrica misura l'impatto del numero e della dimensione del payload di richieste e risposte proxy.
serverMainTaskWaitTime	Tempo di attesa medio (in picosecondi) della coda di elaborazione nelle istanze di runtime per le richieste proxy per l'elaborazione dei criteri.	Questa metrica misura l'impatto della complessità dei criteri associati al flusso di richieste proxy.

Il seguente esempio dalla stanza runtime nella overrides.yaml illustra i parametri standard (e gli intervalli consentiti) per la scalabilità dei pod apigee-runtime in un'implementazione ibrida:

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)
  

Configurare una scalabilità più aggressiva

L'aumento dei valori percent e pods del criterio di scalabilità comporterà un criterio di scalabilità più aggressivo. Analogamente, l'aumento dei valori percent e pods in scaleDown comporterà un criterio di riduzione aggressivo. Ad esempio:

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

Nell'esempio riportato sopra, il valore scaleDown.pods.value viene aumentato a 5, il valore scaleUp.percent.value viene aumentato a 30 e il valore scaleUp.pods.value viene aumentato a 5.

Nota: il valore di periodSeconds non deve essere inferiore a 30.

Configurare una scalabilità meno aggressiva

I valori di configurazione hpaBehavior possono anche essere ridotti per implementare criteri di ridimensionamento meno aggressivi. Ad esempio:

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

Nell'esempio riportato sopra, il valore scaleDown.percent.value viene ridotto a 10, il valore scaleDown.pods.value viene ridotto a 1 e il valore scaleUp.stablizationWindowSeconds viene aumentato a 180.

Per saperne di più sulla scalabilità basata su metriche che utilizza il campo hpaBehavior, consulta Criteri di scalabilità.

Disabilita la scalabilità basata su metriche

Sebbene la scalabilità basata sulle metriche sia attiva per impostazione predefinita e non possa essere disattivata completamente, puoi configurare le soglie delle metriche a un livello in cui la scalabilità basata sulle metriche non verrà attivata. La conseguente scalabilità sarebbe lo stesso della scalabilità basata sulla CPU. Ad esempio, puoi utilizzare la seguente configurazione per impedire l'attivazione della scalabilità basata sulle metriche:

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

Risoluzione dei problemi

Questa sezione descrive i metodi di risoluzione dei problemi per gli errori comuni che potresti riscontrare durante la configurazione della scalabilità e della scalabilità automatica.

L'HPA mostra unknown per i valori delle metriche

Se la scalabilità basata sulle metriche non funziona e l'HPA mostra unknown Per i valori delle metriche, utilizza il comando seguente per verificare l'output HPA:

kubectl describe hpa HPA_NAME

Quando esegui il comando, sostituisci HPA_NAME con il nome dell'HPA che vuoi visualizzare.

L'output mostrerà il target e l'utilizzo della CPU del servizio, a indicare che la scalabilità della CPU funzionerà in assenza di scalabilità basata su metriche. Per il comportamento HPA che utilizza più consulta Scalabilità su più metriche.