Kubernetes biedt in heel veel gevallen meerwaarde. Het maakt het beheren van applicaties in veel opzichten eenvoudiger, het biedt een eenvoudige manier om high-availability te introduceren en het biedt een erg efficiente vorm van schaalbaarheid. Daarmee kan het gebruik van Kubernetes veel tijdswinst opleveren ten opzichte van de meer traditionele vormen van infrastructuur en hosting. Om die reden helpen wij je graag op weg met Kubernetes. Dit is het eerste artikel van een reeks waarin we je op weg willen helpen met Kubernetes. In dit artikel behandelen we de belangrijkste termen en concepten die relevant zijn om goed te starten met Kubernetes. Houdt ons Kubernetes blog in de gaten voor de volgende artikelen.

Termen

Node

Een node is een virtuele of fysieke server. Meerdere nodes vormen samen een cluster waarop het volledige Kubernetes platform draait.

Cluster

Kubernetes draait op een aantal samenwerkende nodes die samen het cluster vormen. Dat cluster van nodes vormt de basis van je Kubernetes-infrastructuur. Een cluster bestaat uit meerdere nodes, zodat de belasting van je applicaties goed verdeeld kan worden en om high-availability te kunnen bieden. Valt een van de nodes uit, dan staan andere nodes klaar om het werk over te nemen. Kies je voor de Kubernetes van Cloudlets, dan is Kubernetes in staat om zelf een nieuwe node op te starten en te koppelen aan je cluster. Je kunt het cluster het beste beschouwen als een centrale omgeving waar al je applicaties op draaien. Je hebt geen omkijken naar de individuele nodes, want Kubernetes zorgt ervoor dat de containers die je draait gelijkmatig verdeeld worden over het cluster.

Container

Een container is een uitvoerbaar pakket met software. De container bevat alles dat het nodig heeft om zelfstandig te kunnen draaien, onafhankelijk van het besturingssysteem van de onderliggende server of computer. Alle noodzakelijke software, libraries en afhankelijkheden zijn in de container aanwezig. Doordat de software in de container geïsoleerd is van de onderliggende software en infrastructuur, zal de container overal hetzelfde functioneren. Dat maakt de software portable, voorkomt een vender lock-in en biedt optimale controle over je applicatie.

Pod

In de meeste gevallen heb je meerdere containers nodig om je applicatie goed te draaien. Denk bijvoorbeeld aan een container voor de webserver, een container voor PHP en een container met je daadwerkelijke applicatie. De groep van containers die bij elkaar horen vormen samen een pod. De containers in de pod kunnen onderling communiceren, maken gebruik van het geheugen en de CPU die aan de pod is toegekend, waardoor je je geen zorgen hoeft te maken over de resource-behoeften van de individuele containers. Je containers draaien dus niet direct op het Kubernetes cluster, maar in de pod. De pod zou je kunnen zien als een laag boven de container. De pod is het fundament voor een van de grootste voordelen van Kubernetes, namelijk high availability en schaalbaarheid.

Deployment

De deployment vormt de laag tussen het Kubernetes cluster en de pods. In deze abstracte laag wordt de schaalbaarheid en replicatie van de pods geregeld. In je deployment geef je aan hoeveel replicates van je pod tegelijkertijd moeten draaien. Kies je ervoor om meerdere replicas van een pod te draaien en crasht een van deze pods, dan zorgt je deployment voor het starten van een nieuwe pod, zodat weer voldaan wordt aan het aantal pods dat je altijd wilt hebben draaien. Ondertussen regelt je deployment ook dat al het verkeer over de beschikbare pods verdeeld wordt. Hiermee kan je met deployment zorgen voor high-availability en schaalbaarheid van je applicaties. Draai je meerdere replicas van je pod, dan geeft een crash van een van de containers in je pod geen overlast voor de gebruikers van je applicatie.

Persistent Volume

Containers en pods komen en gaan, doordat Kubernetes extra replicas kan opstarten om aan je schaalbaarheidsbehoefte te voldoen, omdat een container crasht of omdat je het aantal nodes in je cluster uitbreidt. Daarom wil je geen data opslaan in je containers. Je containers behoren alleen data te bevatten die bewaard moet blijven, want bij een herstart van de container is die data weg. Daarom dien je een Persistent Volume aan te maken waarom je container alle data opslaat. Iedere container maakt gebruik van de data op deze Persistent Volume. Daardoor kan Kubernetes waarborgen dat iedere deployment van een pod identiek is. Het mag natuurlijk niet zo zijn dat meerdere bezoekers of gebruikers van je applicatie andere data zien.

Concepten

Elke container zijn eigen taak

De kracht van Kubernetes zit in de high-availability, schaalbaarheid en beheergemak. Om van die kracht te profiteren is het van belang dat je voor iedere taak een eigen container maakt. Dat zorgt ervoor dat je pods eenvoudig kunt repliceren, dat containers en pods opnieuw en onafhankelijk van elkaar gestart kunnen worden zonder dat het je infrastructuur in gevaar brengt en het houdt het geheel overzichtelijk. Het is niet raar om een container te hebben voor je webserver en een container voor de daadwerkelijke applicatie die je wilt draaien.

Image Immutability Principle

Verander nooit een image dat je al hebt gebruikt om containers mee uit te rollen. Het is best practice om met ieder nieuw image een nieuw label mee te geven waaraan je kunt herkennen welk image je hebt gebruikt om containers mee te deployen. Zodra je een nieuw image hebt, dient je met dit image de bestaande containers te vervangen. Voor de consistentie van je deployments is het van groot belang dat containers identiek aan elkaar zijn. Als je bestaande images aanpast, komt die consistentie in gevaar. Wij adviseren je gebruik te maken van labels in de metadata van je pods en containers om het overzicht tussen de verschillende versies van je image te bewaren.

Scheiding data en applicatie

Containers zijn van nature vervangbaar. Is er een nieuwe versie van je image, dan start je op basis van dat image nieuwe containers op die de bestaande containers vervangen. Alle data die in de tussentijd aan je container is toegevoegd, gaat daarmee verloren. Het is dus cruciaal dat je een strikte scheiding hanteert tussen je applicatie en je applicatie-data. Containers horen stateless te zijn, dat wil zeggen dat de container geen gebruiksdata vast zou moeten houden. Alle data die door gebruikers gegenereerd wordt en bewaard moet blijven of door meerdere replica’s van een container gebruikt moet worden, behoort op een Persistent Volume te staan.

Meer weten over de meest gebruikte principes bij het ontwerpen van je containergebaseerde infrastructuur? Lees dan het whitepaper Principles of Container-Based Application Design van Red Hat.