RATIVERA

Understand first. Decide next.

Connect an authorized AKS environment, inspect the available data, and review the reasoning before changing a workload.

One Problem at a Time · Episode 2 · 1:13

What happens when your monitoring data isn't good enough?

How gaps and short observation windows can prevent a supported recommendation.

Includes an earlier AKS test-workload assessment dated October 26, 2026, shown in the November 4 recording. The generic recommendation card is an illustration, not RATIVERA output. The CPU history threshold shown belongs to that assessment policy; memory protective increases can have different requirements.

English captions are burned into the video. An optional English caption track and transcript are also available. Use fullscreen for small screen details.

Collected versus usable evidence · Why a recommendation is withheld

Episode page & transcript · Download MP4

  1. 01

    Prepare Azure

    Check your account access, a running AKS cluster, Azure Managed Prometheus, and required retained metrics.

  2. 02

    Authorize discovery and evidence reads

    An Azure administrator grants the appropriate roles. Subscription discovery and per-cluster evidence access have separate scopes.

  3. 03

    Select workloads and review readiness

    Explicitly choose the intended workloads. A connected cluster is not proof of complete telemetry. Check collection status, timestamps, usable history, and the reason for any gap.

  4. 04

    Understand the recommendation

    Compare current and proposed requests, CPU and memory reasoning, and constraints. A withheld recommendation explains why a supported proposal cannot yet be made.

  5. 05

    Record a decision and use your change process

    Accepting records a decision. It does not apply a change. Your team remains responsible for reviewing, merging, and deploying changes.

Keep the distinctions clear.

Discovered does not mean selected. Collected data does not necessarily mean usable evidence. Acceptance does not mean deployment. A deployment verification describes the cluster at the time checked; it is not a promise of continuing drift detection.

Read about evidence readiness · Understand decisions

Connect Azure. Work with Git. Keep control.

Azure connections provide the reviewed resource and monitoring access. Supported Git connections link the right repository and source files. Change Requests help organize supported proposed edits for review.

Permissions, source mapping, plan eligibility, and execution availability must be confirmed for the environment. Your team reviews, merges, and deploys changes. A merge alone does not prove deployment; application verification compares observed Kubernetes configuration at the time checked.

Git workflow and safety · Azure permissions