Zijn we klaar voor Embedded Kubernetes? - Ronde 1

Kubernetes en embedded systemen lijken op het eerste gezicht geen vanzelfsprekende combinatie. Kubernetes is groot geworden in datacenters, waar rekenkracht, geheugen en opslag doorgaans ruim beschikbaar zijn. Embedded systemen bevinden zich vaak aan de andere kant van dat spectrum: ze moeten hun werk doen met beperkte hardware, een vast energieverbruik en componenten die soms jarenlang ongewijzigd in productie blijven. Toch is het landschap de afgelopen jaren veranderd. Met de komst van lichtere Kubernetes-distributies en gespecialiseerde besturingssystemen is het steeds interessanter geworden om te onderzoeken of Kubernetes ook op aanzienlijk kleinere systemen praktisch inzetbaar is.

Vanuit mijn ervaring in het Cloud Native-ecosysteem zie ik dat de complexiteit van Kubernetes steeds beter beheersbaar wordt. We gebruiken Kubernetes al jaren voor edge computing, maar de stap naar kleinere embedded systemen roept andere vragen op. Hoeveel geheugen heeft een Kubernetes-installatie werkelijk nodig? Welke invloed heeft de keuze voor een distributie op het resourcegebruik? En wanneer wordt een systeem zo beperkt dat het niet langer betrouwbaar functioneert? De antwoorden op die vragen zijn niet altijd te vinden in documentatie alleen. Opgegeven minimumvereisten geven een nuttig vertrekpunt, maar vertellen niet noodzakelijk wat er gebeurt wanneer je de beschikbare hardware daadwerkelijk tot het uiterste beperkt.

Daarom heb ik drie combinaties van besturingssysteem en Kubernetes-distributie met elkaar vergeleken: Alpine Linux met KubeSolo, Alpine Linux met K3s en Talos Linux. Ik heb de systemen op identieke virtuele hardware getest, dezelfde applicatie gebruikt en vervolgens de beschikbare hoeveelheid geheugen stapsgewijs verlaagd. Het doel was niet om op voorhand een winnaar aan te wijzen, maar om inzicht te krijgen in de praktische verschillen tussen deze benaderingen en vast te stellen waar de grenzen van iedere configuratie liggen.

Drie benaderingen van een kleine Kubernetes-installatie

Hoewel alle drie de kandidaten Kubernetes kunnen draaien, verschillen ze wezenlijk in hun ontwerpfilosofie. Alpine Linux met KubeSolo vertegenwoordigt een aanpak waarin een compacte Linux-basis wordt gecombineerd met een Kubernetes-distributie die is gericht op een single-node-omgeving. Alpine is daarbij gekozen als relatief minimale, algemene Linux-distributie. Daarmee kan ik de eigenschappen van KubeSolo onderzoeken zonder meteen ook de complexiteit van een eigen embedded Linux-build mee te nemen.

K3s vormt de tweede kandidaat. Deze distributie is ontwikkeld om Kubernetes eenvoudiger en lichter inzetbaar te maken, zonder de mogelijkheden van een volwaardige Kubernetes-omgeving volledig los te laten. De combinatie met Alpine Linux maakt het mogelijk om de basis van het besturingssysteem gelijksoortig te houden aan die van de eerste kandidaat. Daardoor kunnen verschillen in resourcegebruik beter worden onderzocht binnen de grenzen van deze testopstelling.

Talos Linux kiest voor een andere benadering. In plaats van een algemene Linux-distributie waarop Kubernetes wordt geïnstalleerd, is Talos een besturingssysteem dat specifiek voor Kubernetes is ontworpen. Het systeem is immutable en wordt via een API beheerd, zonder de traditionele beheeromgeving met shell en SSH. Daarmee richt Talos zich op een minimalistische en gecontroleerde operationele omgeving, maar dat betekent niet automatisch dat het ook de kleinste geheugenvoetafdruk heeft. Juist dat onderscheid tussen een minimaal besturingssysteem en een minimale Kubernetes-installatie maakt de vergelijking interessant.

De testopstelling en meetmethode

Om de resultaten zo goed mogelijk vergelijkbaar te maken, heb ik alle drie de configuraties op hetzelfde Proxmox-cluster uitgevoerd. De virtuele machines gebruikten dezelfde configuratie, met twee vCPU's, dezelfde virtuele hardware-instellingen en dezelfde opslagbackend. Ook de workload was identiek: iedere installatie draaide traefik/whoami, waarbij exact dezelfde container-image-digest is gebruikt. Daarmee zijn belangrijke variabelen gelijkgetrokken, zodat verschillen in de resultaten vooral samenhangen met de gekozen softwareconfiguratie.

De eerste metingen zijn uitgevoerd met 2 GB toegewezen geheugen. Drie minuten nadat een systeem de status Ready had bereikt, heb ik het geheugengebruik vastgelegd. Vervolgens heb ik de beschikbare hoeveelheid RAM stapsgewijs teruggebracht, met tests op onder meer 1 GB, 768 MB en 512 MB. Bij iedere stap is het systeem opnieuw gestart om te controleren of de configuratie nog functioneerde. Daarbij ging het niet uitsluitend om de vraag of Linux opstartte, maar ook om de vraag of Kubernetes beschikbaar bleef en de testapplicatie daadwerkelijk kon draaien.

Een belangrijke beperking is dat deze tests zijn uitgevoerd op virtuele x86-64-hardware en niet op fysieke embedded hardware, zoals een ARM-gebaseerd systeem. De resultaten bieden daarmee een gecontroleerde vergelijking tussen de geteste softwareconfiguraties, maar zijn geen directe voorspelling van de minimale hardwarevereisten op een concreet embedded apparaat. De gevonden ondergrenzen gelden uitsluitend voor de onderzochte configuraties en workload.

De eerste resultaten: aanzienlijke verschillen in geheugengebruik

De eerste meting laat zien dat de keuze voor een Kubernetes-distributie en de bijbehorende systeemarchitectuur een merkbaar verschil maakt in het geheugengebruik. Met 2 GB RAM toegewezen aan iedere virtuele machine, gemeten drie minuten nadat het systeem Ready was geworden, kwam KubeSolo uit op 382 MB, K3s op 591 MB en Talos op 726 MB. Binnen deze testopstelling gebruikte K3s daarmee ongeveer anderhalf keer zoveel geheugen als KubeSolo, terwijl Talos bijna twee keer zoveel gebruikte.

Deze cijfers zijn interessant, maar vertellen niet het volledige verhaal. Een momentopname van het geheugengebruik zegt namelijk weinig over de hoeveelheid geheugen die een systeem nodig heeft om onder alle omstandigheden betrouwbaar te functioneren. Een installatie kan bij een ruime geheugentoewijzing relatief weinig RAM gebruiken, maar bij een kleinere hoeveelheid geheugen alsnog tegen problemen aanlopen. Om die reden heb ik niet alleen gekeken naar het gebruik bij 2 GB, maar ook onderzocht hoe de systemen zich gedragen wanneer de beschikbare resources steeds verder worden beperkt.

Het resultaat van die tweede test is minstens zo interessant als het verschil in de eerste meting. KubeSolo bleef in deze configuratie functioneren bij 768 MB RAM, maar viel uit bij 512 MB. K3s bleef stabiel bij 1 GB, maar werd onbruikbaar bij 768 MB. Talos functioneerde bij 2 GB, maar was in deze test niet meer bruikbaar bij 1 GB. De laagste geteste werkende geheugenconfiguratie verschilde dus aanzienlijk tussen de drie kandidaten.

Het is belangrijk om deze resultaten correct te interpreteren. Ze laten zien bij welke geheugenconfiguraties de geteste installaties in deze specifieke opstelling wel of niet functioneerden. Ze bewijzen niet dat 768 MB de universele minimumvereiste van KubeSolo is, of dat K3s onder alle omstandigheden minimaal 1 GB nodig heeft. Andere workloads, softwareversies, configuraties en hardware kunnen tot andere resultaten leiden. Wel geven de metingen een concreet uitgangspunt voor vervolgonderzoek en laten ze zien dat het verschil tussen de gekozen oplossingen in de praktijk relevant kan zijn.

Waarom de lichtste oplossing niet automatisch de beste is

Wanneer we de resultaten naast elkaar leggen, ligt de conclusie voor de hand dat KubeSolo de aantrekkelijkste kandidaat is voor systemen met zeer weinig geheugen. Die conclusie is echter slechts gedeeltelijk juist. KubeSolo kwam als lichtste uit deze test, maar de hoeveelheid geheugen die een systeem gebruikt, is maar één aspect van de geschiktheid voor een embedded toepassing. Ook de beschikbare functionaliteit, de operationele aanpak, de beveiliging en de mogelijkheid om het systeem op afstand te beheren, spelen een rol.

Het verschil tussen K3s en Talos illustreert dat goed. K3s richt zich op het vereenvoudigen en verkleinen van Kubernetes zelf. Het bundelt verschillende onderdelen in een compactere distributie en gebruikt standaard SQLite als datastore voor een single-serverinstallatie, in plaats van de gebruikelijke etcd-configuratie. Talos kiest voor een andere benadering: het minimaliseert en beveiligt de besturingslaag, terwijl Kubernetes zelf een architectuur behoudt die dichter bij de upstream-componenten ligt. De verschillende keuzes hebben gevolgen voor het aantal processen, de manier waarop het systeem wordt beheerd en de hoeveelheid resources die nodig is.

Daar staat tegenover dat Talos een praktisch voordeel biedt dat niet uit het geheugengebruik naar voren komt: er is geen apart besturingssysteem om te onderhouden. Omdat Talos immutable is en volledig via een API wordt beheerd, vervalt het traditionele beheer van pakketten, updates en configuratie op OS-niveau. Dat kan bijdragen aan een stabielere basis, met minder kans op configuratiedrift, en daarmee op termijn minder operationele overhead. Die afweging kan de hogere geheugenbehoefte van Talos in een ander licht zetten: iets meer investeren in basishardware, in ruil voor mogelijk lagere operationele kosten gedurende de levensduur van het apparaat.

Dat maakt de term lichtgewicht minder eenduidig dan hij op het eerste gezicht lijkt. Een besturingssysteem kan weinig beheercomponenten bevatten en toch relatief veel geheugen gebruiken doordat het meerdere afzonderlijke Kubernetes-processen draait. Een distributie die Kubernetes zelf compacter maakt, kan juist minder geheugen nodig hebben zonder dezelfde nadruk te leggen op een immutable besturingssysteem. Welke aanpak het beste past, hangt af van de eisen die aan het uiteindelijke product worden gesteld. Voor een apparaat dat één applicatie lokaal uitvoert, kunnen andere afwegingen gelden dan voor een industriële gateway die op afstand wordt beheerd en meerdere applicaties moet kunnen draaien.

Minimumvereisten uit documentatie versus de praktijk

De metingen zijn ook interessant wanneer we ze vergelijken met de minimumvereisten die de projecten zelf documenteren. De oorspronkelijke documentatie van KubeSolo noemt volgens de onderzochte configuratie 512 MB RAM als doel voor ARM-hardware. In onze x86-64-test bleek de installatie op datzelfde geheugenniveau niet meer bruikbaar. Dat verschil is op zichzelf geen bewijs dat de documentatie onjuist is: het platform verschilt, en de omstandigheden waaronder een minimumvereiste wordt opgegeven, zijn niet noodzakelijk gelijk aan onze testopstelling.

Bij K3s is het beeld anders. Hoewel de onderzochte documentatie 2 GB als minimum noemt, bleef de geteste installatie met 1 GB RAM functioneren. Dat suggereert dat een lagere geheugenconfiguratie onder bepaalde omstandigheden mogelijk is dan de documentatie als uitgangspunt neemt. Ook hier is voorzichtigheid geboden: een systeem dat met een beperkte testworkload stabiel blijft, is niet automatisch geschikt voor productie met een grotere applicatie, uitgebreide monitoring of aanvullende netwerkcomponenten.

Talos sluit in deze test het meest aan bij de opgegeven ondergrens van 2 GiB. De configuratie bleef functioneren bij 2 GB toegewezen geheugen, maar was bij 1 GB niet bruikbaar. Daarmee lijkt de gedocumenteerde vereiste in deze opstelling een realistischer uitgangspunt dan bij de andere kandidaten. Dat betekent niet dat de drie documentaties op dezelfde manier zijn opgesteld of dat de genoemde waarden rechtstreeks vergelijkbaar zijn. Minimumvereisten kunnen immers betrekking hebben op verschillende configuraties en gebruiksscenario's.

De bredere les is dat documentatie een belangrijk startpunt vormt, maar geen vervanging is voor testen met de daadwerkelijke workload en het beoogde hardwareplatform. Vooral bij embedded systemen, waar de geheugenconfiguratie vaak vooraf vastligt en achteraf niet eenvoudig kan worden uitgebreid, is het verstandig om voldoende ruimte te houden voor variaties in belasting en toekomstig onderhoud.

Compatibiliteit verdient aandacht

Naast resourcegebruik heb ik ook gekeken naar een aantal functionele eigenschappen van de drie configuraties. Daarbij bleek dat de oplossingen niet op alle punten dezelfde mogelijkheden bieden. Zo verschilt de beschikbaarheid van shell- en SSH-toegang, varieert het aantal standaard systeem-pods en is niet iedere kandidaat bedoeld voor dezelfde vorm van clusterbeheer. KubeSolo is gericht op single-nodegebruik, terwijl K3s en Talos ook kunnen worden ingezet voor multi-nodeclusters.

In de praktijk is de kans echter klein dat je op een embedded apparaat daadwerkelijk een multi-nodecluster opbouwt: de meeste embedded toepassingen draaien op zichzelf staand, zonder dat meerdere apparaten samen één cluster vormen. Voor de meeste praktijksituaties is dit verschil daarom minder relevant dan het op het eerste gezicht lijkt. Alleen wanneer een product later wordt ingezet in een scenario waarin apparaten juist wél gezamenlijk worden beheerd, kan het alsnog gaan meewegen. Iets vergelijkbaars geldt voor shell- en SSH-toegang: embedded apparaten worden doorgaans niet interactief beheerd, waardoor ook dit verschil in de praktijk minder zwaar weegt dan het op papier lijkt.

De vergelijking laat daarmee zien dat resource-efficiëntie en functionele geschiktheid twee verschillende vragen zijn. Een oplossing die weinig geheugen gebruikt, kan voor een specifieke toepassing uitstekend passen, maar alsnog beperkingen hebben die voor een productieomgeving onacceptabel zijn. Andersom kan een oplossing die meer geheugen gebruikt, juist aantrekkelijk zijn vanwege de manier waarop updates, beheer en beveiliging zijn georganiseerd.

CPU en opslag: minder doorslaggevend in deze test

Hoewel RAM het belangrijkste onderscheid tussen de drie kandidaten vormde, heb ik ook het CPU-gebruik en de benodigde opslag bekeken. Bij een idle-meting van vijf seconden, met twee vCPU's toegewezen, kwam KubeSolo uit op ongeveer 2,5% CPU-gebruik, K3s op 1,9% en Talos op 4,9%. Talos had daarmee het hoogste gemeten idle-gebruik, terwijl K3s in deze momentopname het laagste gebruik liet zien. Het zijn echter beperkte metingen: ze geven geen volledig beeld van piekbelasting, opstartgedrag of de prestaties wanneer applicaties actief zijn.

Ook het opslaggebruik verschilde. De gemeten schrijfbare opslag bedroeg ongeveer 925 MB voor KubeSolo, 1,2 GB voor K3s en 1,26 GB voor Talos, waarbij voor Talos daarnaast een afzonderlijke OS-image van circa 80 MB werd gerapporteerd. Voor de interpretatie is het belangrijk om dezelfde meetdefinitie aan te houden: de omvang van een image, de gebruikte opslag na installatie en de totale benodigde opslag voor een product zijn niet noodzakelijk hetzelfde. Containerimages, logs, updates en tijdelijke bestanden kunnen de benodigde capaciteit verder verhogen.

Op basis van deze beperkte metingen lijkt RAM de belangrijkste beperkende factor te zijn geweest in de onderzochte configuraties. Dat is een conclusie over deze test, niet over embedded Kubernetes in het algemeen. Op een apparaat met een zeer beperkte CPU, trage flashopslag of specifieke hardwareversnelling kunnen andere factoren veel belangrijker worden. Om vast te stellen hoe representatief de resultaten zijn voor echte embedded producten, zijn daarom aanvullende tests op fysieke hardware nodig.

Wat zeggen de resultaten nu werkelijk?

De belangrijkste uitkomst van dit onderzoek is niet dat één Kubernetes-distributie onder alle omstandigheden de beste keuze is. De resultaten laten vooral zien dat de architectuur van de gekozen oplossing invloed heeft op de hoeveelheid geheugen die nodig is en op de manier waarop een installatie zich gedraagt wanneer de beschikbare resources opraken. Binnen onze testopstelling had KubeSolo de kleinste gemeten geheugenvoetafdruk en bleef het functioneren bij de laagste geteste hoeveelheid RAM. K3s nam een tussenpositie in, terwijl Talos in deze configuratie meer geheugen nodig had.

Dat verschil moet worden afgewogen tegen de eigenschappen van de oplossingen. Voor een single-nodeapparaat met een zeer beperkt geheugenbudget is KubeSolo een interessante kandidaat voor verder onderzoek. K3s combineert een compactere Kubernetes-distributie met de optie tot multi-node-uitbreiding — een eigenschap die in de meeste embedded scenario's beperkt relevant zal zijn, maar die het onderzoeken waard maakt wanneer die uitbreiding wel aan de orde is. Talos biedt een andere combinatie van eigenschappen, met een immutable besturingssysteem en API-gestuurd beheer als belangrijke ontwerpkeuzes, wat kan opwegen tegen de hogere geheugenbehoefte. De juiste keuze volgt uiteindelijk uit de eisen van het product, niet uit één enkele benchmarkwaarde.

De test laat ook zien waarom het belangrijk is om onderscheid te maken tussen een systeem dat kan opstarten, een systeem dat een eenvoudige workload kan draaien en een systeem dat onder realistische omstandigheden betrouwbaar blijft functioneren. Die drie situaties worden in discussies over minimale hardwarevereisten nog weleens op één hoop gegooid. Voor een embedded toepassing is vooral de laatste relevant, omdat het apparaat na oplevering vaak langdurig zelfstandig moet blijven werken en niet zomaar extra geheugen of rekenkracht kan krijgen.

De volgende ronde

In een volgende fase wil ik de vergelijking uitbreiden met andere oplossingen, waaronder k0s, Kairos en MicroK8s. Daarmee ontstaat een breder beeld van de verschillende manieren waarop Kubernetes op een beperkte omgeving kan worden ingezet. Het doel is niet om zoveel mogelijk distributies op een lijst te zetten, maar om beter te begrijpen welke ontwerpkeuzes invloed hebben op resourcegebruik, beheerbaarheid en de functionaliteit die beschikbaar blijft.

Een bijzonder interessante vervolgstap is de combinatie met Yocto Linux. In plaats van te beginnen met een bestaande algemene distributie, kunnen we dan onderzoeken wat er gebeurt wanneer het besturingssysteem doelgericht wordt samengesteld voor een specifieke embedded toepassing. Dat maakt het mogelijk om de invloed van de Linux-basis afzonderlijk te onderzoeken en beter te bepalen hoeveel van het totale resourcegebruik wordt veroorzaakt door het besturingssysteem, de Kubernetes-distributie en de applicaties die erop draaien.

De centrale vraag blijft daarbij dezelfde: hoe klein kan Kubernetes worden zonder dat we de eigenschappen verliezen die het voor een bepaalde toepassing interessant maken? Het antwoord zal waarschijnlijk niet bestaan uit één universeel minimumaantal megabytes. Het zal afhangen van de combinatie van hardware, besturingssysteem, distributie, workload en operationele eisen. Met deze eerste vergelijking hebben we een beginpunt om die factoren systematisch te onderzoeken.

Alle metingen zijn direct uitgevoerd op een Proxmox-homelabcluster, oktober 2026. De workload was identiek (traefik/whoami, dezelfde image-digest) over alle drie de kandidaten. Methodologie en volledige ruwe resultaten zijn op aanvraag beschikbaar.