Hej, mit navn er Dmitry Krasnov. I mere end fem år har jeg administreret Kubernetes-klynger og bygget komplekse mikroservicearkitekturer. I begyndelsen af dette år lancerede vi en service til styring af Kubernetes-klynger baseret på Containerum. Ved at benytte denne mulighed vil jeg fortælle dig, hvad Kubernetes er, og hvordan integration med en leverandør adskiller sig fra open source.
Til at begynde med, hvad er . Dette er et system til håndtering af containere på et stort antal værter. Fra græsk er det i øvrigt oversat som "pilot" eller "rorsmand". Oprindeligt udviklet af Google og derefter doneret som et teknologibidrag til Cloud Native Computing Foundation, en international non-profit organisation, der samler verdens førende udviklere, slutbrugere og udbydere af containerteknologi.
Håndter et stort antal containere
Lad os nu finde ud af, hvilken slags beholdere det er. Dette er en applikation med hele sit miljø - hovedsageligt de biblioteker, som programmet afhænger af. Alt dette er pakket i arkiver og præsenteret i form af et billede, der kan køres uanset styresystem, testes med mere. Men der er et problem - at administrere containere på et stort antal værter er meget vanskeligt. Det er derfor Kubernetes blev oprettet.
Et containerbillede repræsenterer et program plus dets afhængigheder. Applikationen, dens afhængigheder og OS-filsystembilledet er placeret i forskellige dele af billedet, såkaldte lag. Lag kan genbruges til forskellige beholdere. For eksempel kan alle applikationer i en virksomhed bruge Ubuntu-basislaget. Når du kører containere, er der ingen grund til at gemme flere kopier af et enkelt basislag på værten. Dette giver dig mulighed for at optimere billedlagring og levering.
Når vi ønsker at køre en applikation fra en container, bliver de nødvendige lag overlejret på hinanden, og der dannes et overlay-filsystem. Et optagelag lægges ovenpå, som fjernes, når beholderen stopper. Dette sikrer, at når containeren kører, vil applikationen altid have det samme miljø, som ikke kan ændres. Dette garanterer reproducerbarhed af miljøet på forskellige værtsoperativsystemer. Uanset om det er Ubuntu eller CentOS, vil miljøet altid være det samme. Derudover er containeren isoleret fra værten ved hjælp af mekanismer indbygget i Linux-kernen. Programmer i en container kan ikke se filer, processer fra værten og tilstødende containere. Denne isolering af applikationer fra værts-OS giver et ekstra lag af sikkerhed.
Der er mange tilgængelige værktøjer til at administrere containere på en vært. Den mest populære af dem er Docker. Det giver dig mulighed for at levere containernes fulde livscyklus. Det virker dog kun på én vært. Hvis du har brug for at administrere containere på tværs af flere værter, kan Docker gøre livet til et helvede for ingeniører. Det er derfor Kubernetes blev oprettet.
Efterspørgslen efter Kubernetes skyldes netop muligheden for at administrere grupper af containere på flere værter som en slags enkelt enhed. Systemets popularitet giver mulighed for at bygge DevOps eller Development Operations, hvor Kubernetes bruges til at køre processerne for netop denne DevOps.
Figur 1. Skematisk fremstilling af, hvordan Kubernetes fungerer
Fuld automatisering
DevOps er dybest set automatisering af udviklingsprocessen. Groft sagt skriver udviklere kode, der uploades til depotet. Så kan denne kode automatisk samles med det samme i en container med alle bibliotekerne, testes og "rulles ud" til næste fase - Staging, og derefter straks til produktion.
Sammen med Kubernetes giver DevOps dig mulighed for at automatisere denne proces, så den sker med stort set ingen deltagelse fra udviklerne selv. På grund af dette er opbygningen væsentlig hurtigere, da udvikleren ikke behøver at gøre dette på sin computer - han skriver blot et stykke kode, skubber koden til repository, hvorefter pipelinen lanceres, som kan omfatte processen opbygning, test og udrulning. Og dette sker med hver forpligtelse, så testning sker løbende.
Samtidig giver brug af en beholder dig mulighed for at være sikker på, at hele miljøet i dette program vil blive frigivet til produktion nøjagtigt i den form, som det blev testet. Det vil sige, der vil ikke være nogen problemer som "der var nogle versioner i testen, andre i produktion, men da vi installerede dem, faldt alt." Og da vi i dag har en tendens til mikroservicearkitektur, hvor der i stedet for én enorm applikation er hundredvis af små, for at kunne administrere dem manuelt, vil der være behov for en enorm stab af medarbejdere. Det er derfor, vi bruger Kubernetes.
Fordele, fordele, fordele
Hvis vi taler om fordelene ved Kubernetes som platform, så har det betydelige fordele med hensyn til at styre en mikroservicearkitektur.
- Håndtering af flere replikaer. Det vigtigste er at administrere containere på tværs af flere værter. Endnu vigtigere, administrer flere applikationsreplikaer i containere som en enkelt enhed. Takket være dette behøver ingeniører ikke at bekymre sig om hver enkelt container. Hvis en af containerne går ned, vil Kubernetes se dette og genstarte det igen.
- Klynge netværk. Kubernetes har også et såkaldt klyngenetværk med eget adresserum. Takket være dette har hver pod sin egen adresse. En subpod forstås som den mindste strukturelle enhed af en klynge, hvor containere lanceres direkte. Derudover har Kubernetes funktionalitet, der kombinerer en load balancer og Service Discovery. Dette giver dig mulighed for at slippe af med manuel IP-adressestyring og uddelegere denne opgave til Kubernetes. Og automatiske sundhedstjek hjælper med at opdage problemer og omdirigere trafik til fungerende pods.
- Konfigurationsstyring. Når du administrerer et stort antal applikationer, bliver det vanskeligt at administrere applikationskonfigurationen. Til dette formål har Kubernetes specielle ConfigMap-ressourcer. De giver dig mulighed for centralt at gemme konfigurationer og udsætte dem for pods, når du kører applikationer. Denne mekanisme giver os mulighed for at garantere konsistensen af konfigurationen i mindst ti eller hundrede applikationsreplikaer.
- Vedvarende mængder. Containere er i sagens natur uforanderlige, og når containeren 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 en disklagringsadministrationsfunktionalitet - Persistent Volumes. Denne mekanisme bruger ekstern lagring til data og kan overføre vedvarende lagring, blok eller fil, til containere. Denne løsning giver dig mulighed for at gemme data adskilt fra arbejdere, hvilket gemmer dem, hvis de samme arbejdere går i stykker.
- Load Balancer. Selvom vi i Kubernetes administrerer abstrakte enheder som Deployment, StatefulSet osv., kører containere i sidste ende på almindelige virtuelle maskiner eller hardwareservere. De er ikke perfekte og kan falde når som helst. Kubernetes vil se dette og omdirigere intern trafik til andre replikaer. Men hvad skal man gøre med trafik, der kommer udefra? Hvis du blot dirigerer trafik til en af arbejderne, vil tjenesten blive utilgængelig, hvis den går ned. For at løse dette problem har Kubernetes tjenester som Load Balancer. De er designet til automatisk at konfigurere en ekstern cloud balancer for alle medarbejdere i klyngen. Denne eksterne balancer dirigerer ekstern trafik til arbejdere og overvåger selv deres status. Hvis en eller flere medarbejdere bliver utilgængelige, omdirigeres trafikken til andre. Dette giver dig mulighed for at oprette meget tilgængelige tjenester ved hjælp af Kubernetes.
Kubernetes fungerer bedst, når du kører mikroservicearkitekturer. Det er muligt at implementere systemet i klassisk arkitektur, men det er meningsløst. Hvis en applikation ikke kan køre på flere replikaer, hvilken forskel gør det så - i Kubernetes eller ej?
Open source Kubernetes
Open source Kubernetes er en fantastisk ting: Jeg har installeret det, og det virker. Du kan implementere det på dine egne hardwareservere, på din egen infrastruktur, installere mastere og arbejdere, som alle applikationer kører på. Og vigtigst af alt er alt dette gratis. Der er dog nuancer.
- Den første er efterspørgslen efter viden og erfaring fra administratorer og ingeniører, som vil implementere og understøtte alt dette. Da klienten får fuldstændig handlefrihed i klyngen, bærer han selv ansvaret for klyngens udførelse. Og det er meget nemt at bryde alt her.
- Det andet er manglen på integrationer. Hvis du kører Kubernetes uden en populær virtualiseringsplatform, får du ikke alle fordelene ved programmet. Såsom at bruge Persistent Volumes og Load balancer-tjenester.
Figur 2. k8s arkitektur
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 klynge allerede konfigureret og klar til brug.
- For det andet installerer leverandøren selv klyngen og opsætter integration med skyen.
Hvordan det sker her. Ingeniøren, der starter klyngen, specificerer, hvor mange arbejdere han har brug for og med hvilke parametre (f.eks. 5 arbejdere, hver med 10 CPU'er, 16 GB RAM og f.eks. 100 GB disk). Hvorefter den får adgang til den allerede dannede klynge. I dette tilfælde overføres de arbejdere, som belastningen er lanceret på, fuldstændigt til klienten, men hele administrationsplanet forbliver under leverandørens ansvar (hvis tjenesten leveres i henhold til den administrerede servicemodel).
Denne ordning har dog sine ulemper. På grund af det faktum, at administrationsplanet forbliver hos leverandøren, giver leverandøren ikke fuld adgang til klienten, og det reducerer fleksibiliteten i arbejdet med Kubernetes. Nogle gange sker det, at en klient ønsker at tilføje en bestemt funktionalitet til Kubernetes, for eksempel autentificering via LDAP, men konfigurationen af administrationsplanet tillader ikke dette.
Figur 3. Eksempel på en Kubernetes-klynge fra en cloud-udbyder
Hvad skal man vælge: open source eller leverandør
Så er Kubernetes open source eller leverandørspecifik? Hvis vi tager open source Kubernetes, så gør brugeren, hvad han vil med det. Men der er stor chance for at skyde sig selv i foden. Med leverandøren er det sværere, fordi alt er gennemtænkt og konfigureret til virksomheden. Den største ulempe ved open source Kubernetes er kravet om specialister. Med en leverandørmulighed er virksomheden befriet for denne hovedpine, men den bliver nødt til at beslutte, om den skal betale sine specialister eller sælgeren.
Nå, fordelene er indlysende, ulemperne er også kendte. En ting er konstant: Kubernetes løser en masse problemer ved at automatisere håndteringen af mange containere. Og hvilken man skal vælge, open source eller leverandør - alle træffer deres egen beslutning.
Artiklen er udarbejdet af Dmitry Krasnov, førende arkitekt for Containerum-tjenesten fra #CloudMTS-udbyderen
Kilde: www.habr.com