virtuele servere<\/a>, brugte vi Ansible, hvor konfigurationerne l\u00e5 i det samme repository. Men for de fleste udviklere var det lidt sv\u00e6rere at arbejde med. M\u00e6ngden af konfigurationer og kode, du skal tilf\u00f8je for at deploye en service, blev meget mindre. Derudover var det meget nemt for devops at rette eller \u00e6ndre den. I tilf\u00e6lde af overgange, for eksempel til en ny version af Nomad, kunne de massivt opdatere alle operationsfiler, der l\u00e5 p\u00e5 det samme sted.<\/li>\n<\/ol>\n\nMen vi st\u00f8dte ogs\u00e5 p\u00e5 nogle ulemper: <\/p>\n
Det viste sig, at vi ikke kunne opn\u00e5 glidende deployment <\/b>i tilf\u00e6lde af Nomad. Ved udrulningen af containere fra forskellige milj\u00f8er kunne det ske, at den blev startet, og Nomad opfattede den som klar til at modtage trafik. Dette skete, f\u00f8r applikationen indeni n\u00e5ede at starte op. Af denne grund begyndte systemet i en kort periode at give 500-fejl, fordi trafikken begyndte at g\u00e5 til en container, der endnu ikke var klar til at modtage den. <\/p>\n
Vi st\u00f8dte p\u00e5 nogle fejl<\/b>. Den mest v\u00e6sentlige bug er, at Nomad ikke h\u00e5ndterer store klynger s\u00e6rligt godt, hvis du har mange systemer og containere. N\u00e5r du \u00f8nsker at s\u00e6tte \u00e9n af serverne i vedligeholdelse, som er inkluderet i Nomad-klyngen, er der en betydelig risiko for, at klyngen ikke fungerer optimalt og falder fra hinanden. En del containere kan for eksempel falde ned og ikke komme op igen \u2014 dette vil koste dig meget, hvis alle dine systemer i produktion pr\u00e6cist er i klyngen, der styres af Nomad. <\/p>\n
Derfor besluttede vi at overveje, hvilken retning vi skulle g\u00e5 i fremover. P\u00e5 det tidspunkt blev vi meget bedre til at forst\u00e5, hvad vi \u00f8nskede at opn\u00e5. Nemlig: vi \u00f8nsker p\u00e5lidelighed, lidt flere funktioner end hvad Nomad tilbyder, og et mere modent, mere stabilt system. <\/p>\n
I denne henseende valgte vi Kubernetes som den mest popul\u00e6re platform til at k\u00f8re klynger. Is\u00e6r givet at st\u00f8rrelsen og antallet af vores containere var ret store. Til s\u00e5danne form\u00e5l syntes Kubernetes at v\u00e6re det mest passende system blandt dem, vi kunne se p\u00e5. <\/p>\n
Overgangen til Kubernetes<\/h1>\n \nLad mig kort fort\u00e6lle om de grundl\u00e6ggende begreber i Kubernetes og hvordan de adskiller sig fra Nomad. <\/p>\n
Pod<\/b> \u2014 det er en gruppe af en eller flere containere, der altid k\u00f8rer sammen. Og de fungerer som om, de altid strengt k\u00f8rer p\u00e5 \u00e9n virtuel maskine. De kan tilg\u00e5 hinanden via IP-adressen 127.0.0.1 p\u00e5 forskellige porte. <\/p>\n
Lad os antage, at du har en PHP-applikation, der best\u00e5r af nginx og php-fpm \u2013 en klassisk ops\u00e6tning. Du vil sandsynligvis have, at b\u00e5de nginx og php-fpm containere altid skal v\u00e6re sammen. Kubernetes g\u00f8r det muligt at opn\u00e5 dette ved at beskrive dem som en f\u00e6lles pod. Det var netop dette, vi ikke kunne opn\u00e5 med Nomad.<\/p>\n
Det n\u00e6ste begreb er deployment<\/b>. Faktisk er pod'en i sig selv en efem\u00e6r ting, den starter og forsvinder. Vil du f\u00f8rst dr\u00e6be alle dine tidligere containere og derefter starte nye versioner med det samme, eller vil du udrulle dem gradvist \u2013 dette er pr\u00e6cist det, som begrebet deployment ansvarer for. Det beskriver, hvordan du implementerer dine pods, i hvilken m\u00e6ngde, og hvordan de opdateres. <\/p>\n
Det tredje begreb er service<\/b>. Din service er faktisk dit system, som modtager en vis trafik og derefter sender det til en eller flere pods, der svarer til din service. Det betyder, at det tillader at angive, at al indg\u00e5ende trafik til en given service med et bestemt navn skal sendes til netop disse pods. Og samtidig sikrer det, at du f\u00e5r trafikbalance. Det vil sige, at du kan k\u00f8re to pods af din applikation, og al indg\u00e5ende trafik vil blive j\u00e6vnt fordelt mellem de relevante pods til denne service.<\/p>\n
Og det fjerde grundl\u00e6ggende begreb \u2014 Ingress<\/b>. Det er en service, der k\u00f8rer i Kubernetes-klusteret. Den fungerer som en ekstern belastningsfordeler, der modtager alle foresp\u00f8rgsler. Gennem Kubernetes API kan Ingress bestemme, hvor disse foresp\u00f8rgsler skal sendes. Desuden g\u00f8r den dette meget fleksibelt. Du kan sige, at alle foresp\u00f8rgsler til denne v\u00e6rt og den p\u00e5g\u00e6ldende URL skal sendes til denne service. Og disse foresp\u00f8rgsler, der kommer til denne v\u00e6rt og en anden URL, skal sendes til en anden service. <\/p>\n
Det mest fantastiske for den, der udvikler applikationen, er, at du har mulighed for at styre det hele selv. Ved at angive Ingress-konfigurationen kan du sende al trafik, der kommer til en bestemt API, til separate containere, der f.eks. er skrevet i Go. Og denne trafik, der kommer til den samme dom\u00e6ne, men til en anden URL, kan sendes til containere, der er skrevet i PHP, hvor der er meget logik, men de er ikke s\u00e5 hurtige.<\/p>\n
Hvis man sammenligner alle disse begreber med Nomad, kan man sige, at de f\u00f8rste tre begreber er samlet i en Service. Det sidste begreb findes ikke i Nomad. Vi brugte en ekstern belastningsfordeler til dette form\u00e5l: det kan v\u00e6re haproxy, nginx, nginx+ osv. I tilf\u00e6ldet med Kubernetes beh\u00f8ver du ikke at introducere dette begreb separat. Men hvis du ser p\u00e5 Ingress indeni, s\u00e5 er det enten nginx, haproxy eller traefik, men som ombygget inden for Kubernetes. <\/p>\n
Alle de begreber, jeg har beskrevet, er i realiteten ressourcer, der eksisterer inden for Kubernetes-klusteret. For at beskrive dem i Kubernetes bruges yaml-formatet, som er mere l\u00e6sbart og velkendt end HCL-filer i tilf\u00e6lde af Nomad. Men strukturelt beskriver de f.eks. pods det samme. De siger \u2013 jeg \u00f8nsker at implementere s\u00e5danne pods derhen, med s\u00e5danne billeder, i s\u00e5danne m\u00e6ngder. <\/p>\n
Grundl\u00e6ggende begreber i Helm<\/h1>\n \nHelm er pakkeh\u00e5ndtering<\/b> til Kubernetes. Det ligner, hvordan package managers fungerer i programmeringssprog. De giver dig mulighed for at gemme en service, der best\u00e5r f.eks. af deployment nginx, deployment php-fpm, konfiguration for Ingress, configmaps (dette er en enhed, der g\u00f8r det muligt at definere env og andre parametre for dit system) i form af s\u00e5kaldte charts. Samtidig fungerer Helm ovenfor Kubernetes<\/b>. S\u00e5 det er ikke et system, der st\u00e5r uafh\u00e6ngigt, men blot en anden service, der k\u00f8rer inden for klynge. Du interagerer med det gennem dets API ved hj\u00e6lp af kommandolinje. Dets bekvemmelighed og sk\u00f8nhed ligger i, at selvom Helm skulle g\u00e5 ned, eller du sletter det fra klyngen, s\u00e5 forsvinder dine tjenester ikke, da Helm i bund og grund kun fungerer som en opstart af systemet. Det er Kubernetes, der herefter st\u00e5r for driften og tilstanden af tjenesterne. <\/p>\n
Vi inds\u00e5 ogs\u00e5, at skabelonbehandling<\/b>, som vi tidligere var n\u00f8dt til at implementere manuelt ved at integrere jinja i vores konfigurationer, er en af Helm's grundl\u00e6ggende funktioner. Alle konfigurationer, du laver til dine systemer, gemmes i Helm som skabeloner, der ligner en smule p\u00e5 jinja, men som i virkeligheden bruger skabelonbehandling af sproget Go, som Helm er skrevet i, ligesom Kubernetes. <\/p>\n
Helm tilf\u00f8jer os endnu et par yderligere begreber. <\/p>\n
Chart<\/b> \u2014 er beskrivelsen af din service. I andre package managers ville det blive kaldt et package, bundle eller noget lignende. Her kaldes det chart. <\/p>\n
Values <\/b>\u2013 er de variabler, som du \u00f8nsker at bruge til at samle dine konfigurationer fra skabeloner. <\/p>\n
Release<\/b>Hver gang en service, der deployeres med helm, modtager en inkrementel version af udgivelsen. Helm husker, hvordan konfigurationen af servicen var ved den tidligere, forrige udgivelse og s\u00e5 videre. Derfor er det nok at udf\u00f8re kommandoen helm rollback med den tidligere version af udgivelsen. Selv hvis den tilsvarende konfiguration ikke er tilg\u00e6ngelig i dit repository p\u00e5 tidspunktet for rollback, husker helm stadig, hvordan den var, og vil gendanne dit system til den tilstand, det var i ved den tidligere udgivelse. <\/p>\n
N\u00e5r vi bruger helm, bliver de almindelige konfigurationer for Kubernetes ogs\u00e5 til skabeloner, hvor der er mulighed for at anvende variabler, funktioner og betingede operatorer. P\u00e5 den m\u00e5de kan du samle konfigurationen af din service afh\u00e6ngigt af milj\u00f8et.<\/p>\n
Selvom vi ikke opbevarer nogen virkelig f\u00f8lsomme data i selve konfigurationsfilerne, s\u00e5som adgangskoder til databaser, da de opbevares som secrets i Kubernetes, er der stadig enkelte ting, som vi ikke \u00f8nsker at give adgang til for alle. Derfor er adgangen til \"deploy\"-repositoryet mere begr\u00e6nset, mens \"helm\"-repositoryet indeholder blot beskrivelsen af servicen. Af denne grund kan adgangen til det gives p\u00e5 en sikker m\u00e5de til et bredere publikum. <\/p>\n
Da vi har ikke kun produktion, men ogs\u00e5 andre milj\u00f8er, kan vi med denne opdeling genbruge vores helm-charts til at deployere tjenester ikke bare i produktionen, men ogs\u00e5 for eksempel i QA-milj\u00f8et. Selv for at kunne udvikle dem lokalt ved at bruge Minikube<\/i> \u2014 det er en ting til lokal k\u00f8rsel af Kubernetes. <\/p>\n
Inden for hver repository har vi opdelt i separate mapper for hver tjeneste. Det vil sige, at der inden for hver mappe findes skabeloner, der relaterer sig til den p\u00e5g\u00e6ldende chart og beskriver de ressourcer, der skal implementeres for at starte vores system. I repository'et 'deploy' har vi kun efterladt milj\u00f8variabler. I dette tilf\u00e6lde valgte vi ikke at bruge skabelonisering med jinja, fordi helm selv tilbyder skabelonisering som standard \u2013 det er en af dens prim\u00e6re funktioner. <\/p>\n
Vi har efterladt et script til implementering \u2013 deploy.sh, som forenkler og standardiserer opstarten til implementering med helm. Dermed ser deploy-gr\u00e6nsefladen for alle, der \u00f8nsker at implementere, n\u00f8jagtig ud som den gjorde i tilf\u00e6lde af implementering via Nomad. Den samme deploy.sh, navnet p\u00e5 din tjeneste, og hvor du \u00f8nsker at implementere den. Dette medf\u00f8rer, at helm k\u00f8rer indeni. Det indsamler konfigurationer fra skabeloner, erstatter dem med de n\u00f8dvendige v\u00e6rdifiler, og derefter implementerer det ved at kaste dem ind i Kubernetes. <\/p>\n
Konklusioner<\/h1>\n \nKubernetes-tjenesten ser mere kompleks ud end Nomad. <\/p>\n
Ved overgangen opdagede vi, at Kubernetes har alle funktioner, som Nomad, som vi tidligere brugte, og tilf\u00f8jer mange nye muligheder. Det kan udvides gennem plugins, og faktisk gennem brugerdefinerede ressourcearter. Det vil sige, at du ikke kun kan bruge de standardressourcer, der f\u00f8lger med Kubernetes, men ogs\u00e5 skabe dine egne ressourcer og tjenester, der kan l\u00e6se dem. Dette giver ekstra muligheder for at udvide dit system uden behov for at geninstallere Kubernetes og uden n\u00f8dvendigheden af \u00e6ndringer. <\/p>\n
Et eksempel p\u00e5 en s\u00e5dan anvendelse er Prometheus, som k\u00f8rer inde i vores Kubernetes-kluster. For at det kan begynde at samle metrics fra en given tjeneste, skal vi tilf\u00f8je en ekstra ressourcetype i tjenestens beskrivelse, s\u00e5kaldt service-monitor. Takket v\u00e6re Prometheus' evne til at l\u00e6se brugerdefinerede ressourcearter, n\u00e5r det k\u00f8rer i Kubernetes, begynder det automatisk at indsamle metrics fra det nye system. Det er bastante praktisk. <\/p>\n
Den f\u00f8rste deployment, vi lavede i Kubernetes, var i marts 2018. Og i denne periode har vi aldrig haft problemer med det. Det fungerer stabilt uden betydelige fejl. Derudover kan vi udvide det yderligere. I dag er de tilg\u00e6ngelige funktioner tilstr\u00e6kkelige til vores behov, og vi er meget tilfredse med udviklingshastigheden i Kubernetes. I \u00f8jeblikket er der mere end 3000 containere i Kubernetes. Klustret str\u00e6kker sig over flere noder. Det er servicevenligt, stabilt og let at kontrollere.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Afspil](\"https:\/\/img.youtube.com\/vi\/oqrb7dWECSo\/hqdefault.jpg\")
\r\n