Applying Kernel Settings on Talos Linux via Declarative Machine Config

Apply a kernel sysctl via Talos machine config

If you need to change a kernel parameter such as net.ipv4.ip_forward on a Talos node, edit the machine configuration YAML and push it with talosctl apply-config. The node will reboot and activate the new setting without manual file edits.

How the declarative config works

Talos treats the operating system as immutable. All system adjustments are expressed in a versioned machine config that is sent to the node’s API (https://:50000/v1/config). The talosd service validates the schema, stores the config, and applies it on the next reboot. This prevents drift and ensures upgrades reuse the same settings.

Worked example

1. Prepare the machine config. Create a file machineconfig.yaml that includes the desired kernel sysctl:

# machineconfig.yaml
version: v1alpha1
kernel:
  sysctl:
    net.ipv4.ip_forward: true

1. Apply the config. Run this command from a workstation that can reach the node’s API (you need read/write access to the Talos API):

talosctl apply-config --insecure --nodes 192.0.2.10 --file machineconfig.yaml

Replace 192.0.2.10 with the node’s IP address. The --insecure flag is for testing only; in production use proper TLS certificates.

1. Reboot the node. The config is staged; a reboot activates it:

talosctl reboot --nodes 192.0.2.10

1. Verify the setting. After the node returns online, check the kernel value:

talosctl get config --nodes 192.0.2.10

Look for the kernel.sysctl section in the output; it should show net.ipv4.ip_forward: true. You can also inspect the running kernel:

talosctl cmd --nodes 192.0.2.10 -- sysctl net.ipv4.ip_forward

A successful apply will log a message like “Applied machine config” in journalctl -u talosd. If the YAML contains a typo or an unsupported field, the API returns a schema validation error and the config is not staged.

Limits and common mistakes

• Only API‑exposable settings can be changed. Talos validates against its OpenAPI schema; attempts to set arbitrary files (e.g., editing /etc/sysctl.conf directly) are overwritten on the next reboot or upgrade.
• Node reachability is required. If the node is offline or the talosd service is not running, talosctl apply-config fails with a connection error. Ensure network connectivity and that the API port (50000) is open.
• Versioning matters. The machine config includes a version field. Using an outdated schema version will be rejected; always match the version documented for your Talos release.
• Insecure flag risk. Using --insecure disables TLS verification, exposing the config to man‑in‑the‑middle attacks. Replace it with proper certificates (--tls-cert, --tls-key, --tls-ca) before moving to production.
• Rollback is manual. Applying a new config changes the node’s desired state. To revert, re‑apply the previous known‑good machine config (or a minimal config) and reboot again. There is no automatic rollback.

Verification and rollback

After applying a config, you can confirm persistence across upgrades:

1. Run talosctl get version --nodes 192.0.2.10 to ensure the API is reachable.
2. Perform an upgrade: talosctl upgrade --nodes 192.0.2.10 --image talos/v1.5.0 (adjust the image tag to your version).
3. After the node reboots, run talosctl get config --nodes 192.0.2.10 again. The kernel sysctl should still be present, demonstrating that the declarative config survives upgrades.

If you need to revert to the original state, reuse the earlier machine config (or a blank config) and repeat the apply‑reboot cycle.