🥇Kubernetes: avoimen lähdekoodin vs. toimittajan ratkaisut

Hei, nimeni on Dmitri Krasnov. Yli viiden vuoden ajan olen hallinnoinut Kubernetes-klustereita ja rakentanut monimutkaisia mikropalveluarkkitehtuureja. Tämän vuoden alussa lanseerasimme Containerumiin perustuvan Kubernetes-klusterien hallintapalvelun. Käytän tätä tilaisuutta hyväkseni ja kerron sinulle, mitä Kubernetes on ja kuinka integraatio toimittajan kanssa eroaa avoimesta lähdekoodista.

Aluksi, mikä on Kubernetes. Tämä on järjestelmä useiden isäntien säilöjen hallintaan. Kreikasta se on muuten käännetty "lentäjäksi" tai "ruorimieheksi". Alun perin Googlen kehittämä ja sitten lahjoitettu teknologiapanokseksi Cloud Native Computing Foundationille, kansainväliselle voittoa tavoittelemattomalle organisaatiolle, joka yhdistää maailman johtavat kehittäjät, loppukäyttäjät ja konttiteknologian toimittajat.

Hallitse suurta määrää säiliöitä

Selvitetään nyt, millaisia säiliöitä nämä ovat. Tämä on sovellus, jossa on koko ympäristö - pääasiassa kirjastot, joista ohjelma on riippuvainen. Kaikki tämä pakataan arkistoon ja esitetään kuvan muodossa, jota voidaan käyttää käyttöjärjestelmästä riippumatta, testata ja paljon muuta. Mutta on ongelma - säilöjen hallinta suurella määrällä isäntiä on erittäin vaikeaa. Siksi Kubernetes luotiin.

Säilökuva edustaa sovellusta ja sen riippuvuuksia. Sovellus, sen riippuvuudet ja käyttöjärjestelmän tiedostojärjestelmäkuva sijaitsevat kuvan eri osissa, niin sanotuissa kerroksissa. Kerroksia voidaan käyttää uudelleen eri säiliöissä. Esimerkiksi kaikki yrityksen sovellukset voivat käyttää Ubuntun peruskerrosta. Säilöjä ajettaessa ei tarvitse tallentaa useita kopioita yhdestä peruskerroksesta isäntään. Näin voit optimoida kuvien säilytyksen ja toimituksen.

Kun haluamme ajaa sovellusta säilöstä, tarvittavat kerrokset asetetaan päällekkäin ja muodostetaan peittotiedostojärjestelmä. Päälle asetetaan tallennuskerros, joka poistetaan, kun säiliö pysähtyy. Tämä varmistaa, että konttia suoritettaessa sovelluksella on aina sama ympäristö, jota ei voi muuttaa. Tämä takaa ympäristön toistettavuuden eri isäntäkäyttöjärjestelmissä. Olipa kyseessä Ubuntu tai CentOS, ympäristö on aina sama. Lisäksi säilö on eristetty isännästä käyttämällä Linux-ytimeen sisäänrakennettuja mekanismeja. Säilön sovellukset eivät näe isäntäkoneen tiedostoja, prosesseja ja viereisiä säilöjä. Tämä sovellusten eristäminen isäntäkäyttöjärjestelmästä tarjoaa lisäsuojaustasoa.

Käytettävissä on monia työkaluja isäntäkoneen säilöjen hallintaan. Suosituin niistä on Docker. Sen avulla voit tarjota konttien koko elinkaaren. Se toimii kuitenkin vain yhdellä isännällä. Jos sinun on hallittava useiden isäntien säiliöitä, Docker voi tehdä insinöörien elämästä helvetin. Siksi Kubernetes luotiin.

Kubernetesin kysyntä johtuu nimenomaan kyvystä hallita konttiryhmiä useilla isännillä jonkinlaisena yhtenä kokonaisuutena. Järjestelmän suosio tarjoaa mahdollisuuden rakentaa DevOps- tai kehitysoperaatioita, joissa Kubernetesia käytetään juuri tämän DevOpsin prosessien ajamiseen.

Kuva 1. Kaavamainen esitys Kubernetesin toiminnasta

Täysi automaatio

DevOps on pohjimmiltaan kehitysprosessin automatisointi. Karkeasti sanottuna kehittäjät kirjoittavat koodin, joka ladataan arkistoon. Sitten tämä koodi voidaan automaattisesti kerätä välittömästi säiliöön, jossa on kaikki kirjastot, testata ja "rullaa" seuraavaan vaiheeseen - vaiheeseen ja sitten välittömästi tuotantoon.

Yhdessä Kubernetesin kanssa DevOps mahdollistaa tämän prosessin automatisoinnin niin, että se tapahtuu käytännössä ilman kehittäjien itsensä osallistumista. Tästä johtuen rakentaminen on huomattavasti nopeampaa, koska kehittäjän ei tarvitse tehdä tätä tietokoneellaan - hän yksinkertaisesti kirjoittaa koodinpätkän, työntää koodin arkistoon, minkä jälkeen putkisto käynnistetään, joka voi sisältää prosessin rakentamisesta, testaamisesta ja käyttöönotosta. Ja tämä tapahtuu jokaisen sitoumuksen yhteydessä, joten testausta tapahtuu jatkuvasti.

Samalla konttia käyttämällä voit olla varma, että tämän ohjelman koko ympäristö vapautetaan tuotantoon juuri siinä muodossa, jossa se on testattu. Eli ei tule ongelmia, kuten "joitakin versioita oli testissä, toisia tuotannossa, mutta kun asensimme ne, kaikki putosi." Ja koska meillä on nykyään suuntaus kohti mikropalveluarkkitehtuuria, kun yhden valtavan sovelluksen sijaan on satoja pieniä, niiden manuaaliseen hallintaan tarvitaan valtava määrä työntekijöitä. Siksi käytämme Kubernetesia.

Plussat, plussat, plussat

Jos puhumme Kubernetesin eduista alustana, niin sillä on merkittäviä etuja mikropalveluarkkitehtuurin hallinnan näkökulmasta.

Useiden kopioiden hallinta. Tärkeintä on säilöjen hallinta useiden isäntien välillä. Vielä tärkeämpää on hallita useita sovellusreplikoita säilöissä yhtenä kokonaisuutena. Tämän ansiosta insinöörien ei tarvitse huolehtia jokaisesta yksittäisestä säiliöstä. Jos jokin säilöistä kaatuu, Kubernetes näkee tämän ja käynnistää sen uudelleen.
Klusteriverkko. Kubernetesilla on myös ns. klusteriverkko omalla osoiteavaruudellaan. Tämän ansiosta jokaisella podilla on oma osoite. Subpodilla tarkoitetaan klusterin vähimmäisrakenneyksikköä, jossa kontit laukaistaan suoraan. Lisäksi Kubernetesissa on toimintoja, joissa yhdistyvät kuormituksen tasapainottaja ja Service Discovery. Näin voit päästä eroon manuaalisesta IP-osoitteiden hallinnasta ja delegoida tämän tehtävän Kubernetesille. Automaattiset terveystarkastukset auttavat havaitsemaan ongelmat ja ohjaamaan liikennettä toimiviin koteloihin.
Kokoonpanon hallinta. Kun hallitaan suurta määrää sovelluksia, sovellusten määrityksiä on vaikea hallita. Tätä tarkoitusta varten Kubernetesilla on erityisiä ConfigMap-resursseja. Niiden avulla voit tallentaa kokoonpanot keskitetysti ja paljastaa ne podille, kun sovelluksia ajetaan. Tämän mekanismin avulla voimme taata kokoonpanon yhdenmukaisuuden vähintään kymmenessä tai sadassa sovelluskopiossa.
Pysyvät volyymit. Säilöt ovat luonnostaan muuttumattomia ja kun säilö pysäytetään, kaikki tiedostojärjestelmään kirjoitetut tiedot tuhoutuvat. Mutta jotkut sovellukset tallentavat tiedot suoraan levylle. Tämän ongelman ratkaisemiseksi Kubernetesilla on levytallennushallintatoiminto - Pysyvät taltiot. Tämä mekanismi käyttää ulkoista tallennustilaa tiedoille ja voi siirtää pysyvää tallennustilaa, lohkoa tai tiedostoa, säilöihin. Tämän ratkaisun avulla voit tallentaa tiedot työntekijöistä erillään, mikä säästää heidät, jos samat työntekijät hajoavat.
Load Balancer. Vaikka Kubernetesissa hallinnoimme abstrakteja entiteettejä, kuten Deployment, StatefulSet jne., kontit toimivat lopulta säännöllisesti. virtuaalikoneet Tai paljaita metallipalvelimia. Ne eivät ole täydellisiä ja voivat kaatua milloin tahansa. Kubernetes havaitsee tämän ja ohjaa sisäisen liikenteen muihin replikoihin. Mutta entä ulkoinen liikenne? Pelkkä liikenteen ohjaaminen yhdelle työntekijälle tarkoittaa, että palvelu ei ole käytettävissä, jos se kaatuu. Tämän ongelman ratkaisemiseksi Kubernetes tarjoaa palveluita, kuten Load Balancer. Ne on suunniteltu määrittämään automaattisesti ulkoinen pilvipohjainen kuormituksen tasaaja kaikille klusterin työntekijöille. Tämä ulkoinen kuormituksen tasaaja reitittää ulkoisen liikenteen työntekijöille ja valvoo heidän tilaansa. Jos yksi tai useampi työntekijä tulee pois käytöstä, liikenne ohjataan muille. Näin voit luoda erittäin käytettäviä palveluita Kubernetesin avulla.

Kubernetes toimii parhaiten käytettäessä mikropalveluarkkitehtuureja. Järjestelmä on mahdollista toteuttaa klassiseen arkkitehtuuriin, mutta se on turhaa. Jos sovellus ei voi toimia useissa replikoissa, mitä eroa sillä on - Kubernetesissa vai ei?

Avoimen lähdekoodin Kubernetes

Avoimen lähdekoodin Kubernetes on hieno asia: asensin sen ja se toimii. Voit ottaa sen käyttöön omilla laitteistopalvelimillasi, omassa infrastruktuurissasi, asentaa isännät ja työntekijät, joilla kaikki sovellukset toimivat. Ja mikä tärkeintä, kaikki tämä on ilmaista. On kuitenkin vivahteita.

Ensimmäinen on järjestelmänvalvojien ja insinöörien tiedon ja kokemuksen tarve, jotka ottavat käyttöön ja tukevat kaikkea tätä. Koska asiakas saa klusterissa täydellisen toimintavapauden, hän kantaa itse vastuun klusterin toiminnasta. Ja täällä on erittäin helppoa rikkoa kaikki.
Toinen on integraatioiden puute. Jos käytät Kubernetesia ilman suosittua virtualisointialustaa, et saa kaikkia ohjelman etuja. Kuten Persistent Volumes- ja Load Balancer -palveluiden käyttäminen.

Kuva 2. k8s-arkkitehtuuri

Kubernetes myyjältä

Integrointi pilvipalveluntarjoajan kanssa tarjoaa kaksi vaihtoehtoa:

Ensinnäkin henkilö voi yksinkertaisesti napsauttaa "luo klusteri" -painiketta ja saada klusterin, joka on jo määritetty ja valmis käytettäväksi.
Toiseksi toimittaja itse asentaa klusterin ja määrittää integraation pilveen.

Miten se tapahtuu täällä. Klusterin käynnistävä insinööri määrittää, kuinka monta työntekijää hän tarvitsee ja millä parametreilla (esimerkiksi 5 työntekijää, jokaisessa 10 CPU:ta, 16 Gt RAM-muistia ja esimerkiksi 100 Gt levyä). Tämän jälkeen se saa pääsyn jo muodostettuun klusteriin. Tällöin työntekijät, joille kuorma käynnistetään, siirtyvät kokonaan asiakkaalle, mutta koko hallintataso jää toimittajan vastuulle (jos palvelu tarjotaan hallitun palvelumallin mukaan).

Tällä järjestelmällä on kuitenkin haittapuolensa. Koska hallintataso pysyy toimittajalla, toimittaja ei anna täyttä pääsyä asiakkaalle, mikä vähentää joustavuutta työskennellä Kubernetesin kanssa. Joskus käy niin, että asiakas haluaa lisätä Kubernetesiin tiettyjä toimintoja, esimerkiksi todennuksen LDAP:n kautta, mutta hallintatason konfiguraatio ei tätä salli.

Kuva 3. Esimerkki Kubernetes-klusterista pilvipalveluntarjoajalta

Mitä valita: avoin lähdekoodi tai toimittaja

Onko Kubernetes avoin lähdekoodi vai toimittajakohtainen? Jos otamme avoimen lähdekoodin Kubernetesin, niin käyttäjä tekee sillä mitä haluaa. Mutta on suuri mahdollisuus ampua itseäsi jalkaan. Myyjän kanssa se on vaikeampaa, koska kaikki on harkittu ja konfiguroitu yritykselle. Avoimen lähdekoodin Kubernetesin suurin haitta on asiantuntijoiden tarve. Myyjävaihtoehdolla yritys vapautuu tästä päänsärystä, mutta sen on päätettävä, maksaako se asiantuntijoilleen vai myyjälle.

No, hyvät puolet ovat ilmeisiä, myös haitat tiedetään. Yksi asia on pysyvää: Kubernetes ratkaisee monia ongelmia automatisoimalla monien säiliöiden hallinnan. Ja kumpi valita, avoimen lähdekoodin vai toimittaja - jokainen tekee oman päätöksensä.