Kubernetes je skvelý nástroj na spúšťanie kontajnerov Docker v klastrovanom produkčnom prostredí. Existujú však problémy, ktoré Kubernetes nedokáže vyriešiť. Pre časté produkčné nasadenia potrebujeme plne automatizované modré/zelené nasadenie, aby sme sa vyhli prestojom v procese, ktorý tiež potrebuje spracovávať externé HTTP požiadavky a vykonávať SSL offloads. Vyžaduje si to integráciu s vyrovnávačom zaťaženia, ako je ha-proxy. Ďalšou výzvou je poloautomatické škálovanie samotného klastra Kubernetes pri spustení v cloudovom prostredí, napríklad čiastočné škálovanie klastra v noci.
Hoci Kubernetes nemá tieto funkcie hneď po vybalení, poskytuje API, ktoré môžete použiť na riešenie podobných problémov. Nástroje pre automatizované Blue/Green nasadzovanie a škálovanie klastra Kubernetes boli vyvinuté v rámci projektu Cloud RTI, ktorý bol vytvorený na báze open-source.
Tento článok, prepis videa, vám ukáže, ako nastaviť Kubernetes spolu s ďalšími komponentmi s otvoreným zdrojovým kódom na vytvorenie prostredia pripraveného na produkciu, ktoré akceptuje kód z príkazu git bez prestojov vo výrobe.
Takže akonáhle budete mať prístup k svojim aplikáciám z vonkajšieho sveta, môžete začať plne nastavovať automatizáciu, to znamená priviesť ju do štádia, kedy môžete vykonať git commit a uistiť sa, že toto git commit skončí vo výrobe. Prirodzene, pri implementácii týchto krokov, pri implementácii nasadenia, nechceme naraziť na výpadky. Takže akákoľvek automatizácia v Kubernetes začína s API.
Kubernetes nie je nástroj, ktorý možno produktívne používať hneď po vybalení. Samozrejme, môžete to urobiť, použiť kubectl a tak ďalej, ale aj tak je API to najzaujímavejšie a najužitočnejšie na tejto platforme. Použitím rozhrania API ako sady funkcií môžete v Kubernetes pristupovať takmer ku všetkému, čo chcete. Samotný kubectl tiež používa REST API.
Toto je REST, takže na prácu s týmto API môžete použiť akýkoľvek jazyk alebo nástroj, no váš život vám výrazne uľahčia vlastné knižnice. Môj tím napísal 2 takéto knižnice: jednu pre Java/OSGi a jednu pre Go. Ten druhý sa nepoužíva často, no v každom prípade tieto užitočné veci máte k dispozícii. Ide o čiastočne licencovaný open-source projekt. Existuje veľa takýchto knižníc pre rôzne jazyky, takže si môžete vybrať tie, ktoré vám najviac vyhovujú.
Takže skôr, ako začnete s automatizáciou nasadenia, musíte sa uistiť, že proces nebude podliehať žiadnym prestojom. Náš tím napríklad vykonáva produkčné nasadenia uprostred dňa, keď ľudia používajú aplikácie najviac, takže je dôležité vyhnúť sa oneskoreniam v tomto procese. Aby sa predišlo prestojom, používajú sa 2 spôsoby: modro/zelené nasadenie alebo priebežná aktualizácia. V druhom prípade, ak máte spustených 5 replík aplikácie, aktualizujú sa postupne jedna po druhej. Táto metóda funguje skvele, ale nie je vhodná, ak máte počas procesu nasadenia súčasne spustené rôzne verzie aplikácie. V tomto prípade môžete aktualizovať používateľské rozhranie, kým backend beží na starej verzii a aplikácia prestane fungovať. Preto je z programátorského hľadiska práca v takýchto podmienkach dosť náročná.
To je jeden z dôvodov, prečo na automatizáciu nasadenia našich aplikácií uprednostňujeme modré/zelené nasadenie. Pri tejto metóde musíte zabezpečiť, aby bola súčasne aktívna iba jedna verzia aplikácie.
Modro-zelený mechanizmus rozmiestnenia vyzerá takto. Návštevnosť pre naše aplikácie prijímame cez ha-proxy, ktorá ju preposiela na spustené repliky aplikácie rovnakej verzie.
Keď sa vykoná nové nasadenie, použijeme Deployer, ktorý dostane nové komponenty a nasadí novú verziu. Nasadenie novej verzie aplikácie znamená, že sa „vytvorí“ nová sada replík, po ktorej sa tieto repliky novej verzie spustia v samostatnom novom module. Ha-proxy však o nich nič nevie a zatiaľ na nich nesmeruje žiadnu záťaž.
Preto je v prvom rade potrebné vykonať kontrolu výkonu nových verzií kontroly stavu, aby ste sa uistili, že repliky sú pripravené na obsluhu záťaže.
Všetky komponenty nasadenia musia podporovať určitú formu kontroly stavu. Môže ísť o veľmi jednoduchú kontrolu HTTP volania, kedy dostanete kód so stavom 200, alebo o hĺbkovú kontrolu, pri ktorej skontrolujete prepojenie replík s databázou a ďalšími službami, stabilitu pripojení dynamického prostredia. a či sa všetko spustí a funguje správne. Tento proces môže byť dosť zložitý.
Keď systém overí, že všetky aktualizované repliky fungujú, Deployer aktualizuje konfiguráciu a odovzdá správny confd, ktorý prekonfiguruje ha-proxy.
Až potom bude premávka nasmerovaná na modul s replikami novej verzie a starý modul zmizne.
Tento mechanizmus nie je funkciou Kubernetes. Koncept nasadenia Blue/green je tu už pomerne dlho a vždy využíval load balancer. Najprv všetku návštevnosť nasmerujete na starú verziu aplikácie a po aktualizácii ju kompletne prenesiete do novej verzie. Tento princíp sa využíva nielen v Kubernetes.
Teraz vám predstavím nový komponent nasadenia – Deployer, ktorý vykonáva kontroly stavu, prestavuje proxy atď. Toto je koncept, ktorý sa nevzťahuje na vonkajší svet a existuje vo vnútri Kubernetes. Ukážem vám, ako si môžete vytvoriť svoj vlastný koncept Deployer pomocou open-source nástrojov.
Prvá vec, ktorú Deployer urobí, je vytvoriť radič replikácie RC pomocou rozhrania Kubernetes API. Toto API vytvára moduly a služby pre ďalšie nasadenie, to znamená, že vytvára úplne nový klaster pre naše aplikácie. Hneď ako sa RC presvedčí, že repliky sa spustili, vykoná kontrolu ich funkčnosti. Na tento účel Deployer používa príkaz GET /health. Spustí príslušné komponenty kontroly a skontroluje všetky prvky, ktoré podporujú činnosť klastra.
Keď všetky moduly nahlásia svoj stav, Deployer vytvorí nový konfiguračný prvok – distribuované úložisko etcd, ktoré interne používa Kubernetes, vrátane uloženia konfigurácie vyrovnávača zaťaženia. Zapisujeme údaje do etcd a malého nástroja s názvom confd monitors etcd pre nové údaje.
Ak zistí nejaké zmeny v počiatočnej konfigurácii, vygeneruje nový súbor nastavení a prenesie ho do ha-proxy. V tomto prípade sa ha-proxy reštartuje bez straty pripojení a prenesie záťaž na nové služby, ktoré umožňujú fungovanie novej verzie našich aplikácií.
Ako vidíte, napriek množstvu komponentov tu nie je nič zložité. Musíte len venovať väčšiu pozornosť API a atď. Chcem vám povedať o open-source nasadzovači, ktorý sami používame – Amdatu Kubernetes Deployer.
Je to nástroj na organizovanie nasadení Kubernetes a má nasledujúce funkcie:
- Modré/zelené rozmiestnenie;
- nastavenie externého vyrovnávača zaťaženia;
- riadenie deskriptorov nasadenia;
- riadenie skutočného nasadenia;
- kontrola funkčnosti zdravotných kontrol počas nasadenia;
- implementácia premenných prostredia do modulov.
Tento Deployer je postavený na rozhraní Kubernetes API a poskytuje rozhranie REST API na správu rukovätí a nasadení, ako aj rozhranie Websocket API na streamovanie protokolov počas procesu nasadenia.
Vkladá konfiguračné údaje load balancera do etcd, takže nemusíte používať ha-proxy s predpripravenou podporou, ale jednoducho použite svoj vlastný konfiguračný súbor load balanceru. Amdatu Deployer je napísaný v Go, rovnako ako samotný Kubernetes, a je licencovaný Apache.
Predtým, ako som začal používať túto verziu nasadenia, použil som nasledujúci deskriptor nasadenia, ktorý špecifikuje parametre, ktoré potrebujem.
Jedným z dôležitých parametrov tohto kódu je povoliť príznak „useHealthCheck“. Musíme špecifikovať, že počas procesu nasadenia sa musí vykonať kontrola zdravého rozumu. Toto nastavenie je možné zakázať, keď nasadenie používa kontajnery tretích strán, ktoré nie je potrebné overovať. Tento deskriptor tiež označuje počet replík a frontend URL, ktoré ha-proxy potrebuje. Na konci je príznak špecifikácie pod „podspec“, ktorý volá Kubernetes pre informácie o konfigurácii portu, obrázku atď. Toto je pomerne jednoduchý deskriptor JSON.
Ďalším nástrojom, ktorý je súčasťou open-source projektu Amdatu, je Deploymentctl. Má používateľské rozhranie na konfiguráciu nasadení, ukladá históriu nasadenia a obsahuje webhooky pre spätné volania od používateľov a vývojárov tretích strán. Používateľské rozhranie nemôžete používať, pretože samotný Amdatu Deployer je REST API, ale toto rozhranie vám môže výrazne uľahčiť nasadenie bez použitia akéhokoľvek API. Deploymentctl je napísaný v OSGi/Vertx pomocou Angular 2.
Vyššie uvedené teraz predvediem na obrazovke pomocou vopred nahratého záznamu, aby ste nemuseli čakať. Nasadíme jednoduchú aplikáciu Go. Nerobte si starosti, ak ste Go ešte neskúšali, je to veľmi jednoduchá aplikácia, takže by ste na to mali prísť.
Tu vytvárame HTTP server, ktorý odpovedá iba na /health, takže táto aplikácia testuje iba kontrolu stavu a nič iné. Ak kontrola prebehne úspešne, použije sa štruktúra JSON uvedená nižšie. Obsahuje verziu aplikácie, ktorú nasadzovateľ nasadí, správu, ktorú vidíte v hornej časti súboru, a booleovský typ údajov – či naša aplikácia funguje alebo nie.
S posledným riadkom som trochu podvádzal, pretože na začiatok súboru som umiestnil pevnú booleovskú hodnotu, ktorá mi v budúcnosti pomôže nasadiť aj “nezdravú” aplikáciu. Tomuto sa budeme venovať neskôr.
Tak poďme na to. Najprv skontrolujeme prítomnosť akýchkoľvek spustených modulov pomocou príkazu ~ kubectl get pods a na základe absencie odpovede z adresy URL frontendu sa uistíme, že sa momentálne nevykonávajú žiadne nasadenia.
Ďalej na obrazovke vidíte rozhranie Deploymentctl, ktoré som spomínal, v ktorom sa nastavujú parametre nasadenia: priestor názvov, názov aplikácie, verzia nasadenia, počet replík, front-end URL, názov kontajnera, obrázok, limity zdrojov, číslo portu pre kontrolu stavu, atď. . Limity zdrojov sú veľmi dôležité, pretože umožňujú využiť maximálne možné množstvo hardvéru. Tu si môžete pozrieť aj denník Deployment.
Ak teraz zopakujete príkaz ~ kubectl get pods, môžete vidieť, že systém „zamrzne“ na 20 sekúnd, počas ktorých sa prekonfiguruje ha-proxy. Potom sa modul spustí a naša replika sa zobrazí v denníku nasadenia.
Z videa som vystrihol 20 sekundové čakanie a teraz na obrazovke vidíte, že bola nasadená prvá verzia aplikácie. To všetko bolo vykonané iba pomocou používateľského rozhrania.
Teraz skúsme druhú verziu. Aby som to urobil, zmením správu aplikácie z "Ahoj, Kubernetes!" na „Hello, Deployer!“, systém vytvorí tento obrázok a umiestni ho do registra Docker, potom jednoducho znova klikneme na tlačidlo „Deploy“ v okne Deploymentctl. V tomto prípade sa protokol nasadenia automaticky spustí rovnakým spôsobom, ako sa to stalo pri nasadení prvej verzie aplikácie.
Príkaz ~ kubectl get pods ukazuje, že momentálne sú spustené 2 verzie aplikácie, ale frontend ukazuje, že stále používame verziu 1.
Nástroj na vyvažovanie zaťaženia čaká na dokončenie kontroly stavu a až potom presmeruje prevádzku na novú verziu. Po 20 sekundách prepneme do curlingu a vidíme, že teraz máme nasadenú verziu 2 aplikácie a prvá bola vymazaná.
Išlo o nasadenie „zdravej“ aplikácie. Pozrime sa, čo sa stane, ak pre novú verziu aplikácie zmením parameter Healthy z true na false, to znamená, že sa pokúsim nasadiť nezdravú aplikáciu, ktorá neprešla kontrolou stavu. To sa môže stať, ak sa v aplikácii vyskytli chyby v konfigurácii vo fáze vývoja a v tejto forme bola odoslaná do výroby.
Ako vidíte, nasadenie prechádza všetkými vyššie uvedenými krokmi a ~kubectl get pods ukazuje, že oba moduly sú spustené. Na rozdiel od predchádzajúceho nasadenia však protokol zobrazuje stav časového limitu. To znamená, že z dôvodu zlyhania kontroly stavu nie je možné nasadiť novú verziu aplikácie. V dôsledku toho vidíte, že systém sa vrátil k používaniu starej verzie aplikácie a nová verzia bola jednoducho odinštalovaná.
Dobrá vec na tom je, že aj keď do aplikácie prichádza veľké množstvo požiadaviek súčasne, ani si nevšimnú výpadok pri implementácii postupu nasadenia. Ak túto aplikáciu otestujete pomocou rámca Gatling, ktorý jej posiela čo najviac požiadaviek, žiadna z týchto požiadaviek nebude zrušená. To znamená, že naši používatelia si ani nevšimnú aktualizácie verzií v reálnom čase. Ak zlyhá, práca bude pokračovať na starej verzii, ak bude úspešná, používatelia prejdú na novú verziu.
Existuje len jedna vec, ktorá môže zlyhať – ak je kontrola stavu úspešná, ale aplikácia zlyhá hneď, ako je na ňu aplikovaná záťaž, to znamená, že kolaps nastane až po dokončení nasadenia. V takom prípade sa budete musieť manuálne vrátiť k starej verzii. Pozreli sme sa teda na to, ako používať Kubernetes s open-source nástrojmi, ktoré sú na to určené. Proces nasadenia bude oveľa jednoduchší, ak tieto nástroje zabudujete do svojich kanálov na zostavenie/nasadenie. Zároveň na spustenie nasadenia môžete použiť buď používateľské rozhranie, alebo tento proces plne automatizovať použitím napríklad commit to master.
Náš Build Server vytvorí obraz Docker, vloží ho do Docker Hub alebo akéhokoľvek registra, ktorý používate. Docker Hub podporuje webhook, takže môžeme spustiť vzdialené nasadenie cez Deployer spôsobom uvedeným vyššie. Týmto spôsobom môžete plne automatizovať nasadenie vašej aplikácie do potenciálnej produkcie.
Prejdime k ďalšej téme – škálovanie klastra Kubernetes. Všimnite si, že príkaz kubectl je príkaz na zmenu mierky. S väčšou pomocou môžeme ľahko zvýšiť počet replík v našom existujúcom klastri. V praxi však zvyčajne chceme skôr zvýšiť počet uzlov ako podov.
Počas pracovnej doby možno budete musieť zvýšiť a v noci, aby ste znížili náklady na služby Amazonu, možno budete musieť znížiť počet spustených inštancií aplikácií. To neznamená, že škálovanie len počtu modulov bude stačiť, pretože aj keď je jeden z uzlov nečinný, budete za to musieť zaplatiť Amazon. To znamená, že spolu so škálovaním modulov budete musieť škálovať počet použitých strojov.
To môže byť náročné, pretože či už používame Amazon alebo inú cloudovú službu, Kubernetes nevie nič o počte používaných strojov. Chýba mu nástroj, ktorý umožňuje škálovať systém na úrovni uzla.
Takže sa budeme musieť postarať o uzly aj struky. Spustenie nových uzlov môžeme jednoducho škálovať pomocou AWS API a strojov skupiny Scaling na konfiguráciu počtu pracovných uzlov Kubernetes. Na registráciu uzlov v klastri Kubernetes môžete použiť aj cloud-init alebo podobný skript.
Nový počítač sa spustí v skupine Scaling, inicializuje sa ako uzol, zaregistruje sa v hlavnom registri a začne pracovať. Potom môžete zvýšiť počet replík na použitie vo výsledných uzloch. Zmenšenie si vyžaduje viac úsilia, pretože sa musíte uistiť, že takýto krok nevedie k zničeniu už spustených aplikácií po vypnutí „zbytočných“ strojov. Aby ste predišli takémuto scenáru, musíte nastaviť uzly do stavu „neplánovateľné“. To znamená, že predvolený plánovač bude tieto uzly pri plánovaní modulov DaemonSet ignorovať. Plánovač z týchto serverov nič nevymaže, ale ani tam nespustí žiadne nové kontajnery. Ďalším krokom je vyradenie odtokového uzla, teda premiestnenie bežiacich modulov z neho do iného stroja, prípadne iných uzlov, ktoré na to majú dostatočnú kapacitu. Keď sa ubezpečíte, že na týchto uzloch už nie sú žiadne kontajnery, môžete ich z Kubernetes odstrániť. Potom pre Kubernetes jednoducho prestanú existovať. Ďalej musíte použiť AWS API na deaktiváciu nepotrebných uzlov alebo strojov.
Môžete použiť Amdatu Scalerd, ďalší open-source nástroj na škálovanie podobný AWS API. Poskytuje CLI na pridávanie alebo odstraňovanie uzlov v klastri. Jeho zaujímavou funkciou je možnosť konfigurácie plánovača pomocou nasledujúceho súboru json.
Zobrazený kód znižuje kapacitu klastra na polovicu počas nočného obdobia. Konfiguruje počet dostupných replík a požadovanú kapacitu klastra Amazon. Používanie tohto plánovača automaticky zníži počet uzlov v noci a zvýši ich ráno, čím ušetrí náklady na používanie uzlov z cloudovej služby, ako je Amazon. Táto funkcia nie je zabudovaná do Kubernetes, ale používanie Scalerd vám umožní škálovať túto platformu tak, ako chcete.
Chcel by som zdôrazniť, že veľa ľudí mi hovorí: „To je všetko v poriadku, ale čo moja databáza, ktorá je zvyčajne statická?“ Ako môžete spustiť niečo také v dynamickom prostredí, ako je Kubernetes? Podľa môjho názoru by ste to nemali robiť, nemali by ste sa pokúšať spustiť dátový sklad v Kubernetes. To je síce technicky možné a na internete sú na túto tému návody, ale poriadne vám to skomplikuje život.
Áno, v Kubernetes existuje koncept trvalých obchodov a môžete sa pokúsiť spustiť dátové úložiská ako Mongo alebo MySQL, ale je to dosť náročná úloha. Je to spôsobené tým, že dátové sklady plne nepodporujú interakciu s dynamickým prostredím. Väčšina databáz vyžaduje značnú konfiguráciu vrátane manuálnej konfigurácie klastra, nepáči sa im automatické škálovanie a iné podobné veci.
Preto by ste si nemali komplikovať život pokusom o spustenie dátového skladu v Kubernetes. Usporiadajte ich prácu tradičným spôsobom pomocou známych služieb a jednoducho poskytnite Kubernetes možnosť ich používať.
Na záver témy by som vám rád predstavil platformu Cloud RTI založenú na Kubernetes, na ktorej pracuje môj tím. Poskytuje centralizované protokolovanie, monitorovanie aplikácií a klastrov a mnoho ďalších užitočných funkcií, ktoré sa vám budú hodiť. Na zobrazenie monitorovania využíva rôzne open-source nástroje, ako je Grafana.
Bola tu otázka, prečo používať ha-proxy load balancer s Kubernetes. Dobrá otázka, pretože v súčasnosti existujú 2 úrovne vyrovnávania záťaže. Služby Kubernetes sa stále nachádzajú na virtuálnych IP adresách. Nemôžete ich použiť pre porty na externých hostiteľských počítačoch, pretože ak Amazon preťaží svojho cloudového hostiteľa, adresa sa zmení. To je dôvod, prečo umiestňujeme ha-proxy pred služby – aby sme vytvorili statickejšiu štruktúru pre prevádzku, aby mohla bezproblémovo komunikovať s Kubernetes.
Ďalšou dobrou otázkou je, ako sa môžete postarať o zmeny schémy databázy pri nasadzovaní modrej/zelenej? Faktom je, že bez ohľadu na použitie Kubernetes je zmena databázovej schémy náročná úloha. Musíte sa uistiť, že stará a nová schéma sú kompatibilné, potom môžete aktualizovať databázu a potom aktualizovať samotné aplikácie. Databázu môžete vymeniť za chodu a potom aktualizovať aplikácie. Viem o ľuďoch, ktorí spustili úplne nový databázový klaster s novou schémou. Toto je možnosť, ak máte databázu bez schém ako Mongo, ale aj tak to nie je ľahká úloha. Ak nemáte ďalšie otázky, ďakujeme za pozornosť!
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com