{"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 vs tootja lahendus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, mina olen Dmitri Krasnov. Juba \u00fcle viie aasta olen tegelenud Kubernetes klastrite haldamise ja keerukate mikroteenuste arhitektuuride \u00fclesehitamisega. Selle aasta alguses k\u00e4ivitasime Kubernetes klastrite haldamise teenuse, mis p\u00f5hineb Containerumil. Kasutades juhust, r\u00e4\u00e4gin natuke, mis t\u00e4pselt on Kubernetes ja kuidas erineb integratsioon teenusepakkujaga avatud l\u00e4htekoodist.<\/b><\/p>\n

Alustuseks, mis on Kubernetes<\/a><\/noindex>. See on s\u00fcsteem konteinerite haldamiseks paljude hostide peal. Kreeka keeles t\u00f5lgituna t\u00e4hendab see \"piloot\" v\u00f5i \"juht\". Alguses arendas seda Google, seej\u00e4rel anti tehnilise panusena \u00fcle Cloud Native Computing Foundationile, mis on rahvusvaheline mittekasumitootav organisatsioon, mis \u00fchendab juhtivaid maailmas arendajaid, l\u00f5ppkasutajaid ja konteineritehnoloogiate tarnijaid. <\/p>\n

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

Konteinereid juhtida <\/h3>\n

\nN\u00fc\u00fcd vaatame, mis need konteinerid ikkagi on. Need on rakendused koos kogu nende keskkonnaga \u2013 peamiselt raamatukogadega, millest rakenduse t\u00f6\u00f6 s\u00f5ltub. K\u00f5ik see on pakitud arhiividesse ja esitatud kujul, mida saab k\u00e4ivitada s\u00f5ltumatult operatsioonis\u00fcsteemist, testida ja palju muud. Kuid probleem on selles \u2013 paljude hostide peal konteinerite haldamine on v\u00e4ga keeruline. Seet\u00f5ttu loodi Kubernetes. <\/p>\n

Konteineri pilt on rakendus koos selle s\u00f5ltuvustega. Rakendus, selle s\u00f5ltuvused ja operatsioonis\u00fcsteemi failis\u00fcsteemi pilt asuvad erinevates piltides, nn kihtides. Kihti saab taaskasutada erinevate konteinerite jaoks. N\u00e4iteks v\u00f5ib k\u00f5ikide ettev\u00f5tte rakenduste puhul kasutada p\u00f5hikihti Ubuntu. Konteinerite k\u00e4ivitamisel ei ole vaja hostis hoida mitmeid koopiaid \u00fchest ja samast p\u00f5hikihtidest. See v\u00f5imaldab optimeerida hoidmist ja piltide tarnimist.<\/p>\n

Kui soovime k\u00e4ivitada rakendust konteinerist, paigutatakse vajalikud kihid \u00fcksteise peale ja moodustatakse \u00fclekandefailis\u00fcsteem. Peale asetatakse kirjutamiskiht, mis eemaldatakse konteineri peatamisel. See tagab, et konteineri k\u00e4ivitamisel on rakendusel alati sama keskkond, mida ei saa muuta. See tagab keskkonna reprodutseeritavuse erinevates hostide operatsioonis\u00fcsteemides. Olgu see siis Ubuntu v\u00f5i CentOS \u2013 keskkond on alati sama. Lisaks on konteiner isoleeritud hostist Linuxi k\u00e4rude kaudu. Konteineris olevad rakendused ei n\u00e4e hosti v\u00f5i naaber konteinerite faile ega protsesse. Selline rakenduste isoleeritus hosti operatsioonis\u00fcsteemist pakub lisakihi turvalisust. <\/p>\n

Konteinerite haldamiseks hostis on palju t\u00f6\u00f6riistu. K\u00f5ige populaarsem neist on Docker. See v\u00f5imaldab tagada konteinerite t\u00e4ieliku eluts\u00fckli. Siiski t\u00f6\u00f6tab see ainult \u00fche hostiga. Kui on vaja haldada konteinerite mitmeid hoste, v\u00f5ib Docker muuta inseneride elu p\u00f5rguks. Seet\u00f5ttu loodi Kubernetes.<\/p>\n

Kubernetes'e n\u00f5udlus tuleneb v\u00f5imalusest juhtida konteinerigruppide hulki paljude hostide peal kui \u00fchtseid \u00fcksusi. S\u00fcsteem on populaarne, kuna see v\u00f5imaldab luua DevOps v\u00f5i arendustegevuse, kus Kubernetesit kasutatakse nende DevOps protsesside k\u00e4ivitamiseks.<\/p>\n

\"Kubernetes:
\n
\nJoonis 1. Schemaatiline kujutis Kubernetes'e t\u00f6\u00f6printsiibist<\/i><\/p>\n

T\u00e4iuslik automatiseerimine<\/h3>\n

\nDevOps on p\u00f5him\u00f5tteliselt arenduse automatiseerimine. Lihtsalt \u00f6eldes kirjutavad arendajad koodi, mis laaditakse repole. Seej\u00e4rel v\u00f5ib kood automaatselt kokku panna konteineriks koos k\u00f5igi raamatukogadega, testida ja \"\u00fcles laadida\" j\u00e4rgmisse etappi \u2013 Staging, ja seej\u00e4rel otse Productionisse.<\/p>\n

Kubernetes'i ja DevOps'i abil saab seda protsessi automatiseerida, et see toimuks praktiliselt ilma arendajate enda osaluseta. Selle tulemusena kiireneb koostamine suuresti, kuna arendaja ei pea seda oma arvutis tegema \u2013 ta kirjutab lihtsalt koodi, pushib selle repole ning k\u00e4ivitub pipeline, mis v\u00f5ib h\u00f5lmata koostamise, testimise ja \u00fcles laadimise protsessi. Ja see toimub iga commit'i korral, seega toimub testimine pidevalt.<\/p>\n

Konteineri kasutamine tagab, et kogu selle programmi keskkond j\u00f5uab tootmisse just sellisena, nagu seda testiti. See t\u00e4hendab, et ei teki probleeme, nagu \u201etestides olid \u00fched versioonid, tootmises \u2013 teised, ja kui installisime, kukkus k\u00f5ik kokku\u201c. T\u00e4nap\u00e4eva m\u00fc\u00fcgis on mikroteenuste arhitektuuri trend, kus \u00fche suure rakenduse asemel on sadu v\u00e4ikeseid. Nende k\u00e4sitsi haldamiseks on vajalik suur t\u00f6\u00f6tajaskond. Seet\u00f5ttu kasutamegi Kuberneteset.<\/p>\n

<\/p>\n

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

<\/b>
\nKui r\u00e4\u00e4kida Kubernetesest platvormina, siis sellel on olulised eelised mikroteenuste arhitektuuri haldamise kontekstis. <\/p>\n