- v1.12 (più recente)
- Versione 1.11
- Versione 1.10
- Elenco delle versioni supportate
- Versione 1.9
- Versione 1.8
- Versione 1.7
- Versione 1.6
- Versione 1.5
- Versione 1.4
- Versione 1.3
- Versione 1.2
- Versione 1.1
Versioni supportate:
Versioni non supportate:
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) | Vedi Scalabilità di Cassandra. |
Bilanciatore del carico in entrata | 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, in modo da scalare quando scala 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 maggiori informazioni sull'impostazione delle proprietà di configurazione, consulta Gestire i componenti del piano di runtime. |
Runtime Sincronizzatore UDCA |
ApigeeEnvironment (CRD) | Per scalare tramite la configurazione, aumenta il valore della
proprietà replicaCountMin per le stanze 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 la scalabilità per ogni ambiente, consulta la sezione Configurazioni avanzate di seguito. Questi deployment utilizzano un Horizontal Pod Autoscaler per la scalabilità automatica. Imposta la proprietà 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
pari a 5 ed env2 ha unminReplica
pari a 2. - Impostazione di opzioni di scalabilità diverse per ogni componente all'interno di un ambiente. Ad esempio,
dove il componente
udca
ha un valore dimaxReplica
pari a 5 e il componentesynchronizer
ha un valore dimaxReplica
pari a 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
sia nella tuaPATH
: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 su 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 scale up e scale down del servizio di destinazione.
La scalabilità basata su metriche non è disponibile per altri componenti di 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 al livello http. | Questa metrica misura l'impatto del numero e delle dimensioni del payload delle richieste e delle risposte proxy. |
serverMainTaskWaitTime | Tempo medio di attesa (in ms) della coda di elaborazione nelle istanze di runtime per le richieste proxy ai criteri di elaborazione. | Questa metrica misura l'impatto della complessità nei criteri associati al flusso di richieste proxy. |
L'esempio seguente dalla stanza runtime
in 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 scale up comporterà un criterio di scale up più aggressivo. Analogamente, l'aumento dei valori percent
e pods
in scaleDown
determina 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.
Configura una scalabilità meno aggressiva
È inoltre possibile ridurre i valori di configurazione di hpaBehavior
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
è stato ridotto a 10, scaleDown.pods.value
è stato ridotto a 1 e scaleUp.stablizationWindowSeconds
è stato aumentato a 180.
Per saperne di più sulla scalabilità basata su metriche utilizzando il campo hpaBehavior
, consulta
Criteri di scalabilità.
Disabilita la scalabilità basata sulle metriche
Sebbene la scalabilità basata su metriche sia abilitata per impostazione predefinita e non può essere completamente disabilitata, puoi configurare le soglie delle metriche a un livello in cui la scalabilità basata sulle metriche non verrà attivata. Il comportamento di scalabilità risultante sarà uguale a quello della scalabilità basata sulla CPU. Ad esempio, puoi utilizzare la seguente configurazione per impedire l'attivazione della scalabilità basata su 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 per la risoluzione dei problemi per gli errori comuni che potresti riscontrare durante la configurazione della scalabilità e della scalabilità automatica.
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 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à il target della CPU e l'utilizzo del servizio, a indicare che la scalabilità della CPU funzionerà in assenza di scalabilità basata su metriche. Per il comportamento HPA utilizzando più parametri, consulta Scalabilità su più metriche.