Highlights Kubecon 2022; Kubernetes onder de Spaanse zon
Wat maakt Kubecon Kubecon? Een manifestatie rondom Kubernetes, Cloud Native, Containerisatie, Microservices en DevOps praktijken. Dit is dé plek voor mensen die geloven in minimaal één van deze bewegingen. Elk opererend binnen hun eigen maar ook gedeelde echokamers. Niemand op deze conventie hoeft overtuigd te worden met betrekking tot één van deze bewegingen. Ze komen hier om te zien wat er nieuw is binnen hun eigen vakgebied en wat er zich omheen afspeelt. Iets dat ze kunnen gebruiken om een probleem op te lossen voor hun klanten, bedrijf of iets dat hun dagelijks leven gemakkelijker maakt. Daarnaast is Kubecon ook een perfecte gelegenheid om de mensen waarmee je al die tijd virtueel samengewerkt hebt eens de hand te schudden. Ik ben zelf zo iemand die zijn weg probeert te vinden in de kloof der mogelijke oplossingen voor huidige maar zeker ook toekomstige problemen rondom dit landschap dat constant in beweging is. Aangezien ik vast niet de enige ben beschrijf ik in deze blog een aantal Highlights van Kubecon 2022!
Pre-Conference
Maandag kwamen mijn collega en ik aan in een prachtig stadje aan de oostkust van Spanje genaamd Valencia. Een 200 jaar oude stad met brede zandstranden, opvallende architectuur en bruisende cultuur. Al dit zonder de drukte van andere grote Spaanse steden als Madrid of Barcelona. Niet meteen een locatie die je in correlatie brengt met de stereotype IT-specialist. Of wellicht juist een perfecte combinatie om als IT-er iets buiten je comfort zone te stappen om na Kubecon en het netwerken ook eens een drankje te doen met andere helden. Maandag en dinsdag vonden er al wat co-located en gesloten evenementen plaats ter voorbereiding op de daadwerkelijke start van Kubecon op woensdag tot en met vrijdag.
Maandagavond begon al goed met een DoK co-located event waar ik eindelijk de DoK community ambassadeur Bart Farrell ontmoette. Bart Farrell is een bekende content creator en community builder afkomstig uit Spanje. Bart leidt momenteel de Data on Kubernetes Community (DoK). Deze community bestaat uit 25 bedrijven die zich richten op het vormgeven van het volgende decennium van datamanagement op Kubernetes. DoK heeft een geweldige community die zeer actief is op Slack. Elke week organiseert DoK live meetups waar technologen hun verhalen, wijsheid en praktisch advies delen over het draaien van data op Kubernetes. Ook nieuwsgierig waar data op Kubernetes heen gaat? Check hun website en join de community!
Dinsdag hebben wij, naast een aantal Kubecon gerelateerde inspanningen, gespendeerd om Valencia wat beter te leren kennen. En hoe beter dan gebruik te maken van het openbaar vervoer? Voor 5 euro per dag hadden wij toegang tot al het openbaar vervoer dat Valencia te bieden had. We namen de metro naar Fira de Valencia waar het Kubecon evenement plaats vond. Eenmaal aangekomen ontmoette ik wederom Bart Farell voor de ingang van Kubecon voor een persoonlijk interview over de DoK community. Vervolgens hadden wij op Kubecon onze toegangskaarten afgehaald en liepen wij daar rond vol anticipatie. Fira de Valencia is namelijk een prachtig groot complex, perfect voor Kubecon. De rest van onze tijd hebben wij op locatie onze gezamenlijke Kubecon strijdplan uitgelijnd en geperfectioneerd. Alles ter voorbereiding op de start van Kubecon op woensdag 18 mei 2022.
Woensdag – 18 mei
En toen was het daadwerkelijk zo ver. Van 18 tot en met 20 mei volgde een explosie aan informatie, nieuwe inzichten, netwerkgelegenheden en vele gesprekken met klanten en vrienden waarvan wij sommigen door de pandemie nog nooit fysiek de hand konden schudden. Er volgde lange dagen en korte nachten waaruit goede vriendschappen en herinneringen zijn ontstaan. Connecties die je door de waan van de dag niet zou maken vormde de orde van de dag. Aangezien er veel te zien en te doen was zal ik me richten op mijn highlights van deze drie dagen beginnende met de Opening Keynote door “Priyanka Sharma”, de Executive Director van de Cloud Native Computing Foundation.
Keynote Algemeen
De Opening Keynote wees mij er nogmaals op dat, zelfs tijdens de pandemie, het kubernetes- en CNCF-ecosysteem (Cloud Native Computing Foundation) niet heeft stilgestaan. Meer dan 65% van de bezoekers van Kubecon is nog nooit eerder op Kubecon geweest, waaronder ik. Deze hoeveelheid is uit te leggen door de groei van dit ecosysteem tezamen met de pandemie. Kubecon begon 6 jaar terug met 600 mensen en is inmiddels gegroeid naar een evenement met meer dan 7000 bezoekers. Inmiddels bestaan er 127 verschillende CNCF-projecten met 156k individuele contributors. Priyanka benadrukte dat een respectvolle samenwerking de weg naar succes is op de lange termijn. Toch blijft dit lastig met meer dan 800 verschillende bedrijven die samenwerken aan al deze verschillende projecten. De community moet elkaar met respect en genade behandelen om op een gezonde manier samen te blijven werken. Eén ding moesten wij echter nooit vergeten en vele van jullie kennen deze gezegde al “with great power, comes great responsabillity”.
Tijdens het stuk van Priyanka werd er ook aandacht besteed aan Oekraïne. Ihor Dvoretskyi, een geboren Oekraïense developer, vertelde vanuit Oekraïne over de situatie in het land. Vervolgens vertelde een vertegenwoordiger van Razom, wat tezamen betekent, over de tekorten aan medische benodigdheden aan de verschillende fronten rondom Oekraïne. Voor meer informatie hierover, check hun website.
Mercedes & Kubernetes
Een andere highlight was Mercedes met hun verhaal over waarom ze hun eigen cloud native ecosysteem opzetten. In het begin was de IT binnen Mercedes strak ingeregeld en niet geoptimaliseerd op snelheid maar op kostenbesparing. Toch begon, na een zoektocht naar moderne microservice orkestratie, een jong team van developers al met het hosten van applicaties in productie op kubernetes 0.9. Vijf tot zes jaar geleden waren delen van de Mercedes auto-configuratie applicatie al gehost op kubernetes en werd alles uitgerold via CICD pipelines. De developers behaalde uitrol snelheden die ongehoord waren binnen Mercedes. Vervolgens groeide de vraag naar het managen van de alsmaar groeiende kubernetes clusters binnen Mercedes. Omdat er geen gevestigde orde was koos Mercedes ervoor om alles met opensource op te lossen en droeg Mercedes ook bij aan de verbeteringen rondom Kubernetes door kennis en bugfixes terug te geven aan de community. Inmiddels draait Mercedes meer dan 900 Kubernetes clusters wereldwijd on-premise, en kijkt nu naar de Cloud voor verdere expansie. Alles beheerd door vijf platform teams met behulp van de chatops tooling als Slack. Het hele bedrijf is in 6 jaar omgeslagen van een klassieke Enterprise mindset tot een Cloud Native mindset. Een zeer mooie prestatie door Mercedes!
Intel’s groene vingers
Intel shockte ons vervolgens met een verhaal met een aantal feiten over de afgelopen 2 jaar. Sinds 2020 is het globale internetverkeer gegroeid met meer dan 40% en gebruiken datacenters meer dan 2% van de huidige wereldwijde stroomvoorziening. Er wordt verwacht dat dit in 2030 naar meer dan 8% zal stijgen. Het pijnlijkste is om vervolgens te horen te krijgen dat maar 40% tot zelfs 20% van deze CPU-kracht daadwerkelijk gebruikt wordt. Daarnaast vond ik de onderstaande tabel over welke programmeertalen weinig en welke meer gebruikt worden een eyeopener. Intel is in zee gegaan met de “CNCF Environment Sustainability Workgroup” die zich met dit soort onderwerpen bezighoudt. Samen met deze groep probeert Intel zelf en tezamen met partners als Red Hat om bijvoorbeeld het alloceren van CPU-kracht te verbeteren. Intel bevestigde op het eind nogmaals dat wij met zijn allen verantwoordelijk zijn en dat wij beter moeten nadenken over de eventuele ecologische footprint van onze keuzes.
Huawei & the Edge
Huawei kwam ook aan bod. Zij vertelde ons over hun KubeEdge en AI gebruiken om hun Low Earth Orbit (LEO)” satellietsystemen aan te sturen. Een slimme combinatie van lichtgewichte runtimes op de satelliet, die vervolgens gebruik maken van krachtige datacenters en AI om te satellieten te besturen. Aangezien er in het hele verhaal veel architectuur plaatjes en termen naar voren komen laat ik het bij dit onderstaande plaatje. Voor meer informatie suggereer ik om de dit onderdeel van de Keynote terug te kijken als deze eenmaal op YouTube staan. Het is een zeer goed verhaal met geweldig mooi pionierswerk.
Kubernetes & LDAP
In een daaropvolgende presentaties werd mij uitgelegd dat LDAP en k8s vriendelijk met elkaar overweg kunnen doormiddel van het gebruik van DEX tezamen met OauthProxy. Dex is een identiteitsdienst die OpenID connect gebruikt om apps te authentiseren door connectoren te configureren om authenticatie te verschuiven naar een externe entiteit, zoals een AD-server met behulp van het LDAP-protocol. Een interessante manier om jouw applicatie te beveiligen. Tijdens een hands-on tutorial heb ik op k8s ldap opgezet, gebruikers toegevoegd en vervolgens de Dex LDAP-connector geconfigureerd om via oauth2proxy de applicatie af te schermen met LDAP.
Prometheus & Digital Fingerprinting
Tijdens een presentatie over security werd mij verteld dat als je jouw applicatie of tooling niet goed genoeg afschermt iemand met kwade bedoeling zeer snel jouw applicatie of zelfs organisatie kan binnendringen. Eerst werd er een scenario beschreven waarin een DevOps team een on-afgeschermde opzet van Prometheus gebruikte voor het ophalen van hun metrieken vanuit de applicatie. Vervolgens werd er aan de hand van verschillende technieken, waaronder “Digital Fingerprinting”, uitgelegd hoe een hacker te werk gaat. Digital Fingerprinting is het proces waarbij een externe gebruiker kleine stukjes informatie verzamelt over de machine van een gebruiker, en deze stukjes samenvoegt om een uniek beeld, of “vingerafdruk”, te vormen van het apparaat van de gebruiker. Een soort informatiemap van het doelwit. Vervolgens werd er uitgelegd dat binnen het tijdspan van 2 minuten de informatie, die deze Prometheus setup lekte, gebruikt kon worden om het bedrijf binnen te dringen. Erg schrikbarend!
Donderdag – 19 mei
Kubernetes SIG’s
Dag twee startte met een Kubernetes Project Updates keynote. Hier vertelde Jasmin James over de laatste ontwikkelingen rondom Kubernetes aan de hand van SIG’s, Special Interest Groups. Ze behandelde vervolgens een aantal SIG’s. De eerste was SIG Security die zich bezighouden met een aantal initiatieven rondom Kubernetes en Security. Ze houden zich bezig met documentatie, tooling en auditen. Voorbeelden hiervan zijn hun initiatief om officiële en bevestigde kubernetes container images te realiseren. Daarnaast heeft deze groep ervoor gezorgd dat sinds k8s 1.23 Pod Security Admissionnu standaard aan staat op native k8s. Een andere groep is SIG Node. Node is een die verantwoordelijk is voor de componenten die de gecontroleerde interacties tussen pods en node bronnen ondersteunen. Een van hun contributies is het verwijderen van Dockershim en CGroup v2. Vervolgens kwam SIG Storage aan bod. Storage is verantwoordelijk voor de mogelijkheid tot Volume Expansion, Storage Capacity Trackingen CSI Migration. De volgend groep was SIG LifeCycle en deze groep is bezig om het mogelijk te maken om in k8s updates zo alledaags en makkelijk mogelijk te maken. De laatste groep die werd genoemd was SIG Scheduling. De scheduling groep houdt zich bezig met prestatieverbeteringen waaronder “pod schedule latency” en de launch van een nieuwe workgroup die zich gaat richten op “Batch workloads” inclusief AI en ML workloads. De grootste verbetering rondom scheduling is dat het nu mogelijk is om 300 pods per seconde te draaien.
Shopify’s Softwareleveringsketen
Na een korte update rondom Kubernetes vertelde Shane Lawrence van Shopify over de beveiliging van onze softwareleveringsketen. In verhaalvorm vertelt Shawn over het feit dat we eigenlijk nooit 100 procent zeker zijn of de softwarepakketten die wij via vele veelgebruikte “packet managers” installeren kunnen vertrouwen. De voorbeelden gingen van malware die je via een website installeert tot de befaamde “npm install fix-error” (een Trojan), de welbekende “curl pipe bash” reeks die veel gebruikt wordt om opensource softwarepakketten te installeren. Supply Chains zijn enorm fragiel en sommige Supply Chain problemen ontstaan per ongeluk of als initiatief georkestreerd vanuit overheden. Zelfs een van de robots op Mars draait Log4J, dus dit probleem is zelfs al interplanetair. Shopify levert een aantal suggesties hoe bedrijven zich hiertegen kunnen bewapenen door beter om te gaan met deze risico’s. Een voorbeeld is het gebruiken van “in-toto” naast het automatiseren van je builds. “in-toto” biedt een kader om de integriteit van de softwareleveringsketen te beschermen. Het doet dit door te verifiëren dat elke taak in de keten wordt uitgevoerd zoals gepland en daarnaast ook om bijvoorbeeld Trivy te gebruiken voor “vulnrability scans” en nog veel meer. Cyberattacks blijven onze Supply Chain plagen en Shawn dringt er dan ook op aan om te blijven samenwerken om ons hiertegen te bewapenen. Voor meer informatie check CNCF TAG Security.
Kubernetes en High Throughput Computing (HTC)
Vervolgens sprak Ricardo Rocha, een Computer Engineer vanuit CERN, over HPC, high performance computing op Kubernetes. Alle experimenten die ze uitvoeren bij CERN zorgen voor enorm veel data en in 2016 maakte Ricardo deel uit van een team dat Kubernetes ging gebruiken om al deze informatie zo snel mogelijk te verwerken. Zelfs met een 1000 node cluster lukte dit in het begin al niet omdat de k8s engine niet snel genoeg was in het “schedulen” van de Pods die het werk moesten uitvoeren. Door contributies vanuit CERN en samenwerking met Kubernetes is dit vandaag de dag echter wel mogelijk. Een voorbeeld is de mogelijkheid dat k8s nu al 300 Pods per seconde kan starten. Voor CERN gaat het in de context van HPC vooral over het behalen van Low Latency, High Throughput, NUMA Awareness, Software Distribution en Advanced Scheduling. Eigenlijk gaat het hier niet specifiek over HPC maar HTC. Terwijl HPC-systemen doorgaans gericht zijn op strak gekoppelde parallelle taken, betreft HTC-systemen daarentegen onafhankelijke, sequentiële taken die afzonderlijk kunnen worden gepland op veel verschillende computerbronnen. Vervolgens gaf Ricardo een mooie demo over een project genaamd “Kueue”. Kueue is een manager op jobniveau die beslist wanneer een job moet worden toegelaten om te starten en wanneer ze moet stoppen over bijvoorbeeld meerdere clouds mee. Zie deze Github voor meer info.
Metrieken in een Serverless Wereld
Naast de keynotes heb ik ook een presentatie bijgewoond over hoe Prometheus zou kunnen werken in een Serverless wereld. Prometheus staat bekend om metrieken op te halen van een bepaald applicatie endpoint en doet dit bijvoorbeeld elke 5, 10 of 15 seconden. Maar wat als de endpoint, bijvoorbeeld een serverless functie, maar een aantal milliseconde leeft? Een interessant onderwerp. Colin Douch, een SRE bij Cloudflare, heeft hier persoonlijk ervaring mee. Cloudflare bedacht een nieuwe dienst genaamd “Cloudflare Worker”, hun serverless offering. Echter kwamen ze er al snel achter dat informatie m.b.t. de kwaliteit lastig te achterhalen waren van diensten die maar kort leven. Colin en zijn team moesten snel tot een oplossing komen want meer en meer klanten gingen hun serverless oplossing gebruiken. Ze moesten een manier vinden om hun eigen nieuwe dienst te kunnen monitoren! Onder druk onderzochten ze wat hun opties waren met betrekking tot bestaande oplossingen. Prometheus is een Opensource “de facto” standaard voor het behalen van inzichten. Naast het ophalen van metrieken (elke 5,10 of 15 seconden) is het ook mogelijk metrieken naar Prometheus te sturen door bijvoorbeeld iets als de “Prometheus Push Gateway”. Echter behandelt Prometheus elke serverless instantie als een eigen identiteit, dus dit was ook niet handig. Ook keek Cloudflare naar de “Aggregation Gateway”. Dit product zorgt alleen voor een sommatie van de metrieken, echter zijn niet alle metrieken bij elkaar op te tellen. De teams die Cloudflare beheerde hadden counters, gauges, histogrammen en info metrics nodig. De enige oplossing was om zelf iets te bouwen. Toen presenteerde Colin hun eigen en opensource oplossing genaamd “Prometheus Gravel Gateway”
Gravel Gateway is een Prometheus Push Gateway voor FAAS toepassingen. Het stelt jou als gebruiker in staat om te bepalen wat voor aggregatie je toepast op het niveau van individuele metrieken door bepaalde label (clearmode) toe te voegen aan deze metrieken. Aan de hand van deze labels bepaalt de Prometheus Gravel Gateway wat voor soort aggregatie die toepast. Standaard wordt alles bij elkaar opgeteld (sum). Maar andere opties als “ clearmode=”family” zorgt ervoor dat bijvoorbeeld een metriek die gaat over de versie van een applicatie (bijvoorbeeld 0.0.1) niet bij elkaar opgeteld wordt, maar compleet vervangen wordt met de volgende versie (bijvoorbeeld 0.0.3) en pas vervangen wordt als de versie verandert, en niet elke keer bij elkaar opgeteld wordt als er nieuwe metrieken binnen komen. Dit project laat jouw metrieken sturen naar de Prometheus Gravel Gateway die zich vervolgens weer aan laat roepen (scrapen) door Prometheus. Daarnaast levert het ook andere opties als authenticatie, omgang met gauges (pebbels). Check vooral hun Github pagina voor meer informatie.
Opentelemetry!?
Een andere zeer interessant presentatie was die over Opentelemetry gegeven door Dotan Horovits. OpenTelemetry is een leverancier-neutrale standaard manier om telemetriegegevens te verzamelen voor applicaties, hun ondersteunende infrastructuren en overige diensten. Het is sinds kort tot een Cloud Native Computing Foundation project benoemd tezamen met de fusie van OpenCensus en OpenTracing projecten. Zelf vind ik dit een geweldig initiatief om verschillende standaarden samen te laten komen. Volgens Dotan moet telemetrie makkelijk in gebruik en goed gedocumenteerd zijn, het moet universeel zijn over alle talen en signaaltypes als tracering, metriek, logging, etc. Daarnaast streeft Opentelemetry naar een leverancier-neutrale standaard. Dit omdat het gebrek aan gemeenschappelijke normen of API’s geleid heeft tot vendor lock-in voor klanten en belemmerde innovatie door de nauwe koppeling tussen telemetrieverzameling, telemetrieopslag en -analyse. Opentelemartry’s waarden zijn gebaseerd op Compatability, Stability, Resilience en performance. Met OpenTelemetry kan je op een vendor-agnostische manier jouw applicatie instrumenteren en de telemetriegegevens analyseren in de backend tool naar keuze. Of dit nu Prometheus, Grafana, Elastic of anderen zijn. Op dit moment zijn tracing en metrics al stable en released en dit zal binnenkort ook gaan gelden voor logging. Een zeer actief en interessant project dat naast kubernetes als tweede staat op de ranglijst van aantal code commits binnen het CNCF-landschap.
ArgoCD Ecosysteem
Een van de drukbezochte sessies ging over het ecosysteem van ArgoCD. ArgoCD is het meest populaire “Kubernetes GitOps application delivery tool”. Naast het core project ArgoCD is er een snelgroeiend ecosysteem van projecten zoals Argo Events, Argo Rollouts, ApplicationSet, Argo CD Image Updater, Argo CD Vault Plugin, Argo CD Autopilot en Hera Workflows. Allemaal projecten vanuit de community. Als deze eenmaal volwassen en stabiel genoeg zijn worden deze samengevoegd met het Argo core project. Zo zijn ook de ApplicationSet en Argo Notifications projecten dit jaar aan ArgoCD toegevoegd. Uit onderzoek bleek dat iedereen die 1000+ applicaties met ArgoCD deployed ook gebruik maakt van ApplicationSets. Tegelijkertijd ziet men ook behoefte aan andere extensies van ArgoCD zoals een vault plugin, Certmanager, Helm en meer. Tegelijkertijd werkt men aan een plugin of extension systeem waarbij plug-ins onafhankelijk van het core project vrijgegeven en beheerd kunnen worden. Daarvoor komen een aantal tools beschikbaar zoals Manifest Generation, Resources Customization en API Extensions. De resource component library stelt je in staat om zelf makkelijk de ArgoCD UI aan te vullen. In de API extensions komt vanaf ArgoCD 2.5+ deep dive metrics voor performance metric providers voor onder andere Prometheus beschikbaar. Verder krijgt Argo Rollouts ondersteuning voor een API-gateway met een moderne set API’s om L4 en L7 routing in Kubernetes te deployen.
Vrijdag – 20 mei
How to Open Source?
De laatste dag van Kubecon werd geopend door Catherine Paganini van Buoyant (Linkerd) en Josh Berkus van Red Hat. Ze vertelde over dat opensource projecten weten dat ze code, review van documentatie en een platform nodig hebben als Kubecon om ervoor te zorgen dat mensen hun code gaan gebruiken. Maar wat hebben opensource projecten nodig waarvan niet iedereen weet heeft? Een aantal voorbeelden waren marketing, het maken van een Contributor Guide, Contributor Recruitment en Mentoring. Dit om ervoor te zorgen dat je project bekend wordt en het aantrekken en mentoren van contributors ervoor zorgt dat het project in leven blijft. Daaromheen heb je naast contributors ook leiders nodig en een manier om op een eerlijke manier beslissing te maken (gouvernance). Daarnaast zijn er ook vele andere evenementen als Kubecon. Gebruik bijvoorbeeld meetings, meetups en kleinere frequentere events om jouw project te promoten. CNFC kan je met veel van deze dingen ook helpen. Leer vooral veel van elkaar en zorg ervoor dat je niet het wiel opnieuw uitvindt. CNFC biedt hulp voor contributors en maintainers.
Security first
In een andere keynote talk spreekt Connor Gorman van Red Hat. Hij is de laatste 5 jaar werkzaam bij StackRoX, een Kubernetes security platform. Er zijn meer dan 5 miljoen developers bezig met kubernetes, echter zijn er niet evenveel securityspecialisten om ze bij te benen. Connor benoemt log4shell als voorbeeld waar vele mensen samenwerkten om de exploitatie hiervan te voorkomen het probleem op te lossen. Hoe schaal je security met zoveel developers? Volgens Conor moeten we security focused bouwen en het er niet achteraf inschroeven. Niet alleen met de code zelf, maar ook binnen onze code/image repositories en CI/CD pipelines. Dit zodat je als organisatie niet alleen achter de fouten aan loopt maar vooral ook snel jouw beveiligde code in productie krijgt.
CNCF Projecten
Vervolgens volgde er een aantal CNCF-project updates. Waar vele updates genoemd werden rondom een aantal interessante projecten binnen de CNCF. Voor meer informatie zie de CNFC Project Pagina.
Incubation Projects
Kubernetes Failover met Lunar
In een andere keynote vertelde Henrik René Høegh van Lunar over hoe ze failover vroeger deden (generatie 1) en hoe ze failover nu doen (generatie 2). Lunar is een nieuwe hippe bank binnen de Nordics waarmee die applicaties bouwt die men als dienst kan afnemen. Hun Tech Stack bestaat uit Kubernetes, GitOps, Flux, AWS RDS database, RabbitMQ en External DNS en werken met AWS en Azure als Cloudproviders. Daarnaast gebruiken ze Shuttle en Release-manager.
In de voorgaande generatie 1 failover branch zag het volgende cluster er net wat anders uit dan het bestaande cluster zoals de clustername, routingweights en meer. Vervolgens startte men een nieuwe cluster en stuurde het cluster via Flux naar de branch. Ze maken een federatie tussen de RabbitMQ (two-way federation) van het oude cluster en het nieuwe cluster naast een aantal andere aanpassingen. Vervolgens maakte men aanpassingen in main branch om de routingweights aan te passen van 80/20 naar bijvoorbeeld 40/60 tot er geen verkeer meer naar het oude cluster gaat. Als er geen verkeer meer naar het originele cluster gaat, werden de services verwijderd en het oude cluster uiteindelijk opgeruimd. Het lijkt wellicht simpel, maar als je in een crisissituatie zit kan er van alles fout gaan. Het voelde ook niet alsof dit past bij failover met GitOps. Lunar zocht een betere manier om dit te bewerkstelligen.
Vervolgens vertelde Henrik René over hoe Lunar op dit moment failover doet, generatie 2. Om de problemen op te lossen hebben ze zelf twee operators gemaakt. Cluster Identity Controller, die het makkelijk maakt om de clusternaam te achterhalen voor de applicaties. Daarnaast ook Cluster Routing Controller om aan te geven hoe het netwerkverkeer gerouteerd moet worden via routingweights. Daarnaast zijn ze Shuttle gaan gebruiken om de routing weights aan te passen.
Ze starten de failover door een nieuwe kubernetes cluster op te spinnen. Via flux wijzen ze naar een bepaalde repository, alles start op en er gaat nog geen verkeer naar het nieuwe cluster. Ze maken een federatie tussen de RabbitMQ (two-way federation). En op dit moment maken ze gebruik van shuttle om de routingweights aan te passen en te releasen met GitOps. Dit zorgt ervoor dat er geleidelijk per release meer verkeer naar het nieuwe cluster gaat. Vervolgens verwijderen ze de routing weights met shuttle en verwijderen ze het oude cluster op dezelfde manier.
Dit zorgde ervoor dat Lunar in plaats van 4 uur maar 40 minuten deed over een failover. En iedereen die het platform beheert kan nu een failover doen. Een mooi voorbeeld wat er allemaal mogelijk is met alle projecten die aanwezig zijn in het opensource landschap.
Suf-Conference
Zaterdag vlogen mijn collega’s en ik weer terug. Als SRE’er heb ik enorm veel genoten van Kubecon dit jaar en vooral omdat er zoveel interessante ontwikkelingen waren in de observability wereld. Een aantal voorbeelden zijn OpenTelemetry, Cilium en eBPF. De manier waarop er anders gekeken wordt naar een wereld met veel grote bekende namen en oplossingen is bijna overweldigend. Zelf zie ik het als een volgende fase binnen Observability, vol mogelijkheden.
Naast alle keynotes en breakoffsessions zijn wij ook langs alle solution-booths gegaan waar namen stonden als SUSE, Red Hat, Microsoft, NGINX en vele anderen als Prometheus, CertManager, Thanos, InfluxDB en Garden.io en nog veel meer. Te veel om op te noemen! Bij elke booth hadden wij goede gesprekken over hoe wij als HCS deze technologieën zouden kunnen adopteren om onze klanten nog beter van dienst te zijn. Wij hebben mensen ontmoet die wij al meer dan 2 jaar niet konden treffen en deze band hechter gemaakt dan ooit tevoren. Elke hand die wij schudden en elk gesprek die wij vervolgens voerden maakte dit fysieke event het helemaal waard. Dit evenement heeft mijn blik op het CNCF-landschap verbreed als nooit tevoren en zal mij op de korte en de lange termijn helpen de kloof voor de huidige en vooral ook toekomstige problemen te overbruggen. Daarnaast heeft het me ook laten zien dat ik en wij van HCS bij lange na niet de enige zijn binnen dit landschap. We are all-in IT together. Wij kijken uit naar de volgende Kubecon 2023 in Amsterdam. Ik zie er naar uit om jullie daar allemaal weer te spreken! Tot dan!
