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:
- we have 10 pods for the Web and 20 pods for the Rest API.
- we want to upgrade WEB and API from 1.0.0 to 2.0.0
- the new version of WEB supports only the new version of the API
- 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:
- WEB 1.0.0 --> API 1.0.0
- WEB 2.0.0 --> API 2.0.0
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.
Similar Questions
2 Answers
Given the constraints you're telling us, your only choice is to follow a blue/green approach.
You have a pack of stuff which work together, let's say A. And another pack which work together, B. AB is something not possible, so this rule out canary or a/b testing.
You need to deploy B (green), and when everything is correct, switch the domain from A to B.
In kubernetes' words, you will have two different Deployments and Services, like if both are standalone applications. When you are confident the v2 is working properly, you need to change the DNS record pointing to the LoadBalancer of the v1's Service, to point to the v2's Service
I have done the same, and within Kubernetes, you can achieve this. Let's follow the below approach.
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.