Yeah, my use case is basically change the permissions of the hostPath so that my pods running as non root can access it. I dont want a pod running as daemon set for this purpose, since the pod will just be sitting there doing nothing, until a new host appears or a host is reimaged, etc. I believe there is no way to mount a hostPath with so that a non root user can access. I would prefer to run a job externally once in a while to ensure this once in a lifetime needed thing.
There have been other debugging use cases which , want you to run some commands on a subset of nodes and get their output and complete. I believe a first class kubernetes way of accomplishing those would be awesome, although most of those use cases are debugging scenarios. I do agree with the general sentiment that leaving a node dirty is a bad idea but debugging /testing scenarios or collecting some data by running some commands might be scenarios to consider. What do you all think ? -Mayank On Friday, January 20, 2017 at 4:46:25 PM UTC-8, Rodrigo Campos wrote: > > I also think having"state changes" it's a bad use case, as it's been > pointed out (it can be changed again, etc. No "self healing" once you have > state like that, that goes against most of the basic ideas of > reconciliation loops in k8s). > > But I want to add that, although that use case seems like a wrong idea, > there might be other valid use cases (like gather some data from nodes > once). Maybe it's a good idea to find them first :-) > > On Friday, January 20, 2017, Brandon Philips <brandon...@coreos.com > <javascript:>> wrote: > >> On Fri, Jan 20, 2017 at 1:40 PM 'Tim Hockin' via Kubernetes user >> discussion and Q&A <kubernetes-users@googlegroups.com> wrote: >> >>> Concretely the "tweak a sysctl" thing leaves machines that are >>> "dirty". Once you allow any users to do this, the machines become >>> less useful for anyone else who doesn't specifically tolerate that >>> tweak. Almost every sysctl represents a tradeoff. Optimize for >>> low-latency network? Pay higher CPU and memory costs. And so on. >>> >> >> I am not saying it is necessarily the right solution for users; just that >> I have seen people wanting to do `kubectl get nodes | while read host ; ssh >> $host echo foo > /proc/sys/bar`. It would be nice to at least bring that >> into the API fold and auditing. >> >> Brandon >> >> >>> On Fri, Jan 20, 2017 at 12:33 PM, 'David Oppenheimer' via Kubernetes >>> user discussion and Q&A <kubernetes-users@googlegroups.com> wrote: >>> > Brandon, would you like to file an issue in kubernetes/kubernetes to >>> start? >>> > FWIW the privileged run-to-completion node configuration script is a >>> use >>> > case we have also seen at Google, but the semantics get a bit tricky. >>> We >>> > could start with just a run-to-completion DaemonSet which I think >>> covers the >>> > use cases you mentioned as well as the one from Mayank. >>> > >>> > >>> > >>> > On Fri, Jan 20, 2017 at 10:26 AM, Brandon Philips >>> > <brandon.phil...@coreos.com> wrote: >>> >> >>> >> I think this would be a nice thing to have. I have seen a few users >>> >> wanting to do things like run a quick script against all nodes in a >>> cluster >>> >> that say tweaks a sysctl across the entire fleet. Or, gathers up some >>> >> setting and pushes the results to some service. >>> >> >>> >> I think it would be worthwhile to gather other use cases and write a >>> >> proposal. >>> >> >>> >> On Fri, Jan 20, 2017 at 1:01 AM 'David Oppenheimer' via Kubernetes >>> user >>> >> discussion and Q&A <kubernetes-users@googlegroups.com> wrote: >>> >>> >>> >>> Unfortunately I don't think it's possible. The documentation for >>> >>> DaemonSet says the RestartPolicy must be Always. If it allowed Never >>> then it >>> >>> would do what you want. >>> >>> >>> >>> >>> >>> On Thu, Jan 19, 2017 at 2:37 PM, Mayank <krmaya...@gmail.com> wrote: >>> >>>> >>> >>>> Hi All >>> >>>> Is there a way to create a kubernetes job that runs on all nodes in >>> the >>> >>>> cluster and then finishes without creating one job per node using >>> node >>> >>>> selector ? Or may be this is enhancement to say run this job on all >>> hosts >>> >>>> with regex *.ops.net and viola >>> >>>> >>> >>>> -Mayank >>> >>>> >>> >>>> -- >>> >>>> 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. >>> >>> >>> >>> >>> >>> -- >>> >>> 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. >>> >> >>> >> -- >>> >> 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. >>> > >>> > >>> > -- >>> > 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. >>> >>> -- >>> 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. >>> >> -- >> 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. >> > -- 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.
