Disk TYPE on clusters create : gcloud alpha containers clusters create --disk-type

[Josh Whelchel]

As far as I can see, there is not way to specify the disk type? (e.g. SSD persistent)

We run elasticsearch on container engine, and at this time the only way to change this is to clone the instance template and change the type.

Cheers,

[Brendan Burns]

This isn't possible for the boot disk, but you can either:

  * GcePersistentVolume type and mount an SSD-PD into your Pod that way

  * Use a TmpFs Volume and use memory (even faster! even more volatile!)

It depends on your needs.

(we should probably let you chose the root disk type, but it's not currently an option)

--
You received this message because you are subscribed to the Google Groups "Containers at Google" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-contain...@googlegroups.com.
To post to this group, send email to google-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-containers.
For more options, visit https://groups.google.com/d/optout.

[Robert Bailey]

Hi Josh,

Thanks for trying out container engine! Right now, the options you can specify to customize your nodes when creating a cluster are admittedly a bit limiting. And there isn't a way to specify a different disk type. We hope to add more flexibility to the API surface soon, and hearing about specific needs from customers is a great way to elevate the priority of this work.

Can you give a few details on why elastic search requires persistent SSDs for the node boot disks?

Thanks,

Robby

On Fri, Jul 17, 2015 at 3:03 PM, Josh Whelchel <jo...@acappellarecords.com> wrote:

--

[Richard Musiol]

Hi Robert,

we would also like to have the option to use SSDs for the boot disk. Simply because we can and we want to avoid discussions about why we're not using them while they offer better performance for an acceptable price.

Thanks,

Richard

[Robert Bailey]

Hi Richard,

We recently added an option to attach local SSDs to each node in your cluster (or node pool). The boot disk will still be a standard PD, but you can create a high throughput, low latency local scratch space if your application needs it. For example, 

    $ gcloud beta container clusters create my-new-cluster --local-ssd-count=2

will create a cluster where each node has 2 375GB local SSDs attached. Does that help address your use case?

Robby

Visit this group at https://groups.google.com/group/google-containers.

[Richard Musiol]

Hi Robert,

thanks, I didn't know about that. However, it is only somewhat useful in our case. Like I said, it's not really clear reasoning that brings us to SSDs but rather that we want to stop any discussion about whether using them would be helpful for performance by simply doing so preemptively. Such a discussion would just waste time.

Are there any technical reasons why it wouldn't be a good idea to use an SSD as the boot disk? Right now we change it manually by modifying the instance template and we don't see any issues. It would be nice if we wouldn't have to do this change manually.

Thanks,

Richard

You received this message because you are subscribed to a topic in the Google Groups "Containers at Google" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-containers/kF75xIIbK54/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-contain...@googlegroups.com.

[Robert Bailey]

On Fri, Jul 15, 2016 at 2:48 AM, Richard Musiol <ma...@richard-musiol.de> wrote:

Hi Robert,

thanks, I didn't know about that. However, it is only somewhat useful in our case. Like I said, it's not really clear reasoning that brings us to SSDs but rather that we want to stop any discussion about whether using them would be helpful for performance by simply doing so preemptively. Such a discussion would just waste time.

Are there any technical reasons why it wouldn't be a good idea to use an SSD as the boot disk?

None that I know of. Since most folks only use the boot disk for log storage, we hadn't gotten around to exposing parameters to make it SSD instead of PD (either in OSS or in GKE). 

[paolom...@gmail.com]

Richard, can you point me how to change from standard to ssd in the template instance ? I can't find it.

Thanks

[Richard Musiol]

Copy/clone the instance template, then click "Change" on the "Boot disk" option and select SSD at the bottom. At least that's the way I did it last time. When trying it now the boot disk selection dialog seems to be broken again for non-standard images like the GCI image. Alternatively you can get the "Equivalent REST or command line" at the bottom of the instance template creation dialog and then modify the disk type value.

<paolom...@gmail.com> schrieb am Do., 24. Nov. 2016 um 08:40 Uhr:

Richard, can you point me how to change from standard to ssd in the template instance ? I can't find it.

Thanks

--
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/kF75xIIbK54/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.

[paolom...@gmail.com]

On Thursday, November 24, 2016 at 11:13:27 AM UTC+1, Richard Musiol wrote:
> Copy/clone the instance template, then click "Change" on the "Boot disk" option and select SSD at the bottom. At least that's the way I did it last time. When trying it now the boot disk selection dialog seems to be broken again for non-standard images like the GCI image. Alternatively you can get the "Equivalent REST or command line" at the bottom of the instance template creation dialog and then modify the disk type value.

Yes, that is what i did, but you confirm that the interface is broken, i am using the containervm image.
Let me try with the cli equivalent.

Thanks a lot.

[paolom...@gmail.com]

It's broken also the cli command, some unquoted char, quite impossible to debug as is a 50K string blog.

WTF.