Skip to content
GitHub stars

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.

Learn more about Infrastructure as Data →

Architecture Overview

Your Database
node_configs
acme-corpacme.com✓ active
beta-incbeta.io✓ active
Kubernetes Cluster
📋
LynqHub
Syncs every 30 seconds
Click to view YAML
📄
LynqForm
Click to view YAML
LynqNode CRs (Auto-created)
🏢
acme-corp
🏢
beta-inc
Kubernetes Resources
Deployacme-corp-api
Svcacme-corp-svc
Ingressacme-corp-ing
Deploybeta-inc-api
Svcbeta-inc-svc
Ingressbeta-inc-ing

💡 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.

1️⃣

Connect Your Data

Point to your MySQL database where node information lives. The operator reads active nodes automatically and syncs at your defined interval.

2️⃣

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.

3️⃣

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:

  1. Queries your database at regular intervals
  2. Filters rows where activate=true
  3. Creates/updates LynqNode CRs for each active row × template combination
  4. 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:

  1. Defines the infrastructure pattern for your nodes
  2. Uses template variables from database columns
  3. Supports custom functions like toHost(), sha1sum(), fromJson()
  4. 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:

  1. Applies resources in dependency order
  2. Waits for resources to become ready
  3. Detects and corrects drift
  4. Reports detailed status back to hub
  5. Manages resource lifecycle according to policies

Reconciliation Flow

Hub Controller

Triggers: Periodic sync interval, template changes, manual reconciliation

Process:

  1. Query database for active nodes
  2. Calculate desired LynqNode set (templates × active rows)
  3. Create missing LynqNodes
  4. Delete LynqNodes for deactivated/deleted rows
  5. Update hub status with aggregate metrics

Node Controller

Triggers: LynqNode creation/update, resource changes, periodic requeue (30s)

Process:

  1. Finalizer handling - Clean up resources before deletion
  2. Template evaluation - Render all templates with node data
  3. Dependency resolution - Build DAG, detect cycles
  4. Orphan cleanup - Remove resources deleted from template
  5. Resource application - Apply in topological order
  6. Readiness check - Wait for resources with waitForReady=true
  7. 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: Once vs WhenNeeded
  • DeletionPolicy: Delete vs Retain
  • ConflictPolicy: Stuck vs Force
  • PatchStrategy: apply vs merge vs replace

Learn more about Policies →

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:

bash
--hub-concurrency=3    # Default: 3
--form-concurrency=5   # Default: 5
--node-concurrency=10  # Default: 10

Optimized 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

💡 Infrastructure as Data

Understand the paradigm behind Lynq

Learn the Paradigm →
🚀 Quick Start

Get hands-on with a complete tutorial

Start Tutorial →
📐 Architecture

Deep dive into system design

Read Architecture →
📚 API Reference

Complete CRD specifications

View API Docs →
🎯 Use Cases

Real-world examples

Explore Examples →

Released under the Apache 2.0 License.
Built with ❤️ using Kubebuilder, Controller-Runtime, and VitePress.