Notes on Pod upgrades

Regardless of cloud service provider, you might have noticed that both examples provided use a Kubernetes Deployment resource. This kind of resource allows you to preemptively manage the lifecycle of your Pod with regard to the following:

  1. What should happen when the Pod fails?

  2. What should happen when the Pod exits successfully?

  3. How many Pod replicas should there be?

  4. What liveness conditions should be guaranteed when upgrading to a new version?

Anjuna recommends always wrapping your Anjuna Confidential Pod (Confidential Pod) manifest within higher-level manifest kinds, also called workload resources, such as Deployments and StatefulSets.

The Anjuna Kubernetes Toolset ensures that signals are propagated correctly to the Kubernetes control plane, so that workload resources behave as expected.

Simple Pod manifest

You might encounter situations where you want to use a simple Pod manifest. In this case, handle upgrades more carefully; some changes might not trigger a Pod restart, so they never take effect.

For instance, changing only the annotation cvm.anjuna.io/image (or any other annotation) does not result in a Pod restart.

When this happens, delete and recreate the Confidential Pod so that the change takes effect.

Workload resource manifest upgrades

Workload resource manifests control the lifecycle of the Pod as a whole. For example, during upgrades, a Deployment launches a new Pod by default and terminates the old Pod only once the new one is ready.

This conforms to Anjuna’s Confidential Pod immutability feature: the Pods do not change, but upgrades are still possible.

Deployments consider changes to the cvm.anjuna.io/image annotation as a trigger event for upgrades, but only if the annotation is located as part of the Pod spec. Specifically, that means the .spec.template.spec.metadata.annotations field.

As an example, assume the Nginx Pod is defined within a Deployment manifest and needs to have its enclave configuration updated with a new secret. In this case, to upgrade the Pod to the new version, the following simpler procedure is sufficient:

  1. Change the cvm.anjuna.io/image annotation to the new image version.

  2. Reapply the Deployment manifest with kubectl apply -f <manifest>.

The change to the annotation alone triggers an upgrade. You should see output similar to the following:

$ kubectl apply -f nginx.yaml
deployment.apps/nginx configured

$ kubectl get pods
NAME                  READY STATUS            RESTARTS AGE
nginx-9db88ffc8-rzj92 0/1   ContainerCreating 0        10s
nginx-9db88ffc8-dfzvs 1/1   Running           0        3m1s

# after a while
$ kubectl get pods
NAME                  READY STATUS      RESTARTS AGE
nginx-9db88ffc8-rzj92 1/1   Running     0        10s
nginx-9db88ffc8-dfzvs 0/1   Terminating 0        4m1s