🥇Kubernetes: open source vs. leverandørens

Hei, jeg heter Dmitrij Krasnov. Jeg har drevet med administrasjon av Kubernetes-klynger og bygget kompliserte mikrotjenestearkitekturer i over fem år. Tidlig i år lanserte vi en tjeneste for styring av Kubernetes-klynger basert på Containerum. I den forbindelse vil jeg fortelle om hva Kubernetes egentlig er, og hvordan integrasjon med en leverandør skiller seg fra open source.

For å begynne, hva er Kubernetes? Det er et system for håndtering av containere på et stort antall verter. På gresk oversettes det for øvrig til "pilot" eller "styrmann". Det ble opprinnelig utviklet av Google, og deretter, som et teknologisk bidrag, overført til Cloud Native Computing Foundation, en internasjonal ideell organisasjon som samler ledende utviklere, sluttbrukere og leverandører av containerteknologier.

Å styre et stort antall containere

La oss nå se på hva disse containerne er. Det er applikasjoner sammen med alt deres miljø – hovedsakelig bibliotekene som programmet er avhengig av. Alt dette er pakket inn i arkiver og presentert som et bilde som kan kjøres uavhengig av operativsystemet, testes og mer. Men det finnes et problem — det er veldig vanskelig å håndtere containere på et stort antall verter. Derfor ble Kubernetes skapt.

Containerbildet representerer en applikasjon pluss dens avhengigheter. Applikasjonen, dens avhengigheter og bilde av filsystemet til OS ligger i forskjellige deler av bildet, såkalte lag. Lagene kan gjenbrukes for forskjellige containere. For eksempel kan alle applikasjoner i selskapet bruke det grunnleggende laget av Ubuntu. Når containere startes, er det ikke behov for å lagre mange kopier av ett og samme grunnlagslag på verten. Dette gjør det mulig å optimalisere lagringen og distribusjonen av bilder.

Når vi ønsker å kjøre en applikasjon fra en container, legges de nødvendige lagene oppå hverandre og danner et overlay-filsystem. Øverst legges et skrivelag, som fjernes når containeren stoppes. Dette sikrer at applikasjonen alltid har det samme miljøet ved oppstart, som ikke kan endres. Det garanterer reproduserbarhet av miljøet på ulike vertssystemer. Enten det er Ubuntu eller CentOS, vil miljøet alltid være det samme. I tillegg er containeren isolert fra verten ved hjelp av mekanismer innebygd i Linux-kjernen. Applikasjoner i containeren har ikke tilgang til filer, prosesser eller andre containere på verten. Slik isolasjon av applikasjoner fra vertssystemet gir et ekstra lag med sikkerhet.

Det finnes mange verktøy for å administrere containere på verten. Det mest populære av dem er Docker. Det gir en full livssyklus for containerne. Imidlertid fungerer det bare på én vert. Når det er behov for å håndtere containere på flere verter, kan Docker gjøre livet til ingeniører til et mareritt. Derfor ble Kubernetes utviklet.

Etterspørselen etter Kubernetes skyldes nettopp muligheten til å styre grupper av containere på flere verter som en enhet. Populariteten til systemet sikrer muligheten til å bygge DevOps eller Development Operations, der Kubernetes brukes til å kjøre prosessene i denne DevOps.

Figur 1. Schematic illustration of how Kubernetes works

Full automatisering

DevOps representerer i prinsippet automatisering av utviklingsprosessen. Grovt sagt skriver utviklere kode som lastes opp til et repository. Deretter kan denne koden automatisk bygges direkte i en container med alle biblioteker, testes og "rulles ut" til neste fase – Staging, og deretter umiddelbart til Production.

Sammen med Kubernetes gjør DevOps det mulig å automatisere denne prosessen, slik at den nesten skjer uten utviklernes involvering. Dette øker hastigheten på byggingen betydelig, ettersom utvikleren ikke trenger å gjøre dette på sin egen datamaskin — han skriver bare en kodesnutt, pusher koden til depotet, hvoretter en pipeline settes i gang, som kan inkludere bygging, testing og distribusjon. Dette skjer for hver commit, noe som gjør at testing skjer kontinuerlig.

Bruken av containere gir også trygghet for at hele miljøet til programmet vil gå til produksjon akkurat slik det ble testet. Det vil si at det ikke oppstår problemer som «i testen var det en versjon, i produksjon var det en annen, og når det ble plassert, krasjet alt». Siden vi i dag har en trend mot mikrotjenestearkitektur, der det i stedet for ett stort program finnes hundrevis av små, vil det kreve et enormt antall ansatte å administrere dem manuelt. Derfor bruker vi Kubernetes.

Fordeler, fordeler, fordeler

Når det gjelder fordelene med Kubernetes som plattform, har den betydelige fordeler når det gjelder administrering av mikrotjenestearkitektur.

Administrasjon av mange replikaer. Det viktigste er styringen av containere på mange verter. Og enda viktigere er håndteringen av mange replikaer av applikasjoner i containere som en enkelt enhet. Takket være dette trenger ingeniørene ikke å bekymre seg for hver enkelt container. Hvis en av containerne går ned, vil Kubernetes oppdage det og starte den på nytt.
Klynge-nettverk. Kubernetes har også et såkalt klynge-nettverk med sitt eget adresseområde. Dette gjør at hver pod har sin egen adresse. Med pod menes den minste strukturelle enheten i klyngen, der containere kjøres direkte. I tillegg har Kubernetes funksjonalitet som kombinerer en lastbalanserer og tjenestediscovery. Dette gjør det mulig å bli kvitt manuell håndtering av IP-adresser og overlate denne oppgaven til Kubernetes. Automatiske helse-sjekker vil hjelpe med å oppdage problemer og omdirigere trafikk til fungerende pods.
Administrasjon av konfigurasjoner. Når du administrerer mange applikasjoner, blir det vanskelig å håndtere applikasjonskonfigurasjoner. Derfor finnes det spesielle ressurser i Kubernetes som ConfigMaps. De lar deg lagre konfigurasjoner sentralt og sette dem inn i pod-er ved oppstart av applikasjoner. Denne mekanismen sikrer konsistensen av konfigurasjonen, enten det er ti eller hundre replikaer av applikasjonene.
Vedvarende volumer. Containere er i sin natur immaterielle, og når en container stoppes, vil all data skrevet til filsystemet bli slettet. Men noen applikasjoner lagrer data direkte på disken. For å løse dette problemet finnes det funksjonalitet for administrasjon av diskminne i Kubernetes – Vedvarende volumer. Denne mekanismen bruker ekstern lagring for data, og kan gi containere vedvarende lagring, enten blokk- eller filbasert. Dette løsningen lar deg lagre data separat fra arbeidsenhetene, noe som redder dem i tilfelle en av arbeidsenhetene svikter.
Load Balancer. Til tross for at vi i Kubernetes håndterer abstrakte enheter som Deployment, StatefulSet etc., kjører containerne til slutt på vanlige virtuelle maskiner eller fysiske servere. De er ikke perfekte og kan gå ned når som helst. Kubernetes vil oppdage dette og omdirigere intern trafikk til andre replikaer. Men hva med trafikken som kommer utenfra? Hvis vi bare sender trafikk til en av arbeidsenhetene, vil tjenesten være utilgjengelig hvis den går ned. For å løse dette problemet finnes det tjenester i Kubernetes som Load Balancer. De er designet for å automatisk konfigurere en ekstern skybalanserer for alle arbeidsenheter i klyngen. Denne eksterne balansereren dirigerer ekstern trafikk til arbeidsenhetene og overvåker statusen deres. Hvis en eller flere arbeidsenheter blir utilgjengelige, omdirigeres trafikken til andre enheter. Dette gjør det mulig å lage høyt tilgjengelige tjenester med Kubernetes.

Kubernetes viser seg best når det gjelder å kjøre mikrotjenestearkitekturer. Det er mulig å implementere systemet i en klassisk arkitektur, men det er meningsløst. Hvis en applikasjon ikke kan kjøre i flere replikaer, hva er da forskjellen – enten i Kubernetes eller ikke?

Open source Kubernetes

Open source Kubernetes – en fantastisk løsning: installert og klart til bruk. Kan settes opp på egne servere og infrastruktur, med en master og arbeidere, der alle applikasjoner kjører. Og det beste – alt dette er gratis. Men det er noen nyanser.

For det første – kravene til kunnskap og erfaring hos administratorer og ingeniører som skal sette opp og vedlikeholde det hele. Siden kunden får full frihet til å operere i klyngen, bærer han selv ansvaret for klyngens funksjonalitet. Å bryte noe her er veldig enkelt.
For det andre – mangel på integrasjoner. Hvis man bruker Kubernetes uten en populær virtualiseringsplattform, går man glipp av alle programmets fordeler, som bruk av Persistent Volumes og Load balancer-tjenester.

Figur 2. Arkitektur for k8s

Kubernetes fra leverandøren

Integrasjon med en skyleverandør gir to muligheter:

For det første kan man enkelt trykke på knappen «opprett klynge» og få en allerede konfigurert og klar til bruk klynge.
For det andre setter leverandøren selv opp klyngen og konfigurerer integrasjonen med skyen.

Slik skjer det hos oss. Ingeniøren som starter klyngen angir hvor mange arbeidere han trenger og med hvilke spesifikasjoner (for eksempel 5 arbeidere, hver med 10 CPU, 16 GB RAM og for eksempel 100 GB lagring). Deretter får han tilgang til en allerede opprettet klynge. I denne prosessen overdras arbeidere som kjører belastningen helt til kunden, men hele managementpanelet forblir hos leverandøren (hvis tjenesten tilbys som en managed service).

Imidlertid har denne ordningen sine ulemper. Siden managementpanelet forblir hos leverandøren, gir ikke leverandøren full tilgang til kunden, noe som reduserer fleksibiliteten i arbeidet med Kubernetes. Noen ganger ønsker kunden å implementere en spesifikk funksjonalitet i Kubernetes, for eksempel autentisering via LDAP, men konfigurasjonen av managementpanelet tillater ikke dette.

Figur 3. Eksempel på Kubernetes-klynge fra en skyleverandør

Hva bør man velge: open source eller fra leverandør?

Så, er det open source Kubernetes eller leverandørens? Ved å ta open source Kubernetes, kan brukeren gjøre hva han vil med det. Men sjansen for å skyte seg selv i foten er stor. Med leverandørens er det vanskeligere, fordi alt er gjennomtenkt og konfigurert for selskapet. Det største problemet med open source Kubernetes er kravet til spesialister. Med leverandørens slipper selskapet denne hodepinen, men de må bestemme: betale sine spesialister eller leverandøren.

Vel, fordelene er åpenbare, ulempene er også kjent. Én ting er konstant: Kubernetes løser mange problemer ved å automatisere administrasjonen av mange containere. Hvilken man skal velge, open source eller leverandørens, må hver enkelt avgjøre selv.