Zo draaien de meesten van ons Kubernetes nodes. Je installeert een algemene Linux distro, hardent hem met een CIS benchmark script, voegt een SSH key toe, zet een config management tool op om drift in toom te houden, en SSH’t vervolgens twee jaar lang naar binnen om de dingen te fixen die die tool niet ving. Elke node is een sneeuwvlokje met zijn eigen geschiedenis. We hebben dat als normaal geaccepteerd.

De eerste keer dat ik probeerde te SSH’en naar een Talos node, kreeg ik niets. Geen shell, geen verbinding, geen vertrouwde Linux prompt. Mijn eerste reactie was verwarring, toen milde paniek. Hoe moet ik dit ding debuggen?

Dat was drie jaar geleden. Nu kan ik me niet voorstellen Kubernetes op iets anders te draaien.

Wat is Talos Linux?

Talos Linux is een Linux distributie gebouwd voor één taak: Kubernetes draaien. Het een “Linux distributie” noemen doet het tekort, want Talos gooit het meeste weg van wat een normale Linux bak normaal laat voelen.

  • Geen SSH. Je kunt niet inloggen op een Talos node.
  • Geen package manager. Geen apt-get, geen yum, niets installeren.
  • Geen shell. Er is geen bash, geen sh, niets.
  • Immutable filesystem. Het root filesystem is read-only.
  • API-driven. Alle beheer gaat via een gRPC API.

Je eerste reactie is waarschijnlijk de mijne: “Dat is gestoord. Hoe krijg je dan iets gedaan?”

Het antwoord is precies wat mijn kijk op infrastructuur veranderde.

Waarom SSH verwijderen?

Laat me je vertellen over een incident om 3 uur ’s nachts, jaren geleden, ruim voor Talos.

Productie lag plat. Ik SSH’te naar de kapotte node, deed wat panisch debuggen, vond het probleem, en fixte het door met de hand een config file te bewerken en een service te herstarten. Crisis afgewend, terug naar bed.

En dan bijt het sneeuwvlokje. Die fix bestond op precies één plek: de disk van die ene node. Geen documentatie, geen Git commit, geen audit trail. Maanden later vervingen we de node, en het probleem kwam recht terug, omdat niemand zich de handmatige wijziging herinnerde die het stilletjes in leven had gehouden.

Dat is de prijs van mutable infrastructure, en die stapelt zich op. Elke SSH sessie is een kans op config drift. Elke “quick fix” is schuld die je later terugbetaalt, meestal om 3 uur ’s nachts, meestal zonder de context die je de eerste keer had.

Stel je nu de andere kant voor. Wat als de node fysiek niet kon driften, omdat er geen deur was om door te lopen en hem met de hand te veranderen? Talos maakt dat echt. Je kunt niet SSH’en en zitten klooien. Elke wijziging gaat via de API, dus elke wijziging kan getrackt, geversioneerd en gereproduceerd worden. De fix uit dat 3 uur incident was een config diff van één regel in Git geweest, gereviewd en opnieuw toegepast, in plaats van een geheim dat met de disk stierf.

Als ik dit uitleg, komt de tegenwerping snel: “Maar hoe zit het met debuggen? Hoe zit het met noodgevallen?”

Debuggen zonder SSH

Terechte vraag. Dit is de realiteit zonder SSH. Talos levert talosctl, een CLI die praat met de Talos API, en het dekt de dingen waar je normaal een shell voor zou pakken:

# Systeem logs ophalen
talosctl logs kubelet

# Kernel berichten streamen
talosctl dmesg -f

# Draaiende processen tonen
talosctl processes

# Node health checken
talosctl health

# Elk bestand van de node lezen
talosctl read /etc/hosts

# Volledige machine configuratie ophalen
talosctl get machineconfig

Alles wat je normaal via SSH zou doen zit hier, met één belangrijk verschil. De API heeft access control, audit logging, en kan beperkt worden tot specifieke operaties. SSH is een alles-of-niets root shell, en een root shell is precies wat een aanvaller ook wil.

Voor de “ik heb echt een shell nodig” momenten is er een escape hatch:

talosctl dashboard

Dat geeft je een read-only TUI met systeem stats, logs en node status. En voor echte noodgevallen is er een debug container die een privileged container opstart met volledige host access. Het is opzettelijk onhandig in gebruik, en dat is het punt. Ernaar grijpen hoort uitzonderlijk te voelen, want dat is het ook.

Het configuratie model

Talos nodes worden geconfigureerd met één YAML machine config. Een uitgekleed voorbeeld:

machine:
  type: controlplane
  token: <bootstrap-token>
  ca:
    crt: <ca-certificate>
    key: <ca-key>
  network:
    hostname: node-01
    interfaces:
      - interface: eth0
        dhcp: true
  install:
    disk: /dev/sda
    image: ghcr.io/siderolabs/installer:v1.6.0

cluster:
  clusterName: homelab
  controlPlane:
    endpoint: https://192.168.1.100:6443

Deze config beschrijft alles over de node: netwerk settings, disk layout, Kubernetes versie, kernel argumenten, system extensions, CNI configuratie, alles.

Wanneer je hem toepast:

talosctl apply-config --nodes 192.168.1.10 --file controlplane.yaml

Talos “configureert” de node niet zozeer, de node wordt de config. Hij convergeert naar de gewenste staat. Wijzig de config, pas opnieuw toe, en de node convergeert naar de nieuwe staat. Hetzelfde declaratieve mentale model als Kubernetes, alleen een laag lager in de stack.

GitOps all the way down

Vergelijk dat met waar OS configuratie normaal leeft: Ansible playbooks die afdrijven van de werkelijkheid, een config management tool die niemand helemaal vertrouwt, en een laag tribal knowledge vergaard via SSH sessies die geen spoor achterlieten. De source of truth is “vraag het de persoon die het opzette”, en die persoon vertrekt uiteindelijk.

Omdat alles in Talos YAML is, valt het direct in een GitOps workflow. Mijn setup ziet er zo uit:

infrastructure/
├── talos/
│   ├── controlplane-1.yaml
│   ├── controlplane-2.yaml
│   ├── controlplane-3.yaml
│   ├── worker-1.yaml
│   └── worker-2.yaml
├── kubernetes/
│   └── ... (manifests beheerd door ArgoCD)
└── ...

Wanneer ik iets moet wijzigen op een node, zoals een kernel argument toevoegen of de netwerk config aanpassen, bewerk ik de YAML, commit het, en pas toe. De wijziging is gedocumenteerd omdat de commit de documentatie is. Het is reviewbaar in een PR, en het is reproduceerbaar op de volgende node die ik bouw. De source of truth is expliciet en version-controlled, en dat is de hele reden om dit zo te doen.

Security by default

Haal de shell en de package manager weg en een hele klasse aanvallen werkt niet meer:

  • Geen package manager betekent geen curl | bash malware install
  • Geen SSH betekent geen brute-forcen van SSH credentials
  • Read-only filesystem betekent geen systeembinaries omwisselen
  • Minimale userspace betekent om mee te beginnen al een kleiner attack surface

Het systeem draait alleen wat Kubernetes nodig heeft: containerd, kubelet en een paar ondersteunende services. Geen cron, geen systemd-resolved, geen van de gebruikelijke achtergrond daemons die vooral bestaan omdat een algemene distro aannam dat je ze misschien wilde.

Dus zelfs als een aanvaller een container popt en ontsnapt naar de host, waar landt hij? Een read-only filesystem zonder shell, zonder package manager, en nergens om persistence achter te laten. Dit sluit aan bij zero trust principes: de node vertrouwt zelfs zichzelf niet om correct geconfigureerd te blijven, dus enforced hij continu de gedeclareerde staat.

Upgrades die echt werken

Upgrades zijn een van mijn favoriete onderdelen:

talosctl upgrade --nodes 192.168.1.10 \
  --image ghcr.io/siderolabs/installer:v1.7.0

Talos haalt het nieuwe OS image op, schrijft het naar een tweede partitie, en reboot ernaar. Als de upgrade faalt, rolt de node zichzelf automatisch terug naar de vorige versie.

Dat is een transactionele upgrade. Geen half-toegepaste staat, geen “kernel panicked halverwege de upgrade” zaterdag. Hij voltooit netjes of rolt in zijn geheel terug.

Voor Kubernetes versie sprongen update je de machine config met de nieuwe versie en pas je toe. Talos regelt draining en cordoning als je het Talos-aware upgrade pad gebruikt.

Wanneer Talos niet gebruiken

Ik zou liegen als ik zei dat dit iedereen past. Blijf bij traditioneel Linux als:

  • Je specifieke packages nodig hebt die niet beschikbaar zijn als Talos extensions
  • Je Linux aan het leren bent en de abstractie te veel verbergt
  • Je team niet klaar is voor de shift naar API-driven beheer
  • Je non-Kubernetes workloads draait op dezelfde nodes

Talos is laser-gefocust op Kubernetes draaien. Als dat niet je primaire use case is, ben je je tijd kwijt aan vechten tegen het design in plaats van het gebruiken.

En debuggen heeft vooraf een steilere curve. Als iets breekt kun je je er niet zomaar met vim /etc/whatever uitwurmen. Je moet eerst de Talos tools en concepten leren. Op lange termijn is dat een voordeel, omdat het betere gewoontes afdwingt, maar het is een echte kost tijdens adoptie en doen alsof dat niet zo is zou oneerlijk zijn.

Aan de slag

De snelste manier om Talos te proberen is met Docker:

# Maak een lokaal cluster
talosctl cluster create --name demo

# Haal kubeconfig op
talosctl kubeconfig --nodes 127.0.0.1

# Je draait nu Talos lokaal
kubectl get nodes

Voor iets dat dichter bij echt komt, begin met een klein homelab cluster. Mijn homelab draait op refurbished mini-PCs, een goedkope manier om met Talos te experimenteren voordat je productie erop inzet. De Talos documentatie is echt goed, met guides voor bare metal, AWS, GCP, Azure, VMware en meer.

De mentale shift

Dus waarom draait niet iedereen zijn nodes zo? Eerlijk gezegd omdat de hele industrie het tegenovergestelde aanneemt. Traditioneel infrastructuurbeheer is gebouwd rond het idee dat je erin moet om dingen met de hand te fixen. SSH keys, bastion hosts, jump boxes, console access: de hele toolchain bestaat om je een deur te geven.

Talos sluit de deur met opzet. De gok is dat je nooit erin zou moeten, omdat het systeem zichzelf beschrijft en uit zichzelf convergeert. Als iets fout is, fix je de config en pas je opnieuw toe. Dat klinkt rigide. Het is rigide. Die rigiditeit is de feature.

De kloof dichten is makkelijker dan de filosofie laat klinken. Elk incident dat ik op Talos had volgde dezelfde loop: lees de logs via de API, spot de misconfiguratie, fix de config, pas toe. De fix documenteert zichzelf omdat het een config wijziging in Git is. Er blijft geen “wacht, heeft iemand erin ge-SSH’t en iets gedaan?” vraag boven het cluster hangen, want het antwoord is altijd nee.

Drie jaar verder mis ik SSH niet. De API geeft me alles wat een shell me gaf, met betere security, een echte audit trail, en reproduceerbaarheid die een shell nooit kon bieden. Talos is een sterke mening over hoe infrastructuur zou moeten werken, ingebakken in een OS. Als die mening aansluit bij de jouwe, immutable, declaratief, API-driven, is het een van de beste manieren die ik ken om Kubernetes te draaien.