Il giorno lunedì 23 aprile 2018 16:52:20 UTC+2, Rodrigo Campos ha scritto:
> Sorry, there are different parts that I don't follow. Why daemon set?

No problem. 
So why daemon set? Because I have a cluster with 6 nodes (but in the future 
this number could be greater) and to ensure that every node will contain a 
single pod I use a daemonset deploy (as you advised me in this discussion: 
https://groups.google.com/forum/#!topic/kubernetes-users/t1cR-v6NCpM)


 
> And fundamentally why not rebuild ok SVN changes? You can automate that. Take 
> into account that if you don't have different images with the code, you can't 
> use Kubernetes to rollback either. Or you should check in some other way 
> which pod had which svn revision at any moment in time, and also handle if an 
> SVN up fails or fails in some pods only. OIW, it can add more problems than 
> it solves to do that, consider it carefully.

To be honest I don't think that automate svn updates is a reliable solution.
Let me give an example:
- I commit some file --> revision 123 and I have to deploy those changes on prod
- I create a docker image where I update the code to revision 123
- Then I deploy the image with a rolling update to kubernetes cluster
- In the following days I work to the code, committing the files to make them 
available to the team. Now the svn revision is 200. But a deploy on prod is not 
scheduled
- For a memory problem, on prod env, kubernetes kills a pod and restarts it 
automatically. If any automatic code update mechanism is activated when the pod 
is started, it will lead to the situation where a pod will have code of 
revision 200 and all the others will remain to revision 123



> That being said, you can use a sidecar container to update the SVN code in a 
> shared volume. That sounds like a good approach (in most Kubernetes examples 
> shown with a webserver and git, but it's the same). And you should be able to 
> handle restarts and that stuff fine.

In fact from what I have read on the internet this approach should be the most 
correct solution. 
The question is: do I have to create a single persistent disk that will be 
mounted (read only I assume) on every pod (via daemonset.yml) ?
Or is it possible to create one persistent disk for every pod, where each one 
is mounted on a single pod in r/w mode?

Thanks

Marco

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to