Build in progress. This page will be updated with the repository link, architecture diagram and demonstration recordings on completion.
The problem
Most Kubernetes deployments happen through a mix of kubectl, CI scripts and manual intervention. The result is a cluster whose real state nobody can reliably describe, where changes leave no audit trail and rollback means remembering what was there before.
What I’m building
A delivery platform where git is the only deployment mechanism, and releases roll out progressively under service mesh traffic control.
GitOps delivery
ArgoCD in an app-of-apps configuration — a single root Application manages every workload. Git holds the declared state; the cluster is continuously reconciled to match it.
Progressive delivery
New versions deploy alongside the current one and receive a 10% traffic share via Istio VirtualService weights. Promotion is a one-line change in git. Rollback is a revert.
Targeted testing
Header-based routing (x-canary: true) lets testers reach a new version specifically, before any production traffic is shifted onto it.
Observability
Kiali renders the live service graph and mTLS status; Grafana tracks latency and error rate per version, so promotion is a data decision rather than an optimistic one.
The part that matters most
Reconciliation, not deployment.
Scaling a deployment directly against the live cluster — kubectl scale deployment api --replicas=5 — is reverted within seconds. Git says otherwise, so the controller puts it back.
That usually gets described as a reliability feature. It is also a security control: an unauthorised change to production undoes itself, automatically, with nobody paged.
Design decisions
k3s rather than managed Kubernetes. CNCF-conformant, identical APIs, far lower resource floor. Every manifest is portable to EKS or AKS unchanged.
Separate application and GitOps repositories. CI publishes an image and updates a tag; ArgoCD watches only the GitOps repo. A compromised application pipeline cannot rewrite cluster configuration.
Istio for traffic management rather than a dedicated deployment controller. Weighted and header-based routing come from one mechanism — and the same layer later enforces mTLS and authorization.
Notes from the build
A traffic split that was configured correctly and silently did nothing, because a Kubernetes Service port was named web instead of http. Istio infers protocol from the port name; anything unrecognised falls back to plain TCP, and L7 routing rules cannot apply to traffic the mesh treats as an opaque byte stream.
No error. No warning. Configuration accepted, control absent. Those are the expensive ones.