{"id":81130,"date":"2020-05-11T01:42:39","date_gmt":"2020-05-10T23:42:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo"},"modified":"2020-05-11T01:42:39","modified_gmt":"2020-05-10T23:42:39","slug":"kubernetes-open-source-protiv-vendorskogo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo","title":{"rendered":"Kubernetes: avatud l\u00e4htekood versus tootja lahendus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, minu nimi on Dmitri Krasnov. Olen juba \u00fcle viie aasta tegelenud Kubernetes klastrite haldamise ja keerukate mikroteenuste arhitektuuride loomisega. Sel aasta alguses k\u00e4ivitasime Kubernetes klastrihalduse teenuse Containerumi alusel. Kasutades seda v\u00f5imalust, r\u00e4\u00e4gin, mis Kubernetes on ja kuidas integreerimine vendoriga erineb avatud l\u00e4htekoodiga lahendusest.<\/b><\/p>\n

Alustuseks, mis on Kubernetes<\/a><\/noindex>. See on s\u00fcsteem, mis haldab konteinerite suurt hulka hoste. Kreeka keeles t\u00f5lgituna t\u00e4hendab see \"piloot\" v\u00f5i \"ruuner\". Algusest peale on see v\u00e4lja t\u00f6\u00f6tatud Google'i poolt, p\u00e4rast mida on see tehnoloogilise panusena antud Cloud Native Computing Foundation'ile, rahvusvahelisele mittetulunduslikule organisatsioonile, mis \u00fchendab juhtivaid maailmatasemel arendajaid, l\u00f5ppkasutajaid ja konteineritehnoloogiate pakkujaid. <\/p>\n

\"Kubernetes:
\n<\/a><\/noindex><\/p>\n

Haldada suurt hulka konteinerite <\/h3>\n

\nN\u00fc\u00fcd vaatame, mis need konteinerid on. Need on rakendused koos nende keskkonnaga \u2013 enamasti teekidega, millest s\u00f5ltub programmi t\u00f6\u00f6. K\u00f5ik see on pakkida arhiividesse ja esindada kujul pilti, mida saab k\u00e4ivitada s\u00f5ltumata operatsioonis\u00fcsteemist, testida ja muu hulgas. Kuid probleem on see, et konteinerite haldamine suure hulga hostide peal on v\u00e4ga keeruline. Seet\u00f5ttu loodi Kubernetes. <\/p>\n

Konteineri pilt koosneb rakendusest ja selle s\u00f5ltuvustest. Rakendus, selle s\u00f5ltuvused ja operatsioonis\u00fcsteemi failis\u00fcsteemi pilt asuvad erinevates piltide osades, nn kihtides. Kihti saab taaskasutada erinevate konteinerite jaoks. N\u00e4iteks v\u00f5ib k\u00f5igi ettev\u00f5tte rakenduste jaoks kasutada baasikihti Ubuntu. Konteinerite k\u00e4ivitamisel pole vaja hostis hoida mitmeid koopiaid \u00fchest baasikihist. See v\u00f5imaldab optimeerida piltide s\u00e4ilitamist ja edastamist.<\/p>\n

Kuna me tahame rakendust konteinerist k\u00e4ivitada, ladustatakse vajalikud kihid \u00fcksteise peale ja luuakse overlay failis\u00fcsteem. \u00dclemisele kihile kirjutatakse kiht, mis peatamisel kustutatakse. See tagab, et konteineri k\u00e4ivitamisel on rakendusel alati sama keskkond, mida ei saa muuta. See tagab keskkonna taasesitatavuse erinevatel host-operatsioonis\u00fcsteemidel. Olenemata sellest, kas tegu on Ubuntu v\u00f5i CentOS'iga, on keskkond alati sama. Lisaks on konteiner isoleeritud hostist Linuxi kerneli sisseehitatud mehhanismide abil. Kasti rakendused ei n\u00e4e hosti ja naaberkonteinerite faile ega protsesse. Selline rakenduste isoleerimine host-operatsioonis\u00fcsteemist annab t\u00e4iendava turvakihi. <\/p>\n

Konteinerite haldamiseks hostil on olemas mitmesuguseid t\u00f6\u00f6riistu. K\u00f5ige populaarsem neist on Docker. See v\u00f5imaldab tagada konteinerite t\u00e4isl\u00e4biviimisprotsessi. Kuid see t\u00f6\u00f6tab ainult \u00fchel hostil. Kui on vaja hallata konteinereid mitmel hostil, v\u00f5ib Docker inseneride elu t\u00f5eliselt keeruliseks muuta. Seet\u00f5ttu loodi Kubernetes.<\/p>\n

Kubernetes'e n\u00f5udlikkus tuleneb v\u00f5imalusest hallata konteineri gruppe mitmel hostil kui \u00fchiseid \u00fcksusi. S\u00fcsteemi populaarsus tagab v\u00f5imaluse luua DevOps v\u00f5i Development Operations, kus Kubernetes't kasutatakse DevOpsi protsesside k\u00e4ivitamiseks.<\/p>\n

\"Kubernetes:
\n
\nJoonis 1. Scheem Kubernetes'e t\u00f6\u00f6p\u00f5him\u00f5ttest<\/i><\/p>\n

T\u00e4ielik automatiseerimine<\/h3>\n

\nDevOps t\u00e4histab p\u00f5him\u00f5tteliselt arenduse automatiseerimist. Lihtsalt \u00f6eldes, kirjutavad arendajad koodi, mis laaditakse reposse. Seej\u00e4rel v\u00f5ib seda koodi automaatselt kasutada kohe konteineris koos k\u00f5igi raamatukogudega, testida ja \"v\u00e4lja lasta\" j\u00e4rgmistesse etappidesse \u2013 Staging, ja seej\u00e4rel otse ka Productionisse.<\/p>\n

Koos Kubernetes, DevOps v\u00f5imaldab automatiseerida selle protsessi, et see toimuks peaaegu ilma arendajate vahelesegamiseta. Selle t\u00f5ttu kiireneb kogumine oluliselt, kuna arendajal ei pea olema vajadust seda oma arvutis teha \u2014 ta kirjutab lihtsalt koodi, laadib koodi hoidlasse ja seej\u00e4rel k\u00e4ivitatakse pipeline, mis v\u00f5ib sisaldada kogumise, testimise ja juurutamise protsessi. Ja see toimub iga commit'i korral, seega testimine toimub pidevalt.<\/p>\n

Samas v\u00f5imaldab konteinerite kasutamine olla kindel, et kogu selle programmi keskkond siseneb production'isse just sellises vormis, nagu seda on testitud. See t\u00e4hendab, et ei tekki probleeme, nagu \"testimise ajal olid \u00fched versioonid, production'is \u2013 teised, ja kui need peal, siis k\u00f5ik purunes.\" Kuna t\u00e4nap\u00e4eval on meil trend mikroteenuste arhitektuurile, kus \u00fche hiigelrakenduse asemel on kahesaja v\u00e4ikese rakenduse seas, vajaks nende k\u00e4sitsi haldamiseks tohutut t\u00f6\u00f6tajate arvu. Seep\u00e4rast kasutamegi Kubernetes't.<\/p>\n

<\/p>\n

Plussid, plussid, plussid<\/h3>\n

<\/b>
\nKui r\u00e4\u00e4kida Kubernetes'e plussidest platvormina, siis tal on m\u00e4rkimisv\u00e4\u00e4rsed eelised mikroteenuste arhitektuuri haldamise seisukohalt. <\/p>\n