Kubernetes (k8s) is een container-orkestratie. Volgens de Vandale, betekent orkestratie “voor orkest bewerken“ of “organiseren en leiden“. Dat laatste is wat k8s doet, namelijk ervoor zorgen dat software voor een klant te allen tijde bereikbaar blijft door containers in een cluster van systemen te organiseren. De master is als het ware de dirigent die met de containers communiceert, die op hun beurt rapporteren aan de Application Programming Interface (API).
De teruggekomen informatie wordt door de master geïnterpreteerd en op basis daarvan wordt bepaald wat moet gebeuren om de software beschikbaar te houden voor de klant. Enerzijds zou dit het (verplaatsen of) herstarten (autohealing) van een container kunnen zijn naar een ander system, doordat deze gestopt was door een gebrek aan resources (CPU, memory, storage etc.), anderzijds zou dit het starten van extra containers kunnen zijn (autoscaling).
Waarom kiezen we voor Kubernetes?
Er wordt op internet tal van redenen genoemd waarom men voor k8s zou moeten kiezen. Eén daarvan is DevOps, echter is dit een term die op verschillende manieren wordt uitgelegd door verschillende mensen. Als organisatie wordt gekeken naar een manier van werken, die de Time To Market (TTM) van nieuwe features verkort, beschikbaarheid van de software verhoogt en de kostenefficiëntie voor de klant borgt. Dit is alleen mogelijk met een container-orkestratie die wordt omarmd door meerdere cloud providers, continue verbeterd wordt en beschikt over tenminste auto-healing en -scaling.
Doordat k8s gebruik maakt van YAML Ain’t Markup Language (YAML), kan men vrij eenvoudig beginnen met het deployen van containers op k8s. De basis om software beschikbaar te stellen voor een klant, bestaat meestal uit een deployment, service en ingress in combinatie met een configMap en/of environment variabelen. Als men de eerste deployment heeft uitgevoerd kunnen de developers vrij snel de ontwikkelde software beschikbaar stellen voor de klant. In veel gevallen volstaat een kubectl apply -f deployment.yaml hetgeen de software op k8s laat draaien. Het voordeel van deze manier van werken is dat de TTM significant wordt verlaagd. Indien de consistentie wordt afgedwongen kan de procedure in een Continuous Integration/Continuous Deployment (CI/CD) worden vastgelegd en iedere code change na reviewen automatisch deployed worden. K8s draagt bij aan infrastructure-as-code en verlaagt de TTM.
Binnen ilionx maken we op dit moment gebruik van OpenShift en AWS EKS Fargate, welke beide zijn gebaseerd op Kubernetes.
Beschikbaarheid
Traditioneel Operations hield in dat een System Engineer, software van een Software Engineer kreeg en dat de eerstgenoemde deze software moest gaan uitrollen op een systeem. Indien de applicatie niet meer werkte op een bepaald moment dan zou de engineer deze handmatig moeten herstarten. Het kwam ook voor dat opgegeven moment een applicatie dusdanig veel resources in gebruik ging nemen dat de beheerder het systeem qua resources moest gaan uitbreiden (verticaal schalen) of systemen erbij moest gaan plaatsen (horizontaal schalen) en vervolgens de applicatie op het nieuwe systeem te zetten. Op een gegeven moment werden Configuration Management Tools (CMT), zoals Ansible en Puppet populair en kon dit semi-geautomatiseerd worden door het nieuwe IP van de machine toe te voegen aan de CMT manifests en vervolgens handmatig het weer uit te voeren. Indien een node niet meer bereikbaar was, waren ook de applicaties die op dat systeem stonden niet meer bereikbaar.
K8s bestaat uit minimaal een master node die in staat is te bepalen of er op een systeem genoeg resources zijn om een container te kunnen draaien. Indien een programma stopt om wat voor reden dan ook, dan zorgt k8s ervoor dat dit weer wordt gestart (autohealing). K8s is eveneens in staat om aan de hand van drempelwaarden op CPU en memory, te bepalen of een tweede instantie of meerdere, extra opgestart moeten worden om de load te kunnen verwerken. Het zorgt er eveneens voor dat de containers weer worden afgeschaald indien de load afneemt (autoscaling). Ook de storage allocatie wordt de k8s afgehandeld en deze kan eveneens persistent zijn, hetgeen inhoudt dat de bestanden die in een container zijn aangemaakt weer terugkomen indien een container opnieuw opstart. Standaard zijn container stateless, hetgeen betekent dat er geen staat wordt bijgehouden en deze als het ware is reset na het stoppen van de container. K8s regelt eveneens de loadbalancing en toegang tot applicaties en d.m.v. RBAC kan ook de authorisatie worden ingericht. Bovendien kan een oauth-proxy gebruikt worden om de authenticatie te laten verlopen via k8s. Configuraties kunnen ingevoerd worden en ook environment variabelen en secrets. De laatste is eigenlijk een base64 en is eigenlijk niet secure, maar daarbij kan een 3rdparty tool zoals HashiCorp Vault soelaas bieden.
Kostenefficiëntie
K8s is cloud-agnostisch, hetgeen platform onafhankelijk betekent en wil zeggen dat het op Google Cloud Platform (GCP), Amazon Web Services (AWS), Azure en andere platformen kan draaien. Waarom draagt dit bij aan kostenefficiëntie? Stel dat men alles op bijvoorbeeld GCP door gebruik te maken van services die alleen maar op dat platform voorkomen en GCP besluit hun prijzen te verhogen? Dan kan het voor de klant dusdanig duur worden om te verhuizen naar een ander platform zoals AWS, dat goedkoper is om om GCP te blijven, terwijl het eigenlijk duurder is, maar omdat men meer kosten kwijt zal zijn om te verhuizen zal men bij GCP blijven. Er is dan sprake van Vendor lock-in. Aangezien k8s platform onafhankelijk is kan men zonder hoge kosten verhuizen naar bijvoorbeeld AWS. Indien men Google Kubernetes Engine (GKE) gebruikt kan men de containers probleemloos verplaatsen naar een Amazon Elastic Kubernetes Service (EKS) aangezien men met de API van k8s communiceert alleen dan op een ander platform. Twee dingen om rekening mee te houden zijn de Ingress annotaties en storage classes die per platform verschillend kunnen zijn. Voor AWS, GCP en Azure zijn de annotaties goed gedocumenteerd.
K8s maakt het ook mogelijk om zogeheten requests en limieten te definiëren waarbinnen een container moet draaien. Dit houdt in indien software meer gebruikt dan is toegestaan dat dan de container wordt gestopt en opnieuw wordt gestart (autohealing). Dit bespaart kosten in een cloud wereld, waarin wordt betaald voor iedere resources die per seconde wordt gebruikt. Indien op een of andere manier een memory leak ontstaat in een product dan kan dit ervoor zorgen dat er meer resources worden verbruikt dan men nodig zou moeten hebben en er meer kosten worden gemaakt. Bovendien is het bewust van het verbruik van resources ook beter voor het milieu, hoe minder resources worden verbruikt, hoe minder energie het kost etc.
