Kubernetes 101: pods, knooppunten, containers en clusters

Kubernetes wordt snel de nieuwe standaard voor het implementeren en beheren van software in de cloud. Met alle kracht die Kubernetes biedt, komt er echter een steile leercurve. Als nieuwkomer kan het overweldigend zijn om de officiële documentatie te ontleden. Er zijn veel verschillende onderdelen waaruit het systeem bestaat, en het kan moeilijk zijn om te bepalen welke relevant zijn voor uw toepassing. Deze blogpost biedt een vereenvoudigde weergave van Kubernetes, maar probeert een overzicht op hoog niveau te geven van de belangrijkste componenten en hoe ze bij elkaar passen.

Laten we eerst eens kijken hoe hardware wordt weergegeven

Hardware

Knooppunten

Een node is de kleinste eenheid computerhardware in Kubernetes. Het is een weergave van een enkele machine in uw cluster. In de meeste productiesystemen is een knooppunt waarschijnlijk een fysieke machine in een datacenter of een virtuele machine die wordt gehost op een cloudprovider zoals Google Cloud Platform. Laat conventies u echter niet beperken; in theorie kun je van bijna alles een knooppunt maken.

Door een machine als een “knooppunt” te beschouwen, kunnen we een abstractielaag invoegen. In plaats van ons zorgen te maken over de unieke kenmerken van een individuele machine, kunnen we in plaats daarvan elke machine gewoon zien als een set CPU- en RAM-bronnen die kunnen worden gebruikt. Op deze manier kan elke machine elke andere machine in een Kubernetes-cluster vervangen.

Het cluster

Hoewel werken met afzonderlijke knooppunten handig kan zijn, is dit niet de Kubernetes-manier. Over het algemeen moet u aan het cluster als geheel denken, in plaats van u zorgen te maken over de toestand van individuele knooppunten.

In Kubernetes bundelen nodes hun bronnen om een ​​krachtigere machine te vormen. Wanneer u programma’s op het cluster implementeert, wordt het op intelligente wijze voor u gedistribueerd naar de afzonderlijke knooppunten. Als er knooppunten worden toegevoegd of verwijderd, zal het cluster indien nodig rond het werk schuiven. Het zou voor het programma of de programmeur niet moeten uitmaken welke individuele machines de code daadwerkelijk uitvoeren.

Als dit soort hivemind-achtig systeem je aan de Borg uit Star Trek doet denken, ben je niet de enige; “Borg” is de naam voor het interne Google-project waarop Kubernetes was gebaseerd.

Aanhoudende volumes

Omdat programma’s die op uw cluster worden uitgevoerd, niet gegarandeerd worden uitgevoerd op een specifiek knooppunt, kunnen gegevens niet op een willekeurige plaats in het bestandssysteem worden opgeslagen. Als een programma probeert gegevens op te slaan in een bestand voor later, maar vervolgens wordt verplaatst naar een nieuw knooppunt, zal het bestand niet langer zijn waar het programma verwacht dat het is. Om deze reden wordt de traditionele lokale opslag die aan elk knooppunt is gekoppeld, behandeld als een tijdelijke cache om programma’s vast te houden, maar van lokaal opgeslagen gegevens kan niet worden verwacht dat ze blijven bestaan.

Om gegevens permanent op te slaan, gebruikt Kubernetes persistente volumes. Hoewel de CPU- en RAM-bronnen van alle knooppunten effectief worden samengevoegd en beheerd door het cluster, is permanente bestandsopslag dat niet. In plaats daarvan kunnen lokale of clouddrives als een permanent volume aan het cluster worden gekoppeld. Dit kan worden gezien als het aansluiten van een externe harde schijf op het cluster. Persistent Volumes bieden een bestandssysteem dat aan het cluster kan worden gekoppeld, zonder te worden geassocieerd met een bepaald knooppunt.

Software

Containers

Programma’s die op Kubernetes worden uitgevoerd, worden verpakt als Linux-containers. Containers zijn een algemeen aanvaarde standaard, dus er zijn al veel vooraf gemaakte images die op Kubernetes kunnen worden geïmplementeerd.

Met containerisatie kunt u zelfstandige Linux-uitvoeringsomgevingen maken. Elk programma en al zijn afhankelijkheden kunnen in één bestand worden gebundeld en vervolgens op internet worden gedeeld. Iedereen kan de container downloaden en op zijn infrastructuur implementeren met heel weinig installatie. Het aanmaken van een container kan programmatisch gebeuren, waardoor krachtige CI- en CD-pipelines kunnen worden gevormd.

Er kunnen meerdere programma’s in een enkele container worden toegevoegd, maar u moet zich indien mogelijk beperken tot één proces per container. Het is beter om veel kleine containers te hebben dan één grote. Als elke container een strakke focus heeft, zijn updates gemakkelijker te implementeren en zijn problemen gemakkelijker te diagnosticeren.

Pods

In tegenstelling tot andere systemen die u in het verleden misschien hebt gebruikt, voert Kubernetes containers niet rechtstreeks uit; in plaats daarvan verpakt het een of meer containers in een structuur op een hoger niveau, een pod genaamd. Alle containers in dezelfde pod delen dezelfde bronnen en hetzelfde lokale netwerk. Containers kunnen gemakkelijk communiceren met andere containers in dezelfde pod alsof ze zich op dezelfde machine bevinden, terwijl ze toch een zekere mate van isolatie van anderen behouden.

Pods worden gebruikt als de replicatie-eenheid in Kubernetes. Als uw app te populair wordt en een enkele podinstantie de belasting niet kan dragen, kan Kubernetes worden geconfigureerd om indien nodig nieuwe replica’s van uw pod in het cluster te implementeren. Zelfs als deze niet zwaar wordt belast, is het standaard om op elk moment meerdere kopieën van een pod in een productiesysteem te laten draaien om taakverdeling en storingsbestendigheid mogelijk te maken.

Pods kunnen meerdere containers bevatten, maar u moet uzelf indien mogelijk beperken. Omdat pods als een eenheid omhoog en omlaag worden geschaald, moeten alle containers in een pod samen worden geschaald, ongeacht hun individuele behoeften. Dit leidt tot verspilling van middelen en een dure rekening. Om dit op te lossen, moeten pods zo klein mogelijk blijven, meestal met alleen een hoofdproces en de nauw gekoppelde hulpcontainers (deze hulpcontainers worden meestal “zijspanwagens” genoemd).

Implementaties

Hoewel pods de basiseenheid van berekening zijn in Kubernetes, worden ze doorgaans niet rechtstreeks op een cluster gestart. In plaats daarvan worden pods meestal beheerd door nog een abstractielaag: de implementatie.

Het primaire doel van een implementatie is om aan te geven hoeveel replica’s van een pod tegelijkertijd moeten worden uitgevoerd. Wanneer een implementatie aan het cluster wordt toegevoegd, wordt automatisch het gevraagde aantal pods gestart en vervolgens bewaakt. Als een pod sterft, wordt deze automatisch opnieuw gemaakt door de implementatie.

Met een implementatie hoeft u niet handmatig met pods om te gaan. U kunt gewoon de gewenste toestand van het systeem aangeven, en het wordt automatisch voor u beheerd.

Ingress

Met behulp van de hierboven beschreven concepten kunt u een cluster van knooppunten maken en implementaties van pods op het cluster starten. Er is echter nog een laatste probleem dat moet worden opgelost: extern verkeer naar uw applicatie toestaan.

Kubernetes biedt standaard isolatie tussen pods en de buitenwereld. Als u wilt communiceren met een service die in een pod wordt uitgevoerd, moet u een communicatiekanaal openen. Dit wordt inkomend verkeer genoemd.

Er zijn meerdere manieren om inkomend verkeer aan uw cluster toe te voegen. De meest gebruikelijke manieren zijn door een Ingress-controller of een LoadBalancer toe te voegen. De exacte afwegingen tussen deze twee opties vallen buiten het bereik van dit bericht, maar u moet zich ervan bewust zijn dat u moet omgaan met binnendringen voordat u kunt experimenteren met Kubernetes.

Wat is het volgende

Wat hierboven wordt beschreven, is een te vereenvoudigde versie van Kubernetes, maar het zou u de basis moeten geven die u nodig heeft om te beginnen met experimenteren. Nu u de onderdelen van het systeem begrijpt, is het tijd om ze te gebruiken om een ​​echte app te implementeren. Bekijk Kubernetes 110: Your First Deployment om aan de slag te gaan.

Om lokaal met Kubernetes te experimenteren, maakt Minikube een virtueel cluster op uw persoonlijke hardware. Als u klaar bent om een ​​cloudservice uit te proberen, heeft Google Kubernetes Engine een verzameling handleidingen om u op weg te helpen.

Als je nieuw bent in de wereld van containers en webinfrastructuur, raad ik je aan om de 12 Factor App-methodologie te lezen. Hierin worden enkele van de best practices beschreven waarmee u rekening moet houden bij het ontwerpen van software voor gebruik in een omgeving als Kubernetes.

Tot slot, voor meer van dit soort inhoud, volg me hier op Medium en op Twitter (@ DanSanche21).