Questa pagina è stata tradotta dall'API Cloud Translation.

Scalabilità e scalabilità automatica dei servizi di runtime

Puoi scalare la maggior parte dei servizi in esecuzione in Kubernetes dalla 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	Implementato come	Scalabilità
Cassandra	ApigeeDatastore (CRD)	Consulta Scalabilità di Cassandra.
Ingress/LoadBalancer	Deployment	Anthos Service Mesh utilizza la scalabilità automatica orizzontale dei pod (HPA).
Logger	DaemonSet	I DaemonSet gestiscono le repliche di un pod su tutti i nodi, quindi vengono scalati quando vengono scalati i pod stessi.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Per scalare tramite la configurazione, aumenta il valore della proprietà di configurazione `replicaCountMin` del deployment per le sezioni `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 un Horizontal Pod Autoscaler per la scalabilità automatica. Imposta la proprietà `targetCPUUtilizationPercentage` dell'oggetto Deployment sulla soglia per lo scale up; quando questo valore viene superato, Kubernetes aggiunge pod fino al valore di `replicaCountMax`. Per ulteriori informazioni sull'impostazione delle proprietà di configurazione, vedi Gestire i componenti del piano di runtime.
Runtime Synchronizer UDCA	ApigeeEnvironment (CRD)	Per scalare tramite la configurazione, aumenta il valore della proprietà `replicaCountMin` per le sezioni `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 di override. Se vuoi personalizzare lo scaling per ogni ambiente, consulta le 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 lo scale up. Quando questo valore viene superato, Kubernetes aggiunge pod fino al valore di `replicaCountMax`. Per ulteriori informazioni sull'impostazione delle proprietà di configurazione, vedi 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 diverse opzioni di scalabilità per ogni ambiente. Ad esempio, dove env1 ha un minReplica di 5 ed env2 ha un minReplica di 2.
Impostazione di diverse opzioni di scalabilità per ogni componente all'interno di un ambiente. Ad esempio, dove il componente udca ha un maxReplica di 5 e il componente synchronizer ha un maxReplica di 2.

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

Crea 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 questo esempio presuppone che kubectl si trovi 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 della CPU e delle applicazioni per scalare i pod apigee-runtime. L'API Horizontal Pod Autoscaler (HPA) di Kubernetes utilizza il campo hpaBehavior per configurare i comportamenti di scalabilità orizzontale e riduzione del servizio di destinazione. Lo scaling basato sulle metriche non è disponibile per altri componenti in un deployment ibrido.

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

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

L'esempio seguente della sezione runtime in overrides.yaml mostra i parametri standard (e gli intervalli consentiti) per lo scaling 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 della policy di scalabilità verticale comporterà una policy di scalabilità verticale più aggressiva. Allo stesso modo, l'aumento dei valori percent e pods in scaleDown comporterà una policy di riduzione aggressiva. 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, il valore scaleDown.pods.value è aumentato a 5, il valore scaleUp.percent.value è aumentato a 30 e il valore scaleUp.pods.value è aumentato a 5.

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

Configurare una scalabilità meno aggressiva

I valori di configurazione di hpaBehavior possono anche essere ridotti per implementare criteri di scalabilità verticale e orizzontale 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 utilizzando il campo hpaBehavior, consulta Policy di scalabilità.

Disabilita lo scaling basato sulle metriche

Anche se la scalabilità basata sulle metriche è attivata per impostazione predefinita e non può essere disattivata completamente, puoi configurare le soglie delle metriche a un livello tale da non attivare la scalabilità basata sulle metriche. Il comportamento di scalabilità risultante 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 relativi agli errori comuni che potresti riscontrare durante la configurazione dello scaling e della scalabilità automatica.

HPA mostra `unknown` per i valori delle metriche

Se lo scaling basato sulle metriche non funziona e l'HPA mostra unknown per i valori delle metriche, utilizza il seguente comando per controllare l'output dell'HPA:

kubectl describe hpa HPA_NAME

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

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