Beyond the Cloud: Running Kubernetes with Talos: Comparing Talos, k3s, AKS, and EKS

“If Kubernetes is the engine, Talos is the chassis built specifically for it.”

Introduction: Rethinking the Kubernetes Operating System

When Kubernetes first appeared, it was celebrated as the “Linux of the cloud.” But beneath every Kubernetes cluster, there’s always a traditional operating system like Ubuntu, CentOS, Flatcar, or another Linux distribution. These weren’t originally built specifically for the orchestration layer that overlays them.
This historical setup has quietly influenced how we manage, patch, and secure our clusters. Even as control planes have shifted to managed services such as Azure Kubernetes Service (AKS) and Amazon Elastic Kubernetes Service (EKS), the nodes themselves still rely on an operating system that wasn’t initially designed for immutability or declarative control.

Introducing Talos, an innovative operating system designed specifically for Kubernetes enthusiasts! Developed by Sidero Labs, Talos marks an exciting evolution from simply running Kubernetes on Linux to becoming an OS centered around Kubernetes itself. It enhances security by replacing SSH with a straightforward API, eliminating package managers, and tightly securing its surface to prevent attacks or drift.

In this blog, we will examine Talos, compare it with k3s, AKS, and EKS, and explore its role within the changing landscape of modern Kubernetes operations, from the cloud to the edge.

The Operating System for Kubernetes

Traditional Linux distributions are developed for general-purpose computing, while Talos is a specialized, immutable OS that directly integrates with Kubernetes control plane components.

Fundamentally, Talos eliminates nearly everything you would typically find in a standard Linux system:
• No bash
• No SSH access
• No mutable filesystem
• No package manager
• No direct systemd control

Instead, all administrative tasks are performed through an API called talosd. This setup prevents configuration drift and ensures operations are declarative and version-controlled.

The entire lifecycle of a Talos node, from bootstrap to upgrade, is outlined in YAML and managed via the Talos API using talosctl.

For example, a minimal machine configuration might look like this:

# talosconfig.yaml
machine:
  type: controlplane
  install:
    image: ghcr.io/siderolabs/installer:v1.8.0
    disk: /dev/sda
  network:
    hostname: talos-master-01
cluster:
  controlPlane:
    endpoint: https://10.0.0.10:6443
  clusterName: talos-lab

Every node, whether master or worker, is bootstrapped declaratively, similar to Infrastructure-as-Code. Unlike cloud-managed distributions, Talos does not abstract Kubernetes; instead, it exposes it more transparently.

Talos vs. k3s: Secure Minimalism vs. Edge Minimalism

Both Talos and k3s share a minimal philosophy, but they target different goals.

k3s, developed by Rancher (now part of SUSE), is a compact Kubernetes distribution designed for edge and IoT use cases. It streamlines cluster deployment by packaging components into a single binary. In contrast, Talos is not a Kubernetes distribution; instead, it is the operating system that Kubernetes operates on.

While k3s makes Kubernetes installation easier, Talos strengthens the underlying infrastructure.

Let’s compare their philosophies:

While k3s appeals to developers seeking lightweight Kubernetes at the edge, Talos caters to those requiring secure, auditable infrastructure where every state change is logged and no human has shell access.

A Talos cluster doesn’t just run Kubernetes; it becomes part of it.

Talos vs. Managed Service: AKS and EKS

Managed Kubernetes services like AKS and EKS remove control plane management from your responsibilities. They handle Kubernetes version upgrades, API availability, and integration with cloud IAM, networking, and monitoring.

However, in both services, the node operating system remains mutable. Even if you use Azure Linux, Ubuntu, or Bottlerocket (AWS), those systems still expose SSH, file systems, and package layers that can drift from a baseline over time.

Talos eliminates those layers.

For organizations with strong regulatory or security postures — think NIS2, DORA, or ISO 27001 — that’s a powerful differentiator.

Here’s how they differ conceptually:

Talos doesn’t replace AKS or EKS; it complements them.

You can run AKS in Azure for managed workloads and deploy Talos clusters on the edge, in colocation sites, or even on bare metal for environments that require strict operational control.

Operating Talos — Everything Is Declarative

Every Talos node is configured and controlled through a single declarative interface.

That starts with the machine configuration file, a YAML document that defines networking, storage, certificates, and system extensions.

Example configuration for a worker node:

# worker.yaml
machine:
  type: worker
  network:
    interfaces:
      - interface: eth0
        dhcp: true
  install:
    image: ghcr.io/siderolabs/installer:v1.8.0
  kubelet:
    nodeLabels:
      node-type: edge
cluster:
  clusterName: talos-lab
  controlPlane:
    endpoint: https://10.0.0.10:6443

After generating the configuration with:

talosctl gen config talos-lab https://10.0.0.10:6443

You apply it directly to each node:

talosctl apply-config --insecure --nodes 10.0.0.21 --file worker.yaml

From that point, node configuration and upgrades happen declaratively.

Upgrading all nodes in a cluster to a new version is as simple as:

talosctl upgrade --nodes 10.0.0.21,10.0.0.22,10.0.0.23 --image ghcr.io/siderolabs/installer:v1.9.0

No SSH sessions, no imperative patching — only versioned, API-controlled changes.

Observability and Integration

Since Talos lacks a native shell or package management system, integrations with observability tools are handled externally via Kubernetes or sidecar agents.

Metrics are collected with Prometheus, logs are streamed to Grafana Loki, and system events are accessible via the Talos API. Cloud services such as AKS or EKS offer built-in integrations with Azure Monitor or CloudWatch, whereas Talos follows a bring-your-own-observability strategy.

Since Talos is immutable, you can always see exactly what’s running, with no hidden agents or leftover daemons. Observability pipelines are set up through Kubernetes manifests or external exporters, giving you complete control.

Example Bicep for connecting a Talos edge cluster to Azure Monitor via Arc:

#bicep 
resource arcConnection 'Microsoft.HybridCompute/machines@2023-03-01' = {
  name: 'talos-edge-node'
  location: 'westeurope'
  properties: {
    osName: 'Talos'
    osVersion: '1.8.0'
    connectivityStatus: 'Connected'
  }
}

Security: Immutability as Policy

In Talos, the OS itself enforces a security policy by design:
• No interactive logins
• No filesystem writes beyond /var and /etc
• No package installations
• All administrative actions go through an audited API

Every API call is logged and can be replayed or versioned. That’s a fundamental shift from “trust the admin” to “trust the configuration.”

Compared with managed services like AKS or EKS, Talos pushes the security boundary lower. You can still apply Azure Policy, PodSecurityAdmission, or OPA Gatekeeper at the Kubernetes layer — but Talos ensures the node itself can’t be compromised through local access.

This makes Talos appealing for industries with stringent controls — financial services, defense, or healthcare — where you can’t allow operator drift or arbitrary SSH access.

Use Cases in the Real World

Imagine a national retail chain with hundreds of stores, each running a small edge cluster to manage local POS data and inventory caches. Running full AKS or EKS on-site would be impractical, and k3s might lack the necessary compliance controls. Talos fits this niche by providing secure, immutable edge clusters synchronized with cloud workloads. Consider an industrial manufacturer deploying Kubernetes within restricted OT zones disconnected from the internet. Talos supports air-gapped deployments using signed container images and declarative configurations, without the need for SSH or remote shells.

Hybrid architectures are also well-suited:
• AKS or EKS manages centralized CI/CD, monitoring, and security policies.
• Talos clusters expand compute capabilities to edges, labs, or regulated environments.

All layers remain Kubernetes-native and managed with the same tooling, yet each has its own control plane.

Example Setup: Running Talos on Three Nodes

Let’s walk through a compact Talos lab cluster, suitable for edge or homelab testing.

We’ll deploy three nodes — one control plane and two workers — on x86 or Raspberry Pi.

Generate configurations:

talosctl gen config talos-lab https://192.168.1.100:6443

Apply configs:

talosctl apply-config --nodes 192.168.1.101 --file controlplane.yaml
talosctl apply-config --nodes 192.168.1.102,192.168.1.103 --file worker.yaml

Bootstrap the control plane

talosctl bootstrap --nodes 192.168.1.101

Acces Kubernetes

talosctl kubeconfig ./
kubectl get nodes

Once complete, you have a fully functional Kubernetes cluster — without SSH, without mutable OS layers, and entirely declaratively managed.

For validated documentation and hardware compatibility:

👉 Talos Documentation — Getting Started

Comparative Summary

Let’s consolidate everything into a single overview:

Conclusion: The OS Boundary Is Shifting

Kubernetes used to abstract away the infrastructure layer. But as clusters span data centers, clouds, and edge devices, the operating system itself has become part of the control-plane conversation.

Talos embodies the shift from flexible Linux distributions to API-based, immutable systems built for Kubernetes. It does not compete with managed services such as AKS or EKS; instead, it enhances them by extending the Kubernetes operating model to environments where control, auditability, and security are essential.

For platform and security architects, Talos introduces a new mental model:

“If you can declare it, you can enforce it. If you can’t shell into it, you can trust it.”

As Kubernetes expands beyond the cloud into edge and regulated infrastructures, operating systems like Talos are leading the way for what comes next.