Live architecture models track kubernetes deployments for drift detection
Live Architecture Models for Cloud-Native Architecture-as-Code: Early Results from Kubernetes Conformance Checking
Software Engineering
Summary
Kubernetes systems can sometimes run differently than originally planned due to changes or errors, which is called infrastructure drift. The authors explored a way to keep the system’s actual state and its intended design connected using editable models that reflect live Kubernetes data. Their tool periodically checks for inconsistencies without automatically fixing them, helping developers spot where the system drifts from its intended setup. They tested this approach on a few example applications and found it is feasible for certain Kubernetes configurations.
What this means in practice
- •For cloud platform engineers: Detect mismatches between Kubernetes deployment intentions and live cluster state to improve reliability and debugging.
- •For devops teams: Use synchronized textual and graphical models to visually inspect Kubernetes configuration drifts without disrupting production environments.
Authors
Denis Mamatin, Andrey Salov
Abstract
Infrastructure drift can separate a running Kubernetes system from its documented architectural intent. This paper investigates live architecture models: editable architectural representations connected to selected runtime facts through explicit correspondences and recurring conformance checks. The approach is instantiated through an Archer-specific subset of Kubernetes Deployment Language (KDL) and Archer, a VS Code prototype with synchronized textual and graphical views. Snapshot recovery extracts selected Kubernetes facts into KDL; periodic and on-demand read-only checks report model-cluster inconsistencies without enforcing or repairing deployment state. We assess feasibility on three feature-selected Kubernetes example applications under an author-defined protocol, reporting precision and recall for snapshot recovery and selected inconsistency detection. Recovery scores can be reproduced from saved ground-truth and recovered models; detection uses a documented manual perturbation protocol. The results support feasibility within the evaluated KDL scope. They do not establish comparative superiority, detection of arbitrary production drift, scalability, or developer benefit. Storage coverage and ingress-host representation/default handling remain limitations.