> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getlilac.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How the Operator Works

> Understand the Lilac GPU operator architecture, its 30-second sync loop with the control plane, and how it manages inference pods on idle GPUs.

The Lilac GPU operator is a Kubernetes controller that runs inside your cluster. It discovers idle GPUs, communicates with the Lilac control plane, and manages inference workload pods — all without touching your existing workloads.

## Architecture

```mermaid theme={null}
graph LR
    A[GPU Operator] -->|Discovers idle GPUs| B[Your Cluster Nodes]
    A -->|Syncs state every 30s| C[Lilac Control Plane]
    C -->|Assigns workloads| A
    A -->|Creates/drains| D[vLLM Inference Pods]
    E[Inference Users] -->|API requests| C
    C -->|Routes traffic| D
```

## The Sync Loop

The operator runs a reconciliation loop every **30 seconds** for each GPU pool:

<Steps>
  <Step title="Schedule check">
    Is the current time within the pool's availability window? If not, the operator skips this pool.
  </Step>

  <Step title="GPU discovery">
    The operator scans nodes matching the pool's `nodeSelector` and counts available GPUs, distinguishing between your pods and Lilac inference pods.
  </Step>

  <Step title="Capacity calculation">
    Applies your configured limits — `maxGPUs` and `maxUtilizationPct` — to determine how many GPUs Lilac can use.
  </Step>

  <Step title="Control plane sync">
    Sends a full state snapshot (node inventory, running workloads, draining workloads) to the Lilac control plane and receives back a desired state with workload assignments.
  </Step>

  <Step title="Reconcile">
    Creates new inference pods for assigned workloads, drains pods that are no longer needed, and cleans up any pods that have drifted from the desired spec.
  </Step>
</Steps>

## Connection States

The operator maintains a connection state with the control plane:

| State         | Meaning                                                                    |
| ------------- | -------------------------------------------------------------------------- |
| **Connected** | Syncing normally                                                           |
| **Degraded**  | Sync failed, retrying on next cycle                                        |
| **Draining**  | Disconnected for over 10 minutes — gracefully shutting down inference pods |

A single successful sync returns the operator from Degraded to Connected.

## Preemption

When your workloads need GPUs back, the operator handles it automatically. See [Preemption](/suppliers/operator/preemption) for details on how this works.

## What Gets Deployed

When the control plane assigns a workload, the operator creates a pod running [vLLM](https://docs.vllm.ai/) — a high-performance inference engine. Each pod:

* Runs a single model
* Uses one or more GPUs on a single node
* Is labeled and managed by the operator
* Is automatically cleaned up when no longer needed

Your existing pods, namespaces, and resources are never modified.