How Lynq Works
Lynq is a RecordOps platform that implements Infrastructure as Data for Kubernetes. It bridges your database and cluster with a three-component architecture that automates infrastructure provisioning based on database records.
Infrastructure as Data in Action
Lynq implements Infrastructure as Data through RecordOps—database records control infrastructure state. When you insert, update, or delete a row, infrastructure changes automatically. No YAML files, no CI/CD delays—just real-time infrastructure that follows your data.
Architecture Overview
💡 Interactive Demo
Click LynqHub and LynqForm to see the YAML configuration, or click database rows to toggle nodes on/off. Watch how Lynq automatically synchronizes Kubernetes resources with your database changes.
Three Simple Steps
Lynq implements Infrastructure as Data through a straightforward three-step process that eliminates manual infrastructure management.
Connect Your Data
Point to your MySQL database where node information lives. The operator reads active nodes automatically and syncs at your defined interval.
Define Your Template
Write one template describing what each node needs: deployments, services, ingresses, and any custom resources. Use Go templates with 200+ functions for flexibility.
Deploy Automatically
Every active node gets isolated infrastructure. Resources are created, updated, and cleaned up automatically as your data changes. Full drift detection and auto-correction included.
Core Components
LynqHub: Data Source Connection
LynqHub connects to your external database (currently MySQL) and periodically syncs node information.
Key Features:
- Configurable sync intervals
- Column-to-variable mappings
- Support for multiple templates per hub
- Automatic garbage collection when nodes are deactivated
What it does:
- Queries your database at regular intervals
- Filters rows where
activate=true - Creates/updates LynqNode CRs for each active row × template combination
- Automatically removes LynqNodes when rows are deactivated or deleted
LynqForm: Resource Templates
LynqForm defines the resource blueprint that gets applied to each node.
Key Features:
- Support for all standard Kubernetes resources (Deployments, Services, etc.)
- Go template syntax with 200+ Sprig functions
- Fine-grained policies (Creation, Deletion, Conflict)
- Dependency management between resources
- Cross-namespace resource support
What it does:
- Defines the infrastructure pattern for your nodes
- Uses template variables from database columns
- Supports custom functions like
toHost(),sha1sum(),fromJson() - Enables conditional logic and dynamic naming
LynqNode: Instance Representation
LynqNode represents a single node instance with all its resources.
Key Features:
- Automatically created by LynqHub controller
- Contains resolved resources (templates already evaluated)
- Tracks resource status (ready/failed/desired)
- Handles dependency ordering via topological sort
- Automatic orphan cleanup when templates change
What it does:
- Applies resources in dependency order
- Waits for resources to become ready
- Detects and corrects drift
- Reports detailed status back to hub
- Manages resource lifecycle according to policies
Reconciliation Flow
Hub Controller
Triggers: Periodic sync interval, template changes, manual reconciliation
Process:
- Query database for active nodes
- Calculate desired LynqNode set (templates × active rows)
- Create missing LynqNodes
- Delete LynqNodes for deactivated/deleted rows
- Update hub status with aggregate metrics
Node Controller
Triggers: LynqNode creation/update, resource changes, periodic requeue (30s)
Process:
- Finalizer handling - Clean up resources before deletion
- Template evaluation - Render all templates with node data
- Dependency resolution - Build DAG, detect cycles
- Orphan cleanup - Remove resources deleted from template
- Resource application - Apply in topological order
- Readiness check - Wait for resources with
waitForReady=true - Status update - Report ready/failed/desired counts
Key Features
Real-Time Synchronization
Changes in your database trigger automatic infrastructure updates within 30 seconds (default hub sync interval). This is Infrastructure as Data in practice: your database transaction becomes an infrastructure operation.
Drift Detection & Auto-Correction
Lynq continuously monitors resources and automatically reverts manual changes to maintain desired state.
Policy-Based Control
Fine-grained control over resource lifecycle:
- CreationPolicy:
OncevsWhenNeeded - DeletionPolicy:
DeletevsRetain - ConflictPolicy:
StuckvsForce - PatchStrategy:
applyvsmergevsreplace
Dependency Management
Define dependencies between resources using dependIds. Lynq automatically:
- Builds dependency graph
- Detects cycles (fails fast)
- Applies resources in correct order
- Waits for dependencies to be ready
Orphan Resource Cleanup
When you remove a resource from a template, Lynq automatically:
- Detects orphaned resources
- Respects
DeletionPolicy(Delete or Retain) - Adds orphan markers for retained resources
- Re-adopts resources if added back to template
Cross-Namespace Support
Create resources in any namespace using targetNamespace field. Lynq handles:
- Label-based tracking for cross-namespace resources
- Traditional ownerReferences for same-namespace resources
- Automatic cleanup regardless of namespace
Performance & Scalability
Controller Concurrency
Tune performance with concurrent reconciliation:
--hub-concurrency=3 # Default: 3
--form-concurrency=5 # Default: 5
--node-concurrency=10 # Default: 10Optimized Watching
- Event-driven architecture with smart predicates
- Only reconciles on meaningful changes (not status-only updates)
- 30-second requeue for fast status reflection
- Separate watches for same-namespace and cross-namespace resources
Large-Scale Support
- Works with 10 to 10,000+ nodes
- Efficient database queries with column filtering
- SSA for conflict-free updates
- Prometheus metrics for observability
Next Steps
Understand the paradigm behind Lynq
Learn the Paradigm →Get hands-on with a complete tutorial
Start Tutorial →Deep dive into system design
Read Architecture →Complete CRD specifications
View API Docs →Real-world examples
Explore Examples →