Sveiki, mano vardas Dmitrijus Krasnovas. Daugiau nei penkerius metus administruoju Kubernetes grupes ir kuriu sudėtingas mikro paslaugų architektūras. Šių metų pradžioje pradėjome teikti Kubernetes klasterių valdymo paslaugą Containerum pagrindu. Pasinaudodamas proga, papasakosiu, kas yra „Kubernetes“ ir kuo integracija su pardavėju skiriasi nuo atvirojo kodo.
Pirmiausia, kas yra . Tai sistema, skirta daugelio kompiuterių konteineriams valdyti. Beje, iš graikų kalbos jis išverstas kaip „pilotas“ arba „vairininkas“. Iš pradžių sukūrė „Google“, o vėliau kaip technologinį indėlį paaukojo „Cloud Native Computing Foundation“ – tarptautinei ne pelno organizacijai, vienijančiai pirmaujančius pasaulyje kūrėjus, galutinius vartotojus ir konteinerių technologijų tiekėjus.
Tvarkykite daugybę konteinerių
Dabar išsiaiškinkime, kokie tai konteineriai. Tai programa su visa aplinka – daugiausia bibliotekomis, nuo kurių priklauso programa. Visa tai supakuota į archyvus ir pateikiama atvaizdo pavidalu, kurį galima paleisti nepriklausomai nuo operacinės sistemos, išbandyti ir kt. Tačiau yra problema – labai sunku tvarkyti konteinerius daugelyje kompiuterių. Štai kodėl buvo sukurtas „Kubernetes“.
Konteinerio vaizdas reiškia programą ir jos priklausomybes. Programa, jos priklausomybės ir OS failų sistemos vaizdas yra skirtingose vaizdo dalyse, vadinamuosiuose sluoksniuose. Sluoksniai gali būti pakartotinai naudojami skirtingiems konteineriams. Pavyzdžiui, visos įmonės programos gali naudoti pagrindinį Ubuntu sluoksnį. Paleidžiant konteinerius, pagrindiniame kompiuteryje nereikia saugoti kelių vieno pagrindinio sluoksnio kopijų. Tai leidžia optimizuoti vaizdų saugojimą ir pristatymą.
Kai norime paleisti programą iš konteinerio, reikiami sluoksniai uždedami vienas ant kito ir suformuojama perdangos failų sistema. Ant viršaus uždedamas įrašymo sluoksnis, kuris nuimamas, kai konteineris sustoja. Tai užtikrina, kad kai konteineris paleistas, programa visada turės tą pačią aplinką, kurios negalima pakeisti. Tai garantuoja aplinkos atkūrimą įvairiose pagrindinio kompiuterio OS. Nesvarbu, ar tai Ubuntu, ar CentOS, aplinka visada bus tokia pati. Be to, konteineris yra izoliuotas nuo pagrindinio kompiuterio naudojant „Linux“ branduolyje įmontuotus mechanizmus. Konteinerio programos nemato failų, pagrindinio kompiuterio procesų ir gretimų konteinerių. Šis programų atskyrimas nuo pagrindinės OS suteikia papildomą saugumo lygį.
Yra daug įrankių, leidžiančių valdyti pagrindinio kompiuterio konteinerius. Populiariausias iš jų yra Docker. Tai leidžia užtikrinti visą konteinerių gyvavimo ciklą. Tačiau jis veikia tik viename pagrindiniame kompiuteryje. Jei jums reikia tvarkyti konteinerius keliuose pagrindiniuose kompiuteriuose, „Docker“ gali paversti inžinierių gyvenimą pragaru. Štai kodėl buvo sukurtas „Kubernetes“.
„Kubernetes“ paklausa kyla būtent dėl galimybės valdyti konteinerių grupes keliuose pagrindiniuose kompiuteriuose kaip tam tikrą vienetą. Sistemos populiarumas suteikia galimybę kurti „DevOps“ arba „Development Operations“, kuriose „Kubernetes“ yra naudojama paleisti šio „DevOps“ procesus.
1 pav. Scheminis Kubernetes veikimo pavaizdavimas
Pilna automatika
„DevOps“ iš esmės yra kūrimo proceso automatizavimas. Grubiai tariant, kūrėjai rašo kodą, kuris įkeliamas į saugyklą. Tada šį kodą galima automatiškai surinkti į konteinerį su visomis bibliotekomis, išbandyti ir „išleisti“ į kitą etapą – „Staging“, o tada iš karto į gamybą.
Kartu su „Kubernetes“ „DevOps“ leidžia automatizuoti šį procesą, kad jis vyktų praktiškai nedalyvaujant patiems kūrėjams. Dėl šios priežasties kūrimas yra žymiai greitesnis, nes kūrėjas neturi to daryti savo kompiuteryje - jis tiesiog parašo kodo fragmentą, nustumia kodą į saugyklą, po kurio paleidžiamas dujotiekis, kuris gali apimti procesą. kūrimo, testavimo ir diegimo. Ir tai atsitinka su kiekvienu įsipareigojimu, todėl bandymai vyksta nuolat.
Tuo pačiu konteinerio naudojimas leidžia būti tikriems, kad visa šios programos aplinka bus išleista į gamybą būtent tokia forma, kokia buvo išbandyta. Tai reiškia, kad nebus problemų, tokių kaip „vienos versijos buvo bandomos, kitos - gamyboje, bet kai mes jas įdiegėme, viskas nukrito“. O kadangi šiandien turime tendenciją link mikroservisų architektūros, kai vietoj vienos didžiulės aplikacijos yra šimtai mažų, norint jas administruoti rankiniu būdu, reikės didžiulio darbuotojų kolektyvo. Štai kodėl mes naudojame Kubernetes.
Pliusai, pliusai, pliusai
Jei kalbėsime apie Kubernetes, kaip platformos, pranašumus, tai turi reikšmingų pranašumų mikro paslaugų architektūros valdymo požiūriu.
- Kelių kopijų tvarkymas. Svarbiausias dalykas yra konteinerių valdymas keliuose pagrindiniuose kompiuteriuose. Dar svarbiau, tvarkykite kelias programų kopijas konteineriuose kaip vieną objektą. Dėl šios priežasties inžinieriams nereikia rūpintis kiekvienu atskiru konteineriu. Jei vienas iš konteinerių sugenda, Kubernetes tai matys ir vėl paleis.
- Klasterio tinklas. Kubernetes taip pat turi vadinamąjį klasterių tinklą su savo adresų erdve. Dėl to kiekviena anga turi savo adresą. Subpod suprantamas kaip minimalus struktūrinis grupės vienetas, kuriame konteineriai yra tiesiogiai paleidžiami. Be to, Kubernetes turi funkcionalumą, kuris sujungia apkrovos balansavimo priemonę ir paslaugų aptikimą. Tai leidžia jums atsikratyti rankinio IP adresų valdymo ir perduoti šią užduotį Kubernetes. O automatiniai sveikatos patikrinimai padės aptikti problemas ir nukreipti srautą į veikiančius blokus.
- Konfigūracijos valdymas. Tvarkant daug programų, tampa sunku valdyti programų konfigūraciją. Šiuo tikslu Kubernetes turi specialius ConfigMap išteklius. Jie leidžia centralizuotai saugoti konfigūracijas ir atskleisti jas grupes, kai paleisite programas. Šis mechanizmas leidžia garantuoti konfigūracijos nuoseklumą mažiausiai dešimtyje ar šimte programų kopijų.
- Nuolatiniai tomai. Konteineriai iš prigimties yra nekintami, o sustabdžius konteinerį visi į failų sistemą įrašyti duomenys bus sunaikinti. Tačiau kai kurios programos saugo duomenis tiesiai diske. Norėdami išspręsti šią problemą, Kubernetes turi disko saugyklos valdymo funkciją – nuolatinius tomus. Šis mechanizmas naudoja išorinę duomenų saugyklą ir gali perkelti nuolatinę saugyklą, bloką ar failą į konteinerius. Šis sprendimas leidžia saugoti duomenis atskirai nuo darbuotojų, o tai išsaugo juos, jei tie patys darbuotojai sugenda.
- Apkrovos balansavimo priemonė. Nors „Kubernetes“ valdome abstrakčius objektus, tokius kaip „Deployment“, „StatefulSet“ ir kt., galiausiai konteineriai veikia įprastose virtualiose mašinose arba aparatinės įrangos serveriuose. Jie nėra tobuli ir gali bet kada nukristi. „Kubernetes“ tai matys ir nukreips vidinį srautą į kitas kopijas. Bet ką daryti su eismu, kuris ateina iš išorės? Jei tiesiog nukreipiate srautą į vieną iš darbuotojų, jei jis sugenda, paslauga taps nepasiekiama. Norėdami išspręsti šią problemą, „Kubernetes“ turi tokias paslaugas kaip „Load Balancer“. Jie skirti automatiškai konfigūruoti išorinį debesų balansavimo įrenginį visiems klasterio darbuotojams. Šis išorinis balansuotojas nukreipia išorinį srautą į darbuotojus ir pats stebi jų būseną. Jei vienas ar keli darbuotojai tampa nepasiekiami, srautas nukreipiamas į kitus. Tai leidžia jums sukurti labai prieinamas paslaugas naudojant „Kubernetes“.
„Kubernetes“ geriausiai veikia, kai veikia mikro paslaugų architektūra. Galima sistemą įdiegti į klasikinę architektūrą, bet tai beprasmiška. Jei programa negali veikti keliose kopijose, koks skirtumas – „Kubernetes“ ar ne?
Atvirojo kodo Kubernetes
Atvirojo kodo Kubernetes yra puikus dalykas: aš jį įdiegiau ir jis veikia. Galite įdiegti jį savo aparatinės įrangos serveriuose, savo infrastruktūroje, įdiegti pagrindinius ir darbuotojus, kuriuose veiks visos programos. Ir, svarbiausia, visa tai nemokama. Tačiau yra niuansų.
- Pirmasis yra administratorių ir inžinierių, kurie visa tai įdiegs ir palaikys, žinių ir patirties poreikis. Kadangi klientas klasteryje gauna visišką veiksmų laisvę, jis pats atsako už klasterio veiklą. Ir čia labai lengva viską sulaužyti.
- Antrasis – integracijos trūkumas. Jei paleisite Kubernetes be populiarios virtualizacijos platformos, negausite visų programos privalumų. Pavyzdžiui, nuolatinių garsų ir apkrovos balansavimo paslaugų naudojimas.
2 pav. k8s architektūra
Kubernetes iš pardavėjo
Integracija su debesies paslaugų teikėju suteikia dvi galimybes:
- Pirma, asmuo gali tiesiog spustelėti mygtuką „sukurti grupę“ ir gauti jau sukonfigūruotą ir paruoštą naudoti grupę.
- Antra, pardavėjas pats įdiegia klasterį ir nustato integraciją su debesimi.
Kaip čia atsitinka. Klasterį paleidžiantis inžinierius nurodo, kiek jam reikia darbuotojų ir su kokiais parametrais (pavyzdžiui, 5 darbuotojai, kiekvienas su 10 procesorių, 16 GB RAM ir, tarkime, 100 GB disko). Po to jis gauna prieigą prie jau suformuoto klasterio. Tokiu atveju darbuotojai, kuriems paleidžiamas krovinys, visiškai perduodami klientui, tačiau visa valdymo plokštuma lieka pardavėjo atsakomybe (jei paslauga teikiama pagal valdomo aptarnavimo modelį).
Tačiau ši schema turi savo trūkumų. Dėl to, kad valdymo planas lieka pardavėjui, pardavėjas nesuteikia visiškos prieigos klientui, o tai sumažina lankstumą dirbant su Kubernetes. Kartais nutinka taip, kad klientas nori prie Kubernetes pridėti tam tikrų funkcijų, pavyzdžiui, autentifikavimą per LDAP, tačiau valdymo plokštumos konfigūracija to neleidžia.
3 pav. Kubernetes klasterio pavyzdys iš debesies tiekėjo
Ką pasirinkti: atvirojo kodo ar pardavėjo
Taigi, ar „Kubernetes“ yra atvirojo kodo ar pardavėjo? Jei imtume atvirojo kodo Kubernetes, tai vartotojas su juo daro ką nori. Tačiau yra didelė tikimybė nusišauti sau į koją. Su pardavėju sunkiau, nes viskas apgalvota ir sukonfigūruota pagal įmonę. Didžiausias atvirojo kodo Kubernetes trūkumas – reikalavimas specialistams. Su pardavėjo pasirinkimu įmonė išsivaduoja nuo šio galvos skausmo, tačiau ji turės nuspręsti, ar mokėti savo specialistams, ar pardavėjui.
Na, pliusai akivaizdūs, trūkumai taip pat žinomi. Vienas dalykas yra pastovus: „Kubernetes“ išsprendžia daugybę problemų automatizuodamas daugelio konteinerių valdymą. O kurį pasirinkti, atvirąjį kodą ar pardavėją – kiekvienas sprendžia pats.
Straipsnį parengė Dmitrijus Krasnovas, pagrindinis #CloudMTS teikėjo Containerum paslaugos architektas
Šaltinis: www.habr.com