Hei, mitt navn er Dmitry Krasnov. I mer enn fem år har jeg administrert Kubernetes-klynger og bygget komplekse mikrotjenestearkitekturer. I begynnelsen av dette året lanserte vi en tjeneste for administrasjon av Kubernetes-klynger basert på Containerum. Ved å benytte denne muligheten vil jeg fortelle deg hva Kubernetes er og hvordan integrasjon med en leverandør skiller seg fra åpen kildekode.
Til å begynne med, hva er . Dette er et system for å administrere containere på et stort antall verter. Fra gresk er det forresten oversatt som «pilot» eller «styrmann». Opprinnelig utviklet av Google og deretter donert som et teknologibidrag til Cloud Native Computing Foundation, en internasjonal non-profit organisasjon som samler verdens ledende utviklere, sluttbrukere og leverandører av containerteknologi.
Administrer et stort antall containere
La oss nå finne ut hva slags beholdere dette er. Dette er en applikasjon med hele miljøet - hovedsakelig bibliotekene som programmet er avhengig av. Alt dette er pakket i arkiver og presentert i form av et bilde som kan kjøres uavhengig av operativsystem, testes med mer. Men det er et problem - å administrere containere på et stort antall verter er veldig vanskelig. Det er derfor Kubernetes ble opprettet.
Et beholderbilde representerer en applikasjon pluss dens avhengigheter. Applikasjonen, dens avhengigheter og OS-filsystembildet er plassert i forskjellige deler av bildet, såkalte lag. Lag kan gjenbrukes til forskjellige beholdere. For eksempel kan alle applikasjoner i et selskap bruke Ubuntu-baselaget. Når du kjører containere, er det ikke nødvendig å lagre flere kopier av et enkelt basislag på verten. Dette lar deg optimalisere bildelagring og levering.
Når vi ønsker å kjøre en applikasjon fra en container, legges de nødvendige lagene over hverandre og det dannes et overleggsfilsystem. Et opptakslag legges på toppen, som fjernes når beholderen stopper. Dette sikrer at når beholderen kjører, vil applikasjonen alltid ha det samme miljøet, som ikke kan endres. Dette garanterer reproduserbarhet av miljøet på forskjellige verts-OSer. Enten det er Ubuntu eller CentOS, vil miljøet alltid være det samme. I tillegg er beholderen isolert fra verten ved hjelp av mekanismer innebygd i Linux-kjernen. Applikasjoner i en beholder ser ikke filer, prosesser til verten og nabobeholdere. Denne isolasjonen av applikasjoner fra verts-OS gir et ekstra lag med sikkerhet.
Det er mange tilgjengelige verktøy for å administrere containere på en vert. Den mest populære av dem er Docker. Det lar deg gi hele livssyklusen til containere. Det fungerer imidlertid bare på én vert. Hvis du trenger å administrere containere på tvers av flere verter, kan Docker gjøre livet til et helvete for ingeniører. Det er derfor Kubernetes ble opprettet.
Etterspørselen etter Kubernetes skyldes nettopp muligheten til å administrere grupper av containere på flere verter som en slags enkelt enhet. Populariteten til systemet gir muligheten til å bygge DevOps eller Development Operations, der Kubernetes brukes til å kjøre prosessene til nettopp denne DevOps.
Figur 1. Skjematisk fremstilling av hvordan Kubernetes fungerer
Full automatisering
DevOps er i utgangspunktet automatisering av utviklingsprosessen. Grovt sett skriver utviklere kode som lastes opp til depotet. Deretter kan denne koden automatisk samles umiddelbart i en beholder med alle bibliotekene, testes og "rulles ut" til neste trinn - Staging, og deretter umiddelbart til produksjon.
Sammen med Kubernetes lar DevOps deg automatisere denne prosessen slik at den skjer med praktisk talt ingen deltakelse fra utviklerne selv. På grunn av dette er byggingen betydelig raskere, siden utvikleren ikke trenger å gjøre dette på datamaskinen sin - han skriver bare et stykke kode, skyver koden til depotet, hvoretter rørledningen startes, som kan inkludere prosessen bygging, testing og utrulling. Og dette skjer med hver forpliktelse, så testing skjer kontinuerlig.
Samtidig lar bruk av en beholder deg være sikker på at hele miljøet til dette programmet vil bli utgitt i produksjon nøyaktig i den formen det ble testet i. Det vil si at det ikke vil være noen problemer som "det var noen versjoner i testen, andre i produksjon, men da vi installerte dem, falt alt." Og siden vi i dag har en trend mot mikrotjenestearkitektur, når det i stedet for én stor applikasjon er hundrevis av små, for å administrere dem manuelt, vil det kreves en stor stab av ansatte. Det er derfor vi bruker Kubernetes.
Fordeler, proffer, proffer
Hvis vi snakker om fordelene med Kubernetes som plattform, har den betydelige fordeler fra synspunktet om å administrere en mikrotjenestearkitektur.
- Administrere flere replikaer. Det viktigste er å administrere containere på tvers av flere verter. Enda viktigere, administrer flere applikasjonsreplikaer i beholdere som en enkelt enhet. Takket være dette slipper ingeniører å bekymre seg for hver enkelt container. Hvis en av beholderne krasjer, vil Kubernetes se dette og starte det på nytt.
- Klyngenettverk. Kubernetes har også et såkalt cluster-nettverk med eget adresserom. Takket være dette har hver pod sin egen adresse. En subpod forstås som den minste strukturelle enheten til en klynge der containere blir direkte lansert. I tillegg har Kubernetes funksjonalitet som kombinerer en lastbalanser og Service Discovery. Dette lar deg bli kvitt manuell IP-adresseadministrasjon og delegere denne oppgaven til Kubernetes. Og automatiske helsesjekker vil bidra til å oppdage problemer og omdirigere trafikk til fungerende pods.
- Konfigurasjonsstyring. Når du administrerer et stort antall applikasjoner, blir det vanskelig å administrere applikasjonskonfigurasjonen. Til dette formålet har Kubernetes spesielle ConfigMap-ressurser. De lar deg lagre konfigurasjoner sentralt og eksponere dem for pods når du kjører applikasjoner. Denne mekanismen lar oss garantere konsistensen av konfigurasjonen i minst ti eller hundre applikasjonskopier.
- Vedvarende volumer. Beholdere er iboende uforanderlige og når beholderen stoppes, vil all data som er skrevet til filsystemet bli ødelagt. Men noen applikasjoner lagrer data direkte på disken. For å løse dette problemet har Kubernetes en disklagringsadministrasjonsfunksjonalitet - Persistent Volumes. Denne mekanismen bruker ekstern lagring for data og kan overføre vedvarende lagring, blokk eller fil, til containere. Denne løsningen lar deg lagre data separat fra arbeidere, noe som sparer dem hvis de samme arbeiderne bryter sammen.
- Load Balancer. Selv om vi i Kubernetes administrerer abstrakte enheter som Deployment, StatefulSet, etc., kjører containere til slutt på vanlige virtuelle maskiner eller maskinvareservere. De er ikke perfekte og kan falle når som helst. Kubernetes vil se dette og omdirigere intern trafikk til andre replikaer. Men hva skal man gjøre med trafikk som kommer utenfra? Hvis du bare dirigerer trafikk til en av arbeiderne, hvis den krasjer, vil tjenesten bli utilgjengelig. For å løse dette problemet har Kubernetes tjenester som Load Balancer. De er designet for automatisk å konfigurere en ekstern skybalanserer for alle arbeidere i klyngen. Denne eksterne balansereren dirigerer ekstern trafikk til arbeidere og overvåker selv deres status. Hvis en eller flere arbeidere blir utilgjengelige, blir trafikken omdirigert til andre. Dette lar deg lage svært tilgjengelige tjenester ved hjelp av Kubernetes.
Kubernetes fungerer best når du kjører mikrotjenestearkitekturer. Det er mulig å implementere systemet i klassisk arkitektur, men det er meningsløst. Hvis en applikasjon ikke kan kjøre på flere replikaer, hvilken forskjell gjør det da - i Kubernetes eller ikke?
Åpen kildekode Kubernetes
Åpen kildekode Kubernetes er en flott ting: Jeg installerte det og det fungerer. Du kan distribuere det på dine egne maskinvareservere, på din egen infrastruktur, installere mastere og arbeidere som alle applikasjoner skal kjøre på. Og viktigst av alt, alt dette er gratis. Det er imidlertid nyanser.
- Den første er etterspørselen etter kunnskap og erfaring fra administratorer og ingeniører som vil distribuere og støtte alt dette. Siden klienten får full handlefrihet i klyngen, er han selv ansvarlig for utførelse av klyngen. Og det er veldig enkelt å bryte alt her.
- Det andre er mangelen på integrasjoner. Hvis du kjører Kubernetes uten en populær virtualiseringsplattform, får du ikke alle fordelene med programmet. For eksempel bruk av vedvarende volumer og lastbalanseringstjenester.
Figur 2. k8s arkitektur
Kubernetes fra leverandøren
Integrasjon med en skyleverandør gir to alternativer:
- For det første kan en person ganske enkelt klikke på "opprett klynge"-knappen og få en klynge allerede konfigurert og klar til bruk.
- For det andre installerer leverandøren selv klyngen og setter opp integrasjon med skyen.
Hvordan det skjer her. Ingeniøren som starter klyngen spesifiserer hvor mange arbeidere han trenger og med hvilke parametere (for eksempel 5 arbeidere, hver med 10 CPUer, 16 GB RAM og for eksempel 100 GB disk). Deretter får den tilgang til den allerede dannede klyngen. I dette tilfellet blir arbeiderne som lasten lanseres på, fullstendig overført til klienten, men hele administrasjonsplanet forblir under leverandørens ansvar (hvis tjenesten leveres i henhold til den administrerte tjenestemodellen).
Imidlertid har denne ordningen sine ulemper. På grunn av at administrasjonsplanet forblir hos leverandøren, gir ikke leverandøren full tilgang til klienten, og dette reduserer fleksibiliteten i arbeidet med Kubernetes. Noen ganger hender det at en klient ønsker å legge til noen spesifikk funksjonalitet til Kubernetes, for eksempel autentisering via LDAP, men administrasjonsplankonfigurasjonen tillater ikke dette.
Figur 3. Eksempel på en Kubernetes-klynge fra en skyleverandør
Hva du skal velge: åpen kildekode eller leverandør
Så, er Kubernetes åpen kildekode eller leverandørspesifikk? Hvis vi tar åpen kildekode Kubernetes, så gjør brukeren hva han vil med den. Men det er stor sjanse for å skyte deg selv i foten. Med leverandøren er det vanskeligere, fordi alt er gjennomtenkt og konfigurert for selskapet. Den største ulempen med åpen kildekode Kubernetes er kravet til spesialister. Med et leverandøralternativ er selskapet frigjort fra denne hodepinen, men det må bestemme om det skal betale spesialistene eller leverandøren.
Vel, fordelene er åpenbare, ulempene er også kjent. En ting er konstant: Kubernetes løser mange problemer ved å automatisere administrasjonen av mange containere. Og hvilken du skal velge, åpen kildekode eller leverandør - alle tar sin egen avgjørelse.
Artikkelen ble utarbeidet av Dmitry Krasnov, ledende arkitekt for Containerum-tjenesten til #CloudMTS-leverandøren
Kilde: www.habr.com