Puoi scalare la maggior parte dei servizi in esecuzione in Kubernetes
alla riga di comando o in un override della configurazione. Puoi impostare la scalabilità
per i servizi di runtime ibridi Apigee in
File overrides.yaml
.
Servizio | Implementata come | Scalabilità |
---|---|---|
Cassandra | ApigeeDatastore (CRD) | Consulta Scalabilità di Cassandra. |
Bilanciatore del carico/in entrata | Deployment |
Gestisci la scalabilità con
|
Registratore | DaemonSet | I DaemonSet gestiscono le repliche di un pod su tutti i nodi, quindi scalano quando scali i pod stessi. |
MART Apigee Connect Visione |
ApigeeOrganization (CRD) | Per scalare tramite configurazione, aumenta il valore dell'attributo
Proprietà di configurazione 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 Per ulteriori informazioni sull'impostazione delle proprietà di configurazione, consulta Gestire i componenti del piano di runtime. |
Runtime Sincronizzatore UDCA |
ApigeeEnvironment (CRD) | Per scalare tramite configurazione, aumenta il valore dell'attributo
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 degli override. Se vuoi personalizzare la scalabilità per ciascun ambiente, consulta Configurazioni avanzate di seguito. Questi deployment usano Horizontal Pod Autoscaler per
e la scalabilità automatica. Imposta l'oggetto Deployment
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, dove env1 ha
a
minReplica
di 5 e env2 ha unminReplica
di 2. - Impostare opzioni di scalabilità diverse per ogni componente all'interno di un ambiente. Ad esempio:
in cui il componente
udca
ha un valoremaxReplica
pari a 5 e Il componentesynchronizer
ha un valoremaxReplica
pari a 2.
L'esempio seguente mostra come utilizzare il comando kubernetes patch
per apportare modifiche
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 inPATH
: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 sull'ambiente
Per impostazione predefinita, la scalabilità è descritta a livello di organizzazione. Puoi
esegui l'override delle impostazioni predefinite specificando una scalabilità specifica dell'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.
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 collegati 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)
Configura una scalabilità più aggressiva
L'aumento dei valori percent
e pods
del criterio di scale up si tradurrà in una strategia
criteri di scale up. Allo stesso modo, l'aumento dei valori percent
e pods
in scaleDown
si tradurrà in una politica di scale down 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
viene aumentato a 5, ovvero scaleUp.percent.value
viene aumentato a 30 e scaleUp.pods.value
viene aumentato a 5.
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, il valore scaleDown.percent.value
viene ridotto a 10, ovvero la metrica 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 disattivata, configurare le soglie delle metriche a un livello che non attiva la scalabilità basata sulle metriche. 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, usa il comando seguente 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ù consulta Scalabilità su più metriche.