How To Leverage RealTheory Labels For Scalability and Automation

RealTheory labels are similar to Kubernetes labels. They let you associate meaningful and relevant attributes with resources, so you can organize resources and select subsets of them to take action against.
RealTheory labels play a crucial role in automating workflows based on predefined criteria and conditions. This automation can:

• Enhance overall agility and scalability.
• Streamline operations and reduce manual intervention.
• Ensure consistency and accuracy across your environment.

Ways to Apply RealTheory Labels

You can apply RealTheory labels in two ways. Synthetic labels are recommended: they are the most flexible way to label your resources and are the easiest to maintain.

Where Labels Appear in the Console

RealTheory labels appear on an object's INFO tab, in the Labels section in two groups:

Labels in the first group are read-only in the Console. Labels under the RealTheory synthetic header can be managed from the Console.
Note: Labels applied through the Collector deployment YAML appear in the first group, alongside Kubernetes labels, not under the RealTheory synthetic header.

Where You Can Use Labels

You can use both kinds of RealTheory labels anywhere label selectors are supported, including the policies described in the examples below.
RealTheory labels are associated with objects only within the RealTheory application. RealTheory does not alter any labels in your cluster.

Changing Labels

Your labeling needs can change due to organizational restructuring, infrastructure updates, or new requirements for configuration and observation. To update your labels:

• Synthetic labels: edit or delete them in the Console. See Managing RealTheory Synthetic Labels.
• Labels applied through the Collector: update and re-apply the Collector deployment YAML with the appropriate label changes. You do not need to redeploy any infrastructure.
  Note: You cannot use a synthetic label to change the value of a label applied through the Collector. A synthetic label with the same key as an existing Collector label is rejected as a duplicate key.

Developing a Labeling Protocol — Practical Examples

To leverage the full power of RealTheory labels, design, implement, and enforce a labeling protocol. A consistent, clear protocol helps users configure, monitor, and troubleshoot across the labeled resource sets relevant to their organizational function.

Using Labels to Manage Access Control Policies

Scenario: Your organization has the following situation:

• You have four clusters: Clusters 1, 2, 3, and 4.
• Four teams need cluster access: Teams Blue, Red, Yellow, and Green.
• Team Blue manages cluster 1, Team Red manages cluster 2, and 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.

Labeling protocol: You might define a cluster labeling protocol based on team membership:

• team=blue
• team=red
• team=yellow
• team=green

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

Using Labels to Manage Rate Card Assignments

Scenario: Your organization has the following pricing plans:

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

Labeling protocol: Configure the default rate card for your AWS clusters (the largest group). For the other two providers, you might define a cluster labeling protocol based on their pricing plans:

• 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.

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

Using Labels to Manage Optimization Strategies

Scenario: You want to align resource optimization strategies with the nature and purpose of your workloads across different clusters:

• Your development and staging clusters prioritize cost savings over performance
• Your production clusters must prioritize performance and stability
• Your shared services clusters benefit from a balanced approach

Important: RealTheory always recommends cluster and workload configurations that meet baseline compute needs. The profile strategy influences resource allocation changes while respecting performance needs.

Labeling protocol: You might define a cluster labeling protocol based on optimization strategy:

• optimization-strategy=cost
• optimization-strategy=performance

Note: If you configure the default Optimization policy to use the balanced optimization profile, you do not need to define a label protocol for clusters that follow a balanced optimization strategy—clusters that do not have an optimization-strategy label will automatically use the balanced profile.
Learn more: Creating an Optimization Policy describes how RealTheory labels can be used to automate optimization strategies.

See Also:
RealTheory Synthetic Labels Explained
Managing RealTheory Synthetic Labels
Installing RealTheory in a Cluster
Creating Access Control Policies
Creating Rate Card Policies
Creating Optimization Policies