Apigee hybrid accepte deux types de mises à jour. La première est une mise à jour sur place au cours de laquelle vous appliquez une modification de configuration et commencez une mise à jour progressive de Kubernetes à l'aide d'Apigee hybride. Dans Kubernetes, les mises à jour progressives permettent de mettre à jour les déploiements sans interruption de service grâce à une mise à jour progressive des instances de pod avec de nouvelles instances.
Apigee hybrid est également compatible avec une mise à jour de type Canary ou AB. La nouvelle révision est déployée dans le cadre d'une mise à jour AB. Toutefois, dans un premier temps, un faible pourcentage du trafic lui est destiné. Au fil du temps, ce pourcentage augmente jusqu'à ce que l'ensemble du trafic soit dirigé vers la révision.
Mises à jour sur place
Pour déclencher une mise à jour sur place, il vous suffit de modifier les paramètres de votre choix dans le fichier de remplacement et de l'appliquer au cluster. Par exemple, supposons que vous souhaitiez que la mémoire runtime actuelle de 1 Gi passe à 5 Gi :
Voici la configuration initiale :
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 1Gi
...Dans la nouvelle configuration, la mémoire passe à 5 Gi :
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 5Gi
...Lorsque vous appliquez la modification, les pods mis à jour démarrent et remplacent les pods existants. En raison de la fonctionnalité de mise à jour progressive de Kubernetes, les clients ne remarquent aucun temps d'arrêt.
Comment effectuer une mise à jour AB
Pour effectuer une mise à jour AB, utilisez le tag revision dans votre fichier de remplacement.
Par exemple, supposons que vous souhaitiez que la mémoire runtime actuelle de 1 Gi passe à 5 Gi :
Dans la configuration actuelle, revision est défini sur blue :
...
revision: blue
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 1Gi
...
Dans la nouvelle configuration, si vous remplacez revision par green, vous indiquez que vous souhaitez effectuer une mise à jour progressive lorsque la modification est appliquée. La valeur que vous définissez pour revision n'a pas d'importance. Vous pouvez utiliser n'importe quelle chaîne, à condition de remplacer la valeur précédente par une autre valeur.
...
revision: green
...
runtime:
replicaCountMin: 2
replicaCountMax: 20
resources:
requests:
cpu: 1000m
memory: 5Gi
...Lorsque vous appliquez la modification, un faible pourcentage du trafic est dirigé vers la nouvelle révision. Le trafic dirigé vers la nouvelle révision augmente au fil du temps, jusqu'à atteindre 100 %. L'ancienne révision est alors supprimée.
Pour déclencher un déploiement AB, ajoutez le tag revision s'il n'est pas présent ou modifiez la valeur du tag revision si elle est déjà présente. Vous n'avez pas besoin d'apporter d'autres modifications au fichier de remplacement pour déclencher un déploiement AB.
Le tableau suivant présente le calendrier d'un déploiement AB :
| Étape | Pourcentage du trafic | Temps d'attente |
|---|---|---|
| 1 | 5 % | 60 secondes |
| 2 | 20 % | 10 secondes |
| 3 | 100 % | 10 secondes |
Dans la version actuelle, les pourcentages et les temps d'attente ne sont pas configurables.