1

I have a single page app. It is served by (and talks to) an API server running on a Kubernetes deployment with 2 replicas. I have added a X-API-Version header that my API sends on every request, and my client can compare with, to figure out if it needs to inform the user their client code is outdated.

One issue I am facing however, is when I deploy, I want to ensure only ever 1 version of the API is running. I do not want a situation where a client can be refreshed many times in a loop, as it receives different API versions.

I basically want it to go from 2 replicas running version A, to 2 replicas running Version A, 2 running version B. Then switch the traffic to version B once health checks pass, then tear down the old version A's.

Does Kubernetes support this using the RollingDeploy strategy?

Dominic Bou-Samra
  • 14,799
  • 26
  • 100
  • 156

3 Answers3

3

For blue-green deployment in Kubernetes, I will recommend to use some third party solution like Argo Rollouts, NGINX, Istio etc.. They will let you split the traffic between the versions of your application.

However, Kubernentes is introducing Gateway API which has built-in support for traffic splitting.

Emruz Hossain
  • 4,764
  • 18
  • 26
1

What you are asking isn't a blue/green deploy really. If you require two pods, or more, to run during the upgrade, for performance issues, you will get an overlap where some pods of version A responds and some from version B.

You can fine tune it a little, for instance you can configure it to start all of the new pods at once and for each one that turn from running->ready one of the old will be removed. If your pods starts fast, or at least equally fast, the overlap will be really short.

Or, if you can accept a temporary downtime there is a deployment strategy that completely decommission all old pods before rolling out the new ones. Depending on how fast your service starts this could give a short or long downtime.

Of, if you don't mind just a little bit extra work, you deploy version B in parallell with version A and you add the version to the set of labels.

Then, in your service you make sure the version label is a part of the selector and once the pods for version B is running you change the service selectors from version A to version B and it will instantly start using those instead.

Andreas Wederbrand
  • 38,065
  • 11
  • 68
  • 78
0

I recently starting using Kubernetes. My experience is that yes, K8s behaves this way out of the box. If I have e.g. two pods running and I perform a deployment, K8s will create two fresh pods and then, only once those two fresh pods are healthy, will K8s terminate the original two pods.

Jason Swett
  • 43,526
  • 67
  • 220
  • 351
  • Yeah, but does traffic get routed in an "all or nothing" manner, or does it send it to both deployment versions? – Dominic Bou-Samra Jul 09 '21 at 00:10
  • 1
    Oh I see. My understanding is that there's an overlap period where traffic is being routed to version A and version B at the same time, which sounds like not what you want. Not 100% sure about that part though. – Jason Swett Jul 09 '21 at 00:24