Sinds enkele jaren zien we in het IT-landschap een verschuiving van het bouwen van één grote applicatie (monoliet) naar het opsplitsen van een monoliet in verschillende microservices. Het is deze beweging naar microservices in combinatie met containers die onze manier van bouwen, deployen op verschillende omgevingen en onderhouden van software drastisch heeft veranderd.
Containers
Het gebruik van containers is een relatief nieuwe manier om software te verpakken in één unit of work. Alles wat er nodig is om een applicatie stand alone te kunnen draaien wordt verpakt in een container. Deze container kan softwareversies en applicatie specifieke configuraties bevatten en wordt gebruikt om de applicatie te scheiden van de omgeving waarin hij draait. Wanneer een monoliet applicatie meer load moet verwerken, bijvoorbeeld een webshop tijdens de eindejaarsperiode, is het horizontaal schalen van deze applicatie een mogelijke oplossing. Bij het horizontaal schalen wordt er een nieuwe virtuele machine opgezet, moet de applicatie op deze virtuele machine gedeployed worden en zijn er nieuwe loadbalancing configuraties nodig. Een alternatieve en ook snellere oplossing van dit probleem is het verticaal schalen van de applicate. Bij het verticaal schalen van een applicatie wordt er meer vermogen toegevoegd aan de virtuele machine in de vorm van meer RAM en CPU. Maar RAM en CPU zijn duur en bijgevolg ook niet de beste oplossing. Door gebruik te maken van containers en microservices kan de overstap naar horizontaal schalen sneller gemaakt worden. We hernemen het voorbeeld van de webshop tijdens de eindejaarsperiode. Indien een container waarop een bepaalde microservice draait in de problemen komt door het hoge aantal bezoekers van de webshop, kan dezelfde container een tweede keer opgestart worden.
Orchestration
Mits wat loadbalancing configuratie zal deze microservice meer rekenkracht hebben omdat hij nu dubbel zoveel resources tot zijn beschikking heeft. In een landschap met enkele microservices en containers is het nog relatief eenvoudig om dit handmatig te onderhouden. Indien de architectuur uitbreidt en er bijvoorbeeld gesproken wordt van vijftig microservices en een meervoud aan containers is er nood aan een tool die dit voor ons oplost. Zulke tools worden Container Orchestration tools genoemd en één voorbeeld hiervan is Kubernetes.
Kubernetes
Kubernetes is een open source product, ontwikkeld door Google. Wanneer men spreekt over Kubernetes komen volgende begrippen steeds terug: “Kubernetes cluster, cluster control plane, node, kubelet, pod, service en replicasets”. De Kubernetes cluster bevat enkele nodes waarvan minstens één de master node is. Een node is een fysieke of virtuele machine. De master node wordt ook de cluster control plane genoemd. De andere nodes ook wel de worker nodes genoemd, draaien elk het kubelet proces. Dit proces is verantwoordelijk voor het starten, stoppen en onderhouden van pods op de node en krijgt zijn instructies van de master node.
Pod
Een pod is de basis bouwsteen van een Kubernetes cluster en is het object dat aangemaakt en gedeployed wordt in de cluster. Het groepeert containers die dezelfde resources nodig hebben, bijvoorbeeld één zelfde database. Een pod kan één of meerdere containers bevatten, maar de meest voorkomende methode is de one-container-per-Pod methode. Door gebruik te maken van een service kunnen pods logisch gegroepeerd worden op basis van bijvoorbeeld een applicatie naam en/of ip-poort of andere labels. Elke service binnen de Kubernetes cluster krijgt een virtueel IP. Op elke worker node in de Kubernetes cluster draait het kube proxy proces. Dit proces creëert iptables rules (op de node) gebaseerd op alle gedefinieerde services binnen de Kubernetes cluster en routeert het netwerkverkeer op de node naar de juiste pod. Hierdoor kunnen afzonderlijk pods, bijvoorbeeld backend en frontend pods, automatisch met elkaar communiceren. Dit proces wordt in zijn geheel ook wel Service Discovery en load balancing genoemd.
Replicaset
Een replicaset zorgt ervoor dat er steeds een bepaald aantal replica’s van een pod draaien. Wanneer er onverwachts een pod uitvalt, door bijvoorbeeld een onderhoud op een node, zorgt de replicaset ervoor dat deze pod opnieuw opgestart wordt en dit eventueel op een andere (worker) node. Dit wordt ook wel self healing genoemd. Door het aantal replica’s in een replicaset te vermeerderen of te verminderen kan er makkelijk horizontaal geschaald worden. Dit proces, het schalen van de pods, kan ook automatisch getriggerd worden op basis van het monitoren van bepaalde resources. Indien bijvoorbeeld alle pods van de replicaset meer dan 50% van de CPU-capaciteit in beslag nemen, wordt er een nieuwe pod opgestart. Indien het cpu gebruik weer daalt, wordt er één of meerdere pods afgesloten. Dit kan door gebruik te maken van Horizontal Pod Autoscalers. Hiermee worden bepaalde parameters gedefinieerd zoals het maximum en minimum aantal pods van een replicaset en welke resource er gemonitord moet worden.
Self healing
De hierboven beschreven processen: Service discovery en load balancing, automatisch horizontaal schalen, self healing, zijn een deel van het takenpakket die container orchestration tools van ons overnemen. Daarnaast worden deze tools ook gebruikt voor het uitvoeren van rolling updates en het beheren van applicatie configuraties en properties. Kubernetes mag zeker de industrie standaard genoemd worden. Mede dankzij de grote cloud spelers, zij bieden immers elk hun eigen management service rond kubernetes aan. Amazon biedt Amazon Elastic Container for Kubernetes (Amazon EKS) aan. Google Cloud heeft zijn eigen Google Cloud Kubernetes Engine en Azure heeft zijn Kubernetes management oplossing Azure Kubernetes Service genoemd. Kubernetes is natuurlijk niet de enige container orchestration tool op de markt. Docker Swarm en Apache Mesos/Marathon zijn twee populaire alternatieven. Dit is een high level overzicht van wat container orchestration tools zijn met als voorbeeld Kubernetes. Wie een dieper inzicht wil krijgen in Kubernetes kan ik onderstaande Devoxx talk aanraden.
