Feature overview

Providing features that enable customers to create cost models that are better suited to modify behaviour of customers

Goals

• Provide support for pricing that mixes usage and request in a single price
• Provide support for tiers
• Provide support for minimum steps.

Background

 Customers want to change the behaviour of users in their platform, in order to provide a better way of operating the OpenShift platform. One good way of making that change is to  associate higher costs to those behaviours that they want to change.

Support for tiers

Tiers allow the customer to define charges that are specifically against the use of too many resources, and that can encourage additional usage.

Example: Make pods under 256MB of memory free, and put a price on each MB of memory used after that.

Example: Make the first 2 CPU cheap, and CPU after 2 really expensive, so users can decide to use more than CPU, but knowing that it will cost them.

Example: AWS and Google Free tier. This free tier is monthly, not hourly

Minimum step

The data we have have a very good resolution (mCPU, subsecond). But not all the pricing is thought with this level of detail.

For instance, pricing per node is done by CPU or Memory. Or for a minimum of one hour (or 1 second), or a minimum of CPU.

Minimum step allows the customer to define what is the minimum amount considered when applying the price list (i.e. 1/4 of CPU, 128 MB of Memory), so we can model more accurately real prices (i.e. 4 vCPU or 2 sockets).

An additional thing we need to do here is to be able to define usage minimum as the request.

Real usage: 0.002 CPU this hour

Net usage: 1 CPU this hour (the requested CPU)

If the user in this case uses
Real usage: 1.341 CPU this hour

Net usage: 1.341 CPU this hour

If the minimum step is 0.25 CPU

Real usage = 0002 CPU this hour -> Net usage = 1 CPU

Real usage = 1.341 CPU this hour -> Net usage = 1.50 CPU

Mix pricing

Pricing should depend on the reservation of resources to make sure that users make the most out of the cluster.

Kubernetes offers 3 QoS for the cluster:

• Guaranteed. Limit is not 0, request is = limit (for both CPU and memory in all pods).
• Burstable. Requests are not 0, limit is not = request (for some resource)
• Best-Effort. Request and limit are not set for all of the resources.

Pods are not killed if CPU guarantees can not be met, they are throttled temporarily.

For Memory:

• Best-Effort pods will be treated as lowest priority. Processes in these pods are the first to get killed if the system runs out of memory. These containers can use any amount of free memory in the node though.
• Guaranteed pods are considered top-priority and are guaranteed to not be killed until they exceed their limits, or if the system is under memory pressure and there are no lower priority containers that can be evicted.
• Burstable pods have some form of minimal resource guarantee, but can use more resources when available. Under system memory pressure, these containers are more likely to be killed once they exceed their requests and no Best-Effort pods exist.

What we want is to set up pricing that can take this things into account:

• Toggle whether your usage charges consider request as the minimum input. After changing usage, request and usage behave as normal.
• Toggle whether you are using the request charges for usage under request. Then if the usage is under request you charge the request in full. Usage is considered over the request only

Out of scope

1. Tiers based on monthly charges and different inputs (in opposition to tiers based on hourly charges)
2.