Machines

Machine management is the bridge between user-owned hardware and Satusky deployments. It is broader than renting capacity: the target system lets users discover, claim, group, observe, operate, and eventually decommission machines through one coherent control plane.

Current source-of-truth model

Concern	Best source of truth
machine discovery and management reachability	SideroLink
OS-level lifecycle and pre-Kubernetes state	Talos API
schedulability, capacity, allocatable resources	Kubernetes Node API
placement metadata	Kubernetes node labels
ownership, billing history, audit trail	backend database
live host/workload telemetry	Kubernetes metrics, Prometheus, and Talos where needed

SideroLink and Talos

SideroLink gives Talos machines a stable management address over a WireGuard overlay, including when machines sit behind NAT or firewalls. That makes discovery and lifecycle operations possible before ordinary app networking is useful.

Talos machine
  └── SideroLink identity / overlay address
        └── Satusky control plane

Current implementation state

The backend already includes rich primitives: SideroLink discovery, registration tokens, Talos status/resources, machine details, labels, logs, events, decommissioning, and live WebSocket updates. The current 1ctl machine surface is much narrower and mostly exposes inventory, availability, and billing history.

Target tenant-facing model

1ctl machine = fleet ownership and operations
1ctl deploy  = workload placement intent
Kubernetes  = scheduling substrate

Users should be able to:

discover and claim machines,
inspect readiness and health,
assign labels,
query machine pools,
drain / cordon / uncordon safely,
reboot / shut down through Talos-aware lifecycle commands,
monitor CPU, RAM, network, and machine events.

Labels and selectors

This is the strategic center of machine-aware deployment.

machines declare what they are
workloads declare what they need

Primitive	Home
label CRUD	`machine`
pool inspection	`machine query --selector ...`
workload placement request	`deploy --machine-selector ...`

The current deploy --machine-tag flag is a useful early form, but the durable abstraction is label selectors because selectors compose into production pools, GPU pools, compliance pools, canary subsets, and topology strategies.

Current gaps and target direction

Gap	Target
CLI does not yet expose the full discovery / claim / lifecycle flow.	First-class tenant fleet management.
Machine observability is backend-rich but CLI-thin.	`status`, `metrics`, `logs`, and `events` become normal commands.
Placement language is narrower than the intended model.	General selectors become the foundation.
SideroLink/Talos details risk leaking too far upward.	Keep them diagnosable but beneath a clean machine UX.