Rolling Application Upgrades with Payara Micro and Kubernetes

Introduction

Application updates are required as part of the normal maintenance process of your application lifecycle management. These updates should be as smooth as possible, and especially for a micro-services environment, performed with zero-downtime of your Payara Micro application. The Kubernetes Rolling Upgrades feature can help you with this.

With the help of the Rolling Upgrades feature, you can deploy a new version of the application to Kubernetes while keeping the application active throughout the upgrade.

What is the Rolling Upgrades Feature?

Let us first describe the process how the Rolling Upgrades work with the help of the following graphic:

(For more information and illustrations, please see: https://blog.container-solutions.com/kubernetes-deployment-strategies)

In step 1, we see the situation just before we start with the update of our application. We have multiple instances of our service running. In a micro-service environment, it's common to have multiple instances running and in the case of the Rolling Upgrade feature, we need at least two to perform the upgrade seamlessly. All our instances are behind a Load Balancer so that the clients use a single endpoint.

In step 2, we deploy an instance of our second version of the application and add it to the Load Balancer. From this point on, some requests to our service will be handled by the second version. This means the second version of our application needs to be fully compatible with the first version but that is a consequence of using micro-services which needs to be deployable independently.

In step 3 and step 4, each time we replace an instance of the first version. Gradually, more responses will be generated by the second version of the application.

In step 5, the last step, the last instance of the first version of our application is removed and thus we have completely and gradually updated our application but we made sure that our application was available all the time.

How to Update Your Application Running with Payara Micro

The above scenario looks like a lot of work, but it is fully automated within Kubernetes.

Let us go step by step through the process of updating your application running with Payara Micro. I assume you are familiar with the concepts and commands of kubectl. If not, have a look at the Kubernetes website or our guide "How to use Payara Micro with Kubernetes".

Our first version of the application is built and running on Kubernetes as a Docker image with the tag name rolling:v1.

The YAML definition for the Deployment and service description is as follows:

rolling.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payara-micro
spec:
  selector:
    matchLabels:
      name: payara
  replicas: 2
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: payara
    spec:
      containers:
        - name: payara-micro
          image: rolling:v1
          imagePullPolicy: IfNotPresent
          ports:
            - name: payara-micro
              containerPort: 8080
          resources:
            limits:
              cpu: "1"
              memory: 512Mi
            requests:
              cpu: "1"
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 2
            failureThreshold: 20
---
apiVersion: v1
kind: Service
metadata:
  name: payara-micro
  labels:
    name: payara
spec:
  type: NodePort
  ports:
    - port: 8080
      #nodePort: 8888
  selector:
    name: payara

The important part here is the definition of the readiness probe. That part indicates when the container running our application is considered ready and can be added to the Load Balancer. Without it, the Container will be added too soon which will result in an error as the application is not ready to handle user requests.

Within Payara Micro, the health endpoint is specifically designed for the readiness probe of Kubernetes. It indicates an UP status when Payara Micro and the application are completely ready. Custom checks can be added by the developer if needed. For more information on this, have a look at the blog post "Scaling Payara Micro Applications with Kubernetes".

In preparation of the deployment of the second version of the application, we need to build it and create a Docker image for it. In our example, we can call it rolling:v2.

DockerFile

FROM payara/micro:5.192
COPY target/myApp.war $DEPLOY_DIR/myApp.war

As mentioned, the Rolling Upgrade is fully automated within Kubernetes and can be initiated by the following command:

kubectl set image deployment/payara-micro payara-micro=rolling:v2

This sets the Docker Image which is linked to the container named payara-micro in the Kubernetes deployment. Each change to the Deployment will follow the strategy we have defined in the yaml, a rolling update in our example.

Kubernetes will perform the required steps to achieve the flow described in the previous chapter. You can follow the status of this process with the kubectl rollout command.

kubectl rollout status deployment/payara-micro

It will tell you how many 'replicas' are already replaced or that the rollout is finished.

If you have designed and configured the health check correctly, no request to your service will result in an error and will be handled by one of the versions of the application. You should test this using, for example, the fortio tool.

Another alternative is that you update the contents of the rolling.yaml file to reflect the new situation and change the Docker Image name there. When applying this file, Kubernetes detects that the deployment configuration is changed and performs the rolling upgrade.

kubectl apply -f rolling.yaml

Using this scenario, the contents of the yaml configuration file always matches with the situation on the cluster.

Going Back to the Previous Version of Your Application

There are always situations that you need to go back to your previous version of the application for some reason. No matter how well you have tested the new version, you can always miss some cases which may fail now.

Going back to the previous version is also very easy as Kubernetes keeps a history of your deployments. With a single command you can undo your changes:

kubectl rollout undo deployment/payara-micro

Performing Rolling Upgrades

When your deployment is properly configured for Kubernetes, you can update an application without downtime. The /health endpoint of Payara Micro will make sure that the new version of the application is only considered by the Load Balancer after it received the confirmation that everything is up and running. When your service is backed by multiple instances, a gradual replacement of the versions makes sure that the clients never see any error.

And you can go even back to your previous version, also with a single Kubernetes command.