On Tuesday, April 24, 2018, <mderos...@gmail.com> wrote: > 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)
Okay, if you are sure about that, then it seems fine. Just checking =) > 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 Exactly. But that will only happen if you manage SVN files outside of the docker build. As long as the container files are contained there, this can't happen. This is exactly why I was advising not to manage files updates outside of the container. Or am I missing something? > > 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? Why not an emptydir? -- 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.
