Orkestrér din webløsning med Kubernetes

Som web-udvikler består det meste af ens arbejdsdag med at skrive kode, planlægge og kommunikere med kollegaer og kunder. Man får dog også ansvar for tilstødende arbejdsopgaver, blandt andet at drifte web-løsninger og gøre dem skalerbare. Her kommer Kubernetes ind i billedet.

Af Jens Just Iversen

Kubernetes er et såkaldt orkestreringsværktøj, der hjælper med at håndtere deployments, auto-skalering, ressourceallokering og meget andet.

Det bruges til alle slags servere. For en web-løsning er der typisk brug for en webserver til at servere indholdet, en databaseserver og et program, der kan eksekverer kode.

En web-løsning bygget i Laravel består af noget PHP-kode. Den holder forretningslogikken. Der er nok også nogle database migrations med i projektet. De fortæller præcist, hvordan database-strukturen skal se ud. Man kan også have en Dockerfile, som fortæller præcis hvordan det “image”, der kører webserveren, skal se ud.

Så nu er koden, databasen og webserveren strømlinet. På den måde er vi sikre på, at det kører på samme måde på alle systemerne, det skal køre på (lokalt udviklingsmiljø, produktions-serveren, staging-serveren og så videre).

Vi mangler dog endnu et abstraktionsniveau i denne tankegang, for alt deployment (udgivelse af nye versioner), skalering (skal vi bruge flere hardware ressourcer?), håndtering af lagringsdiske, backups og så videre er som udgangspunkt manuelt.

Der findes selvfølgelig diverse værktøjer, som man stykvist kan sammensætte til ens behov, og mange hostingudbyder har integreret nogle af ovenstående processer i deres løsning.

Men hvad nu hvis dette kunne blive en integreret del af ens projekt? Hvad nu hvis det kunne blive versioneret i f.eks. GitHub sammen med kodebasen, database migrations og images? Hvad nu hvis det kunne være uafhængigt af udbyder, sådan at man ikke er fastlåst til værktøjer hos den enkelte hostingudbyder?

Så er det Kubernetes, du søger!

Kubernetes er et meget veludbygget værktøj. Alt konfiguration kan foretages i konfigurationsfiler og dermed medtages i sin versionering af projektet.

Der er masse funktioner indbygget i Kubernetes, og det kan også udvides med brugertilpassede scripts, som man har lyst.

Det har fået en del buzz, men der er desværre stadig mange, der går glip af muligheden for at lette arbejdet i denne fase af et projekt.

Og det er meget forståeligt.

For indlæringskurven til Kubernetes kan godt være ret stejl, og man skal have en vis mængde grundlæggende færdigheder, for at kunne opsætte et projekt.

Når man er kommet over det første bump åbner der sig til gengæld en verden bestående af lettere arbejdsgange, mere tryghed i deployment, bedre overblik over ens driftende miljø med videre.

At bringe Kubernetes ind i sit projekt er ikke en erstatning for Docker. Det er et ekstra abstraktionslag og skal af samme grund selvfølgelig ikke tages i brug som en automatreaktion. Men består ens miljø af flere containere, der skal køre side om side - for eksempel Redis, webserver og database - så begynder det allerede at give mening. Har man på projektet behov for automatisk horisontal skalering, så vil det være meget oplagt.

Spar penge med automatisk skalering

Det kan godt koste lidt ekstra mandetimer, at opsætte ens projekt i et Kubernetes cluster.

Men pengene kan hurtigt være tjent hjem.

Hvis du ikke har haft mulighed for at benytte automatisk op- og nedskalering på dit projekt, har du været tvunget til at lave en vertikal skalering. Det betyder altså, at den ene server, der kører hele projektet, er blevet opgraderet løbende for at følge med på de tidspunkter, hvor der serveren er mest belastet.

De tidspunkter, hvor serveren ikke er mest belastet, har man derfor en overdimensioneret server, og det er meget dyrt.

Med auto-skalering konfigurerer man, at der skal startes en ny container (f.eks. et docker-image af sin webserver) op, når de eksisterende containere er belastet med en vis procent - for eksempel ved 80 % belastning.

Når der kører så mange containere på samme server, at denne også er belastet med 80%, så startes der en ny server op, og denne bliver tildelt nogle af de kørende containers.

Når serveren ikke er belastet mere, så skaleres der automatisk ned.

Det betyder, at man som standard kan have en meget lille server kørende, og den automatiske skalering vil så sikre, at der er rigeligt ressourcer, når ens site er meget belastet.

Ejer man en webshop, har man altså rigeligt ressourcer på black friday, men natten mellem mandag og tirsdag bruges der næsten ingen server-kraft - og altså heller ingen penge.

Løsriv dig fra én udbyder

Cloud hosting har aldrig været nemmere.

Det er lynhurtigt at starte en ny server op hos en af de mange udbydere, og der er en masse af produkter at vælge mellem.

De store hostingplatforme, som f.eks. AWS, Digital Ocean, Google Cloud Platform og Azure, har et utal af løsninger og værktøjer. Lige fra kø-systemer (queue messaging), backup-løsninger til egne udgaver af populære open source databaser.

Det lugter desværre lidt af et såkaldt vendor lock-in. For når du først er begyndt at blive glad for produkter hos én specifik udbyder og disse er blevet en integreret del af dit projekt, så er det svært at skifte udbyder.

Det er her Kubernetes byder sig til som et bedre alternativ.

For er hele miljøet opsat i Kubernetes, så kan dette flyttes rundt fra udbyder til udbyder uden besvær. Man kan også drifte det lokalt med Minikube, eller man kan opsætte det on-premise enten fra bunden af eller ved hjælp af værktøjer som Rancher.

Flere fordele

Det er ikke blot selve arbejdet med deployments, skalering og øvrig drift, der bliver nemmere og sikrere med Kubernetes.

Der er nemlig mange afledte effekter.

Dels skal ens applikation gøres state-less.

Det betyder, at de forskellige dele af applikationen skal kunne starte op og lukke ned uden at holde et stadie enten i hukommelsen eller på en disk, der kan gå tabt. Så kan mange identiske containere køre side om side.

Man er derfor tvunget til at ændre sin applikation til at bruge andre måder at holde styr på disse ting. Det kunne være Redis til kø- og cache-håndtering, S3 eller GCS til fil-upload osv. Nu står du med en applikation, der kan tåle at crashe. For den kan bare starte en ny container op og fortsætte, hvor den slap.

Det får automatisk en afledt effekt på kodekvaliteten. Har man automatisk horisontal skalering aktiveret, vil det være naturligt at bygge færre små jobs, der kan splittes ud på en række containere og servere, når der er behov for det.

På den måde hjælpes man naturligt til at bygge sin kode op i mindre moduler, der har en lav afhængighed af den øvrige forretningslogik.

Ved deployment og drift er man også beskyttet af healthcheck bag en load-balancer, der sikrer, at man ikke kan deploye en container, der fejler. Ligeså hvis en container pludselig får en fejl, så sørger load-balanceren for at sende trafikken hen til andre containere, der kører fejlfrit.

Afslutning

Med nemmere deployment, versionering af hele miljøet, mere tryghed under fejl og lavere omkostninger er fordelene nemme at få øje på. Og med reducering af cloud giganternes magt oveni, ja, så er det nemt at være fortaler for teknologien.

Der er selvfølgelig en ekstra opgave i opsætning og indlæring, og man skal passe på ikke at falde i fælden med “over engineering”.

Har du nogle spørgsmål, er du velkommen til at skrive i kommentarfeltet herunder, ligesom vi altid gerne vil høre om jeres erfaringer på både godt og ondt :-)