Tere, minu nimi on Dmitri Krasnov. Olen enam kui viis aastat administreerinud Kubernetese klastreid ja ehitanud keerulisi mikroteenuste arhitektuure. Selle aasta alguses käivitasime Containerumil põhineva Kubernetese klastrite haldamise teenuse. Seda võimalust kasutades räägin teile, mis on Kubernetes ja kuidas müüjaga integreerimine erineb avatud lähtekoodist.
Alustuseks, mis on . See on süsteem konteinerite haldamiseks suurel hulgal hostidel. Kreeka keelest on see muide tõlgitud kui "piloot" või "tüürimees". Algselt töötas välja Google ja annetati seejärel tehnoloogilise panusena Cloud Native Computing Foundationile, rahvusvahelisele mittetulundusühingule, mis ühendab maailma juhtivaid arendajaid, lõppkasutajaid ja konteinertehnoloogia pakkujaid.
Hallake suurt hulka konteinereid
Nüüd mõtleme välja, mis tüüpi konteinerid need on. See on rakendus kogu oma keskkonnaga – peamiselt raamatukogudega, millest programm sõltub. Kõik see pakitakse arhiividesse ja esitatakse pildina, mida saab operatsioonisüsteemist sõltumata käivitada, testida ja palju muud. Kuid on probleem - konteinerite haldamine suurel hulgal hostidel on väga keeruline. Sellepärast loodi Kubernetes.
Konteinerkujutis tähistab rakendust ja selle sõltuvusi. Rakendus, selle sõltuvused ja OS-i failisüsteemi kujutis asuvad pildi erinevates osades ehk nn kihtides. Kihti saab erinevate konteinerite jaoks uuesti kasutada. Näiteks võivad kõik ettevõtte rakendused kasutada Ubuntu baaskihti. Konteinerite käitamisel ei ole vaja hosti ühest aluskihist mitut koopiat salvestada. See võimaldab optimeerida piltide salvestamist ja edastamist.
Kui soovime rakendust konteinerist käivitada, kantakse vajalikud kihid üksteise peale ja moodustub ülekattega failisüsteem. Peal asetatakse salvestuskiht, mis eemaldatakse konteineri peatumisel. See tagab, et konteineri käitamisel on rakendusel alati sama keskkond, mida ei saa muuta. See tagab keskkonna reprodutseeritavuse erinevates host-OS-ides. Olgu selleks Ubuntu või CentOS, keskkond on alati sama. Lisaks eraldatakse konteiner hostist Linuxi kernelisse sisseehitatud mehhanismide abil. Konteineris olevad rakendused ei näe faile, hosti protsesse ega naaberkonteinereid. See rakenduste isoleerimine host OS-ist annab täiendava turvakihi.
Hosti konteinerite haldamiseks on saadaval palju tööriistu. Neist populaarseim on Docker. See võimaldab teil pakkuda konteinerite kogu elutsüklit. Kuid see töötab ainult ühel hostil. Kui teil on vaja konteinereid hallata mitmes hostis, võib Docker muuta inseneride elu põrguks. Sellepärast loodi Kubernetes.
Nõudlus Kubernetese järele tuleneb just võimalusest hallata mitmel hostil olevaid konteinerirühmi mingisuguse üksiku üksusena. Süsteemi populaarsus annab võimaluse luua DevOpsi või arendusoperatsioone, milles Kubernetest kasutatakse just selle DevOpsi protsesside käitamiseks.
Joonis 1. Kubernetese toimimise skemaatiline kujutis
Täielik automatiseerimine
DevOps on põhimõtteliselt arendusprotsessi automatiseerimine. Jämedalt öeldes kirjutavad arendajad koodi, mis laaditakse hoidlasse üles. Seejärel saab selle koodi automaatselt koguda kõigi teekide mahutisse, testida ja järgmisse etappi - lavastamine - ja seejärel kohe tootmisse "rullida".
Koos Kubernetesiga võimaldab DevOps seda protsessi automatiseerida nii, et see toimuks praktiliselt ilma arendajate endi osaluseta. Tänu sellele on ehitamine oluliselt kiirem, kuna arendaja ei pea seda oma arvutis tegema - ta kirjutab lihtsalt koodijupi, lükkab koodi hoidlasse, misjärel käivitatakse konveier, mis võib protsessi hõlmata. ehitamisest, testimisest ja kasutuselevõtust. Ja seda juhtub iga kohustusega, nii et testimine toimub pidevalt.
Samas võimaldab konteineri kasutamine olla kindel, et kogu selle programmi keskkond lastakse tootmisse täpselt sellisel kujul, nagu seda testiti. See tähendab, et ei teki selliseid probleeme nagu "mõned versioonid olid testis, teised tootmises, kuid kui me need installisime, siis kõik kukkus." Ja kuna täna on meil suund mikroteenuste arhitektuuri poole, kui ühe tohutu rakenduse asemel on sadu väikeseid, on nende käsitsi haldamiseks vaja tohutult töötajaid. Seetõttu kasutame Kubernetes.
Plussid, plussid, plussid
Kui rääkida Kubernetese eelistest platvormina, siis sellel on mikroteenuse arhitektuuri haldamise seisukohalt olulisi eeliseid.
- Mitme koopia haldamine. Kõige tähtsam on konteinerite haldamine mitmes hostis. Veelgi olulisem on hallata mitut rakenduse koopiat konteinerites ühe üksusena. Tänu sellele ei pea insenerid iga üksiku konteineri pärast muretsema. Kui üks konteineritest jookseb kokku, näeb Kubernetes seda ja taaskäivitab selle uuesti.
- Klastrite võrk. Kubernetes on ka oma aadressiruumiga nn klastrivõrk. Tänu sellele on igal potil oma aadress. Alampodi all mõistetakse klastri minimaalset struktuuriüksust, milles konteinerid otse käivitatakse. Lisaks on Kubernetes funktsioonid, mis ühendavad koormuse tasakaalustaja ja Service Discovery. See võimaldab teil vabaneda käsitsi IP-aadressi haldamisest ja delegeerida selle ülesande Kubernetesele. Automaatsed tervisekontrollid aitavad tuvastada probleeme ja suunata liikluse töötavatesse kaustadesse.
- Konfiguratsiooni juhtimine. Suure hulga rakenduste haldamisel muutub rakenduste konfiguratsiooni haldamine keeruliseks. Selleks on Kubernetesil spetsiaalsed ConfigMapi ressursid. Need võimaldavad teil konfiguratsioone tsentraalselt salvestada ja rakenduste käitamisel neid kaustadele avaldada. See mehhanism võimaldab meil tagada konfiguratsiooni järjepidevuse vähemalt kümne või saja rakenduse koopia puhul.
- Püsivad köited. Konteinerid on oma olemuselt muutumatud ja konteineri peatamisel hävitatakse kõik failisüsteemi kirjutatud andmed. Kuid mõned rakendused salvestavad andmed otse kettale. Selle probleemi lahendamiseks on Kubernetesil kettasalvestuse haldusfunktsioon – püsivad köited. See mehhanism kasutab andmete jaoks välist salvestusruumi ja suudab püsiva salvestusruumi, ploki või faili konteineritesse üle kanda. See lahendus võimaldab salvestada andmeid töötajatest eraldi, mis säästab neid, kui need samad töötajad katki lähevad.
- Koormuse tasakaalustaja. Kuigi Kubernetes haldame abstraktseid üksusi, nagu juurutamine, StatefulSet jne, töötavad konteinerid lõpuks tavalistes virtuaalmasinates või riistvaraserverites. Need ei ole täiuslikud ja võivad igal ajal kukkuda. Kubernetes näeb seda ja suunab sisemise liikluse teistele koopiatele. Aga mida teha väljast tuleva liiklusega? Kui suunate liikluse lihtsalt ühele töötajale, siis kui see jookseb kokku, muutub teenus kättesaamatuks. Selle probleemi lahendamiseks on Kubernetesil sellised teenused nagu Load Balancer. Need on loodud välise pilve tasakaalustaja automaatseks konfigureerimiseks kõigi klastri töötajate jaoks. See väline tasakaalustaja suunab välise liikluse töötajatele ja jälgib ise nende olekut. Kui üks või mitu töötajat ei ole saadaval, suunatakse liiklus teistele. See võimaldab teil Kubernetese abil luua väga kättesaadavaid teenuseid.
Kubernetes töötab kõige paremini mikroteenuste arhitektuuride käitamisel. Süsteemi on võimalik juurutada klassikalisesse arhitektuuri, kuid see on mõttetu. Kui rakendus ei saa töötada mitmel koopial, siis mis vahet sellel on – kas Kubernetesis või mitte?
Avatud lähtekoodiga Kubernetes
Avatud lähtekoodiga Kubernetes on suurepärane asi: installisin selle ja see töötab. Saate selle juurutada oma riistvaraserverites, oma infrastruktuuris, installida meistrid ja töötajad, millel kõik rakendused töötavad. Ja mis kõige tähtsam, see kõik on tasuta. Siiski on nüansse.
- Esimene on nõudlus administraatorite ja inseneride teadmiste ja kogemuste järele, kes seda kõike juurutavad ja toetavad. Kuna klient saab klastris täieliku tegevusvabaduse, vastutab ta klastri toimivuse eest ise. Ja siin on väga lihtne kõike murda.
- Teine on integratsioonide puudumine. Kui käivitate Kubernetes ilma populaarse virtualiseerimisplatvormita, ei saa te programmi kõiki eeliseid kasutada. Näiteks püsivate helitugevuste ja koormuse tasakaalustaja teenuste kasutamine.
Joonis 2. k8s arhitektuur
Kubernetes müüjalt
Pilveteenuse pakkujaga integreerimine pakub kahte võimalust.
- Esiteks saab inimene lihtsalt klõpsata nupul Loo klaster ja saada juba konfigureeritud ja kasutamiseks valmis klastri.
- Teiseks installib müüja ise klastri ja seadistab integratsiooni pilvega.
Kuidas see siin toimub. Klastrit käivitav insener määrab, kui palju töötajaid ta vajab ja milliste parameetritega (näiteks 5 töötajat, igaühel 10 protsessorit, 16 GB muutmälu ja näiteks 100 GB ketast). Pärast seda saab see juurdepääsu juba moodustatud klastrile. Sel juhul kantakse töötajad, kellele koorem käivitatakse, täielikult üle kliendile, kuid kogu haldustasand jääb müüja vastutusalasse (kui teenust osutatakse hallatava teenuse mudeli järgi).
Sellel skeemil on aga omad puudused. Kuna haldustasand jääb müüjale, ei anna tarnija kliendile täielikku juurdepääsu ja see vähendab Kubernetesega töötamise paindlikkust. Mõnikord juhtub, et klient soovib Kubernetesele lisada mõnda spetsiifilist funktsiooni, näiteks autentimist LDAP-i kaudu, kuid haldustasandi konfiguratsioon seda ei võimalda.
Joonis 3. Pilvepakkuja Kubernetese klastri näide
Mida valida: avatud lähtekoodiga või müüja
Niisiis, kas Kubernetes on avatud lähtekoodiga või hankija spetsiifiline? Kui võtta avatud lähtekoodiga Kubernetes, siis kasutaja teeb sellega, mida tahab. Kuid on suur võimalus endale jalga tulistada. Müüjaga on see keerulisem, sest kõik on ettevõtte jaoks läbi mõeldud ja konfigureeritud. Avatud lähtekoodiga Kubernetese suurim puudus on nõue spetsialistide järele. Tarnija valikuga vabaneb ettevõte sellest peavalust, kuid ta peab otsustama, kas maksab maksta oma spetsialistidele või müüjale.
Noh, plussid on ilmselged, miinused on ka teada. Üks asi on konstantne: Kubernetes lahendab palju probleeme, automatiseerides paljude konteinerite haldamise. Ja kumba valida, kas avatud lähtekoodiga või müüja – igaüks teeb ise otsuse.
Artikli koostas Dmitri Krasnov, #CloudMTS-i pakkuja Containerumi teenuse juhtivarhitekt
Allikas: www.habr.com