Rolling updates

Apigee hybrid supports two kinds of updates. The first is an in-place update where you apply a configuration change and hybrid begins a Kubernetes rolling update. In Kubernetes, rolling updates allow Deployment updates to take place with zero downtime by incrementally updating Pod instances with new ones.

Apigee hybrid also supports a canary or AB-style update. In an AB update, the new revision is deployed; however, at first a small percentage of traffic is directed to it. Over time, this percentage increases until all of the traffic goes to the revision.

In-place updates

To trigger an in-place update, simply modify the desired settings in the overrides file and apply it to the cluster. For example, suppose you want to change the current runtime memory from 1Gi to 5Gi:

Here is the initial configuration:

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

In the new configuration, memory is changed to 5Gi:

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

When you apply the change, the updated pods start up and replace the existing pods. Because of the Kubernetes rolling update feature, clients do not experience any downtime.

How to perform an AB update

To perform an AB update, use the revision tag in your overrides file. For example, suppose you want to change the current runtime memory from 1Gi to 5Gi:

In the current configuration, revision is set to blue:

...
revision: blue
...
runtime:
  replicaCountMin: 2
  replicaCountMax: 20
  resources:
    requests:
      cpu: 1000m
      memory: 1Gi
...

In the new configuration, if you change revision to green, you signal that you want to perform a rolling update when the change is applied. The value you set revision to does not matter; you can use any string you wish, as long as you change it from the previous value to something else.

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

When you apply the change, a small percentage of traffic to the new revision. Over time, more traffic goes to the new revision until it reaches 100%. At that time, the old revision is deleted.

To trigger an AB rollout, either add the revision tag if it is not present, or change the value of the revision tag if it is already present. You are not required to make any other changes to the overrides file to trigger an AB rollout.

The following table the schedule of an AB rollout:

Stage Traffic percentage Wait time
1 5% 60 seconds
2 20% 10 seconds
3 100% 10 seconds

In the current release, the percentages and wait times are not configurable.