I would need a *Post*Stop hook. But yes, maybe the best solution right now would be to wrap the agent into some helper that on SIGTERM first forwards the signal to the agent and then does the cleanup before exiting itself.
'David Aronchick' via Kubernetes user discussion and Q&A < [email protected]> schrieb am Fr., 3. März 2017 um 19:36 Uhr: > Is a preStop hook enough as a temp solution? > > e.g. /bin/sh rm -rf <mounted-host-dir-foo> > > https://kubernetes.io/docs/user-guide/container-environment/#hook-details > > On Fri, Mar 3, 2017 at 10:24 AM, Richard Musiol <[email protected]> > 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 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.
