持久化卷更改：在 Kubernetes 容器中重新启动服务

Question

I have an HTTP application (Odoo). This app support install/updating modules(addons) dynamically.

I would like to run this app in a Kubernetes cluster. And I would like to dynamically install/update the modules.

I have 2 solutions for this problem. However, I was wondering if there are other solutions.

Solution 1:

• Include the custom modules with the app in the Docker image
• Every time I made a change in the custom module and push it to a git repository. Jinkins pull the changes and create a new image and then apply the new changes to the Kubernetes cluster.

Advantages : I can manage the docker image version and restart an image if something happens

Drawbacks : This solution is not bad for production however the list of all custom module repositories should all be included in the docker file. Suppose that I have two custom modules each in its repository a change to one of them will lead to a rebuild of the whole docker image.

Solution 2:

• Have a persistent volume that contains only the custom modules.
• If a change is made to a custom module it is updated in the persistent volume.
• The changes need to apply to each pod running the app (I don't know maybe doing a restart)

Advantages : Small changes don't trigger image build. We don't need to recreate the pods each time.

Drawbacks : Controlling the versions of each update is difficult (I don't know if we have version control for persistent volume in Kubernetes).

Questions:

• Is there another solution to solve this problem?
• For both methods, there is a command that should be executed in order to take the module changes into consideration odoo --update "module_name" . This command should include the module name. For solution 2, How to execute a command in each pod?
• For solution 2 is it better to restart the app service(odoo) instead of restarting all the nodes? Meaning, if we can execute a command on each pod we can just restart the service of the app.

Thank you very much.

Answer 1

You will probably be better off with your first solution. Specially if you already have all the toolchain to rebuild and deploy images. It will be easier for you to rollback to previous versions and also to troubleshoot (since you know exactly which version is running in each pod).

There is an alternative solution that is sometime used to provision static assets on web servers: You can add an emptyDir volume and a sidecar container to the pod. The sidecar pull the changes from your plugins repositories into the emptyDir at fixed interval. Finally your app container, sharing the same emptyDir volume will have access to the plugins.

In any case running the command to update the plugin is going to be complicated. You could do it at fixed interval but your app might not like it.