AKS · GitOps · DevSecOps
Secure GitOps Kubernetes Delivery Platform
An AKS delivery platform that reconciles Git-managed workloads, enforces admission policies, stages releases, and exposes rollout health.
5 min read
Kubernetes changes made directly in a cluster can drift from the intended configuration. Releasing a new version also needs a way to catch unsafe manifests and see how the rollout is behaving. I built this AKS platform as a self-directed final project connected to my coursework, bringing those controls into one Git-driven delivery path.
Argo CD reconciles the desired state, Kyverno checks resources at admission, and Argo Rollouts stages application updates. Prometheus, Grafana, and Alertmanager make sync status, rollout progress, and degraded health visible to an operator.
From Git change to observed release
- 01
Commit
A Kubernetes manifest change establishes the desired state in Git.
- 02
Reconcile
Argo CD compares Git with AKS and synchronizes the application resources.
- 03
Validate
Kyverno rejects resources that violate configured admission policies.
- 04
Release
Argo Rollouts progresses Canary or Blue/Green workloads through their configured steps.
- 05
Observe
Prometheus collects controller and workload metrics for Grafana dashboards.
- 06
Alert
Prometheus forwards unhealthy or OutOfSync application alerts to Alertmanager.
GitOps delivery path
- 1Commit desired state to Git
- 2Argo CD syncs manifests to AKS
- 3Argo Rollouts stages the release
Kyverno evaluated resources during Kubernetes admission. Argo CD tracked health and synchronization, while Prometheus and Grafana exposed the result of each change.
Architecture
Git holds desired configuration and AKS holds live resources. Argo CD reconciles the two. The Kubernetes API calls Kyverno for admission decisions, and Argo Rollouts controls progressive workloads. Prometheus collects platform metrics, Grafana queries them, and Alertmanager receives firing alert rules.
Git to AKS workload
4 connected stepsShowHide
- 01
Git repository
Stores desired Kubernetes manifests
desired state - 02
Argo CD
Detects drift and applies Git-managed state
sync request - 03
AKS API
Handles resource admission and live cluster state
admitted Rollout resource - 04
Argo Rollouts and workloads on AKS
Runs staged updates for Rollout resources
Policy and observability handoffs
4 service handoffsShowHide
AKS API
Requests an admission decision
Kyverno
Rejects privileged workloads and missing CPU or memory limits
Argo CD and Argo Rollouts
Expose health and rollout metrics
Prometheus
Stores time series and evaluates alert rules
Prometheus
Serves metric queries
Grafana
Shows synchronization, health, and rollout dashboards
Prometheus
Sends firing alert rules
Alertmanager
Receives and groups application health and sync alerts
What it does
GitOps handles drift while rollout controls slow down risky updates.
Argo CD watched Git-managed application configuration and reported whether AKS matched it. A direct cluster edit appeared as OutOfSync, and synchronizing restored the chosen Git state.
Argo Rollouts added Canary steps with pause and resume controls and a Blue/Green preview that could be promoted. Those controls let an operator inspect a release before exposing the new version through the active service.
Storage and state
Git, AKS, and Prometheus each own a different kind of state.
Git held the desired Kubernetes manifests and their version history. AKS held the live application resources and controller state. Argo CD compared those views to detect and correct drift.
Prometheus stored time-series metrics from Argo CD, Argo Rollouts, and exposed workloads. Grafana queried Prometheus to display health, sync status, rollout phase, traffic weight, and deployment progress.
Security and access
Kyverno rejected privileged workloads and missing resource limits.
Kyverno checked resources during Kubernetes admission. Policies blocked privileged containers and required CPU and memory limits, so a noncompliant manifest could not become a running workload.
I exercised the failure and recovery path by submitting a violating resource, inspecting the rejection, correcting the manifest, and synchronizing the compliant version. Kyverno made the policy failure visible at admission.
Delivery and operations
Argo CD reconciled Git changes and Argo Rollouts controlled exposure.
The delivery path began with Kubernetes configuration in Git. Argo CD detected the change, synchronized AKS, and surfaced application health. A manual cluster edit was treated as drift and corrected by returning to Git-managed state.
For Rollout resources, Canary steps could pause or resume progression. Blue/Green kept a preview version before promotion. Prometheus alert rules watched unhealthy and OutOfSync applications, and Alertmanager received firing alerts.
Testing and verification
Controlled drift, policy failures, rollout changes, and alerts exercised the path.
I verified Healthy and Synced states in Argo CD, changed a live replica count to produce OutOfSync drift, and synchronized the application back to its Git state. Deleting a resource exercised degraded-health monitoring and its alert path.
I submitted workloads that violated privilege and resource-limit policies to confirm Kyverno rejection, then corrected them. Canary pause and resume, Blue/Green preview and promotion, Prometheus metrics, and Grafana rollout panels were checked during updates.
Decisions and lessons
Separate controllers clarified ownership but added operational work.
Keeping Git as the desired-state source made unexpected cluster edits detectable and recoverable. Admission policies moved configuration checks into the deployment path, while progressive rollouts gave releases explicit observation and promotion points.
The tradeoff was more controllers to configure and monitor. Argo CD owned reconciliation, Kyverno owned policy, Argo Rollouts owned progression, and Prometheus with Grafana and Alertmanager owned the metrics and alert path. Each boundary was useful only when its status was visible during a failure.