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.
  • [kubernetes-u... Richard Musiol
    • Re: [kub... 'Tim Hockin' via Kubernetes user discussion and Q&A
      • Re: ... 'Michelle Au' via Kubernetes user discussion and Q&A
        • ... Richard Musiol
          • ... 'David Aronchick' via Kubernetes user discussion and Q&A
            • ... Richard Musiol
              • ... 'Vishnu Kannan' via Kubernetes user discussion and Q&A
            • ... Rodrigo Campos
          • ... aledbf
            • ... Richard Musiol
              • ... Rodrigo Campos
              • ... 'Vishnu Kannan' via Kubernetes user discussion and Q&A
                • ... Richard Musiol

Reply via email to