Zdravo, moje ime je Dmitrij Krasnov. Već više od pet godina se bavim administracijom Kubernetes klastera i izgradnjom kompleksnih mikroservisnih arhitektura. Na početku ove godine pokrenuli smo servis za upravljanje Kubernetes klasterima baziran na Containerum-u. Iskoristiću priliku da objasnim šta je taj Kubernetes i kako se integracija sa provajderima razlikuje od open source.
Za početak, šta je . To je sistem za upravljanje kontejnerima na velikom broju hostova. S grčkog, inače, prevodi se kao „pilot“ ili „kormilar“. Prvobitno je razvijen od strane Google-a, a zatim je kao tehnološki doprinos dat Cloud Native Computing Foundation, međunarodnoj neprofitnoj organizaciji koja okuplja vodeće svetske programere, krajnje korisnike i provajdere kontejnerskih tehnologija.

Upravljati velikim brojem kontejnera
Sada da razjasnimo šta su ti kontejneri. To je aplikacija sa svim svojim okruženjem – uglavnom, bibliotekama od kojih zavisi rad programa. Sve to je spakovano u arhive i predstavljeno u obliku slike koja se može pokretati nezavisno od operativnog sistema, testirati i još mnogo toga. Ali postoji problem — upravljati kontejnerima na velikom broju hostova je veoma teško. Zato je Kubernetes i stvoren.
Slika kontejnera predstavlja aplikaciju plus njene zavisnosti. Aplikacija, njene zavisnosti i slika fajl sistema OS se nalaze u različitim delovima slike, takozvanim slojevima. Slojevi se mogu ponovo koristiti za različite kontejnere. Na primer, za sve aplikacije u kompaniji može se koristiti osnovni sloj Ubuntu. Prilikom pokretanja kontejnera nema potrebe čuvati na hostu brojne kopije jednog osnovnog sloja. To omogućava optimizaciju skladištenja i isporuke slika.
Ko smo željeli zagnati aplikacijo iz kontejnerja, se potrebni sloji prekrivajo in nastane prekrivna datotečna sistema. Na vrh se postavi sloj za pisanje, ki se ob ustavitvi kontejnerja odstrani. To zagotavlja, da ima aplikacija ob zagonu kontejnerja vedno enako okolje, ki ga ni mogoče spremeniti. To zagotavlja reproducibilnost okolja na različnih gostiteljskih operacijskih sistemih. Naj bo to Ubuntu ali CentOS, bo okolje vedno enako. Poleg tega je kontejner izoliran od gosta z vgrajenimi mehanizmi jedra Linuxa. Aplikacije v kontejnerju ne vidijo datotek, procesov gosta in sosednjih kontejnerjev. Takšna izolacija aplikacij od gostiteljske operacijske sistema zagotavlja dodatno plast varnosti.
Za upravljanje kontejnerjev na gostitelju je na voljo veliko orodij. Najbolj priljubljeno med njimi je Docker. Omogoča popoln življenjski cikel dela kontejnerjev. Vendar pa deluje le na enem gostitelju. Ko je potrebno upravljati kontejnerje na več gostiteljih, Docker lahko inženirjem oteži življenje. Zato je bil ustvarjen Kubernetes.
Povpraševanje po Kubernetesu je ravno mogoče posledica njegove sposobnosti upravljanja skupin kontejnerjev na več gostiteljih kot nekaterih enotnih entitet. Priljubljenost sistema zagotavlja možnost izgradnje DevOps ali razvojnih operacij, v katerih se Kubernetes uporablja za zagon procesov tega DevOps.

Slika 1. Shematični prikaz delovanja Kubernetesa
Popolna avtomatizacija
DevOps v osnovi predstavlja avtomatizacijo procesa razvoja. Splošno povedano, razvijalci napišejo kodo, ki se naloži v repozitorij. Nato se ta koda lahko samodejno sestavi v kontejner z vsemi knjižnicami, testira in »izda« na naslednjo stopnjo – Staging, nato pa takoj tudi na Production.
Skupaj z Kubernetes DevOps omogoča avtomatizacijo tega procesa, tako da poteka skoraj brez posega samih razvijalcev. S tem se znatno pospeši gradnja, saj se razvijalec ne ukvarja s tem na svojem računalniku — preprosto napiše kos kode, potisne kodo v repozitorij, nato pa se zažene pipeline, ki lahko vključuje proces gradnje, testiranja in uvajanja. To se dogaja z vsakim commitom, zato se testiranje odvija neprekinjeno.
Ob tem omogočanje uporabe kontejnerja zagotavlja, da bo vse okolje te aplikacije prišlo v produkcijo v točno takšni obliki, kot je bilo testirano. To pomeni, da ne bo težav, kot so 'na testiranju so bile druge različice, v produkciji druge, po namestitvi pa se vse sesuje'. Ker danes beležimo trend mikrostoritev, kjer namesto ene velike aplikacije obstaja na stotine majhnih, bi za ročno upravljanje potrebovali ogromno osebja. Zato uporabljamo Kubernetes.
Prednosti, prednosti, prednosti
Če govorimo o prednostih Kubernetes kot platforme, ima večje prednosti z vidika upravljanja mikrostoritvene arhitekture.
- Upravljanje z več replikami. Najpomembnejše je upravljanje s kontejnerji na več gostiteljih. In kar je še pomembneje, upravljanje z več replikami aplikacij v kontejnerjih kot enotno entiteto. S tem inženirjem ni treba skrbeti za vsak posamezni kontejner. Če enega od kontejnerjev odpove, ga bo Kubernetes opazil in ga ponovno zagnal.
- Klaster omrežje. Kubernetes ima tudi t.i. klastersko omrežje s svojim naslovnim prostorom. S tem ima vsak pod svoj naslov. Pod se razume kot minimalna strukturna enota klasterja, v kateri se neposredno zaženejo kontejnerji. Poleg tega ima Kubernetes funkcionalnost, ki združuje uravnoteževalnik obremenitev in Service Discovery. To omogoča, da se izognemo ročnemu upravljanju z IP naslovi in prenese to nalogo na ramena Kubernetesa. Samodejni health checki pomagajo odkriti težave in preusmeriti promet na delujoče pode.
- Upravljanje konfiguracijama. Pri upravljanju velikim brojem aplikacija postaje teško upravljati njihovom konfiguracijom. Za ovo, Kubernetes ima posebne resurse ConfigMap-ove. Oni omogućuju centralizirano pohranjivanje konfiguracija i njihovo umetanje u podove prilikom pokretanja aplikacija. Ovaj mehanizam jamči dosljednost konfiguracije bilo da se radi o deset ili stotinu replika aplikacija.
- Trajni Volume. Kontejneri su po svojoj prirodi imutabilni i kada se kontejner zaustavi, svi podaci zapisani na datotečni sustav bit će uništeni. No, neka aplikacije pohranjuju podatke izravno na disku. Kako bi se riješio ovaj problem, Kubernetes nudi funkcionalnost upravljanja pohranom diska – Trajni Volumes. Ovaj mehanizam koristi vanjsku pohranu za podatke, omogućava prosljeđivanje trajne pohrane u kontejnerima, bilo blokovne ili datotečne. Ovo rješenje omogućava pohranu podataka odvojeno od radnika, što ih spašava u slučaju kvarova tih radnika.
- Balancer opterećenja. Iako u Kubernetes-u upravljamo apstraktnim entitetima poput Deployment-a, StatefulSet-a itd., konačno se kontejneri pokreću na običnim virtualnim mašinama ili fizičkim poslužiteljima. Oni nisu savršeni i mogu pasti u bilo kojem trenutku. Kubernetes će to primijetiti i preusmjeriti unutarnji promet na druge replikate. No, što učiniti s prometom koji dolazi izvana? Ako jednostavno preusmjerimo promet na jednog od radnika, što će se dogoditi u slučaju njegovog pada, usluga će postati nedostupna. Kako bi se riješio ovaj problem, Kubernetes ima usluge poput Balancer-a opterećenja. One su namijenjene automatskoj konfiguraciji vanjskog oblaka balancer-a na sve radnike u klasteru. Ovaj vanjski balancer usmjerava vanjski promet na radnike i prati njihov status. Ako jedan ili više radnika postanu nedostupni, promet se preusmjerava na druge. Ovo omogućava stvaranje visoko dostupnih usluga pomoću Kubernetes-a.
Kubernetes se najbolje pokazuje prilikom pokretanja mikroservisnih arhitektura. Uvođenje sustava u klasičnu arhitekturu moguće je, ali besmisleno. Ako aplikacija ne može raditi u više replika, koja je svrha razlike – bilo u Kubernetes-u ili ne?
Open source Kubernetes
Odprtokodni Kubernetes – odlična stvar: namestiš in deluje. Lahko ga razširiš na svojih fizičnih strežnikih, na svoji infrastrukturi, namestiš master in delavce, na katerih se izvajajo vse aplikacije. In kar je najpomembneje – vse to je brezplačno. Vendar obstajajo nekatere posebnosti.
- Prva – zahteve po znanju in izkušnjah administratorjev in inženirjev, ki bodo vse to nameščali in vzdrževali. Ker stranka pridobi popolno svobodo delovanja v klasterju, nosi odgovornost za delovanje klasterja sama. In tukaj je zelo enostavno vse pokvariti.
- Druga – pomanjkanje integracij. Če želiš zagnati Kubernetes, ne da bi imel kakšno priljubljeno platformo za virtualizacijo, ne boš izkoristil vseh prednosti programa. Kot so uporaba Persistent Volumes in storitev Load balancer.

Slika 2. Arhitektura k8s
Kubernetes od izvajalca
Integracija s ponudnikom oblačnih storitev ponuja dve možnosti:
- Prvič, uporabnik lahko preprosto pritisne gumb „ustvari klaster“ in dobi že nastavljen in pripravljen klaster.
- Drugič, ponudnik sam postavi klaster in nastavi integracijo z oblakom.
Kako to poteka pri nas. Inženir, ki začne klaster, navede, koliko delavcev potrebuje in s kakšnimi parametri (na primer, 5 delavcev, vsak z 10 CPU, 16 GB RAM-a in recimo 100 GB prostora na disku). Po tem dobi dostop do že oblikovanega klasterja. Pri tem so delavci, na katerih se izvaja obremenitev, popolnoma namenjeni stranki, vendar celotna management plane ostaja v pristojnosti izvajalca (v primeru, da se storitev nudi po modelu upravljane storitve).
Vendar pa ima taka shema svoje slabosti. Zaradi tega, ker management plane ostaja pri izvajalcu, ta ne daje popolnega dostopa stranki, kar zmanjšuje prilagodljivost pri delu z Kubernetesom. Včasih se zgodi, da si stranka želi dodati kakšno specifično funkcionalnost k Kubernetesu, na primer, overjanje preko LDAP, a konfiguracija management plane tega ne omogoča.

Slika 3. Primer klasterja Kubernetes od ponudnika oblačnih storitev
Kaj izbrati: odprtokodno ali od izvajalca
Torej, open source Kubernetes ali vendor? Če izberete open source Kubernetes, lahko uporabnik z njim počne, kar želi. Vendar obstaja velika verjetnost, da si bo s tem lahko poškodoval samega sebe. Pri vendorskih rešitvah je to težje, ker je vse v podjetju premišljeno in nastavljeno. Največja pomanjkljivost open source Kubernetes je zahteva po specialistih. Pri vendorskih rešitvah se podjetje te skrbi reši, vendar se mora odločiti: plačati svoje strokovnjake ali vendorju.


No, prednosti so očitne, slabosti so prav tako znane. Nekaj pa ostaja enako: Kubernetes rešuje množico težav, s tem ko avtomatizira upravljanje številnih vsebnikov. Katero izbrati, open source ali vendor, se vsak odloči sam.
Članek je pripravil Dmitrij Krasnov, vodilni arhitekt storitve Containerum ponudnika #CloudMTS.
Izvor: habr.com
