A preStop hook, although will help, I doubt it can work. Because if the pod crashes or something, the preStop I guess is not executed. But maybe you don't hit the problem often in practice.
Another ugly option might be to periodically clean it, with a daemon set or a cron job on the node. Or even inotify. But that is assuming you know when things can be cleaned up, that I don't know if that is the case. A way to know (without me knowing about the app layerz that may introduce more alternatives) might be trying to map which pod is using which directory inside the host path. If a directory that doesn't belong to a running pod, then it can be erased. This can run in a daemon set too, and ask the kubernetes API for ruining pods (and dirs are pod names) or using an external DB to match them. The pod name can be known inside your container, so it seems simple. And probably unlikely to collide, but not guaranteed Also, if all of this fits in memory, you may just use that (en empty dir with medium memory). For sure it's faster than disk :-) On Friday, March 3, 2017, 'David Aronchick' via Kubernetes user discussion and Q&A <[email protected]> wrote: > 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] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[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] >>> <javascript:_e(%7B%7D,'cvml','[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] >>>> <javascript:_e(%7B%7D,'cvml','[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] >>>>> <javascript:_e(%7B%7D,'cvml','kubernetes-users%[email protected]');> >>>>> . >>>>> To post to this group, send email to [email protected] >>>>> <javascript:_e(%7B%7D,'cvml','[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] >>>> <javascript:_e(%7B%7D,'cvml','kubernetes-users%[email protected]');> >>>> . >>>> To post to this group, send email to [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[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/to >>> pic/kubernetes-users/IVg6QasyxV0/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','kubernetes-users%[email protected]');> >>> . >>> To post to this group, send email to [email protected] >>> <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','kubernetes-users%[email protected]');> >> . >> To post to this group, send email to [email protected] >> <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','kubernetes-users%[email protected]');> > . > To post to this group, send email to [email protected] > <javascript:_e(%7B%7D,'cvml','[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.
