Zdravo, moje ime je Dmitrij Krasnov. Više od pet godina administriram Kubernetes klastere i gradim složene mikroservisne arhitekture. Početkom ove godine pokrenuli smo servis za upravljanje Kubernetes klasterima baziran na Containerumu. Koristeći ovu priliku, reći ću vam šta je Kubernetes i po čemu se integracija sa dobavljačem razlikuje od otvorenog koda.
Za početak, šta je . Ovo je sistem za upravljanje kontejnerima na velikom broju hostova. Sa grčkog se, inače, prevodi kao "pilot" ili "kormilar". Prvobitno razvijen od strane Googlea, a zatim doniran kao tehnološki doprinos Cloud Native Computing Foundation, međunarodnoj neprofitnoj organizaciji koja okuplja vodeće svjetske programere, krajnje korisnike i dobavljače tehnologije kontejnera.
Upravljajte velikim brojem kontejnera
Sada da shvatimo o kakvim se kontejnerima radi. Ovo je aplikacija sa cjelokupnim okruženjem - uglavnom bibliotekama o kojima ovisi program. Sve je to upakovano u arhive i predstavljeno u obliku slike koja se može pokrenuti bez obzira na operativni sistem, testirati i drugo. Ali postoji problem - upravljanje kontejnerima na velikom broju hostova je veoma teško. Zbog toga je stvoren Kubernetes.
Slika kontejnera predstavlja aplikaciju plus njene zavisnosti. Aplikacija, njene zavisnosti i slika OS fajl sistema nalaze se u različitim delovima slike, takozvanim slojevima. Slojevi se mogu ponovo koristiti za različite kontejnere. Na primjer, sve aplikacije u kompaniji mogu koristiti Ubuntu osnovni sloj. Prilikom pokretanja kontejnera, nema potrebe za pohranjivanjem više kopija jednog osnovnog sloja na hostu. Ovo vam omogućava da optimizujete skladištenje i isporuku slika.
Kada želimo da pokrenemo aplikaciju iz kontejnera, potrebni slojevi se prekrivaju jedan na drugi i formira se sistem datoteka sa preklapanjem. Na vrh se postavlja sloj za snimanje, koji se uklanja kada se kontejner zaustavi. Ovo osigurava da kada se kontejner pokrene, aplikacija će uvijek imati isto okruženje, koje se ne može promijeniti. Ovo garantuje reproduktivnost okruženja na različitim operativnim sistemima domaćina. Bilo da je u pitanju Ubuntu ili CentOS, okruženje će uvek biti isto. Osim toga, kontejner je izoliran od hosta pomoću mehanizama ugrađenih u jezgro Linuxa. Aplikacije u kontejneru ne vide datoteke, procese hosta i susjedne kontejnere. Ova izolacija aplikacija od glavnog OS-a pruža dodatni nivo sigurnosti.
Dostupni su mnogi alati za upravljanje kontejnerima na hostu. Najpopularniji od njih je Docker. Omogućava vam da obezbedite puni životni ciklus kontejnera. Međutim, radi samo na jednom hostu. Ako trebate upravljati kontejnerima na više hostova, Docker može napraviti pakao od života za inženjere. Zbog toga je stvoren Kubernetes.
Potražnja za Kubernetesom je upravo zbog mogućnosti upravljanja grupama kontejnera na više hostova kao nekom vrstom jednog entiteta. Popularnost sistema pruža mogućnost izgradnje DevOps-a ili Development Operations, u kojima se Kubernetes koristi za pokretanje procesa upravo ovog DevOps-a.
Slika 1. Šematski prikaz kako Kubernetes radi
Potpuna automatizacija
DevOps je u osnovi automatizacija procesa razvoja. Grubo govoreći, programeri pišu kod koji se učitava u spremište. Zatim se ovaj kod može automatski odmah prikupiti u kontejner sa svim bibliotekama, testirati i „prebaciti“ u sljedeću fazu - Staging, a zatim odmah u produkciju.
Zajedno sa Kubernetesom, DevOps vam omogućava da automatizujete ovaj proces tako da se odvija bez učešća samih programera. Zbog toga je gradnja znatno brža, jer programer to ne mora raditi na svom računaru - on jednostavno napiše dio koda, gurne kod u spremište, nakon čega se pokreće cjevovod koji može uključivati proces izgradnje, testiranja i uvođenja. I to se dešava sa svakim urezivanjem, tako da se testiranje dešava kontinuirano.
U isto vrijeme, korištenje kontejnera vam omogućava da budete sigurni da će cijelo okruženje ovog programa biti pušteno u proizvodnju točno u obliku u kojem je testirano. Odnosno, neće biti problema tipa „bile su neke verzije na testu, druge u proizvodnji, ali kada smo ih instalirali, sve je palo“. A pošto danas imamo trend ka mikroservisnoj arhitekturi, kada umesto jedne ogromne aplikacije postoje stotine malih, da bi se njima ručno administrirali, biće potrebno ogromno osoblje. Zato koristimo Kubernetes.
Za, za, za
Ako govorimo o prednostima Kubernetesa kao platforme, onda on ima značajne prednosti sa stanovišta upravljanja mikroservisnom arhitekturom.
- Upravljanje višestrukim replikama. Najvažnija stvar je upravljanje kontejnerima na više hostova. Što je još važnije, upravljajte višestrukim replikama aplikacije u kontejnerima kao jednim entitetom. Zahvaljujući tome, inženjeri ne moraju da brinu o svakom pojedinačnom kontejneru. Ako se jedan od kontejnera sruši, Kubernetes će to vidjeti i ponovo ga pokrenuti.
- Mreža klastera. Kubernetes takođe ima takozvanu mrežu klastera sa sopstvenim adresnim prostorom. Zahvaljujući tome, svaka mahuna ima svoju adresu. Podpodmet se shvata kao minimalna strukturna jedinica klastera u kojoj se kontejneri direktno lansiraju. Osim toga, Kubernetes ima funkcionalnost koja kombinuje balansiranje opterećenja i otkrivanje usluga. Ovo vam omogućava da se riješite ručnog upravljanja IP adresama i delegirate ovaj zadatak na Kubernetes. A automatske zdravstvene provjere pomoći će u otkrivanju problema i preusmjeravanju prometa na radne podove.
- Upravljanje konfiguracijom. Kada se upravlja velikim brojem aplikacija, postaje teško upravljati konfiguracijom aplikacije. U tu svrhu, Kubernetes ima posebne ConfigMap resurse. Omogućuju vam da centralno pohranjujete konfiguracije i izlažete ih podovima prilikom pokretanja aplikacija. Ovaj mehanizam nam omogućava da garantujemo konzistentnost konfiguracije u najmanje deset ili sto replika aplikacije.
- Persistent Volumes. Kontejneri su inherentno nepromjenjivi i kada se kontejner zaustavi, svi podaci upisani u sistem datoteka će biti uništeni. Ali neke aplikacije pohranjuju podatke direktno na disk. Da bi riješio ovaj problem, Kubernetes ima funkciju upravljanja pohranom na disku - Persistent Volumes. Ovaj mehanizam koristi vanjsku pohranu podataka i može prenijeti trajnu pohranu, blok ili datoteku, u kontejnere. Ovo rješenje vam omogućava pohranjivanje podataka odvojeno od radnika, što ih spašava ako se ti isti radnici pokvare.
- Load Balancer. Iako u Kubernetesu upravljamo apstraktnim entitetima kao što su Deployment, StatefulSet, itd., kontejneri se na kraju pokreću na redovnim virtuelnim mašinama ili hardverskim serverima. Nisu savršene i mogu pasti u svakom trenutku. Kubernetes će to vidjeti i preusmjeriti interni promet na druge replike. Ali šta učiniti sa saobraćajem koji dolazi spolja? Ako jednostavno usmjerite promet na jednog od radnika, ako se sruši, usluga će postati nedostupna. Da bi riješio ovaj problem, Kubernetes ima usluge kao što je Load Balancer. Dizajnirani su da automatski konfigurišu eksterni balans za oblak za sve radnike u klasteru. Ovaj eksterni balanser usmjerava vanjski promet radnicima i sam prati njihov status. Ako jedan ili više radnika postanu nedostupni, promet se preusmjerava na druge. Ovo vam omogućava da kreirate visoko dostupne usluge koristeći Kubernetes.
Kubernetes najbolje radi kada pokreće mikroservisne arhitekture. Moguće je implementirati sistem u klasičnu arhitekturu, ali je besmisleno. Ako aplikacija ne može da radi na više replika, kakva je onda razlika - u Kubernetesu ili ne?
Kubernetes otvorenog koda
Kubernetes otvorenog koda je odlična stvar: instalirao sam ga i radi. Možete ga postaviti na vlastite hardverske servere, na vlastitu infrastrukturu, instalirati mastere i radnike na kojima će sve aplikacije raditi. I što je najvažnije, sve je to besplatno. Međutim, postoje nijanse.
- Prvi je zahtjev za znanjem i iskustvom administratora i inženjera koji će sve to implementirati i podržati. Pošto klijent dobija potpunu slobodu delovanja u klasteru, on sam snosi odgovornost za rad klastera. I ovdje je vrlo lako sve razbiti.
- Drugi je nedostatak integracija. Ako pokrenete Kubernetes bez popularne platforme za virtuelizaciju, nećete dobiti sve prednosti programa. Kao što je korištenje usluga trajnih volumena i balansiranja opterećenja.
Slika 2. k8s arhitektura
Kubernetes od dobavljača
Integracija s provajderom u oblaku pruža dvije opcije:
- Prvo, osoba može jednostavno kliknuti na dugme „kreiraj klaster“ i dobiti klaster koji je već konfigurisan i spreman za upotrebu.
- Drugo, dobavljač sam instalira klaster i postavlja integraciju sa oblakom.
Kako se to dešava ovde. Inženjer koji pokreće klaster određuje koliko radnika treba i sa kojim parametrima (npr. 5 radnika, svaki sa 10 CPU-a, 16 GB RAM-a i recimo 100 GB diska). Nakon toga dobija pristup već formiranom klasteru. U ovom slučaju, radnici na kojima se pokreće opterećenje se u potpunosti prenose na klijenta, ali cijeli plan upravljanja ostaje pod odgovornošću dobavljača (ako se usluga pruža prema modelu upravljane usluge).
Međutim, ova shema ima svoje nedostatke. Zbog činjenice da nivo upravljanja ostaje kod dobavljača, dobavljač ne daje potpuni pristup klijentu, a to smanjuje fleksibilnost u radu sa Kubernetesom. Ponekad se desi da klijent želi dodati neku specifičnu funkcionalnost Kubernetesu, na primjer, autentifikaciju putem LDAP-a, ali konfiguracija ravni upravljanja to ne dozvoljava.
Slika 3. Primjer Kubernetes klastera od dobavljača oblaka
Šta odabrati: open source ili dobavljača
Dakle, da li je Kubernetes open source ili specifičan za dobavljača? Ako uzmemo open source Kubernetes, onda korisnik sa njim radi šta želi. Ali postoji velika šansa da sebi pucate u nogu. Sa dobavljačem je teže, jer je sve osmišljeno i konfigurisano za kompaniju. Najveći nedostatak Kubernetesa otvorenog koda je potreba za stručnjacima. Uz opciju dobavljača, kompanija je oslobođena ove glavobolje, ali će morati odlučiti da li će platiti svojim stručnjacima ili dobavljaču.
Pa, prednosti su očigledne, poznate su i mane. Jedna stvar je konstantna: Kubernetes rješava mnoge probleme automatizirajući upravljanje mnogim kontejnerima. I koju odabrati, open source ili dobavljača - svako donosi svoju odluku.
Članak je pripremio Dmitrij Krasnov, vodeći arhitekta usluge Containerum provajdera #CloudMTS
izvor: www.habr.com