dockerkubernetesopenshiftblue-green-deploymentcanary-deployment

Openshift zero downtime deployment react + rest api

We have a Web interface built using React (and nginx) and a Rest API (with json schema validation). They are in different repositories. Our cluster is a private openshift (3.11)

We would like to achieve a zero downtime deployment. Let's assume that:

  1. we have 10 pods for the Web and 20 pods for the Rest API.
  2. we want to upgrade WEB and API from 1.0.0 to 2.0.0
  3. the new version of WEB supports only the new version of the API
  4. each repo (WEB and API) has its own helm chart (if needed and it is recommended, we could create an additional repository containing a single helm chart that deploys both web and api)

Which deployment strategy should we use? (blue/green, canary, a/b ?)

How can we configure the new WEB pods in order to hit the only new service of the API:

How can we perform the upgrade with zero downtime?

The very important thing is that, during the upgrade, the new version of the WEB should hit only the new version of the API, while the already deployed pods (1.0.0) should continue to hit the old version of the API.

Solution

  • I have done the same, and within Kubernetes, you can achieve this. Let's follow the below approach.

    enter image description here

    If you look above, I am doing my deployment via helm, and all the K8s objects (Pods, SVC, ingress) are unique based on release names. By this, I can access my specific front-end release by adding a context after my domain like https://app.com/1.0 or https://app.com/2.0.

    The version which I want to expose to the internet, I am controlling it via Separate Ingress object (You can call super-ingress), which is independent of your releases and decide which version you want to keep live. By this, you can deploy N number of releases in production without any conflict, and by super-ingress, you can choose, which svc you want to point to the public.