Automation Explained

RealTheory analyzes the CPU and memory usage of your workloads over time and generates right-sizing recommendations if the usage is not optimized. Automation applies those recommendations to your workloads for you, within the guardrails that you set.

Automation is opt-in. Automation is disabled by default and enabled by you. When you enable automation, RealTheory can make configuration changes within the scope and parameters of your automation profiles, including any default values that you have not changed. See Automation Opt-In Requirements Explained.

Note: Automation is currently in a limited Beta. If you do not see automation in your Console, see Why Is Automation Not Available in My Console?

Recommendations Are the Source of Every Change

A right-sizing recommendation describes the CPU and memory requests and limits that a workload needs, based on the workload's observed usage and its active Optimization Profile.

Every change that automation makes comes from a right-sizing recommendation. Automation does not create changes of its own. Automation makes a change to a workload within the guardrails of the Automation Profile that applies to the workload's cluster.

Recommendations that automation does not apply are left for you to review. To find the recommendations for a workload, see How To Find the Recommendations for a Given Cluster and Namespace.

A recommendation exists while the condition that created it exists, such as an under-provisioned or over-provisioned workload. After automation applies a change, RealTheory might raise a new recommendation against the workload's new state if the workload is still not optimized.

What Automation Changes

Automation changes the CPU and memory requests and limits of Kubernetes workloads, for example, Deployments, StatefulSets, and DaemonSets.

The Automation Profile Guardrails topic lists the guardrails that you can configure to control which recommendations automation applies.

How Automation Works

Automation follows a repeating workflow. You set up automation once, RealTheory applies the changes that its recommendations identify within the guardrails that you configured, and you review the results and adjust as needed.

Prepare your environment. Make a cluster automation-ready and turn on automation. See Automation Opt-In Requirements Explained for the full list of requirements for RealTheory to make changes.
Configure automation. Create at least one Automation Profile. The profile defines which workloads are eligible for automated changes, and the profile’s guardrails limit each change. For example, guardrails can control how large a change can be, how often automation can change a workload, and when automation can apply changes. See Automation Profiles Explained and Automation Profile Guardrails.
Assign the profile to the appropriate clusters. Assign the profile to clusters directly, through an Automation Policy that matches clusters by label, or as the default profile. Each profile and policy has an owner, whose cluster access limits which clusters the profile or policy applies to. See Automation Policies Explained and Automation Owners Explained. To check which profile applies to each cluster, see Automation Profiles Explained.
Let RealTheory apply changes. When RealTheory raises a right-sizing recommendation for a workload that is within the scope of an Automation Profile and in a cluster that the profile applies to, automation applies the recommended change to the workload's requests and limits, within the profile's guardrails. Automation can apply further changes to the same workload over time, as often as the profile allows, whenever RealTheory raises a new recommendation for the workload.
Observe the results. The Automation Dashboard shows the impact of the changes that automation applied over the period that you choose. Automation History lists the workloads that automation changed, and a workload's Timeline shows each change that automation applied to that workload.
Roll back a change if its result does not meet your needs. From a workload's Timeline, you can restore the values that existed before the latest change or before an earlier change. See Rolling Back an Automation Change.
Refine. Adjust the profile's guardrails, exclude workloads from automation, or add workloads to the profile's scope. Then review the results again.

Example

Scenario: You want RealTheory to right-size the workloads in your staging clusters.

What you do: You make the staging clusters automation-ready and turn on automation. You create an Automation Profile that covers Deployments and conservatively limits the size of each change, so that you can evaluate the effect of automation. You create an Automation Policy that applies the profile to clusters with the env=staging label.

What happens: The policy applies the profile only to clusters with the env=staging label, so automation applies recommendations to the Deployments in those clusters that fall within the profile's other guardrails. You review the results of the automated changes. One applied change does not suit a workload, so you roll back the change from the workload's Timeline. You also add the workload to the profile's exclusions, so that automation does not re-apply the change when RealTheory identifies the same resource allocation issue and raises a new recommendation for the workload.

What this means: You choose the clusters, workloads, and changes that automation can make, and you can roll back a change if its result does not meet your needs.

Where to Find Automation in the Console

Location	What you find there	Role required
Automation > Workloads	Automation Dashboard and Automation History	No role to view; sys_admin or automation_admin to roll back a change
Settings > Automation > Workloads	Automation Profiles, Automation Policies, and Automation Profile Assignments	sys_admin or automation_admin