aggiornamenti in sequenza.

Apigee hybrid supporta due tipi di aggiornamenti. Il primo è un aggiornamento in loco in cui si applica una modifica della configurazione e l'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à aggiornando in modo incrementale le istanze dei pod con nuove istanze.

Apigee hybrid supporta anche un aggiornamento in stile canary o AB. In un aggiornamento AB viene eseguito il deployment della nuova revisione, ma all'inizio viene indirizzata una piccola percentuale di traffico. Nel tempo, questa percentuale aumenta finché tutto il traffico non viene indirizzato alla revisione.

Aggiornamenti in loco

Per attivare un aggiornamento in loco, è sufficiente modificare le impostazioni desiderate nel file di override e applicarle al cluster. Ad esempio, supponi di voler modificare l'attuale memoria 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 è impostata su 5Gi: 

...
runtime:
  replicaCountMin: 2
  replicaCountMax: 20
  resources:
    requests:
      cpu: 1000m
      memory: 5Gi
...

Quando applichi la modifica, i pod aggiornati vengono avviati e sostituiscono i pod esistenti. A causa della funzionalità di aggiornamento in sequenza di Kubernetes, i client non riscontrano tempi di inattività.

Come eseguire un aggiornamento AB

Per eseguire un aggiornamento AB, utilizza il tag revision nel file di override. Ad esempio, supponi di voler 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, indichi di voler eseguire un aggiornamento in sequenza quando viene applicata la modifica. Il valore impostato su revision non è importante; puoi utilizzare qualsiasi stringa tu voglia, purché il valore precedente venga cambiato con qualcos'altro. 

...
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 tempo, più traffico viene indirizzato alla nuova revisione fino a raggiungere il 100%. A quel punto, la revisione precedente viene eliminata.

Per attivare un'implementazione AB, aggiungi il tag revision, se non è presente, o modifica il valore del tag revision se è già presente. Non devi apportare altre modifiche al file di override per attivare un'implementazione AB.

Nella tabella seguente la pianificazione di un'implementazione AB:

Fase Percentuale di traffico Tempo di attesa
1 5% 60 secondi
2 20% 10 secondi
3 100% 10 secondi

Nella release corrente, le percentuali e i tempi di attesa non sono configurabili.