Apigee ibrido supporta due tipi di aggiornamenti. Il primo è un aggiornamento in loco in cui applichi una modifica alla configurazione e il modello ibrido avvia un aggiornamento in sequenza di Kubernetes. In Kubernetes, gli aggiornamenti in sequenza consentono di eseguire gli aggiornamenti del deployment senza tempi di inattività, grazie all'aggiornamento incrementale delle istanze dei pod con nuove istanze.
Apigee ibrido supporta anche un aggiornamento in stile canary o AB. In un aggiornamento dell'AB, viene eseguito il deployment della nuova revisione, ma da lì viene inizialmente indirizzata una piccola percentuale di traffico. Nel tempo, questa percentuale aumenta finché tutto il traffico non passa alla revisione.
Aggiornamenti in loco
Per attivare un aggiornamento in loco, basta modificare le impostazioni desiderate nel file delle sostituzioni e applicarle al cluster. Ad esempio, supponiamo che tu voglia modificare la memoria attuale di runtime da 1Gi a 5Gi:
Ecco la configurazione iniziale:
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 1Gi
...
Nella nuova configurazione, la memoria viene modificata in 5Gi:
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 5Gi
...
Quando applichi la modifica, i pod aggiornati si avviano e sostituiscono quelli esistenti. A causa della funzionalità di aggiornamento in sequenza di Kubernetes, i client non registrano tempi di inattività.
Come eseguire un aggiornamento dell'AB
Per eseguire un aggiornamento dell'AB, utilizza il tag revision nel file delle sostituzioni.
Ad esempio, supponiamo che tu voglia modificare l'attuale memoria di runtime da 1Gi a 5Gi:
Nella configurazione attuale, revision è impostato su blue:
...
revision: blue
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 1Gi
...
Nella nuova configurazione, se cambi revision in green, segnali
che vuoi eseguire un aggiornamento in sequenza quando
viene applicata la modifica. Il valore impostato per revision non è importante. Puoi utilizzare qualsiasi stringa, a condizione che venga modificata in base al valore precedente.
...
revision: green
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 5Gi
...
Quando applichi la modifica, una piccola percentuale di traffico verso la nuova revisione. Nel corso del tempo, più traffico passa alla nuova revisione fino a raggiungere il 100%. A quel punto, la versione precedente viene eliminata.
Per attivare un'implementazione AB, aggiungi il tag revision se non è presente
oppure modifica il valore del tag revision se è già presente. Non devi apportare altre modifiche al file di override per attivare un'implementazione di AB.
La tabella seguente mostra la pianificazione di un'implementazione di AB:
| Fase | Percentuale di traffico | Tempo di attesa |
|---|---|---|
| 1 | 5% | 60 secondi |
| 2 | 20% | 10 secondi |
| 3 | 100% | 10 secondi |
Nella versione corrente, le percentuali e i tempi di attesa non sono configurabili.