KubeCon 2024; Kubernetes onder de Eiffeltoren! - deel 2

Vanaf woensdag volgt na het CNFC Co-Located event de hoofdact van Kubecon. Naast allerlei geweldige talks en demo’s vindt er een manifestatie plaats van allerlei booths waar de befaamde, bekende en nog reeds onbekende tech bedrijven hun product laten zien. Het perfecte moment om naast het bezoeken van de vele sprekers ook even rond te kijken wat er gaande is in het CNCF- landschap. Vanaf woensdag tot en met vrijdag wordt er elke dag begonnen met een Keynote waar men onder het genot van een bak koffie een aantal uitgelichte presentaties kan volgen op de “Big-Stage”. Vervolgens wordt alles opengegooid en kan je helemaal los gaan! 

Woensdag – 20 april

Dealing with eBPF’s Observability Data Deluge

We bezochten onlangs een KubeCon presentatie van Anna Kapuścińska over “Dealing with eBPF’s Observability Data Deluge” en wilden graag onze bevindingen delen! 

In de presentatie van Anna verdiepten we ons in de uitdagingen en oplossingen rond de enorme hoeveelheid Observability data die door eBPF (extended Berkeley Packet Filter) wordt gegenereerd. Hier zijn enkele belangrijke punten: 

• Algemene problemen en use cases: Er werd gesproken over veelvoorkomende problemen bij het combineren van eBPF met Observability tools, waarbij de nadruk werd gelegd op de belofte van lage overhead, volledige zichtbaarheid en betrouwbaarheid. 
• Betrouwbaarheid en veiligheid: Ondanks dat ze soms onderschat worden, zijn eBPF programma’s geverifieerd en veilig uit te voeren dankzij de ingebouwde verificatie die de veiligheid van programma’s garandeerd. 
• Context en correlatie: Inzicht in systeem. Observability vereist context en correlatie. We moeten kernel-activiteiten binnen gebruikersverzoeken contextualiseren en gebeurtenissen correleren om zinvolle inzichten te verkrijgen. 
• Datacollectie en query’s: eBPF maakt gebruik van BPF maps als een key-value store voor efficiënte datacollectie en query’s. Het biedt opties voor zowel push- als pull-modellen, wat de overdracht van data van kernel naar user space vergemakkelijkt. 
• Beheer van dat complexiteit: We hebben de uitdagingen met betrekking tot datacomplexiteit aangepakt, waaronder cadinality, signaalruis, retentie en complexiteit, op basis van inzichten uit de observability-enquête van Grafana. 
• Oplossingen: Anna noemde verschillende oplossingen voor het beheer van de overvloed aan Observability data, waaronder Tetragon, Pixie en Grafana Beyla, die elk unieke benaderingen voor metrische gegevens, gebeurtenissen en tracespans bieden. 
• Praktische implementatie: Anna deelde inzichten in Tetragon, met nadruk op de rol ervan als een beveiligingstool die wordt aangedreven door Observability. We bespraken praktische stappen voor het effectief filteren en beheren van observability data binnen eBPF. 

Kortom, Anna onderstreepte het belang van het effectief beheren van de lawine aan Observability data met eBPF en bood praktische inzichten en oplossingen voor het optimaliseren van de zichtbaarheid en betrouwbaarheid van systemen. Meer informatie over eBPF is hier te vinden.

Is Serverless Powerfully Powerless?

Vorig jaar, tijdens KubeCon 2023 in Amsterdam, heb ik voor het eerst kennis gemaakt met het Kepler project. Toen alleen maar in de vorm van een lightning talk en is er verder weinig aandacht aan besteedt. Dit jaar kwam Kepler veel vaker terug in verschillende talks en zijn er veel verbeteringen doorgevoerd. Kepler staat voor Kubernetes-based Efficient Power Level Exporter en is een Prometheus exporter om zo je energieverbruik op je containerplatform inzichtelijk te krijgen. Onderliggend gebruikt Kepler de eBPF techniek om zo de CPU performance counters te ‘proben’. Niet alleen het verbruik hiervan, maar dus ook de efficiëntie van de workloads die je draait worden inzichtelijk. Dit is iets wat alles op een containerplatform ten goede komt, of dit nu grote of kleine workloads zijn.

Dit jaar kwamen er ook talks voorbij over de efficiëntie van workloads op Kubernetes. Hierbij werd Knative in combinatie met Kepler gebruikt om aan te tonen of het efficiënter is om een applicatie op een serverless wijze te laten draaien of ‘traditioneel’. Het antwoord op deze vraag was niet eenvoudig te beantwoorden. De enige manier om deze vraag te beantwoorden is het daadwerkelijk meten en inzicht krijgen in de applicatie. De slides tijdens de presentatie hebben laten zien dat het energieverbruik tegenover de aanvragen niet lineair is. Daarom is het heel belangrijk om te kijken hoe een applicatie functioneert door middel van serverless en ‘serverfull’. One size does not fit all! Dit betekent dat je eerst inzicht moet krijgen in de applicatie en op basis daarvan de beslissing kan nemen. Hierdoor bespaar je energie, geld of beiden. Hierdoor worden ook de workloads op de nodes beter verdeeld. 

Enforceable Software Supply Chain Policies and Attestations Using in-toto 

In 2020 kwam een hack bij onder andere de firma SolarWinds aan het licht. Hierbij werd een zogenaamde supply chain attack toegepast: hackers kregen toegang tot een buildserver van SolarWinds en gebruikten deze om gedurende een langere periode diverse malware te injecteren in Orion, een van de core producten van SolarWinds, dat o.a. grootschalig gebruikt wordt door de Amerikaanse overheid. Deze hack maakte duidelijk dat beveiliging van de gehele software supply chain naar een hoger niveau moest worden getild. 

Een belangrijke stap in dit proces is gemaakt door het project in-toto, niet zozeer een stuk software, maar meer een framework om supply chain policies en attestations te definiëren. Wat zijn attestations? Zie het als getuigenissen van een onafhankelijk waarnemer die voor elke stap in de supply chain getuigt over wat er in die stap is gebeurd en wat de stap heeft opgeleverd. Zo kan de volgende stap in de keten valideren dat wat aangeleverd wordt van een betrouwbare bron afkomstig is. 

Op dit moment wordt in-toto reeds ondersteund in bekende oplossingen zoals: GitHub, Tekton, verschillende security scanning tools en meer. Er is zelfs een CLI implementatie beschikbaar en uiteraard gebruikt SolarWinds tegenwoordig zelf ook in-toto om hun supply chain te beveiligen! 

Party Time!

De woensdag werd afgesloten op de Clud Native DevSec Party. Voor de gelegenheid hadden Palo Alto Networks en HashiCorp een super locatie afgehuurd aan de oevers van de Seine waar een ruimte onder de 19e eeuwse brug Pont Alexandre III is omgetoverd tot een hippe club met een prachtig uitzicht op Les Invalides en de Eiffeltoren. Onder het genot van hapjes en drankjes en de opzwepende deuntjes van een DJ hebben wij ons tot in de late uurtjes goed vermaakt! 

Donderdag – 21 april

 De Rustrevolutie: Hoe Rust de Toekomst is van Cloud-Native

In zijn presentatie “The Rustvolution: How Rust Is the Future of Cloud Native” beargumenteert Flynn van Buoyant dat Rust de programmeertaal bij uitstek is voor de toekomst van cloud native. Cloud native is een benadering van softwareontwikkeling die is ontworpen voor het bouwen en uitvoeren van toepassingen in de cloud. Het vereist betrouwbare, schaalbare en veerkrachtige systemen. Traditionele talen zoals C++ en C bieden weliswaar snelheid, maar missen geheugenveiligheid. Talen als Java bieden veiligheid, maar ten koste van snelheid. Rust daarentegen belooft het beste van beide werelden: snelheid én veiligheid. 

Flynn noemt hierbij vier redenen waarom Rust ideaal is voor cloud native omgevingen: 

1. Statische checks zijn veiliger dan runtime checks. Rust controleert je code tijdens het compileren op fouten, zodat bugs al worden geïdentificeerd voordat je code wordt uitgevoerd. 
2. Vrijheid om te coderen vereist het opgeven van pointers. Pointers, die rechtstreeks naar geheugenlocaties verwijzen, kunnen tot veiligheidsproblemen leiden. Rust elimineert de noodzaak van pointers door een ownership-systeem te gebruiken. 
3. Expliciet is veiliger. Expliciet zijn over hoe geheugen wordt beheerd kan lastiger zijn, maar voorkomt geheugenlekken en dangling pointers. 
4. Lifetimes elimineren de noodzaak van garbage collection. Lifetimes specificeren de levensduur van data, waardoor geheugen automatisch wordt vrijgegeven wanneer het niet langer nodig is. 

De voordelen van Rust gaan verder dan veiligheid en snelheid. Rust’s concurrency-model vergemakkelijkt het schrijven van parallelle code zonder dat u zich zorgen hoeft te maken over race conditions. 

Samengevat biedt Rust een unieke combinatie van veiligheid, snelheid, betrouwbaarheid en concurrentievoordelen, waardoor het een ideale taal is voor het bouwen van moderne, cloud-native applicaties. 

Leveling up WASM Support in Kubernetes 

Ik heb nooit echt de moeite genomen om me te verdiepen in WASM (WebAssembly), want laten we eerlijk zijn, er zijn al genoeg CNCF projecten om je mee bezig te houden. Echter, de aankondiging dat het SpinKube project was gedoneerd aan de CNCF triggerde mijn interesse. Wat maakt WASM nu interessant als alternatief voor de inmiddels wel bekende container? 

Voor degene die niet bekend zijn met WASM, WASM is ooit ontwikkeld als een byte code format om direct in een browser te draaien. Het idee erachter is dat de browser veel untrusted code moet uitvoeren, op een veelvoud aan verschillende platformen draait en bij voorkeur meer dan een enkele programmeer taal moet ondersteunen. WASM draagt hier in bij door je de mogelijkheid te geven om je eigen code te compilen in WASM byte code zodat deze cross platform kan draaien. WASM apps draaien daarnaast ook in hun eigen security sandbox en hebben verder geen enkele dependencies. 

Leuke anecdote: Tijdens de sessie werd een voorbeeld gegeven van een C++ library met code uit 1985 die voor Excel Online werd gecompiled in WASM. Wanneer je vandaag de dag een Lambda functie gebruikt in Excel Online wordt deze oude code in je browser uitgevoerd.  

WASM blijkt dus ideaal voor gebruik in de browser, maar blijkt ook perfect als runtime voor serverless functies. Dit is wat het SpinKube project probeert te ondersteunen. Het project maakt het makkelijk voor developers om hun code te compilen in WASM, er een OCI compliant image van te maken en te pushen naar een registry en vervolgens een deployment yaml te genereren. 

Wanneer deze vervolgens wordt gedeployed naar Kubernetes zorgt de containerd-spin-shim ervoor dat je WASM deployment nagenoeg identiek kan worden gemanaged als een reguliere container. 

Kortom, SpinKube en WASM bied de mogelijkheid om serverless workloads veilig te draaien met een minimale startup time, minimale footprint en een maximale portabiliteit. 

KuBBBecon 2024

Na de geslaagde eerste editie van vorig jaar was het het dit jaar de taak om een vervolg te geven aan het bowling avontuur tijdens KubeCon. Veel verschillende bedrijven en maar liefst 75 fanatieke bowlers waren dit jaar aanwezig in Parijs om te strijden voor de felbegeerde wisselbeker. Onder het genot van een drankje en hapjes werd er fanatiek door 9 teams tegelijk gebowld. Ook hier was er weer een goede mix tussen ontspanning, gezelligheid en een informele setting om kennis en ervaringen te delen met je vakcollega’s. Deze gezelligheid zorgt er soms dan wel weer voor dat iemand moet worden aangespoord om weer een balletje te gooien. Wat wil je als organisatie nog meer… Uiteindelijk kan er maar 1 team winnen; Stefan, Patrick, Peter, Rajesh en Florian bij deze nogmaals gefeliciteerd met de overwinning. Iedereen zal er volgend jaar weer op gebrand zijn om jullie te verslaan in Londen. 

Benieuwd naar de highlights van de laatste dag KubeCon 2024? Stay tuned!