How To Leverage RealTheory Labels For Scalability and Automation

RealTheory labels are similar to Kubernetes labels. They allow you to associate meaningful and relevant attributes to resources that can then be used to organize and select subsets of resources to take action against. RealTheory labels play a crucial role in automating many workflows based on predefined criteria and conditions. This automation can enhance overall agility and scalability, streamline operations, reduce manual intervention, and ensure consistency and accuracy across the environment.

You associate RealTheory labels to clusters by defining them as part of the RealTheory Collector deployment YAML. You can define as many labels as needed in the cluster deployment YAML. To leverage the full power of RealTheory labels, you should design, implement, and enforce a labeling protocol to ensure consistency and clarity so that users can configure, monitor, and troubleshoot across labeled resource sets relevant to their organizational function. RealTheory labels are only associated with objects within the RealTheory application; RealTheory does not alter any labels in your cluster.

If your labeling needs change due to organizational restructuring, infrastructure updates, or new requirements for configuration and observation, you can easily update the RealTheory labels associated with a cluster to adapt to those changes. Simply update and re-apply the cluster deployment YAML with the appropriate label changes to augment your labels without the need to redeploy any infrastructure.

Installing RealTheory in a Cluster describes how to associate RealTheory labels to your Kubernetes resources.

Developing a Labeling Protocol — Practical Examples

Using Labels to Manage Access Control Policies

Let's say that you have the following situation in your organization:

• You have four clusters: Clusters 1, 2, 3, and 4
• Among the organization's employees are four teams that need cluster access: Teams Blue, Red, Yellow, and Green
• Team Blue manages cluster 1
• Team Red manages cluster 2
• Team Yellow manages cluster 3
• The entire organization has access to cluster 4
• Team Green does not manage a cluster but must have access to all clusters

In this scenario, you might define a cluster labeling protocol based on team ownership:

• team=blue
• team=red
• team=yellow
• team=all-teams

Creating Access Control Policies describes how RealTheory labels can be used to automate discretionary access control (DAC).

Using Labels to Manage Rate Card Assignments

Let's say that you have the following pricing plan situation:

• 80% of your clusters are in AWS and at AWS you have a 50% discount
• 15% of your clusters are in GCP and at GCP you have a 45% discount
• 5% of your clusters are in Azure and at Azure you have a 40% discount

In this scenario, you would configure the default rate card for your AWS clusters (the largest group) and you might define a cluster labeling protocol based on the cloud provider pricing plans applicable in your environment for the other two providers:

• rate-card=gcp-45
• rate-card=azure-40

Note: You do not need a rate card labeling convention for clusters that will use the default rate card because the default rate card will be used by any cluster that does not meet the conditions specified in the preceding policies.

Creating Rate Card Policies describes how RealTheory labels can be used to automate how rate cards are assigned to clusters.

See Also:
Installing RealTheory in a Cluster
Creating Access Control Policies
Creating Rate Card Policies