Puoi scalare la maggior parte dei servizi in esecuzione in Kubernetes dalla riga di comando o in una sostituzione di 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 si adattano quando esegui lo scale dei pod stessi. |
MART Apigee Connect Watcher |
ApigeeOrganization (CRD) | Per eseguire il ridimensionamento tramite 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, consulta Gestire i componenti del piano di runtime. |
Runtime Synchronizer UDCA |
ApigeeEnvironment (CRD) | Per eseguire il ridimensionamento tramite configurazione, aumenta il valore della proprietà
replicaCountMin per le stanza udca , synchronizer e/o runtime nel file delle sostituzioni. 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 delle sostituzioni. Se vuoi personalizzare la scalabilità per ogni ambiente, consulta 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, consulta Gestire i componenti del piano di runtime. |
Configurazioni avanzate
In alcuni scenari, potrebbe essere necessario utilizzare opzioni di ridimensionamento avanzate. Ecco alcuni scenari di esempio:
- Impostazione di opzioni di ridimensionamento diverse per ogni ambiente. Ad esempio, env1 ha un valore
minReplica
pari a 5 e env2 ha un valoreminReplica
pari a 2. - Impostazione di opzioni di scalabilità diverse per ciascun componente all'interno di un ambiente. Ad esempio,
se 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 modificare la proprietà maxReplicas
del 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 questo esempio 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
sostituire le impostazioni predefinite specificando la scalabilità specifica per l'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 su metriche, il runtime può utilizzare le metriche della CPU e dell'applicazione per scalare i pod apigee-runtime
.
L'API Horizontal Pod Autoscaler (HPA) di Kubernetes utilizza il campo hpaBehavior
per configurare i comportamenti di scalabilità verso l'alto e verso il basso del servizio target.
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) 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 del proxy. |
serverMainTaskWaitTime | Tempo di attesa medio (in picosecondi) della coda di elaborazione nelle istanze di runtime per le richieste proxy per l'elaborazione delle norme. | Questa metrica misura l'impatto della complessità dei criteri associati al flusso di richieste proxy. |
L'esempio seguente della stanza runtime
in overrides.yaml
illustra i parametri standard (e gli intervalli consentiti) per il ridimensionamento 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 scalabilità comporterà un criterio di scalabilità più aggressivo. Analogamente, l'aumento dei valori percent
e pods
in scaleDown
comporterà un criterio di riduzione 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 riportato sopra, 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 hpaBehavior
possono anche essere ridotti per implementare criteri di scalabilità 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 riportato sopra, il valore scaleDown.percent.value
viene ridotto a 10, il valore scaleDown.pods.value
viene ridotto a 1 e il valore scaleUp.stablizationWindowSeconds
viene aumentato a 180.
Per saperne di più sulla scalabilità basata su metriche che utilizza il campo hpaBehavior
, consulta
Criteri di scalabilità.
Disattivare la scalabilità basata sulle metriche
Sebbene la scalabilità basata sulle metriche sia attiva per impostazione predefinita e non possa essere disattivata completamente, 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à lo stesso 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 di risoluzione dei problemi relativi agli errori comuni che potresti riscontrare durante la configurazione del ridimensionamento e del ridimensionamento automatico.
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 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 e l'utilizzo della CPU del servizio, a indicare che la scalabilità della CPU funzionerà in assenza di scalabilità basata su metriche. Per il comportamento dell'HPA che utilizza più parametri, consulta Eseguire il scaling in base a più metriche.