Any news for this topic? Should we really create 3 controllers to set up a cluster of 3 cassandra nodes each having a separate persistent storage?
On Saturday, 20 February 2016 01:43:51 UTC+3, Lakhindr wrote: > > Could some labels be used with some regexp like matching criterion to > select PVs for a certain PVC? Additionally, this labeling might help in > geographic affinity -- which can help deliver a better network utilization. > Multiple label matching would give a fine grained control, and without any > special instrumentation. > > BTW, what is a 'special snowflake', that you have referred to in your > reply above? > > Thanks. > > On Tuesday, October 13, 2015 at 8:49:19 AM UTC-7, Brendan Burns wrote: >> >> Yes, this is too hard/awkward right now and it *should* work out of the >> box but we haven't had a chance to implement it. The basic idea is to have >> a generic PV claim on a pool of PVs and then create a replication >> controller style loop manage the size of the pool of PVs. >> >> There are relevant designs in github. If someone has time to implement >> it... >> >> Otherwise, I'd guess we'll get to it in early 2016. >> >> Sorry! >> Brendan >> On Oct 13, 2015 8:31 AM, "George Antoniadis" <[email protected]> wrote: >> >>> I'm currently trying to get around the same issue. >>> I get that the RC does not have access to AWS/GCE to create volumes but >>> I assumed that there would be a way to pick an available PV from a pool in >>> order to allow the RC be able to scale something. >>> >>> Having a "master" cassandra node in a kubernetes environment seems to me >>> missing the forest for the trees. >>> Is there a best practice for data storage for dbs etc, or is it just >>> using the emptyDir? >>> >>> Rafael would it be possible for you to share your solution/configs? I >>> would be very interested in checking out how you decided and managed to >>> solve this. >>> >>> Thank you all very much in advance! :) >>> George >>> >>> On Thursday, September 24, 2015 at 6:58:46 AM UTC+1, Rafael Chacón wrote: >>>> >>>> Thanks for the feedback! >>>> >>>> I ended up doing something like Ward mentioned and it has been working >>>> nicely. >>>> >>>> Best, >>>> >>>> On Tuesday, September 15, 2015 at 2:41:53 PM UTC-7, Ward Harold wrote: >>>>> >>>>> We've tried a couple of approaches. >>>>> >>>>> Initially we created persistent disks in GCE, mounted them on selected >>>>> VMs in our GKE cluster, and then used nodeSelectors to make the Cassandra >>>>> pods, which used hostPath mounts, run on those nodes. That worked fine >>>>> but >>>>> the manual mounts were going to be a problem if we wanted to do an >>>>> automated GKE node upgrade. >>>>> >>>>> Next we created persistent disks and used persistent volumes and >>>>> claims to avoid the manual mounts. That worked as advertised but forced >>>>> us >>>>> to do separate replication controllers for each of our Cassandra nodes >>>>> which isn't a terrible thing. The big win, we hope, is that it will allow >>>>> us to to an automated GKE node upgrade when the time comes. >>>>> >>>>> Brendan's solution is simple and clean, and basically what we do in >>>>> out dev and qa namespaces, but wouldn't handle "big data" unless you made >>>>> very large root partitions on your nodes. >>>>> >>>>> On Sunday, September 13, 2015 at 3:59:06 PM UTC-5, Rafael Chacón wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm playing with the Cassandra example in >>>>>> https://github.com/kubernetes/kubernetes/tree/master/examples/cassandra >>>>>> and I was wondering which kind of volume type I can use that is not >>>>>> emptyDir. At first I thought in gcePersistentDisk but that can only be >>>>>> mounted by one pod in read-write. Has anyone tried this before? >>>>>> >>>>>> Best, >>>>>> >>>>>> Rafael. >>>>>> >>>>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/google-containers. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-containers. For more options, visit https://groups.google.com/d/optout.
