3 belangrijke Kubernetes-trends voor 2023

Trend 1 - eBPF (Extended Berkeley Packet Filter)

eBPF maakt de Linux kernel programmeerbaar. Men kan hier dynamische programma’s mee draaien die de kernel kunnen uitbreiden, of die zelfs kunnen veranderen hoe de kernel zich gedraagt.

eBPF-programma's, vaak geschreven in C, worden rechtstreeks in de kernel uitgevoerd, waardoor ze extreem snel en efficiënt zijn. eBPF-programma's kunnen door de ontwikkelaar worden gekoppeld aan een systeemgebeurtenis (bijvoorbeeld dat een netwerkkaart een pakket verstuurt) en kunnen daarom worden gebruikt voor diverse doeleinden, zoals het monitoren en aanpassen van netwerkverkeer.

eBPF is niet per se een nieuwe technologie, maar heeft de laatste tijd wel flink aan populariteit gewonnen door de toepassingen binnen Kubernetes. De voornaamste toepassing van eBPF in Kubernetes op dit moment zijn services meshes.

Service meshes

Een service mesh zorgt ervoor dat verschillende applicaties data met elkaar kunnen delen, en dat beheerders deze data beter kunnen controleren en beveiligen. Services meshes zien we vooral terug in complexe omgevingen met een grote hoeveelheid pods verdeeld over meerdere clusters.

Op dit moment werken de meeste service meshes nog met de sidecar-architectuur, waarbij elke pod wordt uitgerust met een proxy dat ervoor zorgt dat de applicatie onderdeel wordt van de service mesh.

De sidecar-architectuur heeft een aantal nadelen:

• In grotere omgevingen, met bijvoorbeeld honderden pods, moeten ook honderden proxies worden geïnjecteerd, wat extra systeemcapaciteit vraagt.
• Bij het snel opschalen kan het even duren voordat de proxy actief is (cold start-tijd)
• Door het toevoegen van een proxy-laag moet een netwerkpakket door meerdere TCP/IP lagen voordat het de applicatie bereikt, wat een negatieve invloed heeft op voornamelijk CPU-prestaties en netwerk-latency.

Deze nadelen worden opgelost door service meshes op basis van eBPF-technologie, omdat deze taken worden afgehandeld in de kernel zelf, in plaats van via een proxy.

De voordelen van eBPF

De voornaamste voordelen van eBPF zijn:

1. Betere performance. Omdat eBPF binnen de kernel draait is er een vlottere stroom van data. Alle pods communiceren namelijk direct met een universele proxy, in plaats van met aparte sidecars.
2. Meer inzicht. eBPF kan inzicht geven in wat er gebeurt binnen de kernel zelf. Met tools zoals Pixie en Hubble van Cilium kunt u bijvoorbeeld een grafische weergave krijgen van uw kernel, en sneller fouten opsporen.
3. Minder moving parts. Door eBPF zijn sidecars overbodig.

Trend 2 - Kubernetes “at the edge”

Steeds meer apparaten zijn verbonden aan het internet. De ontwikkelingen binnen de Internet of Things (IoT) zorgen ervoor dat data wordt verzameld op steeds meer verschillende apparaten - niet alleen computers en telefoons. Denk bijvoorbeeld aan medisch apparatuur of machinesensoren.

Databronnen, zoals sensoren in machines, zijn vaak afgeschermd in streng-beveiligde netwerken. Dit maakt het gebruik van Edge Computing interessant. Door dataverkeer vanuit het machinenetwerk te verwerken en te versturen naar een centraal platform zijn er geen ingangen nodig binnen het machinenetwerk.

Door het gebruik van Kubernetes in de Edge kunnen de voordelen van Kubernetes naar de Edge worden gebracht. Denk bijvoorbeeld aan:

• Beschikbaarheid van service mesh tooling voor het veilig uitrollen van gedistribueerde applicaties.
• Flexbiliteit, zoals centrale management (evt. met GitOps) en self-healing capaciteiten.
• Eenvoudige(re) uitrol. Wanneer een machine stuk gaat is het eenvoudig om een nieuwe Kubernetes-machine te plaatsen en de applicatie opnieuw uit te rollen, mocht er geen redundantie aanwezig zijn.

Steeds meer providers introduceren tools om decentrale Kubernetes-clusters centraal te beheren, zoals Azure Arc en Rancher K3s.

Trend 3 - GitOps: Infrastructure as Code

GitOps is een onderwerp dat al langer rondgaat binnen de DevOps/Kubernetes-wereld, maar ook voor 2023 blijft dit een belangrijk thema. Tijdens de Kubernetes Community Days zijn ook diverse keynotes gegeven omtrent dit thema, zoals over het product ArgoCD.

Nu Kubernetes in steeds meer organisaties de norm wordt, en langzaam z’n intreden doet in de enterprise-wereld (Rabobank heeft hierover gesproken op de KCD), wordt het gedistribueerd uitrollen van applicaties op een veilige, gecontroleerde manier steeds belangrijker.

Kubernetes deployments behoorden eigenlijk altijd al tot Infrastructure as Code. Met behulp van tools zoals Helm of Kustomize kunnen configuraties worden opgeslagen in Git repositories. Echter, het probleem blijft dat de uitrol van applicaties vaak nog steeds vanaf een lokale machine (van de ontwikkelaar) wordt uitgevoerd. Dit is foutgevoelig, en bij het gebruik van meerdere Kubernetes-clusters ook onhandig.

Voor organisaties die werken met meerdere ontwikkelaars, en met meerdere clusters, is een GitOps-tool zoals ArgoCD of Flux belangrijk voor een geïntegreerd deployment- én audit-proces. Elke grote cloudprovider is hier inmiddels ook mee bezig, zoals AWS, Azure en GCP, die recent ook nog het GitOps observability dashboard hebben geïntroduceerd.

GitOps (tooling) kent twee vormen van deployment:

• Push deployments, waarbij bijv. een CI/CD pipeline een Kubernetes container deployment afvuurt naar het cluster.
• Pull model, waarbij een agent, actief binnen het Kubernetes-cluster, controleert of de infrastructuur nog steeds dezelfde status (desired state) heeft zoals beschreven in Git. Mocht de configuratie zoals deze in Git staat afwijken van de uitgerolde configuratie, dan probeert de GitOps-tool deze weer gelijk te maken.

GitOps beschrijft dus:

1. Op welke manier je omgaat met Infrastructure as Code - idealiter net zoals bij softwareontwikkeling: met versiebeheer, automatische tests van gevalideerde code (vier ogen) en een single source of truth.
2. Het centraal en geautomatiseerd uitrollen van de laatste gevalideerde versie van de infrastructuur.