How does actual utilization relate to billing, compared to resource reservations? Kubernetes schedules by requests (more or less), what should a customer be billed who reserves N cores but only uses a small fraction? Or a customer who under-reserves but uses spare capacity? You can also forbid the latter using limits, should you choose to.
Billing by reservation would be easier than actual usage, since you can basically multiply the reservation (whichever dimensions you choose) by the run time. You could do this with Prometheus or simply by collecting the data for finished containers from the Kubernetes API. /MR On Mon, May 29, 2017, 22:28 Ben Kochie <sup...@gmail.com> wrote: > This could easily be done with Prometheus. It's also for real-time > monitoring, but it it has a good time-series database and query API for > getting the kind of data you need. > > On Mon, May 29, 2017 at 8:50 PM, <viri...@gmail.com> wrote: > >> Hi folks, relative newcomer here. :) I'm working on using Kubernetes to >> create a render farm for my company. One of the things I need to be able to >> do is measure machine utilization so that I can bill our customers. I >> looked into the heapster docs, but that doesn't seem to be the correct tool >> - it seems to be focused on real-time monitoring, whereas what I need to >> know is the total resource usage for a job that may last 10 hours or more. >> (More accurately, I want to know how much AWS is going to charge us, but I >> need to know it on a per-container basis, since multiple containers for >> multiple customers may be running on a single node.) >> >> The approach I've been looking at is to get the docker stats by talking >> to the node directly. That is, given a job, query to find the pod metadata, >> then talk to the pod to get the docker stats for the container. I haven't >> quite gotten this to work yet. >> >> Is there a better approach? >> >> -- >> 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. > -- 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.
