Automatisk skalering med Kubernetes

Kubernetes (tit forkortet til k8s) er et af de mest velkendte systemer, når vi taler om skalering inden for IT-systemer. I denne artikel forklarer vi, hvordan og hvornår Kubernetes er relevant at bruge som orkestreringsværktøj til dine containere.

Af Sebastian

Hvad kan Kubernetes?

Mange har forsøgt at forklare Kubernetes - og har fejlet, da de forsøger at give den helt rigtige forklaring. Her prøver vi med en simpel version: Overordnet hjælper Kubernetes med at holde software stabilt og i gang – selv under store udsving i brugere, eller når noget går galt.

Du kan se Kubernetes som en autopilot, der styrer små softwarepakker (containere) og sørger for, at der bliver stillet de ressourcer til rådighed, der er nødvendige for at kunne klare belastningen. Kubernetes kigger hele tiden på dit cluster og sørger for at allokere de nødvendige ressourcer, der er stillet til rådighed i clusteret for at sikre stabil drift under belastning. Og skruer automatisk ned igen for at spare på ressourcerne og strømmen.

På den måde kan komplekse backend-systemer køre sikkert, hurtigt og uden problemer. Kubernetes understøtter flere forskellige container runtimes, men den mest populære er Docker's runtime, der hedder Docker Engine. Fordelen ved Kubernetes er, at man slipper for manuelle processer for at op- og nedskalere ressourcer for både at sikre oppetid - men samtidig minimere økonomiforbrug. Det kan dog blive en dyr fornøjelse at bruge Kubernetes, hvis der reelt set ikke er behov for det. Det skal vi nok komme nærmere ind på.

Kubernetes er bygget ovenpå Docker i den forstand, at Kubernetes orkestrerer dine Docker images og containere ved hjælp af konfigurationsfiler, som du skriver. Konfigurationsfilerne skrives i YAML-format, og du kan definere mange forskellige parametre såsom levetiden på dine Pods, og hvor mange ressourcer en Pod må bruge.

Kubernetes anvendes også til at styre deployments, men det der gør Kubernetes fordelagtigt er de skaleringsmuligheder, der er. Formålet er at bruge Kubernetes i et cluster, hvor du har flere forskellige servere der arbejder sammen med hinanden for at opnå en højere båndbredde.

Hvad erstatter Kubernetes?

Man kan opnå de samme resultater uden Kubernetes gennem mere manuelle processer. Det er dog mere tidskrævende og udfordrende, da det kræver en mere "hjemmebygget" og skræddersyet automatisering fx:

• Manuel serveropsætning med loadbalancer foran. Ofte overprovisionerede servere, som man ved er i stand til at stå imod spidsbelastning.
• Skræddersyede scripts, der allokerer ressourcer indenfor en enkelt eller flere servere til en given applikation eller service.
• Klassisk autoskalering som er native til en platform, fx AWS EC2 autoscaling
• Andre kommercielle løsninger, fx tidligere Heroku, App Platform hos Digital Ocean, Azure App Service osv.
• Køsystemer, der beder folk vente i stedet for at stille ressourcer til rådighed.

Kort fortalt erstatter Kubernetes manuelle processer og automatiserer op- og nedskalering af ressourcer, så dine systemer hele tiden har den rette kapacitet.

Skaleringsmuligheder i K8s

Der er 2 måder at skalere din applikation på. Horisontal skalering og vertikal skalering.

Vertikal skalering er den simpleste form for skalering, hvor du bare forøger kræfterne på den maskine, der hoster din applikation. Hvis du køber en større processor, eller får flere RAM til jeres webserver, så har du skaleret vertikalt.

Horisontal skalering er mere kompliceret. Her deler du din applikation ud på flere instanser. Hvis du køber en ny webserver og balancerer trafikken på din hjemmeside på tværs af de 2 webservere, du nu ejer, så har du skaleret horisontalt.

Horisontal skalering kommer med flere ting, du skal være opmærksom på, da din applikation nu er delt op på tværs af flere forskellige maskiner. Du skal kunne centralisere ting som filer, der skal bruges af din applikation og din database, sådan at begge maskiner kan tilgå de samme filer og den samme database.

For at kunne skalere noget i Kubernetes, kræver det, at du har Metrics Server installeret i dit cluster. Metrics Server måler ressourcerne i dit cluster for at vide, hvor der er brug for hvilken slags skalering. Det er IKKE et værktøj, man kan bruge, hvis man gerne vil se grafer over sit forbrug på clusteret.

Vertikal skalering kan foregå på forskellige måder i Kubernetes. Du kan enten opgradere din Node, så den er mere kraftfuld, eller du kan skalere en enkelt Pod vertikalt. Hvis du vil skalere en Pod vertikalt, skal du bruge det, som Kubernetes kalder en VerticalPodAutoscaler. Det er hvor Kubernetes går ind og måler, hvor mange ressourcer din Pod har brug for for at kunne udføre sit arbejde. Hvis du ikke har meget trafik på din hjemmeside, reducerer Kubernetes mængden af ressourcer, der skal dedikeres til den Pod, så du ikke spilder ressourcer. Hvis trafikken bliver forøget, så allokerer Kubernetes flere ressourcer til den Pod, så den kan trække mere kraft fra din Node.

Horisontal skalering i Kubernetes kan også gøres på Node og Pod niveau, ligesom den vertikale skalering. Da Kubernetes fungerer bedst som et cluster af maskiner, kan den nemt vide, hvilken maskine/node, din applikation skal uddelegeres til. Et eksempel på horisontal skalering i Kubernetes ville være at tilføje en ekstra "worker node" til dit cluster, som kan tage imod Pods fra din webapplikation. Det kan f.eks være, at du kører med 2 Nodes, der håndterer al trafik på din hjemmeside, men du har brug for at tilføje en ekstra maskine. Nu bliver den nye maskine koblet op til dit cluster, og Kubernetes kan selv finde ud af at smide Pods over på den nye Node for at balancere arbejdskraften. Dette kaldes en Node Autoscaling eller Cluster Autoscaler.

Du kan også skalere Pods horisontalt med en HorizontalPodAutoscaler. Det er hvor, Kubernetes fordeler læsset på flere Pods i din Node. Det gør den ved hjælp af nogle grænser, som du sætter i din konfigurationsfil. Det kan f.eks være, at du har beskrevet i din konfiguration, at en Pod ikke må bruge mere end 1 ud af de 8 CPU-kerner, din Node har. Hvis Kubernetes kan se, at en Pod rammer grænsen, vil den starte en ny Pod op. Du bestemmer selv, hvad minimum og maksimum-antallet af Pods er på din Node.

Regler for et HA-cluster med Kubernetes

Et High Availability-cluster (HA-cluster) har krav på minimum 3 nodes, hvis du bruger etcd som din datastore. Etcd indfører noget, der hedder: "Raft consensus algorithm", som bestemmer hvilken node der skal indføres som den nye leder, hvis den eksisterende leder holder op med at virke.

Algoritmen stiller krav til, at der skal være minimum 2 nodes til stede, for at de kan blive enige om, hvem der tager føringen. Derfor har vi som minimum 3 nodes, der fungerer som master nodes.

Visuelt

Kommunikation med Kubernetes foregår igennem den indbyggede API, og almindelig brug er sædvanlig igennem cli værktøjer som kubectl og k9s.

Herunder viser vi et par skærmbilleder fra k9s, som vil ligne det, man som anvender af Kubernetes vil se.

Skærmbillede der viser, de pods der driver platformen Eventværk, som vi har udviklet til Aarhus Universitet, hvor vi har opsat Kubernetes. Læg mærke til at de er fordelt på forskellige worker nodes.

Skærmbillede der viser den nuværende HorizontalPodAutoscaler på platformen Eventværk. Man kan se det eksisterende forbrug på alle Pods, og hvad grænsen er, før at Kubernetes skal sparke flere Pods i gang.

Skærmbillede fra én af vores Worker Nodes. Læg mærke til, at 100% forbrug betyder 1 vCPU. Vores Worker Node har i alt 8 vCPU'er, hvilket vil sige, at max forbrug svarer til 800% i denne graf.

Hvornår er Kubernetes den bedste løsning?

Kompleksitet og udsving i brugere af systemet/hjemmesiden er afgørende faktorer for, om det giver mening at benytte Kubernetes som orkestreringsværktøj. Kubernetes er et dyrere værktøj - men det kan være en rigtig vigtig og afgørende investering.

Man kan ikke komme med et præcist tal for, hvor mange brugere der skal være, før Kubernetes er den mest relevante løsning - det er en helhedsvurdering. Har man en platform eller system, der har store udsving, så er Kubernetes relevant at kigge på.

Vi har opsat Kubernetes for en række af vores kunder, hvor udsving i brugerne har været den afgørende faktor. Her sikrer Kubernetes, at der altid er kapacitet, så brugerne får en god oplevelse.

Selvom Kubernetes ikke kun hjælper med skalering - men også deployments, så er det klart skalering, der er dens force. Har du kun brug for zero-downtime deployments, er der mange løsninger, der er bedre og mere overskuelige.

Eksempler på kunder, hvor vi bruger Kubernetes

Vi bruger Kubernetes til Aarhus Universitet, hvor vi leverer en platform til at håndtere events; Eventværk. Her er der store udsving i antal brugere. TV2 Regionerne, hvor der også er store udsving - det kan være, når der er breaking news, så strømmer brugerne ind på deres platforme. Det er også relevant for vores kunde Firmagave shop, da der kommer et stort antal brugere ind på samme tid for at bestille julegaver, mens der på andre tidspunkter er mere jævnt fordelt trafik.

Du kan læse vores kundecase om TV2 regionerne her, og Firmagave shop her.

Vi hjælper dig gerne med at vurdere, om Kubernetes er relevant og rentabelt for dig og jeres forretning.