Kubernetes door de ogen van Level27: Deel 2

In deel 1 van deze blogreeks vertelden we je het verschil tussen containers en virtuele machines, wat belangrijk is om te begrijpen aangezien het gebruik van containers de basis vormt van Kubernetes. In deze blog gaan we dieper in op de oorsprong van Kubernetes en Docker en de reden waarom beide doorheen de jaren zo populair werden.

Voor sommigen klinkt Kubernetes misschien redelijk nieuw in de oren, maar eigenlijk bestaat de technologie erachter al langer dan je denkt. Voor de eerste aanzet moeten we zelfs teruggaan naar het jaar 1979 en de chroot functie. Met deze functie kan je de root directory van een proces veranderen om zo het file systeem af te scheiden van de rest. Een container kan zonder extra instellingen daardoor dus nooit aan je bestanden op het host systeem.

Na een lange stilte werd de draad terug opgepikt in 2000, en dit zelfs door een klein hostingbedrijf. Ze kwamen op de proppen met freebsd jails om de services van hun klanten af te scheiden van de rest voor security redenen. Die services hadden daarnaast ook een eigen ip-adres. De jaren die erop volgen ontwikkelden ook andere bedrijven meer en meer functionaliteit. Google speelde hier bijvoorbeeld een grote rol in door de ontwikkeling van process containers. Hiermee kan je de resources van containers limiteren, wat later ook in de kernel werd toegevoegd onder de naam cgroups. Het bedrijf LXC zorgde voor de eerste complete implementatie. Warden, Let me container that for you en Docker volgen kort daarna.

Hoe is Docker daar nu als meest populaire uitgekomen? Moeilijke vraag. Waarom is Linux de meest populaire linux-kernel? Docker had misschien niet de beste technische implementatie, maar timing heeft daar zeker een grote rol in gespeeld. Op het moment dat Docker ermee naar buiten trad waren virtuele machines een gegeven. Verandering van spijs doet eten, ook bij technologie is dat zo. 
 

Docker is een opensource project wat dus vrij snel heel populair werd. Door sterk in te zetten op marketing en met dank aan funding, werd er vanaf het begin een grote community opgebouwd waardoor bugs snel werden opgespoord en ze veel functionaliteiten konden verwezenlijken. Dockercon is daar een duidelijk voorbeeld van, een conventie die jaarlijks enorm veel bezoekers trekt. Zelfs op de eerste editie wisten ze al bedrijven te strikken zoals Google, Amazon en IBM. Containers hebben een bepaalde coolheidsfactor en dat trekt natuurlijk nog meer aan wanneer dergelijke grote namen zich achter de technologie scharen.

Het idee om alle applicaties in containers te plaatsen groeide dus steeds meer. En met een heel duidelijke use case heeft ook hier Docker goed op ingespeeld: build, ship and contain. Dit betekent dat je de applicatie laat draaien op je lokale machine, maar daarnaast ook op je staging- en zelfs productieomgeving. Docker ontwikkelde hiervoor een heel ecosysteem, wat ervoor zorgde dat de stap naar container een pak kleiner werd. Zo bestaan er Docker repositories met images die je gewoonweg van het internet kan plukken. Hierin zit dan al mogelijk een volledige installatie van je software inbegrepen. De dockerfiles maken het daarnaast mogelijk om makkelijk extra stappen aan je installatie toe te voegen.

Je applicatie in Docker steken brengt zeker een aantal voordelen met zich mee. Containers kunnen makkelijk gestart en gestopt worden. Ze zijn klein, wat het sneller maakt om ze te verplaatsen naar andere omgevingen. Op zich maakt het ook niet uit waar ze draaien zolang het host systeem maar Docker heeft. Dit zorgt toch wel voor een bepaalde consistentie bij een aantal procedures, zoals een aanpassing of installatie op je productieomgeving. Aangezien alles gesegregeerd is kan je dus enkel je eigen applicatie beïnvloeden. Als je dit lokaal hebt getest werkt die ook op andere omgevingen. Of ja, toch bijna altijd :).

Nu de technologie al beter bekend is gaan bedrijven op zoek naar alternatieven die misschien sneller en beter zijn. Zo heb je in Kubernetes ook de mogelijkheid om andere container-technologieën te gebruiken. Dus Docker is zeker niet de heilige graal.

Wat is dan de stap tussen containers en Kubernetes? Wie al eens een container heeft gestart, weet dat je dit vaak via de command line doet. Dit is handig voor een 5-tal containers, maar wat als er 20 zijn? In dat geval kan je eventueel nog docker-compose gebruiken om al de container configuratie mooi in bestanden te plaatsen. Maar wat als je 100 containers hebt die je wil verdelen over 4 systemen? Hier brengt Kubernetes, of wat we noemen een container orchestratie systeem, de oplossing. We orchestreren hier niet alle instrumenten in een heel orkest, maar alle containers over je omgeving. Op die manier kan je makkelijk een container plaatsen op een systeem dat het meeste resources beschikbaar heeft. Wat is de status van mijn container en wat voor logs spuwt die nu precies uit.

Kubernetes is hier zeker niet de enige soortgelijke technologie, maar toch staan ze alleen aan de top. In de beginjaren was er nog wel wat competitie met rivalen zoals Apache Mesos en Swam. Maar deze wedstrijd was wel vrij snel gespeeld en eigenlijk zie je nog maar weinig vraag naar de concurrentie. Of in sommige gevallen gebruiken andere technologieën zelfs Kubernetes achterliggend. 

Het bedrijf achter Kubernetes is het alom gekende Google. Een partij die over de jaren heen veel credibiliteit heeft gekregen op vlak van technologische vooruitgang. Op andere vlakken is dat dan weer wat minder. In 2003 maakte Google een systeem genaamd Borg, wat de basis zou zijn van het latere Kubernetes. Hiermee draait Google nagenoeg alle interne processen in containers. Het systeem zorgt onder andere voor een makkelijk te schalen applicatie en voorziet automatisch loadbalancing aan de hand van services. Na 10 jaar maakte Google het project open-source, waarmee Kubernetes tot leven kwam. Als je als Google kan aantonen dat al je interne processen op deze technologie draaien, schept dat natuurlijk veel vertrouwen. 

Het open-source project is vandaag nog altijd het meest populaire op Github. Vergelijkbaar met Docker heeft dus ook Kubernetes een heel grote community achter zich geschaard. De hoeveelheid development en pull requests die hier in gaan is gigantisch. Het project blijft maar aangroeien met nieuwe features, al zorgt dit dan weer voor een andere moeilijkheid in het release proces. Maar Google zou Google niet zijn, moesten ze dit perfect aanvullen met een vaste procedure, een wisselend release team en informatieve podcasts. 

Lees meer over dit topic in ons derde deel over Kubernetes!

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.