Questa pagina è stata tradotta dall'API Cloud Translation.

Scalare e scalare automaticamente i servizi di runtime

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

Servizio	Implementata come	Scalabilità
Cassandra	ApigeeDatastore (CRD)	Consulta Scalabilità di Cassandra.
Bilanciatore del carico/in entrata	Deployment	Anthos Service Mesh utilizza la scalabilità automatica orizzontale dei pod (HPA).
Registratore	DaemonSet	I DaemonSet gestiscono le repliche di un pod su tutti i nodi, quindi scalano quando scala i pod stessi.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Per scalare tramite configurazione, aumenta il valore della proprietà di configurazione `replicaCountMin` del deployment per le stanze `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 la proprietà `targetCPUUtilizationPercentage` dell'oggetto Deployment sulla soglia per lo scale up. Se questo valore viene superato, Kubernetes aggiunge i pod fino a un valore pari a `replicaCountMax`. Per maggiori informazioni sull'impostazione delle proprietà di configurazione, consulta Gestire i componenti del piano di runtime.
UDCA Sincronizzatore runtime	ApigeeEnvironment (CRD)	Per la scalabilità tramite configurazione, aumenta il valore della proprietà `replicaCountMin` per le stanza `udca`, `synchronizer` e/o `runtime` nel file degli 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 degli override. Se vuoi personalizzare la scalabilità per ciascun ambiente, consulta Configurazioni avanzate di seguito. Questi deployment utilizzano Horizontal Pod Autoscaler per la scalabilità automatica. Imposta la proprietà `targetCPUUtilizationPercentage` dell'oggetto Deployment sulla soglia per lo scale up. Se questo valore viene superato, Kubernetes aggiunge i pod fino a un valore pari a `replicaCountMax`. Per maggiori 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, dove env1 ha un minReplica di 5 e env2 ha un minReplica di 2.
Impostare opzioni di scalabilità diverse per ogni componente all'interno di un ambiente. Ad esempio, dove 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 per il componente runtime:

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

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

Verifica la modifica:
```
kubectl get hpa -n $NAMESPACE
```

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) 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.

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

Metrica	Misura	Considerazioni
serverNioTaskWaitTime	Tempo di attesa medio (in ms) della coda di elaborazione 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 ms) della coda di elaborazione nelle istanze di runtime affinché le richieste proxy elaborino i criteri.	Questa metrica misura l'impatto della complessità dei criteri collegati al flusso di richieste proxy.

L'esempio seguente tratto 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)

Configura una scalabilità più aggressiva

L'aumento dei valori percent e pods del criterio di scale up si tradurrà in un criterio di scale up più aggressivo. Allo stesso modo, l'aumento dei valori percent e pods in scaleDown comporterà un criterio di scale down 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 precedente, scaleDown.pods.value viene aumentato a 5, scaleUp.percent.value viene aumentato a 30 e scaleUp.pods.value viene aumentato a 5.

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

Configura una scalabilità meno aggressiva

I valori della configurazione hpaBehavior possono anche essere ridotti per implementare criteri di scale up e scale down 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 precedente, scaleDown.percent.value viene ridotto a 10, scaleDown.pods.value viene ridotto a 1 e scaleUp.stablizationWindowSeconds viene aumentato a 180.

Per ulteriori informazioni sulla scalabilità basata sulle metriche con il campo hpaBehavior, consulta Criteri di scalabilità.

Disabilita la scalabilità basata su metriche

La scalabilità basata sulle metriche è abilitata per impostazione predefinita e non può essere completamente disabilitata, ma puoi configurare le soglie delle metriche a un livello che non verrà attivato. Il conseguente comportamento di scalabilità sarà 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 seguente comando per controllare 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 della CPU e l'utilizzo del servizio, a indicare che la scalabilità della CPU funzionerà in assenza di una scalabilità basata sulle metriche. Per il comportamento HPA che utilizza più parametri, consulta Scalabilità su più metriche.