I modified the Docker image to run a script which forwards SIGTERM to the child process and which deletes the files after the child exited.
'Vishnu Kannan' via Kubernetes user discussion and Q&A < [email protected]> schrieb am Mi., 8. März 2017 um 02:52 Uhr: > Richard, > > Can you describe your workflow/use-case a bit more? > Are you having I/O starvation issues with accessing container images > and/or logging as well? > > --Vish > > On Tue, Mar 7, 2017 at 1:35 PM, Richard Musiol <[email protected]> > wrote: > > I have solved this with a wrapper now which does the cleanup on SIGTERM > after the child has exited. > > Thanks for the suggestions, though! > > Cheers, > Richard > > <[email protected]> schrieb am Sa., 4. März 2017 um 20:31 Uhr: > > Maybe you can use a flexVolume plugin? (in bash like the lvm example) > ( > https://github.com/kubernetes/kubernetes/blob/master/examples/volumes/flexvolume/README.md > ) > in the mount you can check if the ssd drive is mounted and then create a > new directory that you can remove when the unmount method is called. > > > On Friday, March 3, 2017 at 3:24:50 PM UTC-3, Richard Musiol wrote: > > Hi Michelle, Hi Tim, > > > > > > there is one local SSD per node, so yes, it is shared between many pods. > > > > > > Solution 1 is already a step forward, but I would really like to use a > local SSD. The use case is that I'm running Buildkite agents on that > cluster and I want to autoscale them. The limits of a normal disk were very > quickly reached with that kind of workload, switching to the local SSD > solved it. > > > > > > Solution 2 sounds involved, but I'm willing to be a guinea pig for this > because the workload is not production critical. > > > > > > -Richard > > > > > > 'Michelle Au' via Kubernetes user discussion and Q&A < > [email protected]> schrieb am Do., 2. März 2017 um 23:33 Uhr: > > > > > > Hi Richard, > > > > > > Are you sharing the local SSD between many pods, or just one pod per SSD? > > > > > > If sharing is ok, then in the short term we could look into one of the > following approaches: > > 1. Ability to create a GKE cluster with kubelet installed on top of a > PD-SSD. Then all EmptyDirs will use this PD. It's not going to perform as > well as a local SSD though. > > 2. Use the alpha flex volumes interface with an lvm plugin, that can > carve out lvs out of a vg comprised of local SSDs. The vgs would have to be > precreated by some DaemonSet on each node before any normal pods start > running. This approach would be meant as a short term solution for now and > require some extra management by the user/admin. Flex itself is alpha and > going through lots of revision. > > > > > > If dedicated disks are required, then we don't have any short-term > solutions besides hostpath. The long term solution is to expose disks as > LocalDisk PVs, and for the temporary use cases, have an "inline" option > where the PV gets created and destroyed with the pod. > > > > > > > > -Michelle > > > > > > > > > > > > > > > > On Thu, Mar 2, 2017 at 9:33 AM, 'Tim Hockin' via Kubernetes user > discussion and Q&A <[email protected]> wrote: > > > > There isn't a clean way to express what you want today. There are some > ideas about being able to express local storage as volumes, but that work > is a long pipeline for what feels.like a simple request. > > > > > > We already have an idea of "medium" in emptyDir. What if we extended > that? The question becomes how to express that multitudes of potential SSD > technologies, current and yet to be developed, without resorting to calling > them all the same? > > > > > > You could imagine a way to config kubelet to build a map of local > mountpoints as named "Local" media, and then allow users to request those. > It's imperfect in a lot of ways, but it might be tractable. > > > > > > @vishh @msau this comes up not FREQUENTLY but enough that maybe we want > to think of a short term goal here? > > > > > > Just thinking out loud... > > > > > > > > > > On Mar 2, 2017 9:21 AM, "Richard Musiol" <[email protected]> wrote: > > > > Hi, > > > > > > I would like to use GKE's local SSD feature to have fast temporary disk > space. > > > > > > The problem when using it with a "hostPath" volume as described on > https://cloud.google.com/container-engine/docs/local-ssd is that the > temporary files do not get removed when the pod gets deleted. Over time the > local SSD would fill up. > > > > > > The volume type "emptyDir" would do what I want, but I don't see how to > put it on the local SSD. > > > > > > Any ideas? > > > > > > Cheers, > > Richard > > > > > > > > > > -- > > > > 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 [email protected]. > > > > To post to this group, send email to [email protected]. > > > > 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 [email protected]. > > > > To post to this group, send email to [email protected]. > > > > 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 a topic in the > Google Groups "Kubernetes user discussion and Q&A" group. > > > > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/kubernetes-users/IVg6QasyxV0/unsubscribe > . > > > > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > > > To post to this group, send email to [email protected]. > > > > 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 a topic in the > Google Groups "Kubernetes user discussion and Q&A" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/kubernetes-users/IVg6QasyxV0/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. > > > To post to this group, send email to [email protected]. > 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 a topic in the > Google Groups "Kubernetes user discussion and Q&A" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/kubernetes-users/IVg6QasyxV0/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
