On Thu, Jan 5, 2017 at 9:52 PM, Montassar Dridi <[email protected]> wrote: > > > On Thursday, January 5, 2017 at 11:17:26 PM UTC-5, Tim Hockin wrote: >> >> On Thu, Jan 5, 2017 at 5:24 PM, Montassar Dridi >> <[email protected]> wrote: >> > Hi Tim, >> > >> > I'm trying to do something like this example >> > >> > https://github.com/kubernetes/kubernetes/tree/master/examples/mysql-wordpress-pd >> > I have a java web application and MYSQL database running within >> > Kubernetes >> > connected to each other, used "kubernetes Deployment" as the example >> > above. >> >> "connected" via a Service or in the same Pod? > > > -> yes via service and each one have it's own "Deployment" so separate pods > >> >> >> > When I try to increase the number of the web replicas, they all try to >> > connect to that persistent disk that was created from the beginning, and >> > they get stuck not be able to create the new web pods. >> >> PDs are only able to be mounted read-write by one pod at a time. >> That's just a limitation of the block device+filesystem interface. > > > -> exactly, that's why I need to automatically generate a new PD unique for > every newly created pod. > >> >> >> > So what I want is when I ask for new pods, a unique new persistent >> > disks/volumes should be created and associated for each one of them, >> > like >> > how Statefulsets/PetSets do it. >> >> Why do you want a new PD for each replica? If it is new, then the >> "persistent" nature of it is not valuable, and you can just use plain >> inline volumes instead of a claim. But if it is going to be released >> with the pod, why use a PD at all? why not just use emptyDir? > > > ->The reason I'm creating new pods, is trying to anticipate what happens if > I turn the Horizontal Pod auto-scaling on. Also I want all the pods to be > consistent with each other, if I modify one, I want them all to get the same > changes.
But why do you need PERSISTENT volumes, if you say you want "unique new" disks? >> > I appreciate your help and thanks for responding. >> > >> > On Thursday, January 5, 2017 at 7:41:22 PM UTC-5, Tim Hockin wrote: >> >> >> >> Can you explain what you're trying to achieve? >> >> >> >> Fundamentally, persistent volumes and replication are at odds with >> >> each other. Replication implies fungibility and "all replicas are >> >> identical". Persistent volumes implies "the data matters and is >> >> potentially different". >> >> >> >> Now, I can think of a couple cases where this isn't quite so >> >> black-and-white, and we've discussed if/how to implement for those >> >> cases. But I am not going to tell you what they are until you explain >> >> to me what you're trying to do, lest I muddy the water :) >> >> >> >> Tim >> >> >> >> >> >> On Thu, Jan 5, 2017 at 4:12 PM, Montassar Dridi >> >> <[email protected]> wrote: >> >> > thanks for responding >> >> > I tried it, still doesn't automatically generate new volumes for the >> >> > new >> >> > pods. PetSets/StatefulSets using "volumeClaimTemplates" for that. >> >> > Is >> >> > there >> >> > a tool like that for Deployment? >> >> > >> >> > On Thursday, January 5, 2017 at 6:19:43 PM UTC-5, Vishnu Kannan >> >> > wrote: >> >> >> >> >> >> Check out dynamic volumes provisioning here. >> >> >> >> >> >> On Thu, Jan 5, 2017 at 3:07 PM, Montassar Dridi >> >> >> <[email protected]> >> >> >> wrote: >> >> >>> >> >> >>> Hello!! >> >> >>> >> >> >>> I'm using Kubernetes deployment with persistent volume to run my >> >> >>> application, but when I try to add more replicas or autoscale, all >> >> >>> the >> >> >>> new >> >> >>> pods try to connect to the same volume. >> >> >>> How can I simultaneously auto create new volumes for each new pod., >> >> >>> like >> >> >>> statefulsets(petsets) are able to do it. >> >> >>> >> >> >>> -- >> >> >>> 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 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 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.
