Kubernetes: pods, nodes en control planes

In een vorig artikel hebben we het uitgebreid gehad over wat Kubernetes is en wat je ermee kunt, maar zijn we nog niet dieper ingegaan op de opbouw van Kubernetes zelf. Hoog tijd om daar eens in te duiken.

Kubernetes is een opensourcesysteem om containerapplicaties mee te beheren, groeperen, af of op te schalen, load-balancen, uitrollen of intrekken. Om dit voor elkaar te krijgen heb je drie lagen in je Kubernetes-cluster: je control plane, gevolgd door je nodes, gevolgd door je pods. Laten we onderaan beginnen.

Pods: de werkbijen van je cluster

Pods zijn tegelijkertijd de minst en meest belangrijke elementen van je cluster. Ze bevatten de containers waarin de applicatie zit die je wilt gebruiken. Daarnaast bevatten ze informatie over hoe de containers uitgevoerd moeten worden. De pods kunnen makkelijk weggegooid en vervangen worden, mochten ze om wat voor reden dan ook falen of niet meer nodig zijn.

Een goed voorbeeld is een e-commerceapplicatie gebaseerd op microservices. Er is een microservice voor de producten waarin alle productinformatie opgehaald kan worden, een microservice voor het winkelmandje, een microservice voor de bestellingen en een losse microservice voor de users waarin accountmanagement, authenticatie en registratie afgehandeld wordt. Al deze losse onderdelen zijn gecontaineriseerd te gebruiken vanuit een pod. Samen met de pods voor je databaseconnectie en je front-endapplicatie vormen deze pods jouw e-commercewebsite.

Dit levert je meerdere voordelen op: je kunt heel makkelijk onderdelen van je e-commerce platform updaten zonder dat je hele applicatie erdoor beïnvloed wordt. De schaalbaarheid van Kubernetes zorgt er daarnaast voor dat je snel kunt inspringen op toegenomen traffic door, bijvoorbeeld, extra winkelmandjespods te deployen.

Pods bevatten normaal gesproken alleen die informatie die ze nodig hebben om hun deel van de applicatie te kunnen laten draaien. Als er problemen ontstaan in je applicatie omdat, bijvoorbeeld, je gebruikmaakt van een library die geüpdatet moet worden, trek je die pod uit je cluster en zet je een nieuwe op. Idealiter sla je daarom bijvoorbeeld geen usergegevens op in een pod, want deze data kan wegvallen wanneer de pod vervangen moet worden.

Nodes: de linemanager van je cluster

Je pods draaien niet als losse, zwevende elementen in je cluster maar worden gerund vanuit een node. Dit is een individuele (virtuele) server op je Kubernetes-cluster. In de node staan alle pods die nodig zijn om jouw applicatie te laten draaien, samen met de services die nodig zijn om je pods met elkaar en de control plane te laten communiceren. Deze components zijn bijvoorbeeld de kubelet, de kube-proxy en de container-runtime.

De kubelet zorgt ervoor dat alle containers binnen een pod worden uitgevoerd en voldoen aan een set eisen die wordt vastgelegd in de PodSpecs. De kube-proxy maakt netwerkcommunicatie zowel binnen als buiten je cluster mogelijk. Container-runtime zorgt er ten slotte voor dat er überhaupt containers uitgevoerd kunnen worden op je platform.

Een Kubernetes-cluster bestaat in principe uit minimaal 2 nodes, omdat één ervan dienst doet als control plane. In de werkelijkheid zul je meestal zien dat een cluster uit meer nodes dan dat bestaat. Hierbij kun je ervoor kiezen om je complete applicatie in één node te stoppen en meerdere nodes van dezelfde applicatie te draaien. Zo kan in het voorbeeld van het e-commerceplatform één node gebruikt worden voor de liveserver, één voor een testomgeving en één voor een tweetalig platform.

Maar het komt vaker voor dat de applicatiepods worden verdeeld over meerdere nodes om te voorkomen dat de load op één te groot wordt. Of dat de applicatie plat gaat als die ene node waar alle databasepods in draaien down gaat. Dit heeft als voordeel dat je de resources per node ook beter kunt verdelen. De node waar je voornamelijk front-end op hebt draaien heeft ten slotte niet zoveel CPU nodig als een node waar je je back-end op regelt.

Control plane: de cockpit van je cluster

Hoewel de control plane node technisch gezien dus gewoon een node in je cluster is waar pods in draaien, is het wel een speciale node. Hier draaien namelijk alle essentiële containers in: de verbinding van je cluster met de Kubernetes API, de scheduler, je controller manager en je key value storage. Al deze containers zijn pods; je zou technisch gezien dus ook ervoor kunnen kiezen je control plane te verdelen over allerlei nodes in plaats van één control plane node te gebruiken.

Je control plane is verantwoordelijk voor alle administratieve taken waardoor je cluster kan doen wat het moet doen. Van de verbinding in stand houden met de Kubernetes API, het inplannen en maken van nieuwe pods, ze toewijzen aan nodes indien nodig, tot resource management en load balancing van het hele cluster.

Hoewel in normale clusters er dus altijd minimaal één node opgaat aan je control plane, hebben we er bij TransIP voor gekozen om dat voor je uit handen te nemen. Dat betekent niet alleen dat jij voor je cluster niet altijd minstens één extra node moet hebben draaien om je cluster überhaupt te kunnen laten werken, maar ook dat het onderhoud van kritieke systemen zoals Etcd en de scheduler bij ons ligt.

Zelf aan de slag?

Wil je zelf aan de slag met een Kubernetes-cluster? Op onze Knowledge Base vind je een enorme berg informatie, te beginnen met de Kubernetes Quickstart-handleiding. Hierin vind je de informatie die je nodig hebt om een cluster op te zetten. Meer informatie over Kubernetes en alle prijzen vind je op de website.