Heeft jullie organisatie regelmatig te maken met piekbelasting? Dan is Kubernetes de oplossing om razendsnel (reken)capaciteit en geheugen voor applicaties op te schalen, zodat je overbelasting voorkomt. In deze monsterblog vertellen we wat Kubernetes is, hoe je het optimaal inricht en geven je tot slot een concrete checklist waarmee je bepaalt of deze oplossing ook voor jullie situatie werkt.

Kubernetes: wat is het en waar gebruik je het voor?

Kubernetes vereenvoudigt op- en afschalen in de cloud door applicaties ‘horizontaal’ te schalen. Daarmee blijven apps ook tijdens piekbelasting soepel draaien. Omdat Kubernetes alleen opschaalt wanneer dat nodig is, voorkom je kostbare overcapaciteit. Je betaalt alleen voor de extra capaciteit tijdens de piekbelasting. Zo weet je dat er altijd genoeg servers beschikbaar zijn, zonder dat je op momenten dat het niet nodig is, betaalt voor onbenutte capaciteit.
Kostenbesparing is het grootste voordeel van Kubernetes. Maar het heeft meer sterke punten: het geeft je inzicht in je kosten en performance, en stelt je in staat snel aanpassingen aan je applicatie door te voeren.

Hoe werkt het?

Kubernetes is een open source containersysteem dat de implementatie, schaalvergroting en beheer van applicaties orkestreert. Dat is met name interessant wanneer applicaties op bepaalde momenten ineens massaal worden aangeroepen. In die gevallen kan een server overbelast raken vanwege onvoldoende rekencapaciteit of geheugen. Het gevolg is uitval of vertraging die storend is voor gebruikers en mogelijk ten koste gaat van de productie of omzet.
Tijdens zo’n piekbelasting kloont Kubernetes de applicatie. We noemen dat horizontaal schalen. Er staan dan als het ware meerdere versies van dezelfde applicatie naast elkaar. Waar eerst 1000 mensen tegelijkertijd gebruik kon maken van de applicatie, kunnen de applicatie en de kloon op 2 servers dan samen 2000 gebruikers aan. Naar behoefte kan dat worden uitgebreid naar 3 servers voor 3000 enzovoort.

Hoe vangt Kubernetes capaciteitstekort op?

Er zijn 2 manieren waarop Kubernetes kan schalen:

1. op pods- of applicatieniveau (in cluster)
   Dit houdt in dat je op applicatieniveau de applicaties omzet in kleine virtuele machines die als replica van elkaar functioneren. Kubernetes beheert deze en zorgt dat ze goed communiceren met alle benodigde services zoals de database, de gebruiker, het internet etc. Zonodig krijgen ze ook meer geheugen toegekend.
2. op clusterniveau
   Op een hoger niveau kun je ook de horizontaal geschaalde applicaties samen een cluster laten vormen, die op zijn beurt ook weer horizontaal geschaald kan worden. In die zin werkt Kubernetes dan als programma binnen de clusters. Ook de servers waarop Kubernetes draait, zijn een cluster.
   Wanneer een cluster of een server tegen de maximale capaciteit aanloopt, dan schakelt Kubernetes automatisch extra resources (in dit geval dus servers) bij.

Toepassingen voor Kubernetes

Deze twee niveaus van klonen, zorgen ervoor dat Kubernetes ingezet kan worden om verschillende redenen:

• Automatisch opschalen bij piekbelasting
  Deze reden noemden we al. Als een server bij gebruiker 1001 begint te haperen, dan leidt Kubernetes deze gebruiker door naar de volgende beschikbare server. Die extra servers worden automatisch gestart. Kubernetes bepaalt welke interactie naar welke server gaat. Beheer heeft hier geen omkijken naar.
• Overzichtelijk beheerlandschap
  Kubernetes vereenvoudigt ook van het beheer van applicaties. In een complex IT-landschap met veel data, applicaties, diensten en gebruikers maakt Kubernetes het geheel overzichtelijker. Dat doet het door te werken met groepen van applicaties in plaats van met individuele servers.
• Uptime tijdens ontwikkelen en updaten van applicaties
  Met Kubernetes kun je dezelfde applicatie in verschillende versies naast elkaar laten draaien. Daardoor kun je een applicatie updaten, zonder dat gebruikers er last van hebben. Je schakelt pas de nieuwe versie in als alles is geaccordeerd.
  Ook kun je verschillende gebruikersgroepen creëren die op verschillende versies werken, bijvoorbeeld in de test- of productieomgeving of ten behoeve van een A/B-test.

De voordelen van Kubernetes

Kubernetes heeft zowel voor beheer als voor de eindgebruiker voordelen:

Eenvoudig en flexibel automatisch opschalen

Het belangrijkste voordeel is duidelijk: Kubernetes schaalt automatisch op wanneer dat nodig is, zonder tussenkomst van beheer.

Minder vertraging en uitval

Door overbelasting te voorkomen, is er minder uitval en vertraging. Kortom, minder verstoringen van de verkoop- en bedrijfsprocessen.

Betalen naar gebruik

Extra servercapaciteit is kostbaar. Zeker wanneer je deze niet continu gebruikt, maar alleen als reserve bij piekbelasting. Met Kubernetes betaal je alleen voor de extra capaciteit op het moment dat je die daadwerkelijk gebruikt.

Minder beheer

Natuurlijk kun je ook meerdere applicaties naast elkaar op servers zetten om piekbelasting op te vangen, maar dat vereist nogal wat van je architectuur, beheer en dataverkeer. Je moet continu de maximumcapaciteit van de servers monitoren en op tijd een extra server inschakelen. Dat bijschakelen vereist in de meeste gevallen handmatige handelingen en, zonder extra services, bovendien een ingewikkelde architectuur en veel data(verkeer). Wat opnieuw ervoor zorgt dat een server al snel volloopt.

Controle voor de IT-manager

De IT-manager kan op elk moment inzien hoeveel capaciteit wordt gebruikt. Kubernetes levert rapportages over de performance. Deze helpen je als IT-manager om proactief issues op te sporen.

Kostenoverzicht

Omdat je als IT-manager inzicht hebt in de gebruikte capaciteit, weet je beter wat er daadwerkelijk wordt gebruikt en kun je de uitgaven daarop afstemmen. De benutte capaciteit kun je per applicatie of cluster bekijken. Dat geeft meer inzicht dan de gebruikte capaciteit voor een hele server.

Minder foutgevoelig

Wanneer IT zelf omgevingen of applicaties dupliceert, leidt dit gemakkelijk tot fouten. Zijn alle instellingen juist overgenomen? Wordt er niet teveel capaciteit bijgeschakeld? Bovendien kost het nogal wat tijd om uit te zoeken wat werkt en wat niet. Met Kubernetes is dit geautomatiseerd en dit maakt het veel minder foutgevoelig.

Zero downtime door updates

Met Kubernetes kun je de oude versie van een applicatie actief laten voor de gebruikers terwijl je daarnaast de nieuwe update inricht en test. Zodra deze akkoord is bevonden en in productie draait, kun je gebruikers overzetten en de oude, gekloonde versie updaten. Eindgebruikers merken zo niks van updates of patches.

A/B testing

Kubernetes is de perfecte tool voor A/B testing. Je stelt simpelweg verschillende versies van een applicatie voor verschillende gebruikersgroepen beschikbaar en test hun ervaringen.

Cloudonafhankelijk

De meeste cloudproviders bieden Kubernetes. Je kunt het dus onafhankelijk van je provider inzetten en eenvoudig meenemen als je migreert. Providers bieden het als platform-as-a-service (PaaS) of infrastructure-as-a-service (IaaS). Daarmee is het ook toepasbaar in hybride situaties.

Snel ontwikkelproces

Omdat Kubernetes cloud native is ontwikkeld, is veel van de toepassing out-of-the-box te koop. Dat versnelt het ontwikkelen van applicaties met Kubernetes aanzienlijk.

Voorbeeld van een toepassing in de praktijk: Storepal

Voor onze klant BrandLoyalty ontwikkelden wij de applicatie Storepal, waarvoor Kubernetes op de achtergrond piekbelasting opvangt.

BrandLoyalty is een organisatie gespecialiseerd in het ontwikkelen en aansturen van loyaliteitspromoties voor internationale retailklanten. De applicatie Storepal geeft de retailklanten inzicht in de effectiviteit van loyaltyprogramma’s. Het geeft inzicht of een programma bijdraagt aan de merkactivatie door te meten in hoeverre de consument meedoet en het nut inziet van het spaarprogramma.

Dat succes is vooral afhankelijk is van de displays in de winkel. Die moeten goed zichtbaar zijn en de klant aanspreken. Om te testen of ze op de goede plek staan, vraagt de app medewerkers foto’s te maken van hoe en waar displays geplaatst zijn en vervolgens vragen als: ‘Hoe beoordeel je de kwaliteit van de display?’, te beantwoorden. Deze foto’s en bijbehorende informatie worden met behulp van beeldherkenning geanalyseerd. Vervolgens berekent Storepal met artificiële intelligentie (AI) welke schappen en welke plekken in de winkel het beste resultaat opleveren.
Met de resultaten kan BrandLoyalty proactief winkels benaderen en hen adviseren hoe ze meer uit de campagne halen. Daardoor is het niet meer nodig mystery shoppers langs te sturen. Het hoofdkantoor van de retailketen krijgt zo meer en objectievere informatie van alle verschillende winkels.

Piekbelasting

Bij elke nieuwe spaaractie verstuurt de app taken naar winkelmedewerkers. Sommige retailketens hebben maar liefst 10.000 gebruikers. Om het aantrekkelijk te maken voor het winkelpersoneel om mee te doen, is er een spelelement toegevoegd. Via zogenaamde ‘leader boards’ kunnen retailers hun resultaten met collega-retailers vergelijken. Elke twee weken wordt een prijs uitgeloofd aan de best presterende winkel. Deze kortstondige periode van taken uitzetten en feedback verwerken, leidt tot een flinke belasting van de app en onderliggende services.

Kubernetes is de ideale oplossing om deze piekbelasting op te vangen.

Opbouw van de applicatie

De applicatie is opgebouwd uit 3 componenten:

• Manager: deze definieert de programma’s, taken en vragenlijst
• API: de webservice die communiceert met de mobiele applicaties van de medewerkers
• Dashboard: een webapplicatie die één keer wordt gedownload naar je browser, waarna alle communicatie via webservices plaatsvindt

De front-end van de applicatie bestaat uit zowel een mobiele app (iOS en Android) als een webapplicatie. Zij communiceren via een API met de Manager. Door de opbouw in losse clusters, zijn de microservices geschikt om horizontaal te schalen. In de checklist hieronder gaan we dieper in op de eisen, waaraan een applicatie moet voldoen om Kubernetes te kunnen toepassen.

Doorlooptijd 4 maanden

De applicatie draaide oorspronkelijk op Amazon Web Services (AWS). Omdat Kubernetes cloudonafhankelijk werkt, kon Storepal op verzoek van BrandLoyalty in korte tijd worden overgezet naar Microsoft Azure. Daarvoor werd gelijk een nieuwe architectuurschets gemaakt, de Azure-omgeving gebouwd, de naamgevingsconventie opgezet, alle componenten in codevorm beschreven en uiteindelijk samen met alle data overgezet. In slechts 4 maanden was de applicatie functioneel in de nieuwe cloudomgeving.

Hoe automatiseer je Kubernetes voor efficiënter beheer en ontwikkeling?

Het project van Storepal werd versneld door de configuratie van Kubernetes te automatiseren. Hierdoor kun je:

• sneller applicaties ontwikkelen
• eenvoudig aanpassingen doen aan een applicatie na oplevering
• naamconventie automatiseren
• uniformiteit bereiken in beheer en monitoring vereenvoudigen
• clusters en omgevingen sneller en eenvoudig reproduceren met minder fouten
• kosten in de hand houden

Het automatiseren van de configuratie van Kubernetes voeren wij uit met de open-source tool Terraform.

Wat kun je automatiseren in de configuratie voor meer gemak en veiligheid?

In Terraform leg je allerlei zaken vast die Kubernetes vervolgens bij reproductie automatisch toepast. Veel van die zaken zijn gerelateerd aan architectuur. Denk bijvoorbeeld aan: de benodigde services, de grootte van de nodes (machines), de te verwachte op- en afschaling, de eventuele begrenzing van de opschaling, de interne en externe netwerkconnectiviteit, opbouw van het database- en het Kubernetes-cluster en de inrichting van de beveiliging.

Zo kun je voor de beveiliging de identificatie van gebruikers, SSO, firewall en reverse proxy vastleggen. Met een reverse proxy stel je een tussenliggende proxyserver in, die namens de client gegevens ophaalt bij de bron – in dit geval het Kubernetes-cluster – en vervolgens het antwoord terugstuurt. De eindgebruiker ziet geen verschil, maar voor de organisatie is het veiliger omdat er nooit een directe link is naar het Kubernetes-cluster.

Terraform, de slimme rekentool

Op basis van al deze gegevens leg je je gewenste infrastructuur vast in een architectuurontwerp. Vervolgens kun je ervoor kiezen alle componenten van de omgeving stuk voor stuk aan te maken in een Managed Kubernetes Cluster dienst, zoals Microsoft Azure Kubernetes Services (AKS). Slimmer is om dit met Terraform te doen, omdat deze de infrastructuur in code vastlegt.
In feite voert deze de definitie van de infrastructuur als volgt in: “een Kubernetes-cluster met zoveel nodes, gekoppeld aan die database, op dat netwerk en die naamgevingsconventie” etcetera. Met die gegevens maakt Terraform een plan. Ben je akkoord met dit plan, dan gaat de tool de omgeving vervolgens configureren.

Omdat Terraform als code objectgeoriënteerd is, kopieer je heel eenvoudig clusters. In projecten is onze methodiek om in eerste instantie clusters stuk voor stuk op te bouwen. Dat geeft het beste overzicht. Als je vooraf ook de naamconventie meeneemt in je configuratie, dan past de naamgeving van de clusters en servers zich eveneens automatisch aan naar de betreffende omgeving.

Wijzigingen op je applicaties doorvoeren

Wil je op een later moment je applicatie wijzigen, dan berekent Terraform op basis van de nieuwe gegevens in je configuratie of de wijziging in de huidige opzet past, of dat hij een nieuw cluster moet aanmaken. Is een nieuw cluster nodig, dan maakt hij deze aan naast de bestaande, tot je akkoord geeft om over te stappen.

Zo bouw je bijvoorbeeld eerst een testomgeving, die je eenvoudig kopieert naar een acceptatie- en daarna naar een productieomgeving. Terraform bewaakt de stabiliteit en veiligheid van je omgeving bij elke toevoeging en wijziging.

De wijzigingen kunnen we dankzij de Continuous Integration/Continous Development (CI/CD) methodiek continu opleveren. Omdat ontwikkelaars samenwerken in één centrale repository, gaan wijzigingen sneller door naar de testers, en na akkoord naar de acceptatie- en productie-omgeving van het betreffende Kubernetes-cluster in de opgebouwde infrastructuur.

Opleveren zonder de gebruikers te hinderen

Nadat de applicatie is opgeleverd, moeten ook de bijbehorende data en gebruikersgegevens uiteraard nog over. Dit doen we zoveel mogelijk buiten kantooruren, zodat gebruikers er niet door gehinderd worden.

Als uiteindelijk alles in dezelfde omgeving staat, verifiëren we altijd nog uitgebreid de werking en veiligheid, zodat je niet voor onverwachte verrassingen komt te staan. Loopt alles goed in de nieuwe omgeving, dan wordt de oude omgeving uitgefaseerd.

Door alle automatische configuratieregels, is de omgeving veel minder foutgevoelig en heeft beheer minder werk aan updates en wijzigingen. Met behulp van Application Insights (voor de Azure-omgeving) kan IT real-time de performance van de app meten. Mochten er knelpunten zijn, dan kun je dat direct zien en pro-actief uitval voorkomen.

Checklist: is Kubernetes geschikt voor mijn organisatie en situatie?

Kubernetes kan een capaciteitsprobleem relatief eenvoudig oplossen, mits je applicatie geschikt is en je het op de juiste wijze toepast. Check dit vooraf, want daarmee bespaar je de organisatie later veel tijd en onnodig onderhoud. Voldoet de applicatie of architectuur nog niet, dan kan herontwerp vooraf efficiënt zijn voor de lange termijn.

Vereisten aan de applicatie en architectuur

De applicatie en/of architectuur moet voldoen aan de volgende 4 voorwaarden:

1) Stateless
Kubernetes werkt het beste als de requests voor de applicatie, los van de context, geïsoleerd afgehandeld kunnen worden. Dat noemen we stateless. De aanvragen kunnen dan makkelijk over de beschikbare resources worden verdeeld en zo nodig halverwege een sessie worden doorgeschakeld naar een andere machine.

Als je je architectuur erop inricht om wel alle informatie bij elkaar te houden – welke gebruiker, welk verzoek doet in welke applicatie – dan vereist dat heel veel informatiestromen over en weer. Koppel je de info los, waarbij de applicatie nog steeds weet welke gebruiker het is, welke data hij moet ophalen en presenteren, los van alle andere context, dan heb je meer flexibiliteit om horizontaal te schalen.

2) Losse componenten of gescheiden microservices
Net als voor de requests aan de applicaties, geldt ook voor de applicatie zelf dat deze het beste uit (micro)services is opgebouwd. Dat maakt het mogelijk om per service of een cluster van services te schalen. De services of clusters kun je indelen voor een specifieke functie of een afgebakende doelgroep.

In het voorbeeld van Storepal lieten we al zien dat het dashboard, de webservices en de Manager aparte componenten zijn, ingedeeld naar functie.
Kortom, een opzet in componenten of services maakt het makkelijker om te schalen dan één grote monolithische applicatie.

3. Onafhankelijke functies
Behalve stateless en gescheiden microservices, moeten de componenten ook daadwerkelijk los van elkaar kunnen functioneren.

Het Storepal-voorbeeld laat dat zien: daar is gekozen om services logisch per functie te clusteren. De druk op deze app ligt achtereenvolgens op de front-end als de winkelmedewerkers worden gevraagd foto’s te maken en vervolgens op de back-end als de Manager tool alle gegevens verwerkt en analyseert. De verschillende services worden op díe momenten dat overbelasting dreigt, uitgebreid.

4. Geheugenrange
Als een applicatie is opgedeeld in microservices en onafhankelijke functies, dan heeft dat ook impact op het geheugengebruik. Een monolithische applicatie heeft vaak meer gigabytes nodig dan een opgedeelde applicatie. Toch is het belangrijk om dit vooraf te checken om te bepalen of Kubernetes de goede oplossing is. Is er bijvoorbeeld alleen al 16 gigabyte nodig om op te starten, dan wordt het cluster te groot om op een server te draaien. In dat geval is virtualisatie een betere optie.

3 tips als je Kubernetes wilt inzetten

Is jullie omgeving of applicatie geschikt voor Kubernetes op basis van deze checks? Dan raden we je zeker aan om dit in te zetten, vanwege alle voordelen die het systeem biedt. We geven je nog 3 tips voor de inrichting met Kubernetes, die je veel tijd besparen:

Tip 1. Koop out-of-the-box opties
Het aanbod in de cloud is gigantisch en groeit elke dag. Als je hier niet dagelijks mee bezig bent, valt het niet mee om door de bomen het bos te zien. Toch loont het je erin te verdiepen of om een expert te raadplegen, want de kant-en-klare opties schelen veel ontwikkel- en beheertijd. Sowieso, omdat het technisch beheer bij de cloudprovider ligt. Heb je een applicatie die onderdeel is van een groter pakket als Microsoft Dynamics? Dan verzorgt de provider daarvan ook vaak de updates en patches.

Tip 2. Automatiseer zoveel mogelijk voor uniformiteit
In de paragraaf over het automatiseren van Kubernetes lieten we al zien dat Terraform helpt bij het inrichten van de infrastructuur en het ontwikkelen en wijzigen van de applicatie. Als je je configuratiebestand vooraf invoert, dan berekent Terraform steeds de meest optimale infrastructuur. Dit is minder foutgevoelig dan wanneer een mens dit doet.

Ook biedt het gemak bij het updaten en wijzigen van de applicatie omdat Terraform synchroon aan het bestaande cluster een nieuw cluster opbouwt, zodat je pas hoeft over te stappen als deze klaar is. Het kopiëren van test-, acceptatie- en productieomgeving doet Terraform ook automatisch.
Door de configuratie te automatiseren, is het reproduceren van je omgevingen eenvoudiger en minder foutgevoelig waardoor je omgeving stabieler blijft.

Tip 3. Naamgevingconventie voor meer duidelijkheid
Het maakt het voor alle betrokken partijen duidelijker als je vooraf een naamgevingconventie afspreekt, waarin je in ieder geval de omgeving, service en applicatie verwerkt. Bijvoorbeeld: een productiedatabase voor de applicatie “StorePal”: db-prd-storepal; “db” voor databases of “k8s” voor Kubernetes. Zo kun je een database server maken met de naam: storepal-db-prd, of een Kubernetes cluster met de naam: storepal-k8s-acc. Het is dan voor iedereen duidelijk om welke omgeving het gaat, zeker als er meerdere worden gekloond. Door de naamgeving in het configuratiebestand van Terraform in te voeren, zorgt de tool dat het systeem dit automatisch toepast als een extra server wordt bijgeschakeld.