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 :)
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. :) 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) 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. 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 <javascript:>> 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 <javascript:>. > > >> To post to this group, send email to kubernet...@googlegroups.com > <javascript:>. > > >> 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 <javascript:>. > > > To post to this group, send email to kubernet...@googlegroups.com > <javascript:>. > > > 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 <javascript:>. > > To post to this group, send email to kubernet...@googlegroups.com > <javascript:>. > > 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.
