1. Je raakt het overzicht kwijt
Een van de issues met Kubernetes is dat organisaties vaak alles te snel én tegelijkertijd willen: én naar de cloud én Kubernetes voor modernisering van het gehele applicatielandschap én meteen alle workloads migreren. Dat is niet verstandig. Kubernetes gaat niet zo zeer over het ‘draaien’ van de afzonderlijke applicaties in containers, maar juist over het inzetten van en werken met deze containers in je ecosysteem. Met containers kun je weliswaar eindeloos schuiven en schalen, maar het gevaar bestaat dat je, ondanks de orkestratie met Kubernetes, redelijk snel het overzicht over je infrastructuur verliest. Een container is nu eenmaal géén virtuele server, maar een relatief vluchtige eenheid binnen het VM-cluster. Containers zijn agile: in een seconde aangemaakt, maar ook in no time weer ‘weg’. En je overzicht net zo.
2. Je hebt geen eigen blauwdruk gemaakt
Met Kubernetes is ieder systeem uniek georkestreerd. Alles gebeurt automatisch. Maar elk systeem gaat uit van de zogenaamde ‘desired state’. Die beschrijft hóé het systeem moet functioneren: de blauwdruk waarin staat wat op welk moment automatisch uitgevoerd moet worden. Een voorbeeld: als je 16 containers met een bepaalde functie hebt en één daarvan valt uit, dan moet er ook automatisch weer eentje bijkomen. Ook het op- of neerschalen van loads gebeurt automatisch, maar moet wél exact gedefinieerd worden. Stel het je zo voor: iemand leert zwemmen. Aan de kant staat de instructeur die continu roept welke bewegingscombinaties de zwemmer moet maken om vooruit te komen. En jíj bent degene die de instructeur vertelt, wat hij op welk moment moet roepen om de zwemmer goed te laten zwemmen. Dat moet heel nauwkeurig en gedetailleerd, want anders gaat de zwemmer kopje onder. Dát is je blauwdruk.
3. Je beheerst de functionaliteiten niet
Containers kunnen enkel één functionaliteit bevatten, geen content (voor gegevensopslag zijn eigen pods en persistent volumes nodig). Een container is dus steeds maar voor één functie of Microservice verantwoordelijk. Die functionaliteitenscheiding moet je heel consequent – bijna tot in het extreme – doorvoeren. Alles in één monstercontainer stoppen, is namelijk precies wat je níét wilt. Naast containers voor upload, load balancing, logging, infrastructurele requests etc. heb je ook nog eens speciale containers voor de specifieke apps. Een symbiose tussen development en operations (DevOps) is dus absolute noodzaak voor de beheersing van alle functionaliteiten.
4. Je creëert een kettingreactie
Door die strikte scheiding tussen functionaliteiten (van een applicatie of site) moeten alle containers 24/7 naadloos samenwerken. Die coöperatie moet je wederom beschrijven (zie blauwdruk). Zo weten containers elkaar te vinden. Maar als dat niet goed gaat, moet je debuggen. Daarvoor zijn ook weer containers nodig die de fouten loggen. Het ene containerprobleem creëert weer een andere container om dat probleem op te lossen. Dan krijg je een kettingreactie met oneindig veel containers. Dat moet je voorkomen. Containers kun je ook niet updaten. Falende containers worden meteen uitgerangeerd en op basis van je blauwdruk vervangen door een nieuwe versie. Ook daarmee moet je rekening houden.
