Kubernetes is hip, maar tenzij je zelf een ontwikkelaar bent, reikt je kennis waarschijnlijk niet verder als ‘het heeft iets met containers te maken’. We onderzoeken in iets meer detail wat Kubernetes is, en waarom het plots zo populair is.
Kubernetes is, heel ruw gesteld, een platform voor de uitrol en het management van containers op grote schaal. Kubernetes, Grieks voor stuurman of piloot, is de tweede naam voor het project, dat oorspronkelijk onder de noemer ‘Seven of Nine’ het levenslicht zag in de grote hallen van Google. ‘Project Seven’ was dan weer een externe versie van ‘Borg’: de task scheduler die de diensten van Google aandrijft, en waarvan de werking lang een Google-geheim was.
Borg werd meer dan een decennium geleden in het leven geroepen om containers binnen Google te beheren. Google koos er heel snel voor om zijn interne workloads in containers te plaatsen, omdat het op die manier (destijds) schaarse serverpk’s optimaal kon benutten. Om te weten wat Kubernetes doet, moet je eerst weten wat een container is, en waarom de dingen tegenwoordig zo hip zijn.
Virtual machines: nu al verouderd
Stel je voor dat je een applicatie wil draaien op een server in de cloud. Hoogstwaarschijnlijk stop je de applicatie in een virtual machine (VM). Die virtuele computer doet zich voor als een fysieke computer, zodat het voor de applicatie lijkt alsof ze op een echt systeem draait. De VM emuleert de hardware van een pc en draait daarbovenop een besturingssysteem, zoals Windows of je favoriete Linuxdistributie. Misschien sta je aan het hoofd van een start-up die de applicatie in kwestie als dienst aanbiedt. Wat de app ook is: jij bent briljant dus we gaan ervan uit dat de vraag naar de app snel stijgt.
Om tegemoet te komen aan de vraag, dien je meerdere instanties van de app te draaien. Dat zou je traditioneel doen door nieuwe VM’s te creëren. Die dienen telkens een hele pc te emuleren, inclusief volledig OS, met daarop uiteindelijk de app. Dat wil zeggen dat iedere instantie van de app best veel van de server vraagt, zodat je al snel betaalt voor heel wat rekenkracht. Een VM heeft minimumvereisten wat cpu en RAM betreft, al is het maar om het OS te draaien. De kans is groot dat je app best licht is, en op zich helemaal niet zoveel RAM of processorkracht nodig heeft.
Kleiner en efficiënter
Dat betekent dat er heel wat rekenkracht wordt verspild. Dat is jammer, en vooral duur. De container biedt soelaas. Containers, populair gemaakt met de lancering van Docker in 2013, kan je kort door de bocht zien als light-versies van VM’s. Ze gaan echter veel slimmer te werk. In plaats van een hele pc te emuleren, bevat een container alleen de dependencies (zoals bibliotheken) die een gegeven applicatie nodig heeft. De app wordt als het ware verpakt in een doosje met daarin alleen het hoogstnodige om vlot de functioneren.
Omdat een container geen hele pc virtualiseert, maakt hij flexibeler gebruik van beschikbare hardware.
Een container is veel kleiner en lichter dan een virtual machine, al is het maar omdat er geen volledige versie van een besturingssysteem in draait. Omdat een container geen hele pc virtualiseert, kan hij bovendien veel flexibeler gebruik maken van de beschikbare hardware.
Containers zijn zo een heel efficiënte technologie om apps en workloads te draaien in een serveromgeving. Zit je app in een container en dien je meerdere instanties te creëren om aan de vraag van je gebruikers te voldoen, dan zal je veel minder servers en serverkracht moeten inzetten voor hetzelfde resultaat. Efficiëntie en schaalbaarheid zijn hier de kernwoorden.
Orde in de chaos
Schaalbaarheid heeft zo z’n keerzijde, ondervond Google tien jaar geleden al. Tien of twintig containers beheren is geen probleem, daarvoor hoef je trouwens niet verder te kijken dan de Docker Swarm, maar wat als je honderden of zelfs duizenden instanties van een applicatie nodig hebt, die draaien in een datacenter met honderden servers? Om kostenefficiënt te blijven, moeten al die workloads zo efficiënt mogelijk verdeeld worden over de beschikbare hardware. Op grote schaal is er geen IT-beheerder die een dergelijke klus manueel wil uitvoeren.
Google ontwikkelde destijds Borg als een tool om grip te krijgen op het veelvoud aan gecontaineriseerde workloads. Seven of Nine en later Kubernetes zijn spin-offs van die technologie. Het laat een administrator toe om heel eenvoudig containers uit te rollen, en neemt het management van de uitgerolde containers in het datacenter op zich.
Opensource-assimilatie
In 2015 vertrouwde Google Kubernetes toe als opensourceproject aan de Cloud Native Computing Foundation, die het platform (of ecosysteem, al naargelang je definitie van platform) sindsdien beheert.
Kubernetes ontpopte zich in geen tijd tot de populairste standaard voor uitrol en management (orkestratie) van containers en gecontaineriseerde workloads. Kubernetes werkt met Docker-containers, die veruit het populairst zijn, maar is ook compatibel met andere containertechnologieën zoals LXD of rkt.
Kubernetes ontpopte zich in geen tijd tot de populairste standaard voor orkestratie van containers.
De technologie maakt gebruik van een Kubernetes-master en Kubernetes-nodes. De Kubernetes-master is het brein van het hele ecosysteem, en draait in principe op een eigen server. De Kubernetes-nodes draaien op de andere beschikbare servers (virtueel of fysiek), en zijn de werkkrachten die uitvoeren wat de master dicteert.
Werken met pods
Kubernetes werkt met ‘pods’. Een pod is een omhulsel voor één of meerdere containers. In één pod plaats je enkel containers die nauw met elkaar samenwerken en dezelfde systeembronnen zullen gebruiken. Denk hierbij niet aan meerdere instanties van dezelfde applicatie, maar eerder een bundeling van verschillende gecontaineriseerde applicaties, die samen deel uitmaken van een workload. Alles wat in een pod zit, draait steeds op hetzelfde systeem.
Verder kan Kubernetes labels toewijzen aan bijvoorbeeld pods. Daarin kan je de functie van een pod omschrijven, of de stabiliteit ervan aangeven. Dat maakt het eenvoudig om pods met bepaalde containers of workloads eenvoudig terug te vinden. Zoiets klinkt misschien triviaal, maar als je Kubernetes in een grote omgeving met heel veel apps en app-instanties gebruikt, is het onontbeerlijk.
De replication controller maakt het dan weer eenvoudig om pods te klonen en nieuwe instanties aan te maken. De controller staat zo in voor het schalen van de workloads.
Een uitrol of deployment van pods heeft een neefje: de services. Een deployment houdt pods online, terwijl services zich ontfermen over de netwerkconnectiviteit naar pods. Services zijn van belang omdat ze, in tegenstelling tot pods, nooit verdwijnen. Terwijl de replication controller extra pods kan aanmaken of verwijderen al naargelang de nood, blijft de service met bijhorende poortconfiguratie en IP-adres bestaan. Dat maakt het mogelijk voor andere applicaties om de service te vinden en ermee te verbinden, of er nu pods actief zijn of niet. Services en pods zijn dus complementair aan elkaar.
Andere relevante functies laten containers en nodes toe om datavolumes te delen, services, nodes en volumes te groeperen en meer. Kortom: de ontwikkelaar of IT-beheerder die zich volledig wil laten gaan met zijn containers, vindt in Kubernetes zijn gading.
Slim omgaan met systeembronnen
Vanuit een financieel plaatje is de ingebouwde load balancer misschien wel het belangrijkst. Dat is de Kubernetes-functie die ervoor zorgt dat nodes zo efficiënt mogelijk verdeeld worden over de beschikbare serverhardware. Moest je één node per server draaien, dan zouden containers niet zoveel efficiënter zijn dan traditionele VM’s. De load balancer zorgt ervoor dat nodes netjes serverkracht delen wanneer dat wenselijk is, of alsnog verspreid worden over meerdere servers wanneer er meer pk’s nodig zijn.
Een IT-infrastructuur gebouwd op containers en georkestreerd met Kubernetes is extreem krachtig, schaalbaar, redundant en efficiënt.
Een laatste relevant trucje dat Kubernetes aan boord heeft, heeft te maken met high availability. Kubernetes houdt je nodes immers permanent in het oog. Loopt er iets mis met de (virtuele) server waarop een node draait, dan zal Kubernetes zelf proberen om het probleem te mitigeren. Lukt dat niet, dan zal het platform een nieuwe node activeren die de taak van de falende node kan overnemen, zonder dat daar menselijke tussenkomst voor vereist is.
Ondanks de bestaande trucjes kan een bedrijf zich toch snel financieel laten vangen. Door de complexiteit van het platform wordt het al snel onoverzichtelijk om alle kosten en inefficiënties te monitoren. Ontwikkelaars bedachten dat de monitoring eenvoudiger zou moeten kunnen en kwamen op de proppen met Kubecost. Het gaat om een tool die realtime data monitort en inzichten geeft in kosten en andere inzichten.
Samengevat is Kubernetes een erg technisch platform, waarvan het desalniettemin interessant is om in grote lijnen te weten wat het net doet. Een IT-infrastructuur gebouwd op containers en georkestreerd met Kubernetes is extreem krachtig, schaalbaar, redundant en efficiënt. Het is niet voor niets dat de technologie na amper enkele jaren al zo alomtegenwoordig is. De opensourcegemeenschap zal de mogelijkheden van Kubernetes ongetwijfeld nog blijven uitbreiden, zodat het platform steeds in staat is de meest relevante containergerelateerde taken uit te voeren. Eén ding is zeker: Kubernetes is hip, en zal dat nog lange tijd blijven.
Herinnerd als grondlegger
Kubernetes zal volgens de voorspellingen dienen als basis van een reeks aan applicaties. Dat haalt de orchestratiesoftware uit de directe spotlights en kan de waan wekken dat Kubernetes slechts een vluchtige hype was.
Ontwikkelaars creëren eigen applicaties vanuit de beginselen van het platform, omdat veel zaken gewoonweg beter kunnen. Zo blijkt de beveiliging niet waterdicht en wordt aan ontwikkelaars aangeraden om Kubernetes Secret-bronnen niet te gebruiken. De beveiliging moet daarentegen gebaseerd zijn op de veilige principes authenticatie en autorisatie die in OIDC-tokens ingebakken ziten.
Negen op de tien ontwikkelaars loopt in een jaar tijd tegen minstens één beveiligingsincident aan. Door een dergelijk incident vormt de beveiliging weer even de topprioriteit van de ontwikkelaars en dat resulteert in een vertraagde uitrol van applicaties om de laatste zaken op vlak van beveiliging te kunnen afchecken.
lees ook
Traditionele hosting of containers met Kubernetes? En moet dat dan bij een hyperscaler?
Dan lopen ontwikkelaars nog tegen mankementen aan in de Ingress-resource. Dat is een API die beheert hoe HTTP-verkeer verdeeld wordt over de workloads. Het probleem is dat de API alleen te simpel is, wie wat meer wil dan de basis van traffic routing is er niets mee. Zelfs de medeoprichter van Kubernetes, Tim Hockin, vindt service meshes een veel geschikter alternatief.
Met service meshes wordt de Ingress-resource in verschillende resources onderverdeeld voor een beter overzicht. Daarnaast geeft het werknemers die instaan voor de structuur meer opties om networking te configureren. Het gaat over functionaliteiten zoals routing, zichtbaarheid, beveiliging en foutentolerantie.
Het schalen van Deployment-resources kan ook op een betere manier dan Kubernetes te bieden heeft. Een Deployment is een resource die definieert hoe een workload moet worden uitgevoerd. Het opvoeren van het aantal van deze resources kan volgens Kubernetes met HorizontalPodAutoscaler, maar daarin wordt de CPU niet optimaal benut en ligt de responstijd laag.
Nog tijd nodig
Dat Kubernetes slechts de grootvader is van een hoop opzichzelfstaande applicaties, is momenteel nog niet het geval. Zowat driekwart van de ondernemingen wereldwijd gebruikt wel iets van Kubernetes. Dat organisaties daar in korte tijd massaal weer vanaf stappen, lijkt ons onrealistisch. Al zijn er dus duidelijke verbeterpunten.
In de evolutie zal het platform wel herdacht worden als grondlegger van heel wat applicaties. Deze applicaties gaan aan de slag met de beginselen van het platform en brengen verbeterde versies uit van wat al in Kubernetes ingebakken zat.
Dit stuk verscheen origineel op 25 juli 2018 en is onderdeel van onze rubriek ‘IT uitgelegd’, waarin we belangrijke begrippen en technologieën achter de producten en innovaties van vandaag op een begrijpelijke manier uitleggen. Het werd laatst geüpdatet voor herpublicatie op 28/12/2022 door Laura Herijgers met de recentste informatie.