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.