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 | Cloud 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 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à 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à 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 unminReplica
di 2. - Impostazione di diverse opzioni di scalabilità per ogni componente all'interno di un ambiente. Ad esempio,
dove il componente
udca
ha unmaxReplica
di 5 e il componentesynchronizer
ha unmaxReplica
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_NAME=my-environment-name
export ENV_RELEASE_NAME=$ENV_NAME # the Helm release name for the environment
export APIGEE_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 inPATH
:kubectl patch apigeeenvironment -n $APIGEE_NAMESPACE \ $(kubectl get apigeeenvironments -n $APIGEE_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 $APIGEE_NAMESPACE
Scalabilità basata sull'ambiente
Per impostazione predefinita, il dimensionamento è descritto a livello di organizzazione. Puoi
ignorare le impostazioni predefinite specificando lo scaling specifico per l'ambiente
nel file overrides.yaml
come mostrato nell'esempio seguente:
envs: # Apigee environment name - name: ENV_NAME> 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 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 |
---|---|---|
serverMainTaskWaitTime | Tempo di attesa medio (in ms) della coda di elaborazione nelle istanze di runtime per le richieste proxy per l'elaborazione dei criteri. | Questa metrica misura l'impatto della complessità nei criteri allegati al flusso di richieste proxy. |
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 delle dimensioni del payload delle richieste e delle risposte 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:
runtime: # the following parameters configure metrics-based scaling hpaMetrics: serverMainTaskWaitTime: 400M # (range: 300M to 450M) serverNioTaskWaitTime: 400M # (range: 300M to 450M) targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 # (range: 30 - 180) value: 20 # (range: 5 - 50) pods: periodSeconds: 60 # (range: 30 - 180) value: 2 # (range: 1 - 15) selectPolicy: Min stabilizationWindowSeconds: 120 # (range: 60 - 300) scaleUp: percent: periodSeconds: 60 # (range: 30 - 120) value: 20 # (range: 5 - 100) pods: periodSeconds: 60 # (range: 30 - 120) value: 4 # (range: 2 - 15) selectPolicy: Max stabilizationWindowSeconds: 30 # (range: 30 - 120)
Applica queste impostazioni aggiornando il grafico apigee-runtime
per ogni ambiente. Ad esempio:
helm upgrade $ENV_RELEASE_NAME apigee-runtime/ \ --namespace APIGEE_NAMESPACE \ --atomic \ --set env=$ENV_NAME \ -f overrides.yaml
Attivare o disattivare la scalabilità basata sulle metriche
La scalabilità basata sulle metriche è abilitata per impostazione predefinita. Puoi attivare o disattivare lo scaling basato sulle metriche impostando la proprietà customAutoscaling.enabled
su true
o false
. Applica le modifiche alla proprietà customAutoscaling.enabled
aggiornando il grafico apigee-telemetry
. Ad esempio:
helm upgrade telemetry apigee-telemetry/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f overrides.yaml
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:
runtime: # ... 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
viene aumentato a 5, il valore scaleUp.percent.value
viene aumentato a 30 e il valore scaleUp.pods.value
viene aumentato a 5.
Configurare una scalabilità meno aggressiva
I valori di configurazione di hpaBehavior
possono anche essere ridotti per implementare criteri di scalabilità orizzontale e verticale meno aggressivi. Ad esempio:
runtime: # ... 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, il valore di scaleDown.percent.value
è diminuito a 10, quello di scaleDown.pods.value
è diminuito a 1 e quello di scaleUp.stablizationWindowSeconds
è aumentato a 180.
Per ulteriori informazioni sulla scalabilità basata sulle metriche utilizzando il campo hpaBehavior
, consulta
Norme di scalabilità.
Risoluzione dei problemi
Questa sezione descrive i metodi di risoluzione dei problemi relativi agli errori comuni che potresti riscontrare durante la configurazione della scalabilità 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 la sezione Scalabilità in base a più metriche.