Vandaag hebben we het over iets waar bijna iedereen van heeft gehoord, maar niemand kan uitleggen, Kubernetes. Het is verwarrend omdat het een probleem oplost dat de meeste mensen niet zien totdat ze er tegenaan lopen. Iedereen weet dat het belangrijk is, maar vraag wat het doet en je krijgt een lege blik. Het is geen vervanging voor Docker of een cloud besturingssysteem, ook al denken mensen dat vaak. De verwarring is logisch, want Kubernetes lost een probleem op waarvan je niet wist dat het bestond totdat je ermee te maken krijgt. Het is een hulpmiddel dat essentieel wordt zodra je meer dan een handvol containers moet beheren. Aan het einde van deze aflevering begrijp je wat Kubernetes echt is, hoe het samenwerkt met containers en waarom Azure Kubernetes Service het praktisch maakt voor teams die niet alles vanaf nul willen opbouwen. Pak je koffie en laten we beginnen. Het probleem voor containers.

Laten we teruggaan naar het probleem. Beeld je een softwarebedrijf in van 10 jaar geleden. Je hebt een paar applicaties die moeten draaien, dus koop je servers, installeer je besturingssystemen en implementeer je alles handmatig. Elke app krijgt zijn eigen machine en je kunt bronnen niet delen tussen hen. Als de ene app veel geheugen nodig heeft en de andere nauwelijks iets gebruikt, krijgen ze toch allebei hun eigen server. De verspilling was enorm. Surfers draaiden op misschien 20% capaciteit, maar je kon ze niet consolideren omdat de applicaties zouden vechten om dependencies. Je eindigde met een kamer vol servers die nauwelijks werk verzetten, allemaal stroom en koeling verbruikten en constant onderhoud nodig hadden. De ene app heeft Python 3.7 nodig, de andere heeft Python 3.8 nodig. De ene heeft een oudere bibliotheek nodig, de andere de allernieuwste. Je kunt ze niet op dezelfde machine draaien zonder dat er iets stuk gaat, dus koop je meer servers en betaal je voor hardware die grotendeels ongebruikt blijft.

Virtuele machines hielpen een beetje door een fysieke server in kleinere stukken te verdelen, elk met zijn eigen OS. Maar elke VM is zwaar met een volledig OS dat schijfruimte en geheugen inneemt en minuten nodig heeft om op te starten. En je moest ze allemaal apart configureren, wat veel werk was. Je bent nog steeds al die besturingssystemen aan het beheren, patchen, updaten en beveiligen. Teams hadden iets lichters en draagbaarders nodig, een manier om een applicatie te verpakken met alles wat nodig is om te draaien, zonder de overhead van een volledige virtuele machine en die makkelijk tussen machines kon worden verplaatst. Dat is waar containers in beeld kwamen, wat containers werkelijk zijn. Een container is een klein pakketje dat je applicatie bevat met alles wat nodig is om te kunnen draaien. Dat betekent dat de code, de runtime, de bibliotheken en de configuratiebestanden allemaal samen in één eenheid zijn gebundeld.

Zie het als een zeecontainer voor software. Een zeecontainer kan op een vrachtwagen, trein of schip en de container zelf blijft altijd hetzelfde. Jouw software container werkt op precies dezelfde manier. Je bouwt hem één keer en hij draait hetzelfde op je laptop, je testserver en je productieomgeving. Het belangrijkste verschil tussen containers en virtuele machines is hun efficiëntie. Een virtuele machine draait een volledig eigen besturingssysteem, dus elke VM heeft een eigen kernel, systeembestanden en al het andere. Een container deelt het besturingssysteem van de host. Het is slechts een proces met een eigen geïsoleerde blik op de wereld. Dat betekent dat containers in seconden opstarten, niet in minuten. Ze gebruiken minder geheugen en je kunt er meer op één machine kwijt. Docker maakte containers populair door ontwikkelaars een simpele manier te geven om ze met één commando te bouwen en te draaien.

Plotseling begon het, het werkt op mijn machine, probleem te verdwijnen. Als je applicatie in een container op je laptop draait, draait hij op dezelfde manier op de server. De omgeving is overal consistent, maar containers lossen één probleem op en creëren een ander. Met een handvol containers werkt handmatig beheer prima. Je kunt ze zelf starten, stoppen en bijhouden. Maar wat gebeurt er als je er honderden hebt? Je moet bepalen welke server welke container draait, vastgelopen exemplaren herstarten, ze met elkaar verbinden en ze opschalen bij pieken in het verkeer. Dat is een nieuwe uitdaging en dat is precies waar Kubernetes om de hoek komt kijken. Het orchestratie probleem. Dus, je hebt containers aan de praat, je verpakt je applicatie, hij draait overal consistent en het leven is goed. Maar slechts voor even, met tien of twintig containers kun je de boel handmatig beheren. Je weet welke server welke container draait, je kunt iets herstarten als het crash en je kunt hier en daar wat dingen updaten.

Het is beheersbaar, maar dan groeit je applicatie. Je stapt over op microservices, dus in plaats van één grote applicatie heb je er twintig kleinere. Elke service heeft voor de betrouwbaarheid meerdere kopieën nodig en nu kijk je naar 200 containers. Handmatig beheer werkt dan niet meer. Je moet bepalen welke server welke container draait, containers herstarten bij falen en ze verbinden zodat ze kunnen communiceren. Je moet ook opschalen bij verkeerspieken, misschien tijdens een uitverkoop of productlancering en weer afschalen als het rustiger wordt. En je moet updates uitrollen zonder downtime, wat betekent dat je oude containers één voor één vervangt door nieuwe, zorgvuldig, zonder iets te breken. Dit zijn orkestratieproblemen en dat is precies waar Kubernetes voor is gebouwd. Kubernetes is een open source platform dat het implementeren, schalen en beheren van gecontaineriseerde applicaties automatiseert.

Zie het als het besturingssysteem voor je datacenter. Net zoals Windows of Linux de bronnen op één computer beheert, zoals CPU, geheugen en schijf, beheert Kubernetes de bronnen over al je servers heen. Het behandelt al je machines als één grote pool van rekenkracht. Jij vertelt wat je wilt draaien en het bepaalt waar het komt te staan, hoe het blijft draaien en hoe het verbonden wordt met de rest. Kernconcepten, pads, nodes en clusters. Laten we kijken hoe Kubernetes daadwerkelijk werkt. De kleinste eenheid in Kubernetes wordt een pad genoemd. Een pad verpakt één of meer containers. Containers binnen dezelfde pad delen opslag en netwerk, zodat ze met elkaar kunnen communiceren via localhost. Je kunt een pad zien als een enkele eenheid voor implementatie. Je implementeert geen containers direct in Kubernetes. Je implementeert pads. Pads draaien niet op zichzelf, ze draaien op nodes. Een node is een server, fysiek of virtueel, die deel uitmaakt van je Kubernetes-cluster.

Elke node draait de software die nodig is voor pads, plus een paar andere zaken waar we zo op terugkomen. Een cluster is de verzameling van alle nodes die als één uniform systeem worden beheerd. Simpel gezegd, een pad is je applicatie, een node is waar deze draait en het cluster is de hele omgeving. Pads zijn vluchtig. Ze kunnen op elk moment worden aangemaakt, vernietigd of verplaatst. Dat is bewust zo ontworpen. Als een node faalt, verplaatst Kubernetes de pads naar een andere node. Bij opschalen worden er nieuwe pads aangemaakt. En wanneer een pad crash, wordt deze automatisch vervangen. Het geheel beschouwt pads als tijdelijk. Maar als pads komen en gaan, heb je een manier nodig om ze te bereiken. In plaats van direct met een pad te communiceren, communiceer je met een service. Een service biedt een stabiel netwerkadres dat verkeer naar de juiste pads leidt, zelfs als pads veranderen.

Stel je een hotel voor. Het telefoonnummer van het hotel is de service. Kamers krijgen steeds andere gasten, maar het telefoonnummer blijft hetzelfde. Je belt de receptie en zij leiden je gesprek door naar de juiste kamer. Dat is precies wat een service in Kubernetes doet. Het geeft je een vast adres dat altijd verwijst naar de pads die op dat moment je applicatie draaien. Het control plane, het brein van het cluster. Dus, je hebt pads, nodes en een cluster. De vraag is, wie bepaalt wat waar draait? Dat is de taak van het control plane. Elk Kubernetes-cluster heeft er een, en het is het brein van de hele operatie. Hier worden alle beslissingen genomen. Het control plane bestaat uit verschillende onderdelen. Het eerste is de API-server, die fungeert als de voordeur van je cluster. Elk commando dat je naar Kubernetes stuurt, of het nu via de opdrachtregel, een dashboard of een automatisch script is, verloopt via de API-server.

Het verifieert je aanvraag, controleert of je de bevoegdheid hebt om dit te doen, en stuurt het vervolgens door naar de juiste plek. Niets gebeurt in Kubernetes zonder eerst via de API-server te gaan. Vervolgens is er de scheduler, die bepaalt op welke nood elke pad draait. Wanneer je zegt, ik wil dat deze applicatie draait, bekijkt de scheduler alle beschikbare noods, controleert de aanwezige middelen, zoals CPU, geheugen en schijfruimte, en kiest de beste voor de taak. Het is als een hotelmanager die kamers toewijst op basis van wat elke gast nodig heeft. Een gast met veel bagage krijgt een grotere kamer, terwijl een lichtgewicht applicatie een kleinere nood krijgt met vrije capaciteit. Dan is er nog de controllermanager. Dit onderdeel houdt het cluster in de gaten en zorgt ervoor dat de werkelijke status overeenkomt met wat je hebt aangegeven. Je hebt aangegeven dat je drie kopieën van je webapp wilt laten draaien.

De controllermanager controleert of er daadwerkelijk drie kopieën draaien. Als er een crash, merkt hij dit op en start hij een vervanger. Als iemand per ongeluk een pad verwijderd, maakt hij een nieuwe aan. Het is het onderdeel dat je cluster betrouwbaar houdt. En tot slot is er etcd, de database van het cluster. Het slaat alles op, zoals wat er draait, waar het draait en hoe het geconfigureerd is. Het is de bron van waarheid voor het hele cluster. Als de API-server de voordeur is, dan is etcd het archiefkastje in het kantoor waar alle gegevens worden bewaard. Het mooie van dit ontwerp is dat jij beschrijft wat je wilt en Kubernetes bedenkt hoe het werkelijkheid moet worden. Je vertelt niet hoe het dingen moet doen, je vertelt hoe het eindresultaat eruit moet zien. Dat is het declaratieve model en het is het kernidee achter alles wat Kubernetes doet. Workloads, deployments, services en schalen.

Dus, laten we praten over hoe je applicaties daadwerkelijk op Kubernetes draait. Je zult niet direct pods aanmaken. In plaats daarvan gebruik je een object op een hoger niveau genaamd een deployment. Zie een deployment als een manager die Kubernetes vertelt hoeveel kopieën van je pad moeten draaien, welke container-image moet worden gebruikt en hoe ze moeten worden bijgewerkt bij een nieuwe versie. Het is de standaard manier om stateles applicaties te draaien. Wanneer je een deployment bijwerkt, bijvoorbeeld als je een nieuwe versie van je app bust, voert Kubernetes een rolling update uit. Het vervangt pods één voor één, zodat er altijd tenminste één kopie actief blijft. Dat betekent geen downtime en geen plotselinge onderbrekingen voor uw gebruikers. En als er iets misgaat met een nieuwe versie, kunt u met één commando terugkeren naar de vorige versie. Dat is een krachtig vangnet. Maar uw pods moeten natuurlijk wel bereikbaar zijn.

Dat is waar services in beeld komen. Een service biedt een stabiel netwerkadres dat verkeer naar de juiste pods leidt. Het kan die pods ook blootstellen aan andere delen van uw applicatie of aan de buitenwereld. Een service kan intern zijn, alleen toegankelijk binnen het cluster of extern, met een openbaar IP-adres dat gebruikers vanaf internet kunnen bereiken. Laten we het nu hebben over schalen. Kubernetes kan uw applicatie automatisch laten groeien of krimpen op basis van de vraag. U stelt een doel in, bijvoorbeeld 70% CPU gebruik, en Kubernetes voegt pods toe als het gebruik boven die drempel komt en verwijdert ze als het daalt. Uw applicatie schaalt op tijdens een verkeerspiek en schaalt terug als het weer rustig wordt. Geen handmatige tussenkomst nodig. Maar al deze kracht brengt complexiteit met zich mee. Het beheren van uw eigen Kubernetes cluster betekent dat u verantwoordelijk bent voor het control plane, upgrades, beveiligingspatches en backups.

U heeft diepgaande expertise nodig om noodstoringen, netwerkconfiguratie en clusterschaling af te handelen. Veel teams besteden meer tijd aan het beheren van het cluster dan aan het bouwen van applicaties. En dat is waar Managed Kubernetes om de hoek komt kijken. Zelfbeheerden versus Managed Kubernetes. Laten we het dus hebben over de realiteit van het zelfdraaien van Kubernetes. Wanneer u uw eigen cluster opzet, bent u verantwoordelijk voor alles, het control plane, upgrades, beveiligingspatches en etcd-backups. Als de API-server uitvalt, is dat uw probleem. Als er een beveiligingsslag wordt ontdekt in de versie die u draait, moet u deze patchen. Als etcd corrupt raakt, moet u herstellen vanaf een backup. Dit alles vereist diepgaande expertise. U moet begrijpen hoe nodes falen, hoe netwerken werken op clusterniveau en hoe u dingen schaalt zonder ze te breken. Dit is wat veel teams verrast.

Veel organisaties besteden meer tijd aan het beheer van hun Kubernetes cluster dan aan het bouwen van de applicaties die erop draaien. Ze zijn voortdurend bezig met upgrades, het oplossen van netwerkproblemen en het omgaan met noodstoringen. Het cluster wordt een fulltime baan. Dat is niet de reden waarom u in eerste instantie voor Kubernetes koos. Dit is waar managed Kubernetes services van pas komen. Services zoals Azure Kubernetes Service of Axe beheren het control plane voor u. Azure beheert de API-server, etcd, de scheduler en de controller-manager. U hoeft zich geen zorgen te maken over het patchen of draaiende houden ervan. Je betaalt alleen voor de worker nodes, de virtuele machines waarop je workloads daadwerkelijk draaien. Het control plane zelf is gratis. Dit verandert de vergelijking drastisch. In plaats van tijd te besteden aan clusteronderhoud, kan je team zich richten op wat echt telt, de applicaties die jullie bouwen.

Voor de meeste teams, zeker degene die net beginnen, is managed Kubernetes de juiste keuze. Je krijgt alle kracht van Kubernetes zonder de operationele overhead. Axe Kubernetes eenvoudig gemaakt op Azure. Dus, wat is Axe precies? Het is de managed Kubernetes service van Azure die een volledig cluster biedt zonder dat je het vanaf nul hoeft op te bouwen. Het control plane is gratis, zoals gezegd, dus je betaalt alleen voor de virtuele machines die je workloads draaien. Dat betekent dat je klein kunt beginnen, weinig betaalt en kunt opschalen naarmate je behoefte groeien. Azure neemt al het zware werk uit handen. Upgrades, patching en gezondheidsmonitoring voor het control plane worden allemaal geregeld. Je hebt geen toegewijd team van Kubernetes experts nodig om alles draaiende te houden. En omdat Axe onderdeel is van het Azure ecosysteem, integreert het met tools die je waarschijnlijk al gebruikt.

Azure Active Directory voor authenticatie, Azure Monitor voor logging en metrics en Azure Policy voor governance. Ze werken allemaal direct samen. Geen losse onderdelen die je erbij moet knutselen. Het opzetten van CI, CD pipelines met GitHub Actions of Azure DevOps kost slechts minuten. Push een wijziging naar je repository en het bouwt automatisch een nieuwe container image. Pus deze naar Azure Container Registry en werk je deployment op Axe bij. Geen handmatige stappen, niet inloggen via SSH op servers. Alles is geautomatiseerd. Voor beginners is er de automatische modus van Axe ontworpen voor teams die niet elke beslissing over clusterconfiguratie willen nemen. Het biedt kant- en klare standaardinstellingen voor schalen, netwerken, beveiliging en upgrades. Je hoeft geen Kubernetes-expert te worden om te kunnen beginnen. Beschrijf simpelweg je applicatie en Axe regelt de rest. Eén commando geeft je een cluster, één manifestbestand krijgt je applicatie werkend.

De vaardigheden die je leert met Axe zijn toepasbaar op elke Kubernetes-omgeving omdat het onderhuids standaard Kubernetes is. Je leert geen eigen systeem, je leert het echte werk terwijl Azure de operationele complexiteit afhandelt. Dus nu heb je het totaalplaatje. Containers verpakken je applicaties zodat ze overal consistent draaien. En Kubernetes orkestreert die containers op schaal, waarbij deployment, schalen en herstel automatisch worden afgehandeld. Axe maakt die orkestratie beheersbaar door het control plane te verzorgen en te integreren met de Azure tools die je al kent. De kernboodschap is, Kubernetes is niet alleen voor grote techbedrijven met enorme engineering teams. Met managed services zoals Axe is het toegankelijk voor elk team. Je huiswerk voor deze week is simpel. Maak een gratis Azure account aan, start een Axe cluster en implementeer een eenvoudige applicatie. Het kost je minuten en je zult zien hoe ver het platform is gevorderd.

Klaar om de diepte in te gaan? De volgende aflevering gaat over het bouwen van je eerste container image en deze naar Azure Container Registry pushen. Abonneer je op je favoriete podcast platform en deel dit met iemand die net aan zijn Kubernetes reis begint.