1

I run small Kubernetes cluster in Azure, so can use abstracts provided by Azure (like storage etc).

On it, I have a Deployment object defined in a file that includes one pod and several containers in it: an application container, mongodb container and some others. Application one run from its image which also includes all the binary, so it only require to have mongo database (in secon cntainer) accessible. MongoDB store its data on persistent volume.

Now let's imagine I need to change the image for application container. I change the deployment definition file and do kubectl apply -f deplyment.yml, and I can see the Kubernetes try to implement the change.

But the problem is, it try to run new pod instead of old one and gracefully route load onto it, but new pod won't run since volumes are mount in old pod, and it can not mount it until old container is down.

So this is the problem. I can not understand how to do such upgrades without interruption. The application can not be load-balanced, so no way to run several copies and upgrade it one by one. And I also affraid that if I delete the Deployment (which will try to effectively delete everything connected to) then the volumes may also be deleted.

Are there any good approach?

Alexander Chekalin
  • 11
  • 1

1 Answers1

0

Separate your database and your application.

The application containers get their own Deployment, and it doesn't need persistent storage. You can now update and replicate this deployment.

Another deployment (or StatefulSet) holds mongoDB. This does use storage. But you only rarely need to update mongodb, so there won't be interruptions very often.

Eric Tune
  • 155
  • 5