KubeCon 2024; Kubernetes onder de Eiffeltoren! - deel 1

CNCF co-located events 

Nadat we de maandag gebruikt hadden om ons te settelen in Parijs was het dinsdag dan echt zover. De co-located events stonden voor deze dag op het programma. Tijdens deze dag worden vanuit allerlei invalshoeken en technieken separate één dag events georganiseerd. Deze co-located events zijn dus toegespitst op één specifiek onderwerp of technologie. 

Cilium + eBPF Day 

Vorig jaar spraken we nog over eBPF en Cilium als “the next big thing”. Inmiddels zijn we een jaar verder en zie je dat er veel gebeurd is. Cilium is gepromoveerd tot “graduated project” en Cilium is de standaard CNI binnen GKE en AKS. Doordat Cilium steeds meer gebruikt wordt zie je de focus van z’n project ook verschuiven. Deze Cilium en eBPF day begon met een deep dive in de architectuur van Cilium met betrekking tot de betrouwbaarheid. Hierin werd statedb gepresenteerd als de oplossing binnen Cilium om de desired state te kunnen waarborgen. Door het gebruik van deze oplossing kan in de toekomst Cilium beter omgaan met fouten of grote hoeveelheden aan transacties. 

Gevolgd op deze sessie werd er gesproken over schaalbaar beheren van Netwerk Policies binnen Cilium. Wanneer je duizenden pods moet beheren is het belangrijk dat je CNI schaalbaar en snel is. Met de komst van een selector cache en policy cache is Cilium in staat om bestaande entiteiten en policies te cachen. Hierdoor kan deze informatie vele malen sneller worden geraadpleegd wanneer vergelijkbare objecten worden aangemaakt binnen Kubernetes. Geïnteresseerd in de details, de slides vind je hier. 

ObservabilityCon – Kubernetes Security 

Security is in elk technisch landschap een belangrijk thema, zo ook binnen Kubernetes. Door de complexiteit van Kubernetes wordt ook het inrichten van een gedegen securitybeleid geen simpele opgave. Niet gek daarom dat deze KubeCon maar liefst 29 sessie gefocust waren op Security. 

Eén van deze sessies werd gegeven door Iain Smart van Controlplane en ging over het pentesten/offensive security testen van Kubernetes. Tijdens deze sessie toonde hij aan dat wanneer je bepaalde RBAC good practices niet volgt je erg gemakkelijk toegang kan verkrijgen tot een compleet cluster. Sommige zaken lijken erg voor de hand liggend maar toch worden deze good practices lang niet altijd opgevolgd. Het doel van Iain was dan ook om aan te tonen wat er mogelijk is en bewustwording te creëren over wat er allemaal wel niet mogelijk is in een complexe platform zoals Kubernetes. Ben je nou benieuwd over welke good practices gesproken werden, je kunt ze hier vinden. 

Platform engineering – Choas Engineer 

Het concept platform engineering is niet meer weg te denken tegenwoordig en natuurlijk was hier tijdens deze KubeCon ook ruim de aandacht voor. Eén van de concepten binnen platform engineering gaat over het betrouwbaar en stabiel bouwen van een platform. Een methode om dit beter te kunnen doen is het toepassen van “Chaos Engineering”. Sayan sprak over de cultuurwijziging die van toepassing is bij het introduceren van deze methode. Hiermee accepteer je dat instabiliteit en incidenten voorkomen op je platform. Door bewust instabiliteit toe te voegen ga je proactief opzoek naar zwakheden van je platform of applicatie. Uiteindelijk leidt dit tot meer bewustwording en kennis van je platform. Klinkt allemaal erg vanzelfsprekend maar binnen een organisatie kan het nog best een uitdaging zijn om management te overtuigen dat je expres instabiliteit wil introduceren binnen je productieplatform.

Fluent Bit versus Opentelemetry 

In zijn presentatie “Telemetry Showdown: Fluent Bit Vs. Opentelemetry – Comprehensive Benchmark Analasyis”, vergelijkt Henrik Rexed (youtube kanaal: isitobservable) twee populaire agents voor het verzamelen van telemetrie data: Fluent Bit en OpenTelemetry Collector. Welke agent is nu het best? 

Beide agents configureren we via een YAML-bestand. Fluent Bit fungeert in feite als een proxy voor logs en metrics. De sleutel hierbij is de “tag”, waarmee je de input identificeert (bijvoorbeeld Kubernetes of OpenShift). OpenTelemetry Collector gebruikt geen tags, maar routing. Afhankelijk van de resource (vergelijkbaar met tags) wordt een bepaalde pipeline uitgevoerd. In tegenstelling tot Fluent Bit (versie 2.0), vereist OpenTelemetry wel het definiëren van meerdere pipelines.  

Ronde 1: Logging
Zowel Fluent Bit als OpenTelemetry ondersteunen protocollen zoals UDP, TCP, Fluentd, Syslog, OpenTelemetry en Kafka (Collector heeft iets meer plugins). Voor de meeste use cases is dit echter voldoende. Beide agents kunnen data filteren, parsen en batchen. Parsen is met Fluent Bit krachtiger en gebruiksvriendelijker dan met OpenTelemetry. 

Ronde 2: Metrics
Beide agents kunnen data verzamelen van Collectd, Statsd, Prometheus, OpenTelemetry en host metrics. Een nadeel van Fluent Bit is het ontbreken van ondersteuning voor het her-labelen van metrics. OpenTelemetry Collector biedt daarentegen tal van opties voor filtering (Drop Cardinality) en het wijzigen van data. 

Ronde 3: Traces
Fluent Bit en OpenTelemetry ondersteunen beide OpenTelemetry plugins, maar OpenTelemetry ondersteunt daarnaast ook Zipkin, OpenCensus en Kafka. Voor het verrijken van data, beheerbeslissingen en het wegschrijven van traces is OpenTelemetry de winnaar. 

Ronde 4: Prestaties
De prestaties werden getest met logs, logs & traces en logs, traces & metrics. Bij alleen logs scoort Fluent Bit iets beter op CPU-gebruik, terwijl het minder geheugen verbruikt. Bij logs & traces is het CPU-gebruik vergelijkbaar, maar verbruikt Fluent Bit minder geheugen. Kies je voor logs, traces & metrics, dan vraagt OpenTelemetry Collector meer CPU en geheugen (ongeveer 1,5 GB meer). OpenTelemetry had last van een geheugenlek, maar dit is opgelost met “The Target Allocator”. Deze allocator zorgt ervoor dat data efficiënter wordt gemanaged. 

Een laatste tip: filter data al bij de bron (collector) om de verwerking later te vereenvoudigen. Voor puur log data is Fluent Bit een uitstekende keuze. Heb je te maken met metrics en traces, dan is OpenTelemetry Collector king!  

Monitoring Serverless Workloads 

In deze presentatie vertelt Ridwan Sharif over de monitoring van serverless workloads. Serverless biedt een aantrekkelijk ontwikkelmodel: je betaalt alleen voor wat je gebruikt. Dit betekent facturering per gebruik, snelle schaling en de mogelijkheid om containers te gebruiken. Serverless is zeer kosteneffectief, omdat je niet betaalt voor ongebruikte ruimte of inactieve CPU. Daarnaast hoef  je je geen zorgen te maken over het schalen van je code, wat leidt tot een snellere time-to-market.  

Serverless workloads zijn ideaal voor request-driven applicaties die werken via streams of events. Ze beschikken echter wel over een lokaal, tijdelijk bestandssysteem (ephemeral file system). 

Waarom is monitoring serverless complex?
Cloudplatformen bieden weliswaar ingebouwde metrische gegevens, maar het zelf implementeren van metrische gegevens in serverless omgevingen is lastig. Dit komt doordat serverless functies kortstondig actief zijn, soms slechts voor één request. Telemetrie moet daarom snel worden geëxporteerd. De meeste back-ends voor metrische gegevens staan cumulatieve metrische gegevens niet toe. Normaal gesproken zijn er twee datapunten nodig om cumulatieve gegevens te berekenen, maar dit is lastig bij serverless, omdat de functie mogelijk al is gestopt voordat de tweede data-scraping plaatsvindt. 

Daarnaast verwachten Prometheus-metrische gegevens meestal een pull-model in plaats van een push-model (waarbij de gegevens worden gepusht). Dit kan leiden tot problemen met Cloudflare-omgevingen, zoals beschreven door Colin Douch. Een bijkomende complexiteit is de configuratie voor het verzamelen van gegevens. Google heeft geprobeerd dit op te lossen door zogenaamde ‘sidecars’ te introduceren. 

Sidecars: De oplossing voor monitoringsproblemen?
Sidecars zijn containers die naast de hoofdcontainer van de serverless workload worden uitgevoerd. Ze delen netwerk, poorten en (tijdelijke) opslagruimte. Sidecars kunnen worden geconfigureerd als afhankelijkheid van container A en B, waarbij sidecar A vóór en ná B start en stopt. Op die manier wordt gegarandeerd dat de sidecar als afhankelijkheid wordt uitgevoerd: eerst de applicatie, dan sidecar A en vervolgens sidecar B. 

Met sidecars volstaat het om de sidecar toe te voegen aan uw serverless workload. De pull-based monitoring is wat complexer. Hierbij moet worden gegarandeerd dat er wordt gescraped, zelfs als de sidecar net is gestart. De laatste scraping moet binnen 10 seconden of bij afsluiting worden voltooid. Cumulatieve metrische gegevens worden vervolgens zoals ze zijn gerapporteerd. De configuratie van sidecars gebeurt via zogenaamde ‘secrets managers’ die fungeren als config-opslagplaatsen. Wijzigingen in de secrets worden automatisch gemount en bijgewerkt in de containers 

ArgoCon – Riskante deployments blokkeren met Kubescape 

We bezochten een fantastische presentatie van Matthias Betrschy en Laurent Rochette over “ArgoCD Security Gating” en leerden hoe Kubescape onze GitOps workflow kan versterken! 

Kubescape is een open-source CNCF-project (dat incubatie nastreeft, dus help ze!) dat fungeert als een beveiligingshek voor onze Kubernetes-deployments. Deze lichtgewicht CLI-tool scant op foutieve configuraties, kwetsbaarheden en algehele risico’s. De voordelen van Kubescape: 

• Flexibel & Uitbreidbaar: We integreren Kubescape naadloos in onze CI/CD-pipeline in verschillende stadia – VS Code, Backstage, CodeFresh, registerscans, Helm-deployments, zelfs Prometheus-waarschuwingen. 
• Blokkeert riskante deployments: Stel je voor dat ArgoCD deployments stillegt totdat Kubescape groen licht geeft! Deze demo liet precies dat zien – het stoppen van een deployment met een slechte image en een andere met privilege-escalatie ingeschakeld. 

De live demo was erg goed opgezet! De sprekers gebruikten een Argo Rollout CRD om deployments te orchestreren via ArgoCD met Kubescape als laatste security checkpoint. Het blokkeerde deployments met kwetsbaarheden en foutieve configuraties en gaf zelfs advies over oplossingen Meer weten? Kijk op Kubescape op GitHub: kubescape. 

BackstageCon 

Backstage is momenteel bezig met een enorme opmars. Niet zo vreemd ook: developer portalen helpen organisaties met het drastisch terugdringen van de tools waarmee een developer bekend moet zijn, maar niet per definitie nodig zou moeten hebben voor zijn of haar dagelijkse werk. Dit is dan ook zeer nadrukkelijk terug te zien in de cijfers. In de top 10 van CNCF project met de meeste end user commits torent Backstage er met kop en schouders bovenuit. 

Veel werk is het afgelopen jaar gestoken in het verbeteren van het plugin system van Backstage. Waarom? Backstage is behoorlijk complex. Het neerzetten van een solide Backstage implementatie vergt veel werk en kennis, vaak meer dan het kost om zelf een portal te bouwen en te beheren. 

De kracht van Backstage zit hem dan vooralsnog ook niet in het front-end. Zodra je zelfbouw oplossing 4 tot 5 feature requests in de backlog heeft staan en het steeds lastiger wordt om deze features tijdig en goed te implementeren wordt de kracht van Backstage duidelijk. Door het rijke plugin ecosysteem kost het toevoegen van functionaliteit die out-of-the-box meer dan 90% van de requirements afdekt een fractie van de tijd die het zou kosten als je de functionaliteit zelf zou moeten bouwen. 

 Zo is de integratie van plugins verbeterd. Het kost minder custom code om plugins te integreren, maar ook het delen van data tussen plugins onderling wordt hierdoor makkelijker. Een mooi voorbeeld hiervan is de Soundcheck plugin van Spotify, waarbij in een enkel dashboard de developer wordt voorzien van zijn compliance op het gebied van testing, resilience, code coverage, dependencies, etc. 

Daarnaast is het plugin systeem schaalbaarder gemaakt, waardoor de plugins (vooral de resource intensieve) op separate noders kunnen worden gehost. Als laatste lijkt het er op dat Spotify op 30 april aanstaande hun eigen Enterprise-grade distributie van Backstage zal uitbrengen onder de naam Spotify Portal. Gaat Spotify zich nu serieus commercieel mengen in de software supply chain markt? 

Isovalent’s Hive Mind Mingle 

Na een dag diverse co-located events gevolgd te hebben was het voor Benoit en Wouter tijd voor een feestje. Zij waren door Isovalent uitgenodigd om de traditionele Hive Mind Mingle tijdens KubeCon bij te wonen. Dit keer in de prachtige bar Le Perchoir Porte de Versailles direct naast de event locatie. Onder het genot van een cocktail en diverse lekkernijen hebben we tijdens deze avond lekker kunnen ontspannen. Natuurlijk wordt er op zo’n avond ook veel over techniek gesproken met vakcollega’s uit binnen– en buitenland. Een ideaal moment om ervaringen met elkaar te delen in een informele setting!

Vanaf woensdag volgt na het CNFC Co-Located event de hoofdact van KubeCon met veel interessante talks, maar ook leuke gesprekken bij de vele booths en andere events. Benieuwd naar de highlights van de andere dagen? Stay tuned!