March 9, 2023

Kubernetes ready!? Dé checklist voor succes

Momenteel is Kubernetes erg populair en wordt het door veel organisaties gezien als de toekomst voor hun applicaties. Het is echter belangrijk om kritisch te blijven en jezelf af te vragen of Kubernetes voor jouw organisatie winstgevend is. In deze blog doorlopen we de belangrijkste checks die je kunt afvinken om te kijken of Kubernetes geschikt is voor jouw organisatie en als je al Kubernetes toepast, het op de juiste manier doet.

Liever de checklist in een PDF zodat je hem zelf kunt invullen wanneer jou het uitkomt? Download hier de checklist Kubernetes.

Kubernetes als volgende stap

Ben je aan het overwegen om Kubernetes toe te passen? Zie hieronder een aantal vragen die je jezelf kunt stellen:

  • Hoe lang ben je van plan om je huidige applicatie(s) nog te gebruiken?
  • Hoe schaalbaar moet(en) applicatie(s) zijn? Groeit het aantal gebruikers van je applicatie(s) nog steeds door?
  • Doe je veel aan productontwikkeling? Is het ontwikkelteam veel bezig met het ontwikkelen en uitrollen van nieuwe features/releases?
  • Wegen de kosten van Kubernetes op tegen de voordelen?
  • Denk hierbij aan meer ontwikkelsnelheid en meer focus van je ontwikkelteam.

Microservices architectuur

Om gebruik te kunnen maken van Kubernetes, moet het ontwikkelteam van jouw organisatie applicaties ontwikkelen volgens een microservices-architectuur. Dit betekent dat de applicatie wordt opgesplitst in afzonderlijke services die onderling met elkaar zijn verbonden. Elk van deze services heeft een specifieke taak en samen vormen ze één geheel. Het is belangrijk om te weten dat zowel het gebruik van een microservices-architectuur als containers die geschikt zijn om op Kubernetes te draaien vereist zijn om Kubernetes te kunnen gebruiken.

Ondersteuning Kubernetes van cloudaanbieder

Ongeacht of je gebruik maakt van een public, private of on-premise cloud, is het van belang om te weten of je huidige cloudprovider Kubernetes ondersteunt. Bij de meest bekende public clouds is dit meestal geen probleem, omdat zij Kubernetes als een dienst aanbieden. Als dit niet het geval is, dan moet je zelf of je hostingprovider de Kubernetes-omgeving opzetten. Hiervoor is het cruciaal om het volgende na te gaan:

  • Of er beheertoegang tot de (virtuele) servers is
  • De (virtuele) servers voorzien kunnen worden van een besturingssysteem dat geschikt is voor Kubernetes, bijvoorbeeld; Ubuntu Server
  • Dat de vrijheid bestaat dat de networking inclusief netwerkscheiding, routeringen en firewalling naar wens in te richten

De databasestrategie

Kubernetes is niet ontworpen voor het uitvoeren van zware databases. Dit komt door een aantal redenen, waarvan de belangrijkste is dat het herstelmechanisme van Kubernetes is ontworpen voor stateless toepassingen die op een Kubernetes worker draaien. Een database is echter stateful, niet stateless. Als je de verkeerde keuze maakt bij het ontwerp van je toepassing, kan dit ernstige gevolgen hebben, zoals het verlies van je data. Het is daarom erg belangrijk om een goede databasestrategie te kiezen. Over het algemeen heb je drie keuzes:

  • Fully managed databases (denk aan Oracle, MongoDB en die van de hyperscalers)
  • Een separate (virtuele)server waar je database op draait
  • Twee separate (virtuele)servers waar een databasecluster op draait
  • Een database op Kubernetes, maar dan dus onder voorwaarden

Kubernetes security

Bij het beveiligen van je Kubernetes-infrastructuur is het van belang om vanaf het begin te bepalen welk niveau van beveiliging noodzakelijk is voor jouw toepassingen. Hoewel het onmogelijk is om alle details hier te beschrijven, zijn hier enkele voorbeelden van waar je aan moet denken bij het beveiligen van je Kubernetes-infrastructuur (Let op: deze punten zijn niet voldoende, maar zijn bedoeld om je te helpen bij het op weg gaan):

  • Scan en beveilig container-images op eventuele kwetsbaarheden
  • Zorg ervoor dat de beveiliging voor Kubernetes pipelines geautomatiseerd wordt
  • Implementeer een beveiliging met meerdere lagen (segmentatie)
  • Beperk bevoegdheden in het cluster door gebruik te maken van Role-Based Access Control

Visualisatie van je ontwikkelproces

Het is niet noodzakelijk om het gehele OTAP-proces (Ontwikkeling, Testen, Acceptatie en Productie) in Kubernetes te integreren. Het is bijvoorbeeld ook mogelijk om lokaal op een laptop te ontwikkelen en vervolgens het TAP-proces door te lopen op één of meerdere Kubernetes-clusters. Vooraf dient helder te zijn hoe het proces exact ingericht dient te worden. Het is hierbij van belang dat;

  • Iedere fase van het OTAP-proces een eigen cluster krijgt of eigen namepace op een gezamenlijk cluster
  • Hoe en wanneer ontwikkel- en testomgevingen automatisch opgespind worden en hoe deze ook weer automatisch afgeschaald worden
  • Op welke cloud(s) de Test-, Ontwikkel-, Acceptatie-, en Productieomgevingen komen te draaien

Het deploymentproces

Het is belangrijk om je deploymentproces in kaart te brengen voordat je begint met het ontwikkelen van een applicatie. De betrouwbaarheid van het ontwikkelingsproces en de implementatiestrategie zijn namelijk cruciaal voor de kwaliteit van de applicatie. Teams die onafhankelijk van elkaar werken, moeten snel en veilig services kunnen vrijgeven. Voer daarom de volgende controles uit:

  • Schrijf uit op welke manier je de deployments (CI/CD) vormgeeft en hoe de integratie met Kubernetes plaatsvindt
  • Bepaal vooraf of ontwikkelaars en/of teams onafhankelijk van elkaar moeten kunnen ontwikkelen en releasen?
  • Is het noodzakelijk kwaliteitspoorten in elke fase van de pipeline af te dwingen?
  • Wie dient de validatie uit te voeren voordat code doorgerold kan worden naar de volgende stap in het OTAP-proces?
  • Bouw een volledig geautomatiseerd deployment proces zodat er van update van de applicatie gemakkelijk en constant uitgerold kunnen worden, de updates in een liveomgeving uitgerold kunnen worden én het terugrollen naar een vorige versie van de applicatie met één druk op de knop uitgevoerd kan worden

Inrichting en beheer Kubernetes

Om optimaal gebruik te maken van de voordelen van Kubernetes, is het cruciaal om te bepalen wie verantwoordelijk is voor de implementatie en het beheer ervan. Kubernetes biedt namelijk regelmatig nieuwe updates en upgrades aan, die moeten worden doorgevoerd om de veiligheid en stabiliteit van de Kubernetes-omgeving te waarborgen. Het implementeren en beheren van Kubernetes vereist specifieke aandachtspunten:

  • Laat het ontwerp van de Kubernetes-omgeving door een gespecialiseerd team maken die alle haken en ogen kent
  • Zorg ervoor dat je niet afhankelijk bent van één persoon die Kubernetes inricht en/of beheert; voorkom Single Point of Failure (SPOF)
  • Wees je ervan bewust dat Kubernetes updates ook impact kunnen hebben op je applicaties en third party tools die je gebruikt. Zorg er dus voor dat iemand het overzicht heeft en in staat is de impact van wijzigingen in te schatten en de aanpassingen probleemloos in de applicatie(s) door kan voeren

Benieuwd hoe wij jouw organisatie naar een hoger niveau tillen? Lees meer over onze aanpak op onze Managed Kubernetes pagina.

Monitoring van je applicaties en logging van data

Waarschijnlijk monitoren je beheerders al de applicaties die draaien, maar het monitoren van Kubernetes vraagt om extra kennis en expertise. Hier zijn een aantal controles die je kunt uitvoeren:

  • Breng in beeld welke metrics een waarheidsgetrouw beeld geven van de applicatie en zijn ze geschikt om op te monitoren?
  • Welke logging wil je verzamelen, naar welke centrale loggingservers stuur je de gegevens toe en hoe haal je hier bruikbare informatie uit?
  • Is jouw monitoring- en loggingtooling geschikt om zowel applicaties als Kubernetes-clusters te monitoren? (of hier geschikt voor te maken)
  • Wie dient de validatie uit te voeren voordat code doorgerold kan worden naar de volgende stap in het OTAP-proces?
  • Applicatie aanpassen dat deze naar de console logt (stdout)

Cultuur en techniek

Kubernetes kan de snelheid van het releaseproces van je software verbeteren. Maar dit zal alleen succesvol zijn als de adoptie van Kubernetes door het hele ontwikkelteam wordt omarmd.

Cultuur

Een nieuw ontwikkelproces vraagt ook om nieuwe regels, verantwoordelijkheden en gedrag. Maak dus duidelijk wie verantwoordelijk is voor wat en welke verwachtingen hierbij horen. Stel ook processen op die gevolgd moeten worden in verschillende omstandigheden.

Techniek

Jouw ontwikkelaars moeten weten hoe ze optimaal van microservices op een Kubernetes-cluster gebruik kunnen maken. Stel vragen over de drie regels van software ontwikkelen op basis van microservices, namelijk:

  • Wordt de applicatie stateless ontwikkelt?
  • Wordt er geen code in de container uitgevoerd met root-rechten (administrator privileges)?
  • Wordt er één functie per container ontwikkelt?

Conclusie

De conclusie is dat voordat een organisatie besluit om Kubernetes te gebruiken, er rekening moet worden gehouden met verschillende factoren om te bepalen of het geschikt is voor de organisatie. Er moet worden overwogen hoe lang de huidige applicaties nog zullen worden gebruikt, hoe schaalbaar de applicaties moeten zijn, of de kosten van Kubernetes opwegen tegen de voordelen en of het ontwikkelteam veel bezig is met ontwikkeling en uitrol van nieuwe features/releases. Bovendien vereist het gebruik van Kubernetes een microservices-architectuur en containers die geschikt zijn om op Kubernetes te draaien. Het is ook belangrijk om te controleren of de cloudaanbieder Kubernetes ondersteunt en om een ​​goede databasestrategie te kiezen. Tot slot is het van essentieel belang om de beveiliging van de Kubernetes-infrastructuur te waarborgen en om het ontwikkelproces te visualiseren.

Wil je eens komen sparren over jouw doelstellingen. Neem contact met ons op.

Deel deze post
Marijn Lergner
Marijn is Lead Engineer en tevens Partner bij ACC ICT. Marijn is vanaf 2010 werkzaam bij ACC ICT in verschillende rollen en begeleidt met veel enthousiasme en precisie zeer technische en complexe klantprojecten. Marijn schrijft graag over technische onderwerpen binnen de IT-branche.