Kubernetes door de ogen van Level27: Deel 3

Zoals we je in deel 1 en deel 2 van deze blogreeks vertelden herbergen zowel Kubernetes als Docker en het gebruik van containers een geschiedenis die veel vertrouwen geven aan het gebruik van Kubernetes. Maar dit is niet voor iedereen de beste toepassing, want zoals elke software moet het gebruik ervan weloverwogen worden. Wij vertellen je waarom je het net wel, of misschien net niet zou moeten doen.

Weet je nog, al dat vertrouwen in de interne processen van Google? Helaas zijn die ook tot aan de rand gevuld met complexiteit. Sommigen durven zelfs stellen dat alles wat overdesigned is. Kubernetes beheer je aan de hand van een API. Bij een creatie kan je kiezen uit een hele reeks aan objecten. Je zal dus wel wat tijd moeten investeren om die leercurve te overbruggen. De makkelijkste objecten zijn pods en services. In de meeste guides ben je wel snel weg met een nginx container en een statische website, maar wat doe je met monitoring, certificaten en persistente data? Hiervoor heb je een extra component nodig op je omgeving en die brengen ook weer eigen API objecten met zich mee.

Een Kubernetes omgeving lokaal installeren kan vrij makkelijk aan de hand van kubeadmin. Eens je naar productie gaat is het niet aangewezen om dat op deze manier te doen. Je zal dan een andere scheduler moeten gebruiken of de installatie misschien volledig zelf doen. Netwerk is daar altijd een belangrijk aspect want je werkt met verschillende systemen voor je masters en workers. Op die workers draaien pods en services met elk een eigen ip-adres en dat moet allemaal vrij dynamisch zijn want die pods kunnen ook nog eens van plaats veranderen. Al deze stukjes moeten dus perfect met elkaar kunnen praten of de werking gaat niet naar behoren zijn. Bovendien heb je verschillende mogelijkheden van implementatie, elk met hun voor- en nadelen wat de keuze nog moeilijker maakt.

Dus als het dan al eens fout gaat op je omgeving moet je al verdomd goed weten waar je mee bezig bent. Wat doe je als een node niet meer beschikbaar is, wat als een namespace geen netwerk krijgt, wat als een pod je hele cluster plat trekt? Hierop zal je je toch wel wat moeten voorbereiden zodat je daar snel op kan reageren. Je kan daarvoor bijvoorbeeld wat failure tests uitvoeren, de logs centraliseren en inzicht brengen in je omgeving door statistieken van je componenten te visualiseren.

Kubernetes is zoals eerder vermeld een open-source project met een kort release proces. Het blijft dus evolueren met nieuwe features die misschien nuttig zijn om te implementeren. Dit wil dan wel zeggen dat je ook tijd zal moeten blijven investeren. Hoe ga je om met upgrades, waar ga je die nieuwe versies ergens testen? De extra componenten zoals je monitoring moeten ook mee, maar werken die wel nog als je een versie hoger gaat gaan? Wat is er daar allemaal aangepast?
 

Laat je vooral niet overtuigen door de buzzwords van Kubernetes zoals; auto-scaling, makkelijk deploybaar, redundant by design, minder resources. In de praktijk ga je al redelijk wat tijd moeten investeren om tot deze features te komen. Daarnaast is een foute implementatie snel gemaakt en dat kan je toch wel voor een bepaalde tijd achtervolgen. Maak dus goed je business case en probeer te kijken of het gebruik van Kubernetes echt een voordeel voor je kan zijn. Stel jezelf de vragen: wat win ik met Kubernetes, wat verlies ik en wat als ik dit toch op de ‘niet-coole’ manier doe?

Klinkt dit alles wat beangstigend? Goed, dat was de bedoeling. Begrijp ons niet verkeerd, Kubernetes is een imposante technologie waar je mooie dingen mee kan doen. Maar net zoals bij elke andere software geldt: gebruik het waar het voor dient. En er zijn zeker een aantal use-cases die het interessant kunnen maken om deze implementatie te realiseren.

Stel dat je bijvoorbeeld een softwarebedrijf bent dat 20 verschillende soorten technologieën gebruikt, elk ook weer op zijn eigen versie. Als je dat met vm’s moet doen ga je toch wel wat automatisatie nodig hebben, zodat de machines gelijkaardig geconfigureerd zijn. Je wil misschien ook niet Java steeds manueel upgraden of een oude versie van PHP ondersteunen op je besturingsysteem? In dit geval zou je dus je software in containers kunnen plaatsen zodat die elk hebben wat ze nodig hebben. Op die manier kan je dus veel sneller volgen met de laatste software versies omdat je niet steeds moet wachten tot de infrastructuur dit kan. Dus om al die technologieën in containers te beheren zal Kubernetes hier zeker een oplossing zijn.

Ben je een tech driven team dat houdt van de laatste technologie, ga ervoor. Als de motivatie er is om er met het hele team veel tijd in te investeren, zal je zeker een mooi resultaat bereiken. Er zijn toch wel wat implementaties die de moeite waard zijn, zoals het beschikbaar maken van statistieken uit je applicatie, een automatische controle op de werking van je container, complexe deployments. Met de gepaste tooling zal je dit ook perfect kunnen standaardiseren en gebruiken op al je omgevingen. 

Scaling is natuurlijk hét verkoopargument bij Kubernetes, want daar werd het uiteindelijk voor gemaakt. Je kan heel eenvoudig extra pods laten draaien op je omgeving zodat je applicatie meer power krijgt. Daarnaast is het toevoegen van extra worker nodes vrij gemakkelijk gezien er enkel Docker op moet draaien en het Kubernetes worker component. Je kan dus heel gemakkelijk spelen met het aantal pods en nodes. Ook bij onderhoud van systemen is dat nuttig want je kan alle pods makkelijk verplaatsen naar een andere node. 

Een stapje verder is auto-scaling. Hier zou ik toch met de gepaste voorzichtigheid aan beginnen zeker als je bij een cloud provider zoals AWS zit. Je wil niet op een morgen wakker worden met plots 30 systemen meer in je omgeving. Of toch niet als je ook de factuur zelf moet betalen :). Zorg daarom eerst voor wat automatisch schalen op je applicatie voordat je aan de systemen begint. 
 

Bij Level27 hebben we onze eigen podcast 'hotline27'. In aflevering 7 gingen we dieper in op een van de populairste technologieën van het moment, namelijk Kubernetes. Een mooie aanvulling op bovenstaand artikel.