On Thu, Sep 6, 2018, 1:52 PM Naseem Ullah <nas...@transit.app> wrote:
> I do not think you have to understand what you are asking for, I've > learned a lot by asking questions I only half understood :) With that said > autoscaling sts was a question and not a feature request :) > LOL, fair enough > I do not see how "data is important, and needs to be preserved" and "pods > (compute) have no identity" are mutually incompatible statements but if you > say so. :) > Think of it this way - if the deployment scales up, clearly we should add more volumes. What do I do if it scales down? Delete the volumes? Hold on to them for some later scale-up? For how long? How many volumes? Fundamentally, the persistent volume abstraction is wrong for what you want here. We have talked about something like volume pools which would be the storage equivalent of deployments, but we have found very few use cases where that seems to be the best abstraction. E.g. In this case, the data seems to be some sort of cache of recreatable data. Maybe you really want a cache? > In any case the data is more or less important since it is fetchable, its > just that if its already there when a new pod is spun up, or when a > deployment is updated and a new pod created, it speeds up the startup time > drastically (virtually immediate vs 2-3 minutes to sync) > Do you need all the data right away or can it be copied in on-demand? Shared storage would be ideal. (deployement with hpa, with a mounted nfs > vol) But I get OOM errors when using RWX persistent volume and +1 pods are > syncing the same data to that volume at the same time, i do not know why > these OOM errors occur. But maybe that has something to do with the code > running that syncs the data. RWX seems to be a recurring challenge. > RWX is challenging because block devices generally don't support it at all, and the only mainstream FS that does is NFS, and well... NFS... > > On Thursday, September 6, 2018 at 4:33:18 PM UTC-4, Tim Hockin wrote: >> >> You have to understand what you are asking for. You're saying "this >> data is important and needs to be preserved beyond any one pod (a >> persistent volume)" but you're also saying "the pods have no identity >> because they can scale horizontally". These are mutually incompatible >> statements. >> >> You really want a shared storage API, not volumes... >> On Thu, Sep 6, 2018 at 1:08 PM Naseem Ullah <nas...@transit.app> wrote: >> > >> > I see I see.. what about autoscaling statefulsets with an HPA? >> > >> > > On Sep 6, 2018, at 4:06 PM, 'Tim Hockin' via Kubernetes user >> discussion and Q&A <kubernet...@googlegroups.com> wrote: >> > > >> > > Deployments and PersistentVolumes are generally not a good >> > > combination. This is what StatefulSets are for. >> > > >> > > There's work happening to allow creation of a volume from a snapshot, >> > > but it's only Alpha in the next release. >> > > On Thu, Sep 6, 2018 at 1:03 PM Naseem Ullah <nas...@transit.app> >> wrote: >> > >> >> > >> Hello, >> > >> >> > >> I have a similar use case to Montassar. >> > >> >> > >> Although I could use emptyDirs, each newly spun pod takes 2-3 >> minutes to download required data(pod does something similar to git-sync). >> If volumes could be prepopulated when a new pod is spun it will simply sync >> the diff, which will drastically reduce startup readiness time. >> > >> >> > >> Any suggestions? Now I have a tradeoff between creating a static >> number of replicas and creating same number of PVCs , or using HPA but >> emptyDir volume which increases startup time for the pod. >> > >> >> > >> Thanks, >> > >> Naseem >> > >> >> > >> On Thursday, January 5, 2017 at 6:07:42 PM UTC-5, Montassar Dridi >> 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 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. >> >> > >> 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 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. >> >> > > 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 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. >> > 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 kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > 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 kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
