Billing

Navigation:  »No topics above this level«

Billing

Previous pageReturn to chapter overviewNext page

How do we calculate the prices:

 

KuberDock billing is based on resource levels allocated to user on per hour, monthly, quarterly or annual basis. The resources are calculated in Kubes. Service providers can set up different Kube Types, and sell them at different prices. Container limits are considered as ‘allocated resources’, meaning that if a customer set up a container that is 5 Kubes size, we will bill it at 5 Kubes per chosen period without accounting for resource levels container is actually using.

 

KuberDock calculates resource levels allocated to a user at any given hour (or other chosen period), and submit that info to the billing system using KuberDock API. This data is used by billing system to calculate the charges.

 

For example:

 

End user has 2 pods. Each pod has a number of docker containers and containers inside the pod are limited to:

Pod #1 - 3 Kubes of Kube Type #1;

Pod #2 - 2 Kubes of Kube Type #2.

Each pod has been working for 4 hours during the day. Then the total amount that end user would have to pay will be the following:

12 Kubes for Pod #1 multiplied by price of  Kube Type #1 per hour +

8 Kubes for Pod #2 multiplied by price of Kube Type #2 per hour.

 

The information on Kubes consumed is submitted to the billing system. Billing system makes calculations and charges user for this amount of resources.

 

How prices are set based on packages and Kube Types:

 

In KuberDock prices are set by a provider in billing system on package level. Service provider can set the following prices:

 

first deposit sum;

price per public IP;

price per GB for persistent storage;

price per additional traffic, per GB (traffic count will be added soon);

price per Kube/hr for each Kube Type for this package. More about Kube Types.

 

 

What does end user see when he orders KuberDock:

 

When a customer signs up for a KuberDock account, end user should see the following according to service provider billing setup:

first deposit sum;

price for using one Public IP;

price per GB for using persistent storage*;

traffic volume included in a package;

over traffic* cost per GB (traffic count will be added soon);

one Kube price for each Kube Type in a package. Kube Type includes:

oRAM capacity;

oDisk space capacity;

oCPU power;

oIncluded amount of traffic in GB (under development).

 

*The correlation between data volume and price is set by a provider.

 

What happens if an end user does not pay for resources

 

Few different behaviors are possible in that case:

 

In case of PAYG billing type.

 

When an end user does not have money to continue using a KuberDock, then he becomes suspended in billing system and in KuberDock. His pods stop, but IPs and persistent storage still exist.

 

Depending on billing configuration it is possible to set suspended days which means that according to the configured amount of suspended days KuberDock will wait until suspend unpaid pods.

 

Other configuration is termination days which means that after configured amount of termination days after due payment date KuberDock will unbind IP and destroy persistent storage of the pod.

 

In case of fixed price billing type.

 

After an end user does not pay for for the working services (predefined application or custom pods) for the upcoming period, then unpaid services acquire “unpaid” status. It means that it will not work but all IPs and persistent storages will be saved. Note that paid services will continue running. That`s why we do not suspend user in billing system and it will be active.

 

Depending on billing configuration it is possible to set suspended days which means that according to configured amount of suspended days KuberDock will wait until stop the pod and will change it status to unpaid. Note that as we do not suspend user in case of fixed price billing type we still use the same parameter in billing system to count days after which we will stop services.