talos (internal)

Internal / not in current user CLI help

1ctl talos is internal platform-operator documentation. It was not present in the current user-facing 1ctl --help verified for v0.8.3. Application developers should not use this page for app deployment workflows.

1ctl talos manages the configuration of Satusky’s cluster nodes, which run Talos Linux — an immutable, API-driven operating system designed for Kubernetes.

Who needs this: Platform engineers managing the underlying infrastructure. If you’re deploying applications, you don’t need these commands. They operate on the nodes your workloads run on, not the workloads themselves.

Talos is not traditional Linux

Talos has no SSH daemon, no shell, and no package manager. The entire OS is read-only except for a small set of configuration paths. You configure a Talos machine by sending it a machine configuration document via the Talos API — and that’s it. Every configuration change, from network settings to Kubernetes node role, happens through that API.

1ctl talos is a wrapper around that workflow. It generates valid machine configurations using Satusky’s cluster parameters, applies them to specific machines, and lets you inspect configuration history and current network state.

Under the hood, machine state is discovered and communicated via SideroLink — a WireGuard-based overlay mesh that connects every node back to Satusky’s management plane, even before Kubernetes is running on the node. Configurations are versioned in the talos_configurations table and managed by the TalosConfigService.

Commands

1ctl talos generate

1ctl talos generate \
  --machine-id <id> \
  --cluster-name <name> \
  [--role worker|controlplane] \
  [--output <file>]

Generates a Talos machine configuration document for a specific machine. The output is a YAML document that can be reviewed, then applied with 1ctl talos apply.

Flags

Flag	Default	Description
--machine-id <id>	required	The machine ID to generate configuration for.
--cluster-name <name>	required	Name of the cluster this machine will join.
--role worker|controlplane	worker	Node role. controlplane nodes run the Kubernetes control plane components. worker nodes run workloads.
--output <file>	stdout	Write the generated config to a file instead of printing to stdout.

# Generate a worker config, review it
1ctl talos generate \
  --machine-id mach_abc123 \
  --cluster-name prod-kul-1 \
  --role worker \
  --output worker-config.yaml

# Generate a controlplane config
1ctl talos generate \
  --machine-id mach_def456 \
  --cluster-name prod-kul-1 \
  --role controlplane \
  --output controlplane-config.yaml

Review the generated YAML before applying it. Pay particular attention to network interface configuration and the cluster endpoint address — these are the most common sources of misconfiguration.

Backend: POST /v1/cli/talos/generate

---

1ctl talos apply

1ctl talos apply --machine-id <id> --config-file <path>

Applies a Talos configuration file to a machine. The machine fetches the configuration, validates it, and if valid, applies it and reboots into the new configuration.

This is a disruptive operation. The machine reboots as part of applying the configuration. For a Kubernetes worker node, this causes pods to be evicted and rescheduled on other nodes. For a controlplane node, this temporarily reduces control plane availability — do not apply to multiple controlplane nodes simultaneously.

Flags

Flag	Description
--machine-id <id>	required — The machine to apply the configuration to.
--config-file <path>	required — Path to the Talos machine configuration YAML.

# Apply configuration to a worker node
1ctl talos apply \
  --machine-id mach_abc123 \
  --config-file worker-config.yaml

Example output:

Applying configuration to mach_abc123...
Configuration validated.
Machine is rebooting into new configuration.
This may take 2-5 minutes.

Backend: POST /v1/cli/talos/apply

---

1ctl talos history

1ctl talos history <machine-id>

Shows the configuration change history for a machine: which configuration versions were applied, when, and by whom. Configurations are stored in the talos_configurations table with full version history.

1ctl talos history mach_abc123

Example output:

VERSION  APPLIED AT             APPLIED BY         ROLE    CLUSTER
4        2026-04-27T10:00:00Z   [email protected]      worker  prod-kul-1
3        2026-04-01T08:30:00Z   [email protected]     worker  prod-kul-1
2        2026-03-15T14:22:00Z   [email protected]     worker  prod-kul-1
1        2026-03-01T09:00:00Z   [email protected]     worker  prod-kul-1

Backend: GET /v1/cli/talos/history/{machineID}

---

1ctl talos network

1ctl talos network <machine-id>

Returns the current network configuration and interface state for a machine. This includes IP addresses, interface names, routes, and whether the SideroLink WireGuard tunnel is active.

1ctl talos network mach_abc123

Example output:

Machine:  mach_abc123
Hostname: node-kul-3

Interfaces:
  eth0   192.168.1.101/24  UP    (primary interface)
  eth1   10.0.0.15/24      UP    (cluster network)
  siderolink  fd00::1/128  UP    (management tunnel)

Routes:
  default via 192.168.1.1 dev eth0
  10.0.0.0/24 dev eth1

SideroLink tunnel: active

Backend: GET /v1/cli/talos/network/{machineID}

Safe practices

One node at a time. When rolling out configuration changes across a cluster, apply to one node, wait for it to rejoin the cluster and reach Ready state (verify with kubectl get nodes), then proceed to the next. Never apply to all nodes simultaneously.

Controlplane changes carry more risk. A three-node controlplane can tolerate one node being down (etcd needs a quorum of two). A single-node controlplane has no tolerance — it will be briefly unavailable during the apply/reboot cycle.

Generate → review → apply. Always generate a config and review the YAML before applying it. The --output flag on talos generate makes this easy. Talos validates the config before rebooting, but syntactic validity is not the same as correct network or endpoint configuration.