0

Say I have an application that has two deployments:

  • An application deployment, with the actual application itself
  • A Redis deployment, which is used by the application deployment for caching

The Redis cache is exposed by a service called "redis". The application connects to the Redis service using the service hostname ("redis").

Say the application gets an update from version 1 to version 2. The Deployment container spec is updated so now it's based on the app:2 container image.

Here's the problem: during the update process, two versions of the application are using the same Redis service. The new application, while reaching its ready state, warms up the cache, basically corrupting it for the still running version 1.

Does Kubernetes facilitate a construction where a new revision of a Deployment gets its own Redis service, which it can warm up before reaching its ready state and which is not affected by the current revision? When the current revision gets killed by Kubernetes because the new revision reached the ready state, it should tear down the Redis service linked to that revision along with it.

Leon Boot
  • 21
  • 2

1 Answers1

0

Does Kubernetes facilitate a construction where a new revision of a Deployment gets its own Redis service

Have you considered shipping your application in a Pod with two containers, one of which being your Redis?

during the update process, two versions of the application are using the same Redis service

Maybe look into changing your deployment strategy to Recreate, if you can afford temporarily shutting down service, it would ensure the previous copy of your application is down before starting the next one.

Should we want to avoid disrupting service at all cost, then maybe look into blue-green deployments: always have two copies of your application (redis+app), re-deploy only on one side, then reconfigure your ingress sending clients to the new version.

SYN
  • 1,751
  • 8
  • 14
  • I actually haven't considered a multi-container pod! Somehow I know about it, but I keep overlooking it. I think it just might be the best way to go at it, although I can think of one downside: when scaling, each instance gets its own Redis service, instead of all app pods using one Redis service. Blue-green sounds good too, but it seems tough to automate. – Leon Boot Nov 06 '19 at 12:48
  • Dealing with blue-green, on OpenShift, I would use a Jenkins pipeline (kinda like https://github.com/openshift/origin/blob/master/examples/jenkins/pipeline/bluegreen-pipeline.yaml ). In Kubernetes, you won't have buildconfigs or routes, you'll need to figure out how to re-route your Ingress, and automate your image builds if you haven't already. Or maybe look into Tekton? Probably more "native", especially with k8s. – SYN Nov 07 '19 at 06:34