Getting Started with Talos Linux: Building Your First Learning Cluster

Introduction

I’ve been hearing a lot about Talos Linux lately and decided to try it out by building a small learning cluster. As someone exploring modern Kubernetes distributions, I was intrigued by Talos’ unique approach. In this post, I’ll document my journey setting up a basic Talos Linux Kubernetes cluster for the first time, sharing what I learned along the way. This is meant to be a learning exercise - perfect for anyone who wants to get hands-on experience with Talos before considering it for more serious deployments.

What is Talos Linux?

Talos Linux is not your traditional Linux distribution. It’s a specialized, immutable operating system designed from the ground up to run Kubernetes with minimal overhead and enhanced security. Key features include:

• Immutability: The system is immutable, preventing runtime modifications that could introduce security vulnerabilities or configuration drift.
• Minimal: Stripped of unnecessary components like shells, package managers, and login capabilities, reducing attack surface dramatically.
• API-driven: All system configuration and maintenance is performed via a secure gRPC API, not SSH.
• Container-optimized: Built specifically for running container workloads.
• Security-focused: Implements the System Integrity Protection scheme with mutual TLS authentication, secure boot capabilities, and encryption.
• Kubernetes-native: Talos is designed exclusively for running Kubernetes, with optimizations for this specific purpose.

This guide will demonstrate how to build a basic three-node Talos cluster, providing you with a solid foundation for exploring its capabilities.

Prerequisites

For this learning cluster, I’ve set up:

• 3 virtual machines with:
  • 2 CPU cores each
  • 2 GB RAM each
  • 50 GB disk space each
• A workstation where we’ll install talosctl and kubectl.
• Static IP addresses for each VM.

Architecture Overview

For this learning cluster, I’m keeping it simple with:

• 1 control plane node (the brains of the operation)
• 2 worker nodes (where our workloads will run)
• Talos Linux running on all nodes
• talosctl and kubectl on my workstation to manage the cluster

This minimal setup is perfect for learning Talos without overwhelming complexity. In future posts, I’ll explore more advanced configurations, but this is ideal for getting started.

Step 1: Installing talosctl

First, I needed to install talosctl on my laptop. This tool is the primary interface for interacting with Talos Linux nodes - think of it as your remote control for the cluster:

# This script will work on macOS, Linux, and WSL on Windows. It supports amd64 and arm64 architecture.

curl -sL https://talos.dev/install | sh

Verify the installation:

talosctl version

Step 2: Downloading Talos Linux Images

The most general way to install Talos Linux is to use the ISO image. The latest ISO image can be found on the Github Releases page: For AMD64 architecture:

https://github.com/siderolabs/talos/releases/download/v1.10.0/metal-amd64.iso

For ARM64 architecture:

https://github.com/siderolabs/talos/releases/download/v1.10.0/metal-arm64.iso

Boot each of the three VMs using the downloaded Talos ISO.

Once the VM boots, you will see a screen displaying the node’s IP address and other information. This is the Talos boot environment, which is very minimalistic and does not provide a shell or login prompt like traditional Linux distributions.

In the console, you will see a the node is in ‘Maintenance’ stage, waiting for configuration. The Talos ISO boots into a minimal environment that allows you to configure the node without needing a traditional installer.

Note the IP addresses assigned to each node during boot. We will need these later for configuration so that the IP addresses don’t change when the VMs restart. Alternatively, you can lease the IP addresses static in your DHCP server.

Also, make sure to note the interface name (usually ens18 or similar) as we will need it for network configuration. Press F3 to see the network configuration options.

I found this ISO worked perfectly with Proxmox, VirtualBox, QEMU/KVM, and VMware - choose whatever virtualization platform you're most comfortable with for a learning environment. I used Proxmox for this setup, but VirtualBox or any other hypervisor would work just as well.

Step 3: Generating Talos Configurations

One thing that surprised me about Talos is its declarative configuration system. Unlike traditional Linux servers where you might SSH in and run commands to configure things, Talos requires configuration files to be generated beforehand.

3.1 Setting Up the static IPs and hostnames

I am not going to use DHCP for this learning cluster, so I set static IPs for my nodes. This is important because Talos nodes need to know their IP addresses upfront. You can just export the IPs to match the IPs assigned to your VMs by your DHCP server and skip setting the static IPs in the VMs via talos config if you are using DHCP leases.

# Set the IP for the VM
export CONTROL_PLANE_IP=192.168.203.20
export WORKER1_IP=192.168.203.21
export WORKER2_IP=192.168.203.22

3.2 Generating the Configuration Files

To generate the configuration files, I used the talosctl gen config command. This command creates the necessary YAML files that define how each node in the cluster should be configured.

# Generate the configurations with a cluster name "my-first-talos"
talosctl gen config my-first-talos https://${CONTROL_PLANE_IP}:6443 --output-dir ./talosconfig

This created three important files in my ./talosconfig directory:

• controlplane.yaml: The configuration for my single control plane node
• worker.yaml: The configuration for my two worker nodes
• talosconfig: The client configuration that my talosctl tool would use

3.3 Customizing the Configuration Files

We can customize these YAML files to set static IPs and hostnames. For this we will use patches

cd talosconfig
mkdir patches
cd patches

Create a patch file for the control plane node controlplane.yaml:

machine:
  network:
    hostname: talos-control-plane
    interfaces:
      - interface: ens18
        addresses:
          - 192.168.203.20/22
        routes:
          - network: 0.0.0.0/0
            gateway: 192.168.200.1

Create a patch file for the worker nodes worker1.yaml:

machine:
  network:
    hostname: worker-01
    interfaces:
      - interface: ens18
        addresses:
          - 192.168.203.21/22
        routes:
          - network: 0.0.0.0/0
            gateway: 192.168.200.1

Similarly, create a patch file for the second worker node worker2.yaml:

machine:
  network:
    hostname: worker-02
    interfaces:
      - interface: ens18
        addresses:
          - 192.168.203.22/22
        routes:
          - network: 0.0.0.0/0
            gateway: 192.168.200.1

Step 4: Installing Talos on the Nodes

With the configurations ready, we can now apply them to our Talos nodes. This is where the magic happens - Talos will transform our VMs into fully functional Kubernetes nodes based on the configurations we provided.

# Navigate to the directory where the configuration files were generated
cd talosconfig

For the control plane node:

# Apply control plane configuration to my first node
talosctl apply-config --insecure -e ${CONTROL_PLANE_IP} --nodes <control-plane-ip> --file ./controlplane.yaml --config-patch @patches/controlplane.yaml

# Replace <control-plane-ip> with the actual IP address of your control plane node that talos was automatically assigned to during boot. 

If you are using DHCP leases, you can skip the patch file and just use the generated controlplane.yaml file directly.

talosctl apply-config --insecure -e ${CONTROL_PLANE_IP} --nodes <control-plane-ip> --file ./controlplane.yaml

The --insecure flag was necessary for this initial connection since TLS certificates haven’t been set up yet.

After applying, check the console of the control plane node. You should the STAGE has changed from Maintenance to Installing and eventually to Booting. This process might take a few minutes as Talos configures the node. Also the TYPE field in the console should change from unknown to controlplane.

For the two worker nodes:

# Apply worker configuration to my two worker VMs
talosctl apply-config --insecure -e ${CONTROL_PLANE_IP} --nodes <worker1-ip> --file ./worker.yaml --config-patch @patches/worker1.yaml
# Replace <worker1-ip> with the actual IP address of your first worker node that talos was automatically assigned to during boot.

If you are using DHCP leases, you can skip the patch file and just use the generated worker.yaml file directly.

talosctl apply-config --insecure -e ${CONTROL_PLANE_IP} --nodes <worker1-ip> --file ./worker.yaml

Repeat the same for the second worker node:

# Apply worker configuration to my second worker VM
talosctl apply-config --insecure -e ${CONTROL_PLANE_IP} --nodes <worker2-ip> --file ./worker.yaml --config-patch @patches/worker2.yaml
# Replace <worker2-ip> with the actual IP address of your second worker node that talos was automatically assigned to during boot.

If you are using DHCP leases, you can skip the patch file and just use the generated worker.yaml file directly.

talosctl apply-config --insecure -e ${CONTROL_PLANE_IP} --nodes <worker2-ip> --file ./worker.yaml

After applying, check the console of the worker nodes. You should the STAGE has changed from Maintenance to Installing and eventually to Booting. This process might take a few minutes as Talos configures the node. Also the TYPE field in the console should change from unknown to worker.

I was surprised how quickly each node accepted its configuration - just a few seconds and they began transforming into Talos systems!

Step 5: Configuring talosctl

Once all the nodes show KUBELET as HEALTHY in the console, it means Talos has successfully booted and is ready to be configured further.

Now that Talos is running on all nodes, I needed to set up talosctl to interact with my cluster. The talosctl tool uses a configuration file (talosconfig) to connect to the Talos nodes.

I generated the talosconfig file during the talosctl gen config step, but I needed to merge it with my existing configuration to make it usable. Similar to KUBECONFIG for Kubernetes, talosctl uses a configuration file to manage connections to Talos nodes. This file contains information about the nodes, their IP addresses, and TLS certificates.

To interact with your Talos cluster, configure talosctl with the generated configuration:

# Merge the generated talosconfig with your existing config
talosctl config merge ./talosconfig

# Alternatively, you can set the TALOSCONFIG environment variable to point to the generated talosconfig file
export TALOSCONFIG=./talosconfig

Next, I needed to set the endpoints for my Talos cluster. This tells talosctl which node to connect to by default. Since I had a single control plane node, I set it as the endpoint:

# Set the endpoints (control plane IPs)
talosctl config endpoints ${CONTROL_PLANE_IP}

# Set the node to interact with by default
talosctl config node ${CONTROL_PLANE_IP}

# You can also set the node for worker nodes if you want to interact with them directly
talosctl config node ${CONTROL_PLANE_IP},${WORKER1_IP},${WORKER2_IP}

Check that the configuration is correct by running:

talosctl config contexts

This should display the current configuration, including the endpoints and nodes. You should see your control plane and worker nodes listed with their respective IP addresses.

CURRENT   NAME             ENDPOINTS        NODES
*         my-first-talos   192.168.203.20   192.168.203.20,192.168.203.21,192.168.203.22

Step 6: Bootstrap the Cluster

With Talos running on all nodes, let’s bootstrap the Kubernetes control plane:

talosctl bootstrap -n ${CONTROL_PLANE_IP}

The bootstrap operation should only be called ONCE on a SINGLE control plane node. (If you have multiple control plane nodes, it doesn’t matter which one you issue the bootstrap command against.)

Wait for the bootstrap process to complete. This might take a few minutes as Talos initializes the etcd database and starts the Kubernetes components.

Step 7: Setting up kubectl Access

Once the cluster is bootstrapped, get the kubeconfig to interact with your Kubernetes cluster:

talosctl kubeconfig --nodes ${CONTROL_PLANE_IP}

This command downloads the kubeconfig and sets it as your current context.

Alternatively, you can specify the output file:

talosctl kubeconfig kubeconfig.yaml --nodes ${CONTROL_PLANE_IP}

Then, set the KUBECONFIG environment variable to point to the kubeconfig file:

export KUBECONFIG=$(pwd)/kubeconfig.yaml

Now, you can use kubectl to interact with your Talos cluster. Verify that kubectl can communicate with the cluster:

kubectl get nodes

You should see all three nodes, with the control plane node having the control-plane role and the worker nodes having the worker role.

Step 8: Verifying Cluster Health

Let’s perform some health checks to ensure everything is running correctly:

# Check node status
kubectl get nodes -o wide

# Check pod status
kubectl get pods -A

# Check Talos health
talosctl health

All systems should report healthy. If not, use the following commands to troubleshoot:

# View logs from Talos
talosctl logs <service>

# View Kubernetes component logs
talosctl logs kubelet

# Check etcd status
talosctl etcd status

Step 9: Exploring Talos Features

With my learning cluster up and running, I spent some time exploring Talos’ unique features. This was the most eye-opening part of my experience!

Viewing Resources

I discovered that Talos has its own resource system (somewhat similar to Kubernetes):

# I tried listing all available resources
talosctl get all

# Then got more specific with these commands
talosctl get services
talosctl get nodes
talosctl get pods
talosctl get disks

The output was fascinating - Talos exposes so much information about the system through these resources.

Interacting with the System

One of the biggest surprises was that there’s no SSH access or shell on Talos nodes! This initially felt limiting, but I quickly appreciated the security benefits. Instead, I used:

# To see running containers
talosctl containers

# When I needed to restart a service
talosctl service restart kubelet

# To check running processes
talosctl ps

The absence of a shell is actually a feature, not a limitation. It drastically reduces the attack surface of your cluster!

Looking at Logs

I found this particularly helpful while learning:

# View Kubernetes API server logs
talosctl logs -f kube-system/kube-apiserver

# Check etcd logs when I was curious
talosctl logs etcd

Step 10: Deploying a Simple Application

With my cluster up and running, I wanted to test it by deploying a simple application:

# Create a test namespace
kubectl create namespace demo

# Deploy nginx as a test application
kubectl create deployment nginx --image=nginx -n demo

# Expose it as a service
kubectl expose deployment nginx --port=80 --type=NodePort -n demo

I was able to access my nginx deployment using the assigned NodePort and any of my node IPs - confirmation that my learning cluster was working correctly!

What I Learned

Building this learning cluster taught me several important things about Talos:

1. Truly Immutable: Unlike other Linux distros that claim to be immutable but allow modifications, Talos is genuinely immutable, enforcing good practices from the start.

2. API-First Design: The absence of SSH or a shell forces you to think differently about system management - everything is API-driven.

3. Simple Mental Model: With a focused purpose (just running Kubernetes), Talos is conceptually simpler than general-purpose distributions.

4. Minimal Attack Surface: The security benefits of removing shells, package managers and other traditional Linux components are substantial.

Next Steps in My Talos Journey

This learning cluster gave me a great introduction to Talos, but there’s more I want to explore in future posts:

1. Building a high-availability cluster with multiple control plane nodes
2. Different networking options beyond the default flannel CNI
3. Advanced configuration patterns and customizations
4. Upgrading Talos versions

Conclusion

Setting up this learning cluster was a fascinating introduction to Talos Linux. The whole experience felt very different from my previous Kubernetes deployments - more streamlined, more focused, and surprisingly elegant once I adjusted to the different approach.

For anyone curious about modern Kubernetes platforms, I highly recommend spending an afternoon setting up a simple Talos cluster like I did. The learning curve isn’t steep, but the concepts are different enough from traditional Linux distributions that hands-on experience is invaluable.

My single control plane with two worker nodes was perfect for learning, and I now feel confident that I understand the fundamentals of Talos. In my next post, I’ll explore setting up a more production-ready configuration with multiple control plane nodes for high availability.

Have you tried Talos yet? What was your first impression? Let me know in the comments below!