Kubernetes je skvelý nástroj na spúšťanie kontajnerov Docker v klastrovom produkčnom prostredí. Existujú však úlohy, ktoré Kubernetes nie je schopný vyriešiť. Pri častom nasadení v pracovnom prostredí potrebujeme plne automatizované Blue/Green deployment, aby sme sa vyhli prestojom v tomto procese, pričom je tiež potrebné spracovávať externé HTTP požiadavky a vykonávať SSL odovzdanie. To si vyžaduje integráciu s vyrovnávačom záťaže, ako je ha-proxy. Ďalšou úlohou je poloaautomatické škálovanie samotného klastru Kubernetes pri práci v cloudovom prostredí, napríklad čiastočné zníženie rozsahu klastru v nočných hodinách.
Hoci Kubernetes tieto funkcie nemá priamo „z krabice“, poskytuje API, ktoré môžete využiť na riešenie podobných úloh. Nástroje na automatizované Blue/Green nasadenie a škálovanie klastru Kubernetes boli vyvinuté v rámci projektu Cloud RTI, ktorý bol vytvorený na základe open-source.
V tomto článku, prepisovaní videa, sa hovorí o tom, ako nastaviť Kubernetes spolu s ďalšími komponentmi s otvoreným zdrojovým kódom na získanie pripraveného na produkciu prostredia, ktoré bez prestojov v produkcii príjma kód z git commit zmien.
Takže po tom, ako ste získali prístup k svojím aplikáciám z vonkajšieho sveta, môžete prejsť na plné nastavenie automatizácie, teda krok, na ktorom môžete vykonať git commit a uistiť sa, že tento git commit končí v produkcii. Samozrejme, že pri realizácii týchto krokov, pri nasadení, sa nechceme stretávať s prestojmi. Takže akákoľvek automatizácia v Kubernetes začína s API.
Kubernetes nie je nástroj, ktorý môžete produktívne používať „priamo z krabice“. Samozrejme, môžete to tak robiť, používať kubectl a podobne, ale API je stále najzaujímavejšou a najužitočnejšou vecou tejto platformy. Použitím API ako sady funkcií, môžete mať prístup prakticky k čomukoľvek, čo chcete robiť v Kubernetes. Samotný kubectl tiež používa REST API.
Toto je REST, takže môžete na prácu s týmto API použiť akékoľvek jazyky a nástroje, ale vaše životy si značne uľahčia používateľské knižnice. Môj tím napísal dve takéto knižnice: jednu pre Java / OSGi a jednu pre Go. Druhá sa nepoužíva často, ale v každom prípade máte k dispozícii tieto užitočné nástroje. Predstavujú čiastočne licencovaný open-source projekt. Existuje množstvo takýchto knižníc pre rôzne jazyky, takže si môžete vybrať tie najvhodnejšie.
Takže skôr než začnete automatizovať nasadzovanie, je potrebné zabezpečiť, že tento proces nebude podliehať žiadnym výpadkom. Napríklad náš tím vykonáva produkčné nasadzovanie uprostred dňa, keď ľudia maximálne využívajú aplikácie, takže je veľmi dôležité vyhnúť sa oneskoreniam v tomto procese. Na to, aby sa predišlo výpadkom, sa používajú dva spôsoby: blue/green nasadzovanie alebo skĺzavá aktualizácia (rolling update). V druhom prípade, ak máte v prevádzke 5 replik aplikácie, sú postupne aktualizované jedna po druhej. Tento spôsob skvele funguje, ale nie je vhodný, ak sa počas nasadzovania súčasne používajú rôzne verzie aplikácie. V takom prípade môžete aktualizovať používateľské rozhranie, zatiaľ čo backend bude pracovať so starou verziou a prevádzka aplikácie sa zastaví. Preto z pohľadu programovania je práca v takých podmienkach dosť obtiažna.
To je jeden z dôvodov, prečo preferujeme použiť blue/green nasadzovanie na automatizáciu nasadzovania našich aplikácií. Pri takomto prístupe musíte zabezpečiť, že v danom okamihu je aktívna iba jedna verzia aplikácie.
Mechanizmus blue/green nasadzovania vyzerá nasledovne. Získavame traffic pre naše aplikácie cez ha-proxy, ktorý ho smeruje na spustené repliky aplikácie rovnakej verzie.
Keď sa uskutoční nové nasadenie, používame Deployer, ktorému sú poskytnuté nové komponenty a on vykonáva nasadenie novej verzie. Nasadenie novej verzie aplikácie znamená, že sa „spustí“ nový súbor replik, po ktorých sa tieto repliky novej verzie spúšťajú v samostatnom, novom pode. Avšak ha-proxy o nich nevie a zatiaľ im nepriraďuje žiadnu pracovnú záťaž.
Preto je v prvom rade potrebné vykonať kontrolu funkčnosti nových verzií health checkingu, aby sa zabezpečilo, že repliky sú pripravené obsluhovať záťaž.
Všetky nasadzovacie komponenty by mali podporovať akúkoľvek formu health checku. Môže to byť úplne jednoduchá kontrola HTTP volaním, pri ktorej dostanete kód so stavom 200, alebo hlbšia kontrola, pri ktorej overujete konektivitu replik s databázou a inými službami, stabilitu spojení dynamického prostredia, či sa všetko spúšťa a funguje správne. Tento proces môže byť pomerne zložitý.
Akonáhle systém overí funkčnosť všetkých aktualizovaných replík, Deployer aktualizuje konfiguráciu a odovzdá správny confd, ktorý prekonfiguruje ha-proxy.
Až potom bude traffic smerovaný do podu s replikami novej verzie a starý pod zmizne.
Tento mechanizmus nie je vlastnosťou Kubernetes. Koncept Blue/green deployment existuje už pomerne dlhú dobu a vždy využíval vyvažovač zaťaženia. Najprv smerujete celý traffic na starú verziu aplikácie a po aktualizácii ho plne prepnite na novú verziu. Tento princíp sa používa nielen v Kubernetes.
Teraz vám predstavím nový komponent nasadenia – Deployer, ktorý vykonáva kontrolu funkčnosti, rekonfiguruje proxy a tak ďalej. Je to koncept, ktorý sa netýka vonkajšieho sveta a existuje vo vnútri Kubernetes. Ukážem, ako si môžete vytvoriť vlastný koncept Deployer pomocou open-source nástrojov.
Takže prvé, čo Deployer robí, je vytvorenie repikačného kontroléra RC pomocou API Kubernetes. Toto API vytvára pod a služby na ďalšie nasadenie, teda vytvára úplne nový klaster pre naše aplikácie. Hneď ako RC zabezpečí, že repliky sa spustili, vykoná kontrolu ich funkčnosti Health check. Na to Deployer používa príkaz GET /health. Ten spúšťa príslušné komponenty kontroly a overuje všetky prvky, zabezpečujúce chod klasteru.
Akonáhle všetky pody oznámia svoje „zdravie“, Deployer vytvorí nový prvok konfigurácie – distribuované úložisko etcd, ktoré sa používa v rámci Kubernetes, vrátane ukladania konfigurácie záťažového vyvažovača. Ukladáme údaje do etcd a malý nástroj confd sleduje etcd na prítomnosť nových údajov.
Ak zistil nejaké zmeny v pôvodnej konfigurácii, vygeneruje nový konfiguračný súbor a odovzdá ho ha-proxy. V tomto prípade sa ha-proxy reštartuje bez straty akýchkoľvek pripojení a adresuje záťaž novým službám, ktoré zabezpečujú chod novej verzie našich aplikácií.
Ako vidíte, napriek množstvu komponentov tu nie je nič zložité. Musíte sa len viac venovať API a etcd. Chcem vám povedať o open-source nasadzovači, ktorý používame – Amdatu Kubernetes Deployer.
Je to nástroj na orchestráciu nasadení Kubernetes s týmito funkciami:
- nasadenie Blue/Green deployment;
- nastavenie externého záťažového vyvažovača;
- správa nasadzovacích deskriptorov;
- správa skutočného nasadenia;
- kontrola funkčnosti Health checks počas nasadenia;
- vnútorne zavádzanie premenných prostredia do podov.
Tento Deployer je postavený na vrchole API Kubernetes a poskytuje REST API na správu deskriptorov a nasadení, ako aj Websocket API na streamovanie logov počas nasadenia.
Ukladá údaje konfigurácie záťažového vyvažovača do etcd, takže môžete nepoužívať ha-proxy s podporou „priamo z krabice“, ale jednoducho použiť svoj vlastný konfiguračný súbor záťažového vyvažovača. Amdatu Deployer je napísaný v Go, rovnako ako samotný Kubernetes, a je licencovaný pod licenciu Apache.
Pred začiatkom používania tejto verzie deployera som použil nasledujúci descriptor nasadenia, v ktorom sú uvedené potrebné parametre.
Jedným z dôležitých parametrov tohto kódu je povolenie príznaku "useHealthCheck". Musíme uviesť, že počas nasadenia je potrebné vykonávať kontrolu dostupnosti. Tento parameter môže byť vypnutý, keď sa pri nasadení používajú kontajnery tretích strán, ktoré nie je potrebné kontrolovať. V tomto descriptoore je tiež uvedený počet replik a URL frontendu, ktorý potrebuje ha-proxy. Na konci je uvedený príznak špecifikácie podu "podspec", ktorý sa obracia na Kubernetes pre informácie o nastavení portov, obraze atď. Ide o pomerne jednoduchý descriptor vo formáte JSON.
Ďalším nástrojom, ktorý je súčasťou open-source projektu Amdatu, je Deploymentctl. Má používateľské rozhranie UI na konfiguráciu nasadenia, uchováva históriu nasadenia a obsahuje webhooks pre spätnej volania od používateľov a vývojárov tretích strán. Môžete nepoužívať UI, pretože samotný Amdatu Deployer je REST API, ale toto rozhranie môže výrazne uľahčiť vaše nasadenie bez potreby zapojiť akékoľvek API. Deploymentctl je napísaný v OSGi/Vertx s použitím Angular 2.
Teraz ukážem vyššie uvedené na obrazovke pomocou predtým urobeného záznamu, takže nemusíte čakať. Budeme nasadzovať jednoducho aplikáciu v Go. Nebojte sa, ak ste sa predtým s Go nestretli, je to veľmi jednoduchá aplikácia, takže vám všetko bude jasné.
Tu vytvárame HTTP server, ktorý reaguje iba na /health, takže táto aplikácia iba kontroluje dostupnosť health check a nič viac. Ak kontrola prebehne úspešne, aktivuje sa zobrazená nižšie JSON štruktúra. Obsahuje verziu aplikácie, ktorá bude nasadená deployerom, message, ktorú vidíte na vrchnej časti súboru, a logický dátový typ boolean — je naša aplikácia dostupná alebo nie.
S posledným riadkom som trochu podviedol, pretože som na vrchu súboru umiestnil pevnú hodnotu boolean, ktorá mi neskôr pomôže nasadiť aj "nezdravú" aplikáciu. Neskôr sa s tým vysporiadame.
A takže, poďme na to. Najprv skontrolujeme, či sú spustené nejaké pod. Pomocou príkazu ~ kubectl get pods a pri absencii odpovede URL frontendovej oblasti sa uistíme, že v súčasnosti nedochádza k žiadnym nasadeniam.
Ďalej na obrazovke vidíte rozhranie Deploymentctl, ktoré som spomínal, kde sa nastavia parametre nasadenia: priestor názvov, názov aplikácie, verzia nasadenia, počet replik, frontend-URL, názov kontajnera, obraz, limity zdrojov, číslo portu pre kontrolu zdravia a pod. Limity zdrojov sú veľmi dôležité, pretože umožňujú využiť maximálne dostupné množstvo „hardvéru“. Tu si môžete tiež pozrieť protokol nasadenia Deployment log.
Ak teraz znova spustíte príkaz ~ kubectl get pods, uvidíte, že systém "zastavuje" na 20 sekúnd, počas ktorých dochádza k rekonfigurácii ha-proxy. Po tomto sa pod spustí a našu replikáciu je možné vidieť v protokole nasadenia.
Vystrihol som z videa 20-sekundové čakanie a teraz vidíte na obrazovke, že prvá verzia aplikácie je nasadená. To všetko bolo urobené len pomocou UI.
Teraz skúsme druhú verziu. Na to mením správu aplikácie z „Hello, Kubernetes!“ na „Hello, Deployer!“, systém vytvorí tento obraz a umiestni ho do registra Docker, po čom jednoducho znova stlačíme tlačidlo „Deploy“ v okne Deploymentctl. Pri tom sa automaticky spustí protokol nasadenia presne tak, ako sa to deje pri nasadení prvej verzie aplikácie.
Príkaz ~ kubectl get pods ukazuje, že momentálne sú spustené 2 verzie aplikácie, avšak frontend ukazuje, že stále beží verzia 1.
Vyvažovač zaťaženia čaká, kým prebehne kontrola zdravia, po ktorej presmeruje prevádzku na novú verziu. Po 20 s prechádzame na curl a vidíme, že teraz máme nasadenú 2. verziu aplikácie, zatiaľ čo prvá je odstránená.
Toto bolo nasadenie „zdravého“ — healthy — aplikácie. Pozrime sa, čo sa stane, ak pre novú verziu aplikácie zmením hodnotu parametra Healthy z true na false, teda ak sa pokúsim nasadiť nezdravú aplikáciu, ktorá neprešla kontrolou funkčnosti. To sa môže stať, ak v štádiu vývoja boli v aplikácii vykonané nejaké chyby konfigurácie a bola odoslaná do produkcie v takomto stave.
Ako vidíte, nasadenie prechádza všetkými vyššie uvedenými krokmi a ~ kubectl get pods ukazuje, že bežia oba pode. V porovnaní s predchádzajúcim nasadením však log zobrazuje stav timeout. To znamená, že kvôli tomu, že kontrola health check neprešla, nová verzia aplikácie nemôže byť nasadená. Výsledkom je, že systém sa vrátil k používaniu starej verzie aplikácie a nová verzia bola jednoducho odstránená.
Dobré na tom je, že aj keď máte obrovské množstvo súbežných požiadaviek smerujúcich do aplikácie, ani si nevšimnú prestoj počas implementácie procedúry nasadenia. Ak túto aplikáciu otestujete pomocou frameworku Gatling, ktorý jej posiela maximálne možné množstvo požiadaviek, žiadna z týchto požiadaviek nebude odmietnutá. To znamená, že naši používatelia si ani nevšimnú aktualizácie verzií v reálnom čase. Ak sa ukončí neúspešne, práca bude pokračovať na starej verzii, ak uspeje - používatelia prejdú na novú verziu.
Existuje len jedna vec, ktorá môže viesť k neúspechu - ak kontrola health check prešla úspešne, ale aplikácia zlyhá, akonáhle dostane pracovnú záťaž, to znamená, že kolaps nastane až po dokončení nasadenia. V takom prípade sa budete musieť ručne vrátiť k starej verzii. Takže sme sa pozreli na to, ako používať Kubernetes s ním určenými open-source nástrojmi. Procedúra nasadenia bude prebiehať oveľa jednoduchšie, ak tieto nástroje integrujete do pipeline pre vytváranie/nasadenie Build/Deploy. Na spustenie nasadenia môžete použiť ako používateľské rozhranie, tak úplne automatizovať tento proces, napríklad pomocou commit do master.
Náš build server vytvorí Docker obraz, vloží ho do Docker Hub alebo iného registry, ktorý používate. Docker Hub podporuje webhook, takže môžeme spustiť vzdialené nasadenie cez Deployer uvedeným spôsobom. Týmto spôsobom môžeme úplne automatizovať nasadenie aplikácie do potenciálneho produkčného prostredia.
Prejdime k preskúmaniu ďalšej témy – škálovanie klastra Kubernetes. Chcem upozorniť, že príkaz kubectl je príkaz na škálovanie. S jeho pomocou môžeme ľahko zvýšiť počet replik v našom klastri. V praxi však zvyčajne chceme zvyšovať počet nie podov, ale nódov.
Počas pracovného času môžete potrebovať zvýšenie, zatiaľ čo v noci, aby ste znížili náklady na služby Amazon, je potrebné znížiť počet spustených inštancií aplikácie. Neznamená to však, že bude stačiť škálovať iba počet podov, pretože aj keď jeden z nódov nebude nič robiť, stále zaň budete musieť platiť Amazonu. To znamená, že vedľa škálovania podov budete musieť škálovať aj počet používaných strojov.
To môže spôsobiť komplikácie, pretože nezávisle od toho, či používame Amazon alebo iný cloudový servis, Kubernetes nič nevie o počte používaných strojov. Chýba mu nástroj, ktorý by umožnil škálovať systém na úrovni nódov.
A preto sa musíme postarať o nody aj o pody. Môžeme ľahko škálovať zavádzanie nových nódov pomocou AWS API a strojov v skupine škálovania (Scaling group) na nastavenie počtu pracovných uzlov Kubernetes. Čo sa týka registrácie nódov v klastri Kubernetes, môžeme tiež použiť cloud-init alebo podobný skript.
Nový stroj sa spúšťa v skupine Scaling, inicializuje sa ako uzol, registruje sa v hlavnom registri a začína pracovať. Po tomto je možné zvýšiť počet replik na novovytvorených uzloch. Zmenšenie počtu uzlov si vyžaduje väčšie úsilie, pretože je potrebné zabezpečiť, aby tento krok nespôsobil zánik už fungujúcich aplikácií po odpojení "zbytočných" strojov. Na zabránenie takémuto scenáru je potrebné previesť uzly do stavu "unschedulable". To znamená, že plánovač pri plánovaní podov DaemonSet bude tieto uzly ignorovať. Plánovač nič neodstráni z týchto serverov, ale ani nespustí nové kontajnery. Nasledujúci krok je odpojenie uzla drain node, to znamená presun pracovných podov na iný stroj alebo iné uzly, ktoré majú na to dostatočnú kapacitu. Keď sa uistí, že na týchto uzloch už nie sú žiadne kontajnery, môžu byť odstránené z Kubernetes. Potom pre Kubernetes prestanú jednoducho existovať. Ďalej je potrebné použiť AWS API na odpojenie nepotrebných uzlov alebo strojov.
Môžete použiť Amdatu Scalerd — ďalší open-source nástroj pre škálovanie, podobný AWS API. Poskytuje CLI na pridávanie alebo odstraňovanie uzlov v klastri. Jeho zaujímavou funkciou je možnosť nastaviť plánovač pomocou nasledujúceho json súboru.
Zobrazený kód znižuje kapacitu klastra na polovicu v nočných hodinách. Nastavené je ako množstvo existujúcich replik, tak aj požadovaná kapacita klastra Amazon. Použitie tohto plánovača automaticky zníži počet uzlov v noci a zvýši ich ráno, čo vám umožní ušetriť náklady na používanie uzlov takého cloudového servisu, ako je Amazon. Táto funkcia nie je integrovaná v Kubernetes, ale použitie Scalerd vám umožní škálovať túto platformu podľa potreby.
Chcem upozorniť na to, že mi mnohí ľudia hovoria: „To všetko je fajn, ale čo s mojou databázou, ktorá obvykle zostáva v statickom stave?“ Ako je možné spustiť niečo také v tak dynamickom prostredí, ako je Kubernetes? Podľa môjho názoru by ste to nemali robiť, nemali by ste sa snažiť organizovať prácu dátového úložiska v Kubernetes. Technicky je to možné a na internete existujú návody, ako na to, avšak to by vám života značne skomplikovalo.
Áno, v Kubernetes existuje pojem trvalých úložísk a môžete sa pokúsiť spúšťať takéto databázy ako Mongo alebo MySQL, ale je to dosť prácne. S tým súvisí fakt, že databázy nepodporujú plne interakciu s dynamickým prostredím. Väčšina databáz vyžaduje značnú konfiguráciu, vrátane ručnej konfigurácie klastru, nemajú radi automatické škálovanie a podobné veci.
Preto si neuľahčujte život pokusmi o spustenie databázy v Kubernetes. Organizujte ich prácu tradičným spôsobom s využitím známych služieb a jednoducho poskytnite Kubernetes možnosť nimi disponovať.
Na záver témy vás chcem oboznámiť s platformou Cloud RTI na báze Kubernetes, na ktorej pracuje môj tím. Zabezpečuje centralizované vedenie logov, monitoring aplikácií a klastrov a disponuje množstvom ďalších užitočných funkcií, ktoré sa vám zídu. Používajú sa v nej rôzne open-source nástroje, ako napríklad Grafana na zobrazenie monitoringu.
Objavil sa otázka, prečo používať s Kubernetes vyrovnávač záťaže ha-proxy. Dobrý dotaz, pretože v súčasnosti existujú 2 úrovne vyrovnávania záťaže. Služby Kubernetes stále fungujú na virtuálnych IP adresách. Nemôžete ich použiť pre porty vonkajších hostiteľských strojov, pretože ak Amazon preťaží svoj cloudový hostiteľ, adresa sa zmení. Preto umiestňujeme pred služby ha-proxy — aby sme vytvorili statickejšiu štruktúru pre bezproblémovú interakciu provozu s Kubernetes.
Ešte jedna dobrá otázka – ako sa dá postarať o zmenu schémy databázy pri realizácii blue/green nasadenia? Faktom je, že bez ohľadu na použitie Kubernetes, zmena schémy databázy je zložitá úloha. Musíte zabezpečiť kompatibilitu starej a novej schémy, až potom môžete aktualizovať databázu a následne aj aplikácie. Môžete vykonať „horúcu výmenu“ hot swapping databázy a potom aktualizovať aplikácie. Poznám ľudí, ktorí nahradili úplne nový klaster databázy s novou schémou, to je možnosť, ak máte schému bez schémy typu Mongo, ale v každom prípade to nie je jednoduchá úloha. Ak sú ďalšie otázky, ďakujem za pozornosť!
Trochu reklamy 🙂
Ďakujeme, že ostávate s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavých materiálov? Podporte nás, vytvorením objednávky alebo odporúčaním známym, , unikátny ekvivalent entry-level serverov, ktorý sme pre vás vytvorili: (k dispozícii varianty s RAID1 a RAID10, až 24 jadier a až 40GB DDR4).
Dell R730xd je dvakrát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len u nás v Holandsku! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolárov! Prečítajte si o tom
Zdroj: habr.com
