RealTheory synthetic labels are labels you add, edit, and delete directly in the RealTheory Console. Use them to label objects from a cluster down to a single Pod, and to apply a label to many subordinate objects in one step.
You can leverage synthetic labels anywhere label selectors are supported, for example, in access control policies, rules, and search. Synthetic labels exist only within the RealTheory application; RealTheory does not add, change, or remove any labels in your cluster.
Where synthetic labels appear
You can manage synthetic labels on an object's INFO tab, in the Labels section, under the RealTheory synthetic header. Labels listed above the header are read-only in the Console. For a comparison of different label types, see How To Leverage RealTheory Labels For Scalability and Automation.
How propagation works
When you add, edit, delete, or clear synthetic labels, you choose where the change applies: the current object, its subordinate objects, or both. Propagating to subordinate objects is optional; by default, a change applies to the current object only.
Propagation follows these rules:
- Propagation goes down only. A change never applies to objects above the current object.
- The current object determines the options. You can propagate only to the object types that are subordinate to the object you start from (see the table below).
- You can choose all subordinate objects or a subset. If you choose a subset, the change applies only to the object types you select. For example, if you start from a cluster and select only Namespaces, the label is added to the cluster's Namespaces but not to the Deployments or Pods in those Namespaces.
- Each object's label is independent. After a label is propagated, you can edit or delete it on an individual object without affecting the object it was propagated from or any other object.
| Current object | Subordinate object types you can propagate to |
|---|---|
| Cluster | Nodes, Namespaces, Deployments, ReplicaSets, DaemonSets, StatefulSets, Services, Pods |
| Node | Pods |
| Namespace | Deployments, ReplicaSets, DaemonSets, StatefulSets, Services, Pods |
| Deployment | ReplicaSets, Pods |
| ReplicaSet | Pods |
| DaemonSet | Pods |
| StatefulSet | Pods |
| Service | Pods |
| Pod | None |
Example: You add team=payments to a Namespace and propagate it to a subset of subordinate objects, selecting Deployments and StatefulSets. The Namespace and its Deployments and StatefulSets receive the label. The ReplicaSets, Pods, and other subordinate objects in the Namespace do not receive the label.
Note: Changes to the current object take effect immediately. Changes propagated to subordinate objects can take longer, depending on how many objects are affected.
Confirm that a label was propagated
Open the INFO tab of a subordinate object, or filter or search using a label selector such as team=payments.
Working with synthetic labels
The following sections describe how synthetic labels interact with other labels on an object and with the policies and rules that target it.
Duplicate keys
An object cannot have two labels with the same key. What happens when you add a label with a key that already exists on the object depends on the origin of the existing label:
| Existing label | Result |
|---|---|
| RealTheory synthetic label | The Console warns you that the existing value will be replaced. When you apply the change, the new value replaces the existing one. |
| Kubernetes label | The Console shows a duplicate key error; the label cannot be added. |
| RealTheory label applied through the Collector deployment YAML | The Console shows a duplicate key error; the label cannot be added. |
Updating a key
When you update the key in a synthetic label, the Console asks whether to remove or keep the original label. If you remove the original, the scope you choose applies to both removing the original and adding the new label. If you keep the original, the scope applies only to adding the new label, and the original stays unchanged on every object.
Updating Kubernetes labels
You cannot use a synthetic label to override the value of a Kubernetes label. To change a Kubernetes label, update the object's manifest or use the kubectl label command.
Updating RealTheory labels applied through the Collector deployment YAML
You cannot use a synthetic label to override the value of a label applied through the Collector deployment YAML. To change a label applied through the Collector, update and re-apply the Collector deployment YAML.
Labels, policies, and rules
Because policies and rules can use synthetic labels to target objects, adding, editing, or deleting a synthetic label can change which policies and rules apply to an object. Before you change a label, check which policies and rules reference it.
See Also
Managing RealTheory Synthetic Labels
How To Leverage RealTheory Labels For Scalability and Automation
How To Use Label Selectors to Identify Resources