Hoe zit Kubernetes technisch in elkaar en wanneer maak je een microservice?

In eerdere blogs hebben we uitgelegd wat Kubernetes is en hoe je Kubernetes installeert. Het is een fantastisch stukje software, maar inhoudelijk is het best complex. In deze blog gaan we in op hoe Kubernetes technisch in elkaar zit en wanneer je een microservice maakt.

Kubernetes: een fantastisch stukje software

Laten we eerst door de basis onderdelen gaan. Kubernetes heeft en aantal onderdelen. De belangrijkste zijn de pod’s, hier zitten de containers in. Om die pod’s te bereiken vanuit buiten Kubernetes heb je een service nodig. Want de pod’s van een microservice, dit noemen we een deployment, kunnen meerdere keren naast elkaar gestart worden. Zoals meerdere servers, deze registeren zich bij de service. De pod’s wordt automatisch herstart bij problemen. Dit alles is actief op nodes, die verwerken de workload, dus de pods en de services. Om alles te beheren hebben, heeft Kubernetes ook software actief op masters. Deze zijn hetzelfde als nodes, maar dan met de paster pods erop. Deze zijn de Api server, de Scheduler, de controler manager en de ETCD database.

Wat is een microservice?

Een applicatie kan uit meerdere onderdelen bestaan, al deze onderdelen noemen we microservices. Een pod is een verzameling van containers die samen een microservice vormen waarbij 1 container het hoofd proces is. Je hebt daarna verschillende types van ondersteunde containers. Dit zijn sidecar’s en init en exit containers.

Voorbeeld:

Je verkoopt schoenen. Je doelgroep wil niet op blote voeten lopen, maar wil graag schoenen aan en in de plassen stampen. Voor de schoenen die je verkoopt maak je een website. Deze website is mooi, maar soms gaat er iets mis en dat wil je wel weten. Daarnaast wil je berichten krijgen als er een nieuwe pod start of als er een stopt. Het belangrijkste is de website, dit is het hoofd proces, om deze container draait het allemaal in deze pod. De rest ondersteunend oftewel een side car. Dit kunnen er meerdere zijn, maar in dit voorbeeld is het er maar één. Deze side car is een ondersteunend proces, deze stuurt de logging door naar centrale systemen omdat als de pod stopt ook de logging weg is en deze wil je graag behouden.

De kern van Kubernetes is een pod

Een pod is het kleinste onderdeel van Kubernetes. Je kan de pod niet rechtstreeks benaderen, dit doe je via een service. Het is namelijk best een uitdaging als je 1- pod’s hebt. Welke zou je dan moeten gebruiken? Dat doe je via een service, een pod meld zich aan bij een service. Deze service betekende requests round robin de requests over de pods verdeeld worden.

Wat is Round robin?

Round robin load balancing is dat een request (dat is 1 enkele aanvraag) naar de eerste gaat en de twee requests naar de tweede en de derde naar de derde en dan de vierde dan weer naar de eerste en enz. Dus de service verdeeld de load over de pod’s. Hij doet dat met behulp van een probe. Om precies te zijn met de Ready ness probe. Met de readiness probe wordt er gekeken of de pod klaar is voor netwerk verkeer. Deze probe kan op verschillende manieren kijken of de container klaar is. Kijk vaak of de poort open is. Dan stuur je netwerk verkeer vanuit de service. Een service krijgt ook een DHCP adres in het cluster. Maar dat is dus ook iets wat wij niet weten en willen weten. Gelukkig heeft een service een voorspelbare DNS naam. Dat is service naam – namespace – cluster naam.

Hoe herstart een pod bij problemen?

Hij kijkt naar de pod met probes, je hebt er drie soorten van. De readiness probe, een liveliness probe en een start up probe. De liveliness probe is een probe die de pod in de gaten houdt. Als deze een fout geeft dan zal hij de pod herstarten. Ook deze kan op verschillende de pod controleren zoals alle probes. Soms heb je een pod die er langer overdoet om te starten, dit wil e niet, maar soms gebeurd het. Dan wil je niet dat de liveliness de readiness probes meteen gaan controleren en de fout in gaan maar daar wil je even mee wachten. Anders kan je een geloopde pod krijgen. Een pod die herstart tijdens het starten omdat de liveliness probe af gaat. Deze startup probe zal dan zorgen dat de andere probes wachten totdat de pod klaar is om die probes te ontvangen. De pod’s draaien op een node. Een node is de hardware van Kubernetes en op de node staan twee stukjes software. Het ene is het kubelet, dat is Kubernetes software. En de andere is de container provider. Dat is in de laatste versie container. Deze is compatible met Docker en alle andere container technieken.

Hoeveel nodes heb je dan nodig?

Maak een cluster van 3 nodes en 2 masters. Op de meeste clouds zoals Azure of Google Cloud worden de masters beheerd door de clouds. De masters in een kubernetes cluster zijn ook normale nodes maar hier zitten een paar speciale pod's op. Het kan in verschillende vormen. 

Op een master zit de volgende pod's, en met 2 masters heb je deze pod's 2 maal

·         Een API server, deze zorgt voor de communicatie tussen alle services en zorgt er voor dat jij kan communiceren met de kubernetes.

·         De Scheduler die zorgt er voor dat de containers op de juiste plek komen op basis van de regels die er voor gesteld worden. Dit kan op basis van resouces of anti-affinity of een specifieke node

·         De Controller Manager zorgt er voor dat de container gecontroleerd worden dat het nog operationeel zijn.  Dit doet hij met de probes. 

·         En een nosql database waarin alles staat ETCD. Dit is een database die gemaakt is om over meerdere machines te draaien, een gedistribueerde database. Hij is ontzettend stabiel en consistent. 

Deze onderdelen zitten in de management omgeving van kubernetes.  Dan is er alleen nog een DNS server.

DNS server

Deze heeft van alle onderdelen die een IP adres hebben. Dat zijn in kubernetes pod's en services. Even een verschil met de on-premise ten opzichte van de cloud kubernetes. Op de on premise omgeving staat er niet alleen centraal een DNS server, het is overgens coredns. Maar op de nodes staat ook dns. Dit zijn dns caching servers en deze halen hun informatie op bij de centrale dns servers. Alle inzake van de snelheid van dns. En wat handig is dat de locale dns servers de communicatie met de centrale DNS server via encrypted kanalen doet. Als er een DNS probleem is dan staat de applicatie op onverklaarbare momenten te wachten op een time-out. Dus het is ontzettend belangrijk dat dat goed geregeld is. Dus nu hebben pods en services en management systemen.

Wanneer maak je een microservice?

Aan microservice zijn altijd voordelen en nadelen aan verbonden. Maar niet voor niets is het een trend dat de gehele development wereld in mee gaat. 

Dus wat is nu een microservice?

Een aantal regels voor het maken van een microservice:

1.   Onafhankelijk

2.   1 Doel 

3.   Functionele afscheiding

Stel je hebt een sokken webshop, een webshop met verschillende soorten sokken die je kan bestellen en je thuis laat bezorgen. Daarnaast heb je nog de keuze om je aan te melden voor een nieuwsbrief en heb je in de organisatie een voorraad beheer en waarschijnlijk nog veel meer. Dus als eerste start je met je webservice, de web pagina wil je graag onafhankelijk. Want je wilt mogelijk veel updates doen aan de voorkant, het aangezicht. Je noemt dit vaak de front-end. Dat is dan de eerste microservice. Dan wil je dat er niets mis gaat met de bestel procedure. Het is handig om deze los te hebben van de webservice, dit is dan de tweede microservice. De nieuwsberichten zijn een overzicht van wat er besteld is en welke leuke dingen er zijn in de webshop. Dit is nogal een zwaar proces en deze loopt op een bepaalde tijd. Deze moet je ook apart als microservice zetten. Dan de voorraad beheer, die krijgt minder updates dan de website dus maak je daar ook een microservice aan. Je kan er nog voor kiezen om voor extern verkeer een microservice te maken voor de updates van de specificaties van de sokken. Dat alles heeft dan een connectie met een database dienst, kan binnen of buiten Kubernetes.

Technieken in microservices

Je kunt verschillende technieken gebruiken in de microservices, vaak zie je dat de front-end een andere taal is dan de back-end omdat het sneller schrijven is. Daarnaast is het makkelijk te overzien, als het onderdeel waar je aan werkt kleiner is. Dus kan je ook de aanpassingen goed overzien. Dus kan je meer aanpassingen doen en dus sneller developen. Als je alleen of met twee personen aan een software product werkt, dan is het misschien een gedoe. Maar bij drie of meer developers gaat het al heel goed werken. Elke developer zou dan zijn eigen verantwoordelijk kunnen krijgen en dus goed overzicht.

Zelf aan de slag met Kubernetes

Wil je interactief aan de slag met Kubernetes? Het gehele jaar door organiseren wij masterclasses over Kubernetes. De categorieën waar je uit kunt kiezen zijn technische masterclasses, strategische masterclasses en Kubernetes & Security. Interesse? Meld je hier aan.