🥇Kubernetes: open source vs. vendor-løsning

Hej, jeg hedder Dmitry Krasnov. Jeg har i mere end fem år arbejdet med administration af Kubernetes-klynger og opbygning af komplekse mikroservice-arkitekturer. I begyndelsen af dette år lancerede vi en service til styring af Kubernetes-klynger baseret på Containerum. Jeg vil benytte lejligheden til at fortælle, hvad Kubernetes egentlig er, og hvordan integrationen med en leverandør adskiller sig fra open source.

For at starte, hvad er Kubernetes. Dette er et system til styring af containere på et stort antal værter. På græsk oversættes det for øvrigt til 'pilot' eller 'styrmand'. Oprindeligt udviklet af Google, blev det efterfølgende givet som teknologisk bidrag til Cloud Native Computing Foundation, en international non-profit organisation, der samler førende globale udviklere, slutbrugere og leverandører af containerteknologier.

At styre et stort antal containere

Lad os nu se nærmere på, hvad disse containere egentlig er. Det er en applikation sammen med sit miljø – primært de biblioteker, som programmets funktionalitet afhænger af. Alt dette pakkes i arkiver og præsenteres som et billede, der kan køres uanset operativsystemet, testes og meget mere. Men der er et problem — det er meget svært at administrere containere på et stort antal værter. Derfor blev Kubernetes skabt.

Containerbilledet består af applikationen plus dens afhængigheder. Applikationen, dens afhængigheder og filsystembilledet af OS'en er placeret i forskellige dele af billedet, de såkaldte lag. Lagene kan genbruges til forskellige containere. For eksempel kan et grundlag som Ubuntu bruges af alle applikationer i virksomheden. Når containere startes, er der ikke behov for at gemme mange kopier af det samme grundlag på værten. Dette optimerer lagring og levering af billeder.

Når vi ønsker at køre en applikation fra en container, lægges de nødvendige lag oven på hinanden og danner et overlay-filsystem. Ovenpå lægges et skrivelag, som fjernes, når containeren stoppes. Dette sikrer, at applikationen altid har et ensartet miljø ved opstart af containeren, som ikke kan ændres. Det sikrer reproducerbarhed af miljøet på forskellige værts-OS'er. Uanset om det er Ubuntu eller CentOS, vil miljøet altid være det samme. Desuden er containeren isoleret fra værten ved hjælp af indbyggede mekanismer i Linux-kernen. Applikationer i containeren kan ikke se filer eller processer fra værten eller nabocontainere. Denne isolation af applikationer fra værts-OS'et giver et ekstra sikkerhedslag.

Der er mange værktøjer til at administrere containere på værten. Det mest populære er Docker. Det gør det muligt at sikre hele livscyklussen for arbejdet med containere. Men det fungerer kun på én vært. I tilfælde af behov for at administrere containere på mange værter kan Docker gøre livet besværligt for ingeniører. Derfor blev Kubernetes skabt.

Efterspørgslen efter Kubernetes skyldes netop muligheden for at styre grupper af containere på mange værter som en samlet enhed. Systemets popularitet sikrer muligheden for at opbygge DevOps eller Development Operations, hvor Kubernetes bruges til at køre processer inden for denne DevOps.

Figur 1. Schematic illustration of the operation principle of Kubernetes

Fuld automatisering

DevOps repræsenterer grundlæggende automatisering af udviklingsprocessen. Groft sagt skriver udviklerne kode, som uploades til et repository. Derefter kan denne kode automatisk samles i en container med alle biblioteker, testes, og "udrulles" til næste fase – Staging, og derefter direkte til Production.

Sammen med Kubernetes muliggør DevOps automatik af denne proces, så den næsten kan finde sted uden udviklernes direkte involvering. Dette betydeligt accelererer opbygningen, da udvikleren ikke behøver at gøre dette på sin egen computer — han skriver simpelthen en kodebit, pushe koden til depotet, hvorefter en pipeline aktiveres, som kan inkludere opbygnings-, test- og udrulningsprocessen. Dette sker for hver commit, så testningen finder sted kontinuerligt.

Brugen af containere sikrer desuden, at hele miljøet for dette program går i produktion præcis i den version, som blev testet. Det vil sige, at der ikke opstår problemer som "der var én version i testen, men en anden i produktionen, og da vi deployede, gik det hele ned". Da vi i dag har en tendens mod mikrotjenestearkitektur, hvor ét stort program erstattes af hundrede små, vil det kræve et kæmpe personale at administrere dem manuelt. Derfor bruger vi Kubernetes.

Fordele, fordele, fordele

Når vi taler om fordelene ved Kubernetes som platform, har den betydelige fordele i forhold til styring af mikrotjenestearkitektur.

Håndtering af mange replikaer. Det vigtigste er håndtering af containere på mange værter. Og vigtigere endnu, håndtering af mange replikaer af applikationer i containere som en enhed. Dette betyder, at ingeniørerne ikke behøver at bekymre sig om hver enkelt container. Hvis én af containerne falder, vil Kubernetes opdage det og starte den op igen.
Klynge-netværk. Kubernetes har også et såkaldt klynge-netværk med sit eget adresserum. Dette sikrer, at hver pod har sin egen adresse. En pod forstås som den mindste strukturelle enhed i klyngen, hvor containere direkte køres. Derudover har Kubernetes funktionalitet, der kombinerer en belastningsfordeler og service discovery. Dette gør det muligt at undgå manuel håndtering af IP-adresser og overlade denne opgave til Kubernetes. De automatiske sundhedstjek hjælper med at opdage problemer og omdirigere trafik til fungerende pods.
Håndtering af konfigurationer. Når du håndterer mange applikationer, bliver det svært at administrere applikationernes konfiguration. I Kubernetes findes der specifikke ressourcer, kaldet ConfigMaps. De giver mulighed for centralt at opbevare konfigurationer og indsætte dem i pods ved lancering af applikationer. Denne mekanisme sikrer, at konfigurationen forbliver konsistent, uanset om der er ti eller hundrede replikaer af applikationerne.
Vedvarende Lager. Containere er i deres natur immutabler, og når en container stoppes, vil alle data, der er skrevet til filsystemet, blive ødelagt. Men nogle applikationer gemmer data direkte på disken. For at løse dette problem har Kubernetes funktionalitet til at håndtere diskopbevaring — Vedvarende Lager. Denne mekanisme bruger ekstern opbevaring til data, og kan give containere permanent lager, om det er blok- eller filbaseret. Denne løsning giver mulighed for at opbevare data adskilt fra arbejderne, hvilket beskytter dem ved fejl i arbejderne.
Load Balancer. Selvom vi i Kubernetes håndterer abstrakte enheder som Deployment, StatefulSet osv., kører containerne til slut på almindelige virtuelle maskiner eller fysiske servere. De er ikke perfekte og kan gå ned når som helst. Kubernetes opdager dette og omdirigerer intern trafik til andre replikaer. Men hvad med trafikken, der kommer udefra? Hvis vi blot dirigerer trafikken til en af arbejderne, hvad sker der, hvis denne går ned, og tjenesten derfor bliver utilgængelig? For at løse dette problem har Kubernetes tjenester af typen Load Balancer. Disse er designet til automatisk at konfigurere en ekstern cloud-balanserer til alle arbejderne i klyngen. Denne eksterne balancerer dirigerer ekstern trafik til arbejderne og overvåger selv deres status. Hvis en eller flere arbejdere bliver utilgængelige, bliver trafikken omdirigeret til andre. Dette muliggør oprettelse af højtilgængelige tjenester ved hjælp af Kubernetes.

Kubernetes giver de bedste resultater, når det bruges til at lancere mikroservicearkitekturer. Det er muligt at implementere systemet i en klassisk arkitektur, men det giver ikke mening. Hvis en applikation ikke kan køre i flere replikaer, hvad er så pointen – om det er i Kubernetes eller ej?

Open source Kubernetes

Open source Kubernetes – fantastisk: installeret og kører. Det kan udsættes på egne servere, på egen infrastruktur, med en master og workers, hvor alle applikationer vil køre. Og vigtigst af alt – alt dette er gratis. Der er dog visse nuancer.

For det første – krav til viden og erfaring fra administratorer og ingeniører, der skal implementere og vedligeholde det. Da klienten får fuld frihed i klyngen, bærer han selv ansvaret for klyngens funktionalitet. Det er meget nemt at bryde alt her.
For det andet – mangel på integrationer. Hvis man starter Kubernetes uden en populær virtualiseringsplatform, vil man ikke opnå alle programmets fordele. Såsom brugen af Persistent Volumes og Load balancer-tjenester.

Illustration 2. Arkitektur for k8s

Kubernetes fra leverandøren

Integration med en cloud-udbyder giver to muligheder:

For det første kan en person blot klikke på knappen "opret klynge" og få en allerede konfigureret og klar klynge.
For det andet installerer leverandøren selv klyngen og konfigurerer integrationen med skyen.

Sådan fungerer det hos os. Ingeniøren, der starter klyngen, angiver, hvor mange workers han har brug for, og med hvilke parametre (for eksempel 5 workers, hver med 10 CPU'er, 16 GB RAM og, lad os sige, 100 GB disk). Derefter får han adgang til den allerede oprettede klynge. Samtidig gives de workers, hvor belastningen køres, helt til klienten, men hele management plane forbliver hos leverandøren (hvis tjenesten leveres som en managed service).

Dog har denne model sine ulemper. Fordi management plane forbliver hos leverandøren, giver leverandøren ikke klienten fuld adgang, og det reducerer fleksibiliteten i arbejdet med Kubernetes. Nogle gange ønsker klienten at tilføje en specifik funktion til Kubernetes, for eksempel autentifikation via LDAP, men konfigurationen af management plane tillader ikke dette.

Illustration 3. Eksempel på en Kubernetes-klynge fra en cloud-udbyder

Hvad skal man vælge: open source eller leverandør-løsning

Så, open source Kubernetes eller vendor-løsning? Hvis man vælger open source Kubernetes, kan brugeren gøre hvad som helst med det. Men der er stor risiko for, at man kommer til at skade sig selv. Med vendor-løsningen er det sværere, da alt er gennemtænkt og konfigureret af firmaet. Den største ulempe ved open source Kubernetes er kravet til specialister. Med vendor-løsningen slipper firmaet for denne hovedpine, men de skal beslutte: betale deres egne specialister eller vendor.

Nå, fordelene er åbenlyse, ligesom ulemperne. Én ting er konstant: Kubernetes løser en masse problemer ved at automatisere håndteringen af mange containere. Hvilken man skal vælge, open source eller vendor-løsning, må den enkelte selv afgøre.