How Kubestead Works
A deployment controller that lives inside your cluster and makes the rollout decision — automatically. No operator in the loop, no runbook to follow.
In-cluster. No external control plane.
The Kubestead controller runs as a Deployment inside your cluster. It watches Kubernetes events, queries your metrics backend directly, and issues promote or rollback commands via the Kubernetes API — no traffic ever leaves your cluster boundary to reach a Kubestead control plane. We do not sit in the data path.
Canary Traffic Split
Kubestead routes progressive percentages of live traffic to your new version. The traffic split progresses only when metrics pass — it never advances blindly.
canarySteps:
- setWeight: 1
- pause: {duration: 1m}
- setWeight: 5
- pause: {duration: 2m}
- setWeight: 12
- pause: {duration: 5m}
- setWeight: 25
- pause: {duration: 10m}
- setWeight: 50
- pause: {duration: 10m}
- setWeight: 100Metric Analysis
The controller queries your metrics backend at every evaluation interval. Supported backends: Prometheus (PromQL), Datadog, custom HTTP endpoints.
Each analysis window evaluates error rate, p99 latency, and any custom SLO metric you define. The decision is made at the end of each interval.
# error-rate-analysis template
apiVersion: kubestead.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: error-rate-analysis
spec:
metrics:
- name: error-rate
provider:
prometheus:
query: |
sum(rate(http_requests_total{
status=~"5..",
service="{{args.service}}"
}[2m])) /
sum(rate(http_requests_total{
service="{{args.service}}"
}[2m]))
successCondition: result[0] < 0.003
failureLimit: 1
Automated Verdict
The controller evaluates success threshold vs error threshold at every analysis gate. If metrics pass, traffic advances to the next canary step. If the error budget burn rate crosses the policy threshold, rollback fires immediately.
Rollback speed: the controller scales down the canary Deployment to 0 replicas, patches the traffic weight back to 100% stable, and the full operation completes in under 90 seconds on average.
errorBudgetPolicy:
burnRateThreshold: 2.0
windowMinutes: 60
# 2× burn rate over 60m => gate fires
rollbackPolicy:
autoRollback: true
maxRollbackDuration: 90s
scaleDownCanary: true
waitForPodsReady: true
notifySlack: true
notifyPagerDuty: false
# PD silent = no 3AM page requiredCommon questions
Argo Rollouts is an open-source CNCF project that provides the traffic-splitting primitives. Kubestead builds on those primitives and adds the error budget burn rate layer, multi-step analysis templating, and a managed controller that doesn't require you to operate the CRD infrastructure yourself. Think of it as "Argo Rollouts with the SRE policy engine already embedded." Kubestead is not a replacement for Argo CD (GitOps sync) or GitHub Actions (CI pipeline) — it owns only the live rollout phase, after the image is built and the manifest is applied.
No. Kubestead works natively with Kubernetes Deployment rolling updates without a service mesh. If you have Istio or Linkerd, it can leverage them for fine-grained traffic shaping — but they are optional. Basic canary splitting uses ReplicaSet weight ratios, which requires no additional infrastructure.
By default, Kubestead treats a metrics backend failure as an indeterminate result — it pauses the rollout at its current traffic split and alerts you via Slack. It does not promote. You configure the inconclusivePolicy field to specify whether to pause, fail, or roll back on metrics unavailability.
Every rollback creates an AnalysisRun resource with the full metric snapshot at the time of the rollback decision. Run kubectl describe analysisrun <name> to see the exact metric values, the threshold that was crossed, the evaluation timestamp, and the controller decision log.
Yes. The Rollout resource is a standard Kubernetes CRD — you add it to your Helm chart like any other resource. The Kubestead controller watches for it and takes over the rollout lifecycle. There is no Helm hook required.
Multi-cluster orchestration is available in the Scale tier today — it allows you to run coordinated rollouts across multiple clusters with shared analysis. The single-controller-per-cluster model is already stable; the Scale tier adds the cross-cluster coordination layer on top.