De 5 valkuilen van Kubernetes

De 5 valkuilen van Kubernetes

18 June 2020 door in Kubernetes

Voordat je aan Kubernetes (k8s) begint moet je goed onderzoeken of dit bij jouw organisatie past. Daarnaast zijn er enkele valkuilen waar je niet in moet trappen. Cyso heeft inmiddels ruime kennis en ervaring met Kubernetes en heeft hierdoor ook een goed beeld van veelgemaakte fouten die ervoor zorgen dat de implementatie van Kubernetes faalt. We lichten vijf valkuilen voor je uit.

1. Geen aparte clusters voor test en productie

Vaak wordt er gestart met een klein Kubernetes cluster met bijvoorbeeld maar 2 nodes. Na een testfase wordt het cluster daarna in productie genomen. De ervaring leert dat het beter is om een nieuw cluster op te zetten voor productiedoeleinden. Dit cluster kan dan ook opgezet worden als productie cluster. Voor een productie cluster zijn er namelijk hogere eisen dan een testomgeving. Denk hierbij aan zaken als multi-master en storage. Verder is het verstandig om zelfs voor het kleinste productie cluster een minimum van 4 worker nodes in te zetten. Hiermee heb je een stuk meer failover capaciteit dan twee nodes.

2. Geen cloud-native schaalbaarheid

Als je jouw applicatie in Kubernetes wilt deployen is het belangrijk om na te denken over de schaalbaarheid van je applicatie. Vaak wordt de state van een applicatie opgeslagen in het geheugen. Als je in Kubernetes meerdere instanties naast elkaar wilt draaien zul je de state van de applicatie ergens anders moeten bijhouden. Bijvoorbeeld in een memory cache (Redis, Memcached), of in een database. Daarnaast zit je bij legacy applicaties vaak ook nog met bestanden / uploads die enkel op een filesystem kunnen staan. Dan loop je tegen het probleem aan dat de meeste storage oplossingen ReadWriteOnce zijn en dus niet tegelijkertijd aan meerdere pods gekoppeld kunnen worden. Een goede oplossing hiervoor is gebruik te maken van een Object Store, maar dit vereist in de meeste gevallen wel flink wat werk aan de applicatie.

3. Geen CI/CD ervaring

Voordat je begint met Kubernetes is het verstandig om al ervaring te hebben opgebouwd met Docker en het inrichten van een CI-straat. Zonder deze kennis en ervaring is het bijna onmogelijk om in een keer de stap te maken naar Kubernetes. Als je in het algemeen geen ervaring hebt met het builden en deployen van containers is het verstandiger om eerst met Docker te starten. Richt automatische builds in in je CI omgeving en vergeet hierbij ook niet om tests uit te voeren. Als je dit allemaal onder de knie hebt is het tijd om te gaan te kijken naar Kubernetes.

4. Geen cloud-native monitoring en logging

Traditionele servers zijn eenvoudig te monitoren en de logs staan op bekende locaties. Bij Kubernetes is dit niet meer het geval. Een veelgemaakte fout bij de transitie naar Kubernetes is dat er niet wordt nagedacht over monitoring en logging. Ook een Kubernetes cluster moet gemonitord worden. Naast de Kubernetes nodes zelf moeten de pods ook gemonitord worden. Om bij te houden hoeveel resources de pods gebruiken en hoe belasting van het cluster is, kan je monitoring tools als Prometheus in combinatie met Grafana dashboards gebruiken. Hiermee krijg je inzicht in hoe je cluster gebruikt wordt.

Als pods eenmaal verwijderd zijn is de logging ook verdwenen. Dit is anders dan bij een reguliere webserver waarbij je de logging voor langere tijd bewaart. Om dit op te lossen kan je central logging op basis van ElasticSearch inzetten. Hier worden de logs van de pods naar toe gestuurd zodat je kan terugzien wat er allemaal is gebeurd ook al zijn de pods al langere tijd weg. Met Kibana kan je hier vervolgens weer dashboards van maken zodat de logging ook makkelijk te zien is.

5. Langzame development cyclus

Hoe vaak doe je releases van je applicatie? Is dit meerdere keren per dag? Of release je maar eens in de paar maanden? Een transitie naar Kubernetes kost aardig wat ontwikkeltijd. Als je bijvoorbeeld enkele keren per dag of meerdere keren per week een release wilt doen kan je hier veel winst mee behalen. Een goed ingerichte CI/CD pipeline zorgt ervoor dat je code volledig automatisch gedeployed kan worden. Als je maar eens in de maand een deploy doet heb je hier veel minder voordeel van. Of een switch naar Kubernetes dan de moeite waard is kan je je dan afvragen.

Conclusie

Zoals je ziet is de overstap naar Kubernetes niet heel eenvoudig en veel organisaties trappen in deze valkuilen. Breng dus van te voren goed in kaart over welke kennis je als organisatie beschikt, welke processen je volgt, hoe je applicatie in elkaar steekt en welk doel je wilt bereiken. Dan kan je goed de eerste vervolgstappen bepalen. Zijn er punten waarover je twijfelt hoe die het best opgelost kunnen worden? Laat het ons weten. Onze ervaren DevOps engineers denken graag met je mee.

VERTEL ONS JOUW VRAAGSTUK
Kwaliteit. Betrouwbaar. Betrokken.
  • 24/7 service support
  • Nederlandse datacenters
  • ISO 27001 gecertificeerd
Bel me terug