Serverless zonder cloudlock-in

Draaien met Knative, OpenFaaS en KEDA op je eigen Kubernetes

Serverless roept nog altijd hetzelfde beeld op: functies draaien in een hyperscaler-cloud, automatisch schalen, betalen per milliseconde en verder nergens meer naar omkijken. Handig, zeker. Maar ook volledig afhankelijk van het platform waarop je draait. De runtime, de eventtriggers, de scaling-mechanismen en soms zelfs je programmeermodel zijn gekoppeld aan één leverancier.

De vraag die steeds vaker op tafel ligt: kun je het serverless-principe toepassen zonder die afhankelijkheid? Kun je functies, event-driven workloads en automatische scaling draaien op je eigen VPS-omgeving of bare metal cluster?

Het korte antwoord: ja. Het langere antwoord is dat je dan moet begrijpen wat serverless daadwerkelijk is, en hoe Kubernetes de bouwstenen al in huis heeft. Tools als Knative, OpenFaaS en KEDA bouwen daarop voort en maken serverless mogelijk zonder dat je je workloads vastzet in een hyperscaler-ecosysteem. Dit artikel gaat over hoe dat werkt, wat de verschillen zijn tussen die frameworks, en wat er nodig is om het op eigen infrastructuur goed neer te zetten.

Wat serverless werkelijk betekent

Serverless betekent niet dat er geen servers zijn. Het betekent dat je als ontwikkelaar niet bezig wilt zijn met het beheren ervan. In de klassieke cloudvariant draait je code als een functie die wordt getriggerd door een event. Je definieert een runtime, levert code aan, en het platform zorgt voor:

• container lifecycle;
• autoscaling;
• load balancing;
• eventrouting;
• logging.

Je betaalt per uitvoering of per verbruikte resources.

De essentie van serverless is dus niet de cloudprovider, maar het execution model:

• event-driven;
• schaal naar nul wanneer idle;
• automatisch opschalen bij load;
• geen langdurig draaiende infrastructuur nodig.

Dat model kun je ook realiseren op Kubernetes. Kubernetes is al een orchestration engine voor containers. Het beheert pods, schaalt replica’s, herstart bij falen en verdeelt verkeer via services en ingress. Wat het niet standaard doet, is schalen naar nul of event-gedreven functies als eerste klasse ondersteunen. Daar komen serverless frameworks om de hoek kijken.

Waarom serverless op Kubernetes?

Kubernetes is in veel organisaties al het platform voor applicatie-uitrol. Containers draaien er, CI/CD is erop ingericht, monitoring is aangesloten. Als je serverless toevoegt aan hetzelfde cluster, vermijd je een aparte execution-omgeving bij een hyperscaler. Dat heeft een paar duidelijke voordelen.

Als je serverless op je eigen Kubernetes-cluster draait, houd je de infrastructuur in eigen hand. Je bent niet gebonden aan een runtime die alleen binnen één cloudomgeving bestaat, omdat je functies gewoon als containers worden gebouwd en uitgerold. Daardoor blijven ze verplaatsbaar. Bij een verhuizing naar een andere omgeving hoef je niet je hele applicatiemodel opnieuw op te bouwen.

Ook je data blijft waar jij die wilt hebben. Voor organisaties met compliance-eisen of strikte eisen rond datasoevereiniteit is dat belangrijk. Je bepaalt zelf in welk datacenter of op welke VPS-omgeving workloads draaien en waar gegevens worden opgeslagen.

Een bijkomend voordeel is dat serverless geen aparte wereld wordt naast je bestaande architectuur. Binnen hetzelfde cluster kun je lang draaiende services combineren met event-gedreven functies. Een API kan bijvoorbeeld bestaan uit vaste backendservices, aangevuld met functies die alleen starten wanneer er een specifieke trigger binnenkomt. Alles draait onder dezelfde orkestratrielaag.

Financieel betekent dit dat je geen aparte executionkosten betaalt bovenop je infrastructuur. Je gebruikt de capaciteit van je eigen cluster en optimaliseert die zoals je dat gewend bent, of dat nu op VPS-nodes is of op bare metal.

Daarmee neem je wel extra verantwoordelijkheid op je schouders. Het clusterbeheer, de schaalmechanismen en de observability regel je zelf. Serverless op Kubernetes is geen kant-en-klare dienst, maar een bewuste architectuurkeuze waarbij controle en beheer samenkomen.

Knative, OpenFaaS en KEDA

Er zijn meerdere frameworks die serverless op Kubernetes mogelijk maken. De drie meest gebruikte in zelfgehoste omgevingen zijn Knative, OpenFaaS en KEDA. Ze lossen hetzelfde probleem op, maar op verschillende manieren.

Knative

Knative is waarschijnlijk de meest “cloud-native” benadering. Het bouwt direct bovenop Kubernetes en voegt twee kerncomponenten toe: Serving en Eventing.

Knative Serving maakt het mogelijk om containers te draaien als schaalbare services die automatisch kunnen schalen tot nul. Het beheert revisions, routing en traffic splitting. Dat laatste is interessant voor canary deployments of gradual rollouts.

Knative Eventing introduceert een eventmodel met brokers en triggers. Events kunnen afkomstig zijn van HTTP, messaging-systemen of andere bronnen. Je definieert welke service op welk type event reageert.

Knative voelt minder als een klassiek functions-as-a-service-platform (FaaS), waarbij je losse functies uitrolt die per request worden gestart, en meer als een uitbreiding van Kubernetes zelf. Je werkt met volledige container images in plaats van kleine functie-snippets. Dat past beter bij teams die al containergebaseerd werken.

OpenFaaS

OpenFaaS is explicieter gericht op functions-as-a-service. Je definieert functies via templates, vaak met een specifieke runtime zoals Python, Node of Go. Het platform bouwt daar automatisch container images van en beheert de scaling. OpenFaaS biedt een gateway die inkomende requests naar functies routeert. Schalen kan op basis van requests per seconde of queue-lengte.

Het voordeel van OpenFaaS is de eenvoud. Voor ontwikkelaars voelt het dichter bij traditionele serverless-diensten. Je schrijft een functie, pusht die, en het platform regelt de rest. Daarmee voeg je wel een extra laag toe bovenop Kubernetes. Je bent dan afhankelijk van de manier waarop OpenFaaS die laag opbouwt en beheert.

KEDA

KEDA, Kubernetes Event-Driven Autoscaling, is een andere benadering. Het is geen volledig FaaS-platform, maar een autoscaling-component. KEDA schaalt bestaande deployments op basis van externe events. Het kan bijvoorbeeld schalen op basis van:

• berichten in een Kafka-topic;
• lengte van een Azure Service Bus queue;
• Prometheus-metrics;
• Redis-streams.

KEDA gebruikt Kubernetes’ native Horizontal Pod Autoscaler en voegt event-gedreven triggers toe. Het ondersteunt ook schaal naar nul. In combinatie met een standaard deployment of met Knative kun je zo een event-driven architectuur bouwen zonder een aparte FaaS-laag.

De keuze tussen deze drie hangt af van je doel:

• Wil je container-first met sterke integratie in Kubernetes? Dan is Knative logisch.
• Wil je klassieke functions-as-a-service? Dan past OpenFaaS beter.
• Wil je vooral event-gedreven scaling toevoegen aan bestaande workloads? Dan is KEDA voldoende.

Hosting op eigen infrastructuur

Serverless op je eigen infrastructuur betekent dat je Kubernetes-cluster stabiel en goed ingericht moet zijn. Op een VPS-omgeving kan dat bijvoorbeeld met een managed control plane of een zelf opgezet cluster via kubeadm. Op bare metal werk je vaak met een CNI zoals Calico of Cilium voor netwerkbeheer.

Belangrijk is dat je cluster voldoende elasticiteit heeft. Serverless workloads schalen op basis van load. Als je onderliggende nodes geen ruimte hebben, stopt het voordeel. Dat betekent dat je vooraf goed moet bepalen hoe je capaciteit regelt. Laat je nodes automatisch opschalen wanneer de belasting toeneemt, of werk je met vaste capaciteit die je handmatig uitbreidt? In een serverless-achtige opzet kan de vraag plotseling stijgen, dus je onderliggende infrastructuur moet die pieken kunnen opvangen.

Daarnaast stel je per namespace duidelijke resource limits in. Zonder grenzen op CPU en geheugen kan één workload disproportioneel veel capaciteit opeisen. Dat raakt niet alleen de betreffende functie, maar mogelijk het hele cluster. Ook de netwerkdoorvoer verdient aandacht. Event-gedreven workloads kunnen in korte tijd veel verkeer genereren, zeker wanneer meerdere functies gelijktijdig opschalen. De netwerklaag moet dat aankunnen zonder latency of pakketverlies.

Ook speelt storage performance een rol. Wanneer functies afhankelijk zijn van persistente volumes of externe opslag, bepaalt de snelheid van die laag hoe snel ze werkelijk kunnen opschalen. Trage I/O kan een bottleneck vormen, ongeacht hoe goed je autoscaling is ingericht.

Daarnaast moet je ingress goed zijn ingericht. Knative bijvoorbeeld gebruikt vaak Istio of een andere service mesh voor routing. Dat voegt complexiteit toe, maar maakt geavanceerde traffic management mogelijk.

Een ander aandachtspunt is cold start. Wanneer je schaal naar nul toepast, duurt het even voordat een nieuwe pod is gestart en ready is. Dat is geen probleem voor batchprocessen, maar kan merkbaar zijn bij latency-gevoelige API’s. Op eigen infrastructuur bepaal je zelf hoe je hiermee omgaat. Je kunt minimale replica’s instellen of agressieve scaling thresholds aanpassen.

Praktische setup-tips

Wie serverless op Kubernetes wil draaien zonder hyperscaler-afhankelijkheid, moet het pragmatisch aanpakken.

• Begin klein. Installeer bijvoorbeeld eerst KEDA op een bestaande deployment en test event-gedreven scaling. Kijk hoe je metrics werken en hoe je cluster reageert op loadpieken.
• Als je Knative gebruikt, zorg dat je ingress en DNS goed zijn geconfigureerd. Knative werkt met services die automatisch URL’s krijgen. Dat vereist een consistente netwerkconfiguratie.
• Houd observability vanaf dag één in de gaten. Serverless workloads schalen dynamisch. Zonder goede metrics en logging zie je niet waarom iets opschaalt of waarom het niet terugschakelt.
• Denk ook aan resource requests en limits. Serverless betekent niet onbeperkt resources gebruiken. Zonder duidelijke limieten kan een burst je cluster onder druk zetten.
• Behandel je serverless-framework als een kerncomponent van je platform. Updates, beveiligingspatches en compatibiliteit met je Kubernetes-versie zijn geen bijzaak.

Minder afhankelijk, niet minder complex

Serverless op Kubernetes zonder cloudlock-in klinkt aantrekkelijk. En dat is het ook, mits je begrijpt wat je doet. Je krijgt flexibiliteit. Je workloads blijven containergebaseerd. Je data blijft op je eigen infrastructuur. Migratie tussen omgevingen wordt eenvoudiger.

Maar je neemt ook verantwoordelijkheid over. Voor clusterbeheer. Voor scalingmechanismen. Voor beschikbaarheid. Het verschil met hyperscaler-serverless is dus niet dat je minder werk hebt. Het verschil is dat je zelf de controle houdt over de laag waar het gebeurt.

Voor ontwikkelaars en DevOps-teams die al werken met containers en Kubernetes is dat vaak een logische stap. Serverless wordt dan geen aparte wereld, maar een uitbreidingspatroon binnen je bestaande platform.