De toepassing van containers wordt steeds gangbaarder. Volgens Gartner zal tegen 2024, 15% van alle applicaties in containers draaien en zal 75% van alle organisaties containers gebruiken in productie. Dit komt door de stijgende populariteit van cloud-native platformen die het gebruik van containers mogelijk maken. Bovendien verwacht Gartner dat 95% van nieuwe digitale workloads tegen 2025 op deze platformen zullen landen. Een van de meest gebruikte platformen is Kubernetes. Kubernetes is de defacto standaard geworden voor de uitrol en het beheer van gecontaineriseerde workloads. Maar als je Kubernetes gaat gebruiken, zijn er een aantal aandachtspunten waarmee je rekening moet houden. In dit artikel gaan we hier dieper op in, zodat je beter voorbereid bent bij het gebruik van Kubernetes.
Het begint bij het gebruik van container-technologie. Een belangrijk kenmerk van containers is portabiliteit. Door de code van een applicatie in een container te verpakken, kan deze overal draaien, omdat alles wat nodig is voor de applicatie in de container aanwezig is. Echter, de container runtime die nodig is om het te laten draaien, is afhankelijk van een server. Als de runtime wegvalt door een uitvallende server, is de applicatie niet langer beschikbaar. Dit is waar Kubernetes om de hoek komt kijken. Kubernetes is een open-source cluster systeem voor het geautomatiseerd uitrollen, op-/af-schalen en beheren van gecontaineriseerde applicaties. Als een applicatie in containers is verpakt, maak je een ‘afspraak’ met Kubernetes om deze container in het cluster te laten draaien. Bij Kubernetes is afspraak een afspraak, dus als er een machine in het cluster uitvalt, zorgt Kubernetes ervoor dat de container op een andere machine wordt geplaatst en dat er een nieuwe machine aan het cluster wordt toegevoegd.
Kubernetes heeft echter nog meer te bieden. Het maakt niet uit waar je Kubernetes gebruikt, je spreekt altijd dezelfde Kubernetes ’taal’, ofwel een universele infrastructuur API. Of je nu Kubernetes in een Public Cloud zoals Azure gebruikt of in een eigen datacenter, je hoeft alleen maar te communiceren met de Kubernetes API. Een aantal jaar geleden was het opzetten van een Kubernetes-cluster een uitdaging, maar tegenwoordig zijn er diverse tools beschikbaar die dit proces vereenvoudigen. Bovendien is het aanbod van beheerde Kubernetes-clusters in de cloud sterk toegenomen.
Ook al lijkt het dat iedereen het tegenwoordig over Kubernetes heeft en IT-leveranciers er alles aan willen doen om je te helpen bij het gebruik ervan, is het nog maar de vraag of het ook voor jouw bedrijf interessant is en wat er allemaal bij komt kijken.
Kubernetes is misschien niet altijd de juiste keuze. Als je het nog niet eerder gedaan hebt, zul je eerst de applicatie moeten containeriseren. Maar het is meer afhankelijk van de grootte en complexiteit van de applicatie. Als je slechts een eenvoudige applicatie hebt met een paar containers, is het opzetten van een Kubernetes-cluster waarschijnlijk niet nodig. In dit geval zijn er andere alternatieven zoals bijvoorbeeld Google Cloud Run of Azure Functions. Als het aantal services en containers stijgt, dan wordt Kubernetes interessant.
Uitrollen van applicaties naar Kubernetes vereist niet alleen de nodige technologie, maar ook kennis en vaardigheden. In Kubernetes komt alles samen: netwerk, compute en opslag. Om dit te gebruiken, zul je Kubernetes manifests moeten schrijven om de benodigde Kubernetes objecten (en er zijn er inmiddels meer dan 50) aan te maken. Bij voorkeur moeten deze manifests geautomatiseerd worden aangeboden via een pipeline. Er zijn geen exacte berekeningen en het is ook afhankelijk van de use case, maar het kost gemiddeld minimaal een maand om een eerste setup te bouwen. Daarnaast kan het oplossen van configuratiefouten soms ook nog eens dagen duren. De leercurve is behoorlijk steil en voordat je echt bekend bent met Kubernetes, zul je er minstens een jaar dagelijks mee bezig moeten zijn.
Via de Kubernetes API kun je de objecten bevragen en aanpassen. Kubernetes zelf beschikt niet over ingebouwde tools die je in een moderne hosting infrastructuur wel zou verwachten. Deploy je een gecontaineriseerde applicatie naar een nieuw Kubernetes-cluster en configureer je toegang tot de container vanaf het internet, dan is het net alsof je een server met een applicatie direct op het internet aansluit. Er zijn geen beveiligingsmaatregelen. Er is geen versleuteling van het netwerk, geen Web Application Firewall (WAF), geen monitoring, geen indringers detectie en geen beleid voor netwerk- en beveiliging. Voor het implementeren van alle benodigde beheer- en beveiligingstools, moet je uitgaan van een ecosysteem van meer dan 2000 open source tools. Je moet alle tools zelf selecteren, implementeren, configureren, installeren en beheren, en alle tools hebben hun eigen configuratie eigenschappen en werken niet standaard samen.
Kubernetes is dus niet een complete oplossing voor gecontaineriseerde applicaties, maar een platform om een platform mee te bouwen. Er is elke dag wel een nieuwe tool om uit te proberen en er zijn 1001 manieren om het platform te bouwen. Dit maakt Kubernetes een interessant en uitdagend project voor infra- en platform engineers. Daarnaast zien we een explosieve groei van consultancybedrijven rondom Kubernetes, omdat de populariteit zo snel groeit dat er een groot tekort aan kennis is op de markt. Er kan veel tijd worden geïnvesteerd in de ontwikkeling van een Kubernetes-platform.
Het is duidelijk dat het gebruik van Kubernetes niet goedkoop is. Gemiddeld zijn bedrijven zo een half jaar met meerdere engineers bezig met het bouwen van een eerste versie van een platform. Maar zodra de eerste versie van het platform is voltooid, ben je nog niet klaar. Komt er een nieuwe Kubernetes versie, dan zul je moeten onderzoeken of alle tools die je gebruikt compatibel zijn en indien nodig aangepast moeten worden. Een Kubernetes-platform maakt (afhankelijk van de mate van beveiliging) al snel gebruik van 10 tot 20 extra open source tools. Een platform is nooit klaar, dus er is altijd noodzaak om het te blijven verbeteren door nieuwe functies toe te voegen die de ontwikkelaar experience verbeteren. Dit alles moet worden gedaan in een markt met een tekort aan kennis.
Er vindt een stijgende trend plaats in configuratiefouten die leiden tot beveiligingsincidenten, volgens verschillende rapporten. Dit omvat containers die root access toestaan, waardoor je direct admin bent zodra je binnenkomt. Of workloads zonder limits, waardoor een container onbeperkte resources in het cluster kan verkrijgen, evenals containers die kwetsbaarheden bevatten, denk aan de Log4J situatie. Hoe voorkom je dergelijke kwetsbaarheden in je container? Deze trend is zorgelijk en tegelijk ook een gevolg van de snelle adoptie van Kubernetes, zonder dat alle mogelijke maatregelen zijn genomen om dit soort problemen te voorkomen.
We krijgen vaak de vraag of men niet gewoon services kan gebruiken van cloud-hyper-scalers zoals GCP, Azure en AWS. Laten we AKS, een beheerde Kubernetes service in Azure, als voorbeeld nemen. Het opzetten van een AKS-cluster is tegenwoordig eenvoudig en binnen een paar minuten gedaan. Maar zoals eerder beschreven, Kubernetes alleen is niet genoeg. Een Kubernetes-cluster maakt gebruik van cloud resources (virtuele machines) en Azure biedt alle mogelijke services om het platform uit te breiden. Deze extra services zijn niet alleen kostbaar, maar ook alleen te gebruiken in combinatie met Kubernetes in Azure. Als je ze ook in een andere cloud wil gebruiken of vanwege compliance/GDPR naar een Private Cloud wilt overstappen, moet je opnieuw beginnen en dat was nou net niet het idee (een universele infrastructuur-API) achter Kubernetes.
Kortom Kubernetes is zeer geschikt voor bedrijven die gecontaineriseerde applicaties willen hosten. Als een applicatie slechts uit een paar containers bestaat, kan Kubernetes overbodig zijn. Het is specifiek ontworpen voor het hosten van complexe architectuur met veel front- en backend services. Bij het implementeren van Kubernetes is het belangrijk om de impact, tijdsinvestering en bijbehorende risico’s voor de organisatie in overweging te nemen.
Dit artikel is geschreven door Sander Rodenhuis, CTO van Red Kubes.
[Fotocredits – bilalulker © Adobe Stock]
