v0.8.0

Tue, 26 May 2026 00:00:00 +0000

Three components ship in this release: rollout-controller v0.8.0, rollout-dashboard v0.8.0, and openkruise-controller v0.4.0.

rollout-dashboard v0.8.0

The dashboard has been substantially reworked since v0.7.7.

Multi-cluster support. A hub dashboard now fans out to spoke dashboards running in remote clusters. All rollouts across all registered clusters are visible from a single URL. Spoke dashboards handle their own cluster’s API calls; the hub aggregates.

OIDC authentication. The dashboard integrates with oauth2-proxy’s extAuth mode. Traffic goes through an authenticating proxy and the dashboard receives the verified identity.

Applications view. A new /apps page groups rollouts into logical applications and shows fleet-wide status at a glance. Drill into an application and you get a version lifecycle Gantt showing when each version was active across environments, with range presets (24h / 7d / 30d / all).

Environments view. /envs shows all environments as stacked sections, each listing every rollout and its current state. Drills down to a per-environment activity timeline.

Activity feed. /activity is a chronological deployment timeline across the whole fleet, filterable by environment, application, and status.

Command palette. ⌘K / Ctrl+K opens a command palette for jumping to any rollout, application, environment, or namespace. It is wired site-wide and visible from every page.

Rollout overview redesign. The main rollout view is the most-used page in the dashboard and it got a full overhaul. The deployment pipeline card shows each canary step with test results inline. Current version, bake status, and stuck detection sit at the top. Resources (pods, replicasets) and schedule status are surfaced without leaving the page. When the controller is holding a deployment after a failed health check, a warning banner appears with the option to retry or skip the failed step.

Datadog APM links. Tests that emit a trace ID get a direct link to the Datadog APM trace viewer next to the existing Logs and CI buttons.

rollout-controller v0.8.0

Retry modes. Setting the rollout.kuberik.com/retry annotation now accepts a mode value: retry re-runs the failed step, skip advances past it. Previously only retry was supported.

New conditions. Two new conditions are set on rollouts in blocked states:

BakeFailureDisabled — set when bake failure detection has been explicitly disabled.
DeploymentBlocked — set when a deployment cannot proceed due to a gate or schedule constraint.

Better failure detection. The controller now prefers Stalled=True as the primary failure witness when evaluating health check conditions, falling back to the newest condition only when Stalled is absent. This reduces false negatives when a check briefly reports healthy before settling into a failed state.

Health status messages. Status messages are enriched with more context. Bake time is now measured correctly in edge cases.

Kustomization health fix. Resources that no longer exist are skipped during kustomization health evaluation rather than returning an error that blocked the reconciliation loop.

Manual deployment requeue. Manual deployments where bakeStatus is Deploying are now requeued correctly instead of being left waiting for an external event.

openkruise-controller v0.4.0

Robust retries. The retry mechanism has been rewritten to handle edge cases that caused the controller to get stuck. Retry side-effects are now applied unconditionally at the start of a retry cycle, and step-ready-at timestamps are preserved so bake time is measured from the right point.

Additional fixes in this release:

Bake time is now respected when a rollout step has no tests.
Test creation is blocked and running jobs are cancelled when KuberikBakeHealthy=False is set.
The same-second failure edge case in stalledBefore is treated correctly as a pre-retry state.
The timeout machinery is skipped entirely when a rollout step is already Healthy or Completed, preventing spurious requeues.
Jobs are deleted asynchronously to avoid blocking the reconciliation loop.
A RolloutTest can no longer be cancelled after the rollout has already continued past its step.

Introducing Kuberik

Mon, 27 Apr 2026 00:00:00 +0000

After almost ten years of watching CD tooling change without the underlying model changing, I built Kuberik. It is a Kubernetes-native controller that runs inside your cluster and owns the full delivery journey as declarative, pluggable resources, from release detection through canary rollouts, health checks, environment promotions, and automatic rollback.

The state so far

I have used Jenkins, GitLab CI, Drone, GitHub Actions over the years. Each generation brought better interfaces and tighter integrations. But the way teams implement continuous delivery stayed exactly the same: you write the steps yourself. The canary, the health checks, the rollback trigger, the promotion conditions. Each of those is bespoke code that lives in your pipeline, is tested by nobody, and fails in production in ways that are hard to trace.

Pipelines also model only the happy path. When something goes wrong or you need to act outside the normal sequence, the pipeline has nothing for you. Roll back a single environment without touching others. Pin a version during an incident. Force a deploy past the gates. None of this is exceptional, it is routine, and it ends up as more bespoke code on top.

GitOps with Flux or ArgoCD addresses part of this. They reconcile a desired state from git, but they do not orchestrate how that state gets there. A change merged to main syncs to every cluster at once. There is no built-in way to roll changes out progressively across environments. Argo Rollouts and Flagger handle the mechanics of a single rollout but nothing beyond. Teams end up stitching all of these together with CI pipeline glue, and the glue becomes the thing nobody wants to touch. There are more complete solutions, but they come with centralized infrastructure, external dependencies, and operational overhead that most teams would rather avoid.

How Kuberik works

Kuberik is a delivery controller, not a stack of scripts. It watches your container registry for new image releases. When a new version appears, it takes over. It runs the canary, checks health, promotes across environments, and rolls back if something goes wrong. Every step is a declarative, pluggable Kubernetes resource. Canary rollouts, health checks, environment promotions, and rollback are not logic you write into a pipeline. They are resources you declare, the same way you would declare a Deployment or a Service. The controller takes it from there.

The design encodes a set of behaviours that are easy to get wrong when you reimplement them in a script. Each environment is autonomous, so rollback is always a local operation. Kuberik will not roll out into an unhealthy environment. It will not undo a manual deployment made during an incident. It processes versions sequentially so every version gets properly verified. You can attach test hooks at any stage of the rollout. You can force deploy a specific version when you need to bypass the gates entirely. You can define deployment windows and Kuberik enforces them. Getting all of this right in a CI pipeline means writing and maintaining the logic yourself, in every pipeline, across every team. With Kuberik, the model scales across every service: written once, reused everywhere.

Deploying to production should just work. Check out how Kuberik works and the getting started guide.

For the story behind Kuberik, see Building Kuberik on my personal blog.