Case Study

Kubernetes Deployment and Release Management

A continuous delivery platform for Kubernetes that compares live clusters with Git and rolls out reviewed changes.

This platform answers two questions for an operator. It shows what is meant to run, and what is actually running in Kubernetes. The platform compares the cluster against what Git holds, shows the difference and records how far a requested rollout has got.

That comparison keeps going after a release. A change made outside the release process shows up as drift, which the controller then reports or corrects, depending on the team's policy.

The challenge

Creating a resource does not prove it is ready for use. Other resources may depend on it. Their own rollout then has to wait for it. Teams also need a say over which destinations they can change, and over when those changes are allowed to run.

We tied these decisions to the rollout itself. A detected difference can lead to a review or to an automatic sync. Either route has to respect the configured rules and show its progress to the operator.

What we built

Each application record holds the destination, the desired state, the health, the sync status and the deployment history. Git events or scheduled checks set off a fresh comparison. An operator can study that result before asking for a sync through the web interface, the command line or the API.

Automatic sync, removal of unused resources and drift correction can all be switched on. Before it acts, the controller checks the project rules and the deployment windows. A closed window can block further syncing, yet an operator can still stop an operation that is under way.

Templates cover workloads that repeat across destinations. Environment lists, registered clusters and configuration files supply the entries that the application records are built from.

Separate rendering from cluster changes

Manifest rendering accepts plain configuration, Helm, Kustomize and other supported renderers. Cached output can be reused when the inputs have not changed. Rendering and cluster writes run as separate components. Their jobs and their credentials can then be handled on their own.

Go controllers keep separate queues for refreshing state, running operations and handling project changes. A request is saved on its application record, and the controller adds progress and results there as the work goes on. An operator can come back to that record once the operation ends.

Wait for readiness between deployment waves

Preparation, the main deployment, follow-up work and failure handling each have their own phase. Numbered waves set the order inside a phase. The controller applies one wave at a time. It waits for that wave's resources to report healthy before it moves on.

Health rules differ by resource kind, and teams can add custom rules for statuses that need special reading. The gate only helps when those rules match the workload's real readiness.

Keep access and operational records connected

Project rules limit the destinations and the resource types, with Casbin enforcing role-based access. Users sign in through local accounts or OIDC. Kubernetes holds the application records, while Redis caches derived views such as resource trees.

Notifications and Prometheus metrics open up activity for a closer look. Inside a shared installation, permissions stay administrative boundaries rather than hard walls. Cluster credentials and secret management need their own controls.

Project success

An operator can move from a config difference to a rollout request, follow its ordered phases and read the recorded outcome. Templates apply the same setup across environments. Health gates make dependencies part of the run itself.

The application record, the history and the metrics stay on hand when a sync fails or drift turns up. A successful configuration write is not treated as proof that every workload is ready. The platform keeps those controls and records in the operator's hands.

Technology stack

Controllers

Go, Kubernetes client-go

Frontend

React, TypeScript

Interfaces

gRPC, REST

Configuration

Git, Helm, Kustomize

Access and observation

Casbin, OIDC, Prometheus

Derived-state cache

Redis

Recognize the pattern?

If one of these looks like your situation, the discovery call is where we find out how close.