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 <kubernetes-users@ > googlegroups.com> 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 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.
