Kubernetes

De komst van docker, nu al meer dan 5 jaar geleden, heeft voor een behoorlijke disrupte gezorgd in onze industrie. Docker heeft containers breed beschikbaar gemaakt, en wij als industrie hebben dit met open armen ontvangen. Containererisation helpt ons met het hoog beschikbaar maken van applicaties. Maar, deze containers moeten natuurlijk ook ergens op gaan draaien.

Kubernetes

Toen was er Kubernetes

De meeste container platformen zijn allemaal gebaseerd op Kubernetes. Eigenlijk is dit ook niet geheel onverwacht, Kubernetes is namelijk de opensource opvolger van 'Borg', het container platform wat Google al in gebruik had. Zij waren al jaren eerder tegen de hyperscale en time-to-market problemen aangelopen, en de oplossing die zij hadden bedacht sloot naadloos aan met de ontwikkeling die docker in gang had gezet. Waar docker het isolatie probleem oploste, gaf Kubernetes het antwoord op hoe dit kan draaien op productie. Hyperscale? Als er 1 container kan draaien, kunnen er natuurlijk ook 100 draaien, of zelfs 100.000.

De bundel "The Datacenter as a computer" van meerde wetenschappelijke publicaties van Google spreekt als titel vooral tot de verbeelding. De grens van de wet van Moore is inmiddels bereikt, en we kunnen al een lange tijd niet meer rekenen dat de rekensnelheid en geheugencapaciteit elke twee jaar verdubbelt. Echter, als een datacenter als computer kan worden beschouwd, hoeft er ook niet verticaal geschaald te worden. De komst van nieuwe hardware vereist ook een nieuw besturingssysteem. Kubernetes kan gezien worden als het besturingssysteem voor dit datacenter. Het datacenter kunnen we zien als 'de cloud'.

Distributies en keuzes

Dat Kubernetes de wedloop heeft gewonnen kan inmiddels wel gezegd worden. Net als Linux zich in de jaren negentig heeft gevestigd, heeft Kubernetes dit in onze huidige eeuw gedaan. En net als bij de komst Linux destijds is gebeurd, zijn er meerdere distributies beschikbaar van dit Operating System. Ieder met zijn eigen smaak en voordelen. Red Hat wijst ons met OpenShift bijvoorbeeld op het belang van package management. SUSE laat ons met Rancher zien dat één gedeeld operating systeem niet altijd de beste keuze is, en maakt het ons makkelijk om meerdere instanties te beheren. De cloud providers specialiseren zich op managed Kubernetes diensten, zoals AKS, EKS en GKE. Deze producten nemen de operationele last over, zodat er zoveel mogelijk gefocust kan worden op de diensten die op het platform moeten draaien.

Wanneer is vanilla Kubernetes de beste oplossing, en wanneer kan er beter gekozen worden voor een meer uitgebreide distributie? Dit hangt af wat er op het platform draaien, en wie gaat het platform beheren. En ook als er gekozen is voor vanilla Kubernetes, zijn er nog tal van opties. Aan het ene uiteinde kan er gekozen worden voor de managed oplossingen in de cloud, aan het andere uiteinde kan er gekozen worden om helemaal van scratch cluster(s) op bare-metal of op VMs in de cloud te installeren. En de vraag die gesteld moet worden is: hoeveel budget is er beschikbaar voor Kubernetes expertise in de organisatie, en staat dat in verhouding met de schaal en het aantal applicaties die op dit platform gaan draaien?

 

Een cluster afgestemd op de applicatie

Na het draaien van Kubernetes is het werk ook nog niet klaar. Logging en monitoring zijn vaak de eerste eisen die ingevuld moeten worden. Producten van bijvoorbeeld banzaicloud kunnen helpen bij de inrichting, en kunnen ook met support contracten afgenomen worden. Een voordeel is dat je kan besluiten om een systeem minimaal te installeren, zeker als het vooraf al duidelijk is dat er maar bijvoorbeeld één bepaalde workload op gaat draaien. Het cluster kan helemaal aangepast worden voor die specifieke applicatie. Is er bijvoorbeeld een build and ship functie nodig in een platform die alleen het doel heeft om die specifieke applicatie te draaien? En hoe belangrijk is een mooie webconsole?

 

Dat is ook één van de grote voordelen van een het draaien van Kubernetes, en het verdelen over meerdere clusters. Het voordeel van een gedeeld platform, zoals OpenShift, is dat de beheerlast ook wordt gedeeld. Het nadeel van een gedeeld platform, is dat het gedeeld is. Men moet meegaan met de lifecycle van de centrale oplossing, en een aantal componenten (met name CRD’s) zijn een globaal. In een gedeeld platform zal het daarom niet zo snel mogelijk zijn om applicatie teams de mogelijkheid te geven om het platform op deze manier uit te breiden. Ook zal iedereen gelijk mee moeten gaan bij bijvoorbeeld updates van de centraal beheerde software (denk aan operators).

Kubernetes werkelijk werkend maken

Veel bedrijven worstelen met het opzetten en werkelijk werkend maken van hun applicatie omgeving in combinatie met Kubernetes. Met maar al te vaak een (leeg) spookplatform als gevolg. Eeuwig zonde, vinden wij. 

Wij maken Kubernetes daadwerkelijk werkend en acteren als een katalysator (We Enable). Voor nu en de toekomst. Hiervoor hanteren we een unieke aanpak, passend bij elke unieke situatie. Uiteindelijk pluk jij daar de vruchten van; jij scoort de voordelen (You Benefit).  Hoe we dat noemen? Business Driven Kubernetes. Omdat Kubernetes zoveel meer is dan alleen een platform.

HCS - We Enable - openshift