Can you elaborate on this, please On Tuesday, September 12, 2017 at 12:24:28 AM UTC+2, Tim Hockin wrote: > When it is rescheduled, it very likely ends up on a different Node. > If you want to erase that info, you'll need to track ordinals yourself > (via templating or via an ID service) or use StatefulSet. > > On Mon, Sep 11, 2017 at 1:03 PM, <sergei.storozhe...@gmail.com> wrote: > > Indeed, restarts do not create new series. However, we don't want a new > > serie even when the pods get rescheduled. > > On Monday, September 11, 2017 at 9:41:01 PM UTC+2, Tim Hockin wrote: > >> Pod restarts should not create new series'. Only if they get rescheduled, > >> as in a rolling update. In that case they ARE different. > >> > >> > >> > >> On Sep 6, 2017 2:06 AM, <sergei.st...@gmail.com> wrote: > >> Is there any way to create ordinal index of pods in a normal ReplicaSet > >> similarly to StatefulSet? > >> > >> From functional point of view this doesn't make much sense. But could be > >> really useful for our monitoring solution. We use Prometheus that scrapes > >> metrics from kubernetes cluster and sends it to InfluxDB. Each newly > >> created pod gets a unique name by adding a random suffix. The problem is > >> that each time a new pod of the same replica is created, a new time series > >> is created. This increases the metrics cardinality reducing performance > >> and increasing memory footprint. It also results in creating each time a > >> new line in a dashboard instead of continuing the same line. > >> > >> For example, suppose, we have a ReplicaSet with 2 replicas and each > >> replica had 5 restarts. This will result in 10 separate time series and 10 > >> lines in a monitoring dashboard, while with the ordinal index in place, > >> there will be just 2. > >> > >> When dealing with very long time intervals, hundred/thousands time series > >> will be created for the same instance instead of one. > >> > >> Any suggestions are greatly appreciated > >> > >> > >> > >> -- > >> > >> 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.
