Kubernetes resource canaries

Right-size with evidence, not hope.

Kapr progressively applies CPU and memory recommendations to live pods, observes each step, and persists only what production has proven safe.

$ kubectl get resourcecanary checkout
NAME       PHASE                              STEP
checkout   ValidationRunning                  25%

$ kubectl get rc checkout -w
checkout   PausedAtStep                       50%
checkout   ValidatedAwaitingPersistence      100%
checkout   Persisted                         100%
The contract

A controlled path from recommendation to rollout

Kapr uses Kubernetes' in-place Pod resize API to validate resource changes across a cumulative slice of the fleet.

CaptureManual or VPA recommendation
ResizeStable pod selection at each step
ObserveReadiness and optional metrics
ValidateFull fleet accepts the revision
PersistRide the next natural rollout
Why Kapr

Production safety without rollout churn

01

Progressive by default

Move through cumulative percentages such as 10 → 25 → 50 → 100, with deterministic pod selection and explicit pauses.

02

Metric-aware

Optionally query Prometheus for CPU throttling after each pause and roll back when the candidate breaches policy.

03

Deferred persistence

Validate against live pods now, then inject resources into the next pod-template update instead of creating a rollout solely for resources.

Works with your workloads

Deployments, StatefulSets, and Argo Rollouts

Use explicit Manual recommendations or consume VPA Target, LowerBound, or UpperBound values. Revision hashes make changes deterministic and supersession safe.

Explore the ResourceCanary API →

Built-in safeguards

  • Minimum ready pod requirements
  • Workload-update detection
  • Startup warm-up delay
  • Concurrent resize limits
  • Sticky failed-revision deny-list
  • Rollback to captured baseline