While RealTheory uses rate cards to calculate the cost of your Kubernetes implementation, rate card policies provide a dynamic, granular, and scalable mechanism for assigning those rate cards to the appropriate clusters in your environment. Using a custom cluster label that you can easily associate with each cluster through the RealTheory Collector deployment YAML, you can minimize the need for excessive oversight and management. Rate card policies provide a highly efficient mechanism for managing cost analysis in large organizations with large numbers of clusters.
Rate card policies define a relationship between clusters with a specific label that you specify and the rate card that must be used for cost analysis for cluster(s) with that label.
Let's say that you have the following pricing plan situation:
In this scenario, you would set a rate card that specifies a 20% discount for AWS as your default rate card because a significant number of your clusters (80%) use that pricing plan, and using that rate card as your default minimizes the amount of configuration you need to implement.
You might then define the following labeling protocol to manage the automatic assignment of rate cards to the appropriate clusters for the other pricing plans:
rate-card=gcp-10rate-card=azure-1-year-resNote: You do not need a rate card labeling convention for the clusters that will use the default rate card.
When you define the RealTheory Collector deployment YAML for each of your clusters, you must add the appropriate rate-card=<value> label to the deployment.
You then create a rate card policy for each pricing plan that is an exception to the default pricing plan. Each policy will specify a label as the Condition and the rate card that is appropriate for the cluster(s) that have the specified label.
rate-card=<value>Note: Only one policy is applied per cluster—the first match wins.
See Also
Search for a command to run...