Toukokuun lopussa piti aiheesta verkkokokouksen . Puhuimme konteista, Kuberneteistä ja periaatteellisesta orkestroinnista, infrastruktuurin valintakriteereistä ja paljon muusta. Osallistujat jakoivat tapauksia omasta käytännöstään.
osallistujat:
- Jevgeni Potapov, ITSumman toimitusjohtaja. Yli puolet sen asiakkaista on jo muuttamassa tai haluaa vaihtaa Kubernetesiin.
- Dmitri Stolyarov, teknologiajohtaja "Flant". Hänellä on yli 10 vuoden kokemus konttijärjestelmien parissa työskentelemisestä.
- Denis Remchukov (alias Eric Oldmann), COO argotech.io, entinen RAO UES. Hän lupasi puhua tapauksista "verisessä" yrityksessä.
- Andrey Fedorovsky, teknologiajohtaja "News360.com"Kun toinen pelaaja on ostanut yrityksen, hän on vastuussa useista ML- ja AI-projekteista ja infrastruktuurista.
- Ivan Kruglov, järjestelmäinsinööri, ex-Booking.com.Sama henkilö, joka teki paljon Kubernetesin kanssa omin käsin.
Teemat:
- Osallistujien näkemykset konteista ja orkestroinnista (Docker, Kubernetes jne.); mitä on käytännössä kokeiltu tai analysoitu.
- Case: Yritys rakentaa infrastruktuurin kehittämissuunnitelmaa vuosiksi. Kuinka päätös tehdään, rakennetaanko (tai siirretäänkö nykyinen) infrastruktuuri kontteihin ja Kuberiin vai ei?
- Ongelmia pilvi-natiivimaailmassa, mitä puuttuu, kuvitellaan mitä tapahtuu huomenna.
Siitä syntyi mielenkiintoinen keskustelu, osallistujien mielipiteet olivat niin erilaisia ja aiheuttivat niin paljon kommentteja, että haluan jakaa ne teidän kanssanne. Syödä , ja alla on yhteenveto keskustelusta.
Onko Kubernetes jo standardi vai loistava markkinointi?
"Me tulimme siihen (Kubernetes. - Toim.), kun kukaan ei tiennyt siitä vielä. Tulimme hänen luokseen, vaikka hän ei ollut paikalla. Halusimme sen aiemmin" - Dmitri Stolyarov
Kuva: Reddit.com
5-10 vuotta sitten työkaluja oli valtava määrä, eikä yhtä standardia ollut. Kuuden kuukauden välein ilmestyi uusi tuote tai jopa useampi kuin yksi. Ensin Vagrant, sitten Salt, Chef, Puppet,... ja rakennat infrastruktuurisi uudelleen kuuden kuukauden välein. Sinulla on viisi järjestelmänvalvojaa, jotka jatkuvasti kirjoittavat asetuksia uudelleen”, Andrey Fedorovsky muistelee. Hän uskoo, että Docker ja Kubernetes ovat "syrjäyttäneet" loput. Dockerista on tullut standardi viimeisen viiden vuoden aikana, Kubernetes kahden viime vuoden aikana. Ja se on teollisuuden kannalta hyvä asia..
Dmitry Stolyarov ja hänen tiiminsä rakastavat Kuberia. He halusivat sellaisen työkalun ennen kuin se ilmestyi, ja tulivat siihen, kun kukaan ei tiennyt siitä. Tällä hetkellä he eivät mukavuussyistä ota asiakasta vastaan, jos he ymmärtävät, että he eivät ota Kubernetesia käyttöön hänen kanssaan. Samaan aikaan, Dmitryn mukaan, yrityksellä on "monia jättimäisiä menestystarinoita kauhean perinnön uudelleentekemisestä".
Kubernetes ei ole vain konttiorkesteri, se on konfiguroinnin hallintajärjestelmä, jossa on kehitetty API, verkkokomponentti, L3-tasapainotus ja Ingress-ohjaimet, mikä tekee resurssien hallinnasta, skaalaamisesta ja abstraktista infrastruktuurin alemmista kerroksista suhteellisen helppoa.
Valitettavasti elämässämme joudumme maksamaan kaikesta. Ja tämä vero on suuri, varsinkin jos puhumme kehittyneen infrastruktuurin omaavan yrityksen siirtymisestä Kubernetesiin, kuten Ivan Kruglov uskoo. Hän saattoi työskennellä vapaasti niin perinteisen infrastruktuurin omaavassa yrityksessä kuin Kuberin kanssa. Tärkeintä on ymmärtää yrityksen ja markkinoiden ominaisuudet. Mutta esimerkiksi Jevgeni Potapoville, joka yleistäisi Kubernetesin mihin tahansa kontin orkestrointityökaluun, tällaista kysymystä ei esiinny.
Evgeniy veti analogian 1990-luvun tilanteeseen, jolloin olio-ohjelmointi ilmestyi tapana ohjelmoida monimutkaisia sovelluksia. Tuolloin keskustelu jatkui ja OOP:n tueksi ilmaantui uusia työkaluja. Sitten mikropalvelut syntyivät keinona siirtyä pois monoliittisesta konseptista. Tämä puolestaan johti konttien ja kontinhallintatyökalujen syntymiseen. "Uskon, että tulemme pian siihen aikaan, jolloin ei tule epäilystäkään siitä, kannattaako pientä mikropalvelusovellusta kirjoittaa, se kirjoitetaan oletusarvoisesti mikropalveluna", hän uskoo. Samoin Dockerista ja Kubernetesista tulee lopulta vakioratkaisu ilman valinnan tarvetta.
Tietokantojen ongelma valtiottomissa
Kuva
Nykyään on olemassa monia reseptejä tietokantojen ajamiseen Kubernetesissa. Jopa kuinka erottaa I/O-levyn kanssa toimiva osa ehdollisesti tietokannan sovellusosasta. Onko mahdollista, että tulevaisuudessa tietokannat muuttuvat niin paljon, että ne toimitetaan laatikossa, jossa yksi osa ohjataan Dockerin ja Kubernetesin kautta ja toisessa osassa infrastruktuuria erillisen ohjelmiston kautta tallennusosa ? Muuttuvatko pohjat tuotteena?
Tämä kuvaus on samanlainen kuin jonojen hallinta, mutta vaatimukset tietojen luotettavuudelle ja synkronoinnille perinteisissä tietokantoissa ovat paljon korkeammat, Andrey uskoo. Välimuistin osumasuhde normaaleissa tietokannoissa pysyy 99 prosentissa. Jos työntekijä kaatuu, uusi käynnistetään ja välimuisti "lämpenee" tyhjästä. Kunnes välimuisti on lämmennyt, työntekijä toimii hitaasti, mikä tarkoittaa, että sitä ei voi ladata käyttäjän kuormalla. Vaikka käyttäjä ei kuormita, välimuisti ei lämpene. Se on noidankehä.
Dmitry on pohjimmiltaan eri mieltä - päätösvaltaisuus ja sirpalointi ratkaisevat ongelman. Mutta Andrey väittää, että ratkaisu ei sovi kaikille. Joissain tilanteissa päätösvaltaisuus on sopiva, mutta se kuormittaa verkkoa lisää. NoSQL-tietokanta ei sovellu kaikissa tapauksissa.
Tapaamiseen osallistuneet jaettiin kahteen leiriin.
Denis ja Andrey väittävät, että kaikkea, mikä kirjoitetaan levylle - tietokannat ja niin edelleen - on mahdotonta tehdä nykyisessä Kuber-ekosysteemissä. Kubernetesissa on mahdotonta ylläpitää tuotantotietojen eheyttä ja johdonmukaisuutta. Tämä on perusominaisuus. Ratkaisu: hybridiinfrastruktuuri.
Jopa nykyaikaiset pilvipohjaiset tietokannat, kuten MongoDB ja Cassandra, tai viestijonot, kuten Kafka tai RabbitMQ, vaativat pysyviä tietovarastoja Kubernetesin ulkopuolella.
Evgeniy vastustaa: "Kuberan tukikohdat ovat lähellä venäläistä tai yritysläheistä vahinkoa, joka liittyy siihen, että Venäjällä ei ole Cloud Adoptionia." Pienet tai keskisuuret yritykset lännessä ovat Cloud. Amazon RDS-tietokantoja on helpompi käyttää kuin itse Kubernetesin kanssa puuhailla. Venäjällä he käyttävät Kuberia "on-premisessä" ja siirtävät siihen tukikohtia, kun he yrittävät päästä eroon eläintarhasta.
Dmitry oli myös eri mieltä väitteestä, jonka mukaan Kubernetesissa ei voida pitää tietokantoja: ”Kanta on erilainen kuin kanta. Ja jos työnnät jättimäistä relaatiotietokantaa, niin ei missään olosuhteissa. Jos työnnät jotain pientä ja pilvistä syntyperäistä, joka on henkisesti valmistautunut puoliaikaiseen elämään, kaikki on hyvin. Dmitry mainitsi myös, että tietokannan hallintatyökalut eivät ole valmiita Dockerille tai Kuberille, joten suuria vaikeuksia syntyy.
Ivan puolestaan on varma, että vaikka irtautuisimme valtiollisen ja valtiottoman käsitteistä, yritysratkaisujen ekosysteemi Kubernetesissa ei ole vielä valmis. Kuberin kanssa on vaikea ylläpitää lainsäädännöllisiä ja sääntelyvaatimuksia. On esimerkiksi mahdotonta tehdä identiteetin varmistusratkaisua, jossa vaaditaan tiukat palvelimen tunnistustakuut aina palvelimiin asennettavaan laitteistoon asti. Tämä alue kehittyy, mutta ratkaisua ei vielä ole.
Osallistujat eivät päässeet yksimielisyyteen, joten tässä osassa ei tehdä johtopäätöksiä. Otetaan pari käytännön esimerkkiä.
Tapaus 1. "Mega-regulaattorin" kyberturvallisuus, jonka tukiasemat ovat Kuberan ulkopuolella
Kehittyneen kyberturvallisuusjärjestelmän tapauksessa konttien ja orkestroinnin avulla voidaan torjua hyökkäyksiä ja tunkeutumisia. Esimerkiksi yhdessä mega-säätelijässä Denis ja hänen tiiminsä ottivat käyttöön yhdistelmän orkesterin ja koulutetun SIEM-palvelun kanssa, joka analysoi lokit reaaliajassa ja määrittää hyökkäyksen, hakkeroinnin tai epäonnistumisen prosessin. Hyökkäyksen, yrityksen sijoittamisyrityksen tai ransomware-viruksen hyökkäyksen sattuessa se poimii orkesterin kautta kontteja sovelluksilla nopeammin kuin ne saavat tartunnan tai nopeammin kuin hyökkääjä hyökkää niihin.
Tapaus 2. Booking.com-tietokantojen osittainen siirto Kubernetesiin
Booking.comissa päätietokanta on MySQL asynkronisella replikaatiolla - siellä on isäntä ja kokonainen orjahierarkia. Kun Ivan lähti yrityksestä, käynnistettiin projekti sellaisten orjien siirtämiseksi, jotka voitiin "ammua" tietyillä vaurioilla.
Pääpohjan lisäksi mukana on Cassandra-installaatio itsekirjoitetulla orkestraatiolla, joka on kirjoitettu jo ennen kuin Kuber tuli valtavirtaan. Tässä suhteessa ei ole ongelmia, mutta se on jatkuva paikallisilla SSD-levyillä. Etätallennustilaa ei käytetä, vaikka se olisikaan samassa datakeskuksessa, korkean viiveen vuoksi.
Kolmas tietokantaluokka on Booking.com-hakupalvelu, jossa jokainen palvelusolmu on tietokanta. Yritykset siirtää hakupalvelu Kuberiin epäonnistuivat, koska jokaisessa solmussa on 60-80 Gt paikallista tallennustilaa, jota on vaikea "nostaa" ja "lämmittää".
Tämän seurauksena hakukonetta ei siirretty Kubernetesiin, eikä Ivan usko, että lähitulevaisuudessa tulee uusia yrityksiä. MySQL-tietokanta siirrettiin puoliksi: vain orjat, jotka eivät pelkää tulla "ammuksi". Cassandra on sopeutunut täydellisesti.
Infrastruktuurin valinta tehtävänä ilman yleistä ratkaisua
Kuva
Oletetaan, että meillä on uusi yritys tai yritys, jossa osa infrastruktuurista on rakennettu vanhalla tavalla. Se rakentaa infrastruktuurin kehittämissuunnitelmaa vuosiksi. Miten päätetään rakentaako infrastruktuuri konteille ja Kuberille vai ei?
Yritykset, jotka taistelevat nanosekunneista, suljetaan keskustelun ulkopuolelle. Terve konservatiivisuus kannattaa luotettavuuden kannalta, mutta silti on yrityksiä, joiden pitäisi harkita uusia lähestymistapoja.
Ivan: "Perustaisin ehdottomasti yrityksen nyt pilvessä, koska se on nopeampi", vaikkakaan ei välttämättä halvempaa. Pääomakapitalismin kehittyessä startupilla ei ole suuria ongelmia rahan kanssa, ja päätehtävänä on valloittaa markkinat.
Ivan on sitä mieltä nykyisen infrastruktuurin kehittäminen on valintakriteeri. Jos aiemmin on tehty vakava investointi ja se toimii, ei ole mitään järkeä tehdä sitä uudelleen. Jos infrastruktuuria ei ole kehitetty ja työkalujen, turvallisuuden ja valvonnan kanssa on ongelmia, on järkevää tarkastella hajautettua infrastruktuuria.
Vero on joka tapauksessa maksettava, ja Ivan maksaisi sen, mikä antoi hänelle mahdollisuuden maksaa vähemmän tulevaisuudessa. "Koska jo pelkästään sen perusteella, että matkustan junassa, jota muut liikkuvat, matkustan paljon pidemmälle kuin jos istun toisessa junassa, johon minun täytyy itse laittaa polttoainetta."Ivan sanoo. Kun yritys on uusi ja latenssivaatimukset ovat kymmeniä millisekunteja, niin Ivan katsoisi "operaattoreihin", joihin klassiset tietokannat "kääritään" nykyään. Ne nostavat replikointiketjun, joka vaihtaa itsensä vikasietotilanteessa jne...
Pienelle yritykselle, jolla on pari palvelinta, Kuberassa ei ole mitään järkeä”, Andrey sanoo. Mutta jos se aikoo kasvaa satoihin tai useampiin palvelimiin, se tarvitsee automaatiota ja resurssienhallintajärjestelmän. 90 % tapauksista on hintansa arvoisia. Lisäksi kuormituksesta ja resursseista riippumatta. On järkevää, että kaikki, startup-yrityksistä suuriin yrityksiin, joilla on miljoonia yleisöjä, katsovat vähitellen kontin orkestrointituotteisiin. "Kyllä, tämä on todella tulevaisuutta", Andrey on varma.
Denis hahmotteli kaksi pääkriteeriä - skaalautuvuus ja toiminnan vakaus. Hän valitsee tehtävään parhaiten sopivat työkalut. "Se voisi olla polvillesi koottu noname, ja siinä on Nutanix Community Edition. Tämä voisi olla toinen rivi Kuberin sovelluksen muodossa, jonka taustalla on tietokanta, joka on replikoitu ja jossa on määritetty RTO- ja RPO-parametrit" (palautusaika/pistetavoitteet - noin).
Evgeni tunnisti mahdollisen ongelman henkilöstössä. Tällä hetkellä markkinoilla ei ole paljon korkeasti päteviä asiantuntijoita, jotka ymmärtäisivät "suun". Todellakin, jos valittu tekniikka on vanhaa, on vaikea palkata muita kuin keski-ikäisiä, jotka ovat kyllästyneitä ja kyllästyneitä elämään. Vaikka muut osallistujat uskovat, että tässä on kysymys henkilöstön koulutuksesta.
Jos asetetaan valintakysymys: käynnistää pieni yritys Public Cloudissa Amazon RDS:n tietokannoilla tai "paikalla" Kubernetesin tietokannoilla, niin joistakin puutteista huolimatta Amazon RDS:stä tuli osallistujien valinta.
Koska suurin osa tapaamisen kuuntelijoista ei ole "verisestä" yrityksestä, niin hajautetut ratkaisut ovat se, mihin meidän pitäisi pyrkiä. Tiedontallennusjärjestelmien on oltava hajautettuja, luotettavia ja luotava viive, joka mitataan millisekuntien yksiköissä, enintään kymmenissä", Andrey tiivisti.
Kubernetesin käytön arviointi
Kuuntelija Anton Zhbankov esitti ansakysymyksen Kubernetesin anteeksiantajille: miten valitsit ja suoritit toteutettavuustutkimuksen? Miksi Kubernetes, miksi ei esimerkiksi virtuaalikoneet?
Kuva
Dmitri ja Ivan vastasivat siihen. Molemmissa tapauksissa yrityksen ja erehdyksen kautta tehtiin sarja päätöksiä, joiden seurauksena molemmat osallistujat saapuivat Kubernetesiin. Nyt yritykset alkavat itsenäisesti kehittää ohjelmistoja, jotka on järkevää siirtää Kuberille. Emme puhu klassisista kolmannen osapuolen järjestelmistä, kuten 1C. Kubernetes auttaa, kun kehittäjien on tehtävä nopeasti julkaisuja, jatkuvalla jatkuvalla parannuksella.
Andreyn tiimi yritti luoda virtuaalikoneiden pohjalta skaalautuvan klusterin. Solmut putosivat kuin domino, mikä joskus johti klusterin romahtamiseen. ”Teoreettisesti voit viimeistellä sen ja tukea sitä käsin, mutta se on tylsää. Ja jos markkinoilla on ratkaisu, jonka avulla voit työskennellä suoraan laatikosta, ryhdymme siihen mielellämme. Ja sen seurauksena vaihdoimme”, Andrey sanoo.
Tällaista analysointia ja laskentaa varten on olemassa standardeja, mutta kukaan ei voi sanoa, kuinka tarkkoja ne ovat todellisissa käytössä olevissa laitteissa. Laskelmien kannalta on myös tärkeää ymmärtää jokainen työkalu ja ekosysteemi, mutta se ei ole mahdollista.
Mikä meitä odottaa
Kuva
Teknologian kehittyessä ilmaantuu yhä enemmän erilaisia kappaleita, ja sitten tapahtuu vaihemuutos, jolloin ilmaantuu myyjä, joka on tappanut tarpeeksi taikinaa, jotta kaikki yhdistyisi yhdeksi työkaluksi.
Luuletko, että tulee aika, jolloin Linux-maailmaan tulee Ubuntun kaltainen työkalu? Ehkä yksi kontti- ja orkestrointityökalu sisältää Kuberin. Sen avulla on helppo rakentaa paikan päällä olevia pilviä.
Ivan antoi vastauksen: "Google rakentaa nyt Anthosia - tämä on heidän paketoitu tarjouksensa, joka ottaa käyttöön pilven ja sisältää Kuberin, Service Meshin, valvonnan - kaikki laitteistot, joita tarvitaan paikallisiin mikropalveluihin." Olemme melkein tulevaisuudessa."
Denis mainitsi myös Nutanixin ja VMWaren vRealize Suite -tuotteen kanssa, joka pystyy selviytymään samanlaisesta tehtävästä ilman konttia.
Dmitry jakoi näkemyksensä, että "kivun" vähentäminen ja verojen alentaminen ovat kaksi aluetta, joilla voimme odottaa parannuksia.
Yhteenvetona keskustelusta korostamme seuraavia modernin infrastruktuurin ongelmia:
- Kolme osallistujaa havaitsi välittömästi ongelman statefulissa.
- Erilaisia tietoturvatukiongelmia, mukaan lukien mahdollisuus, että Docker päätyy useisiin Python-versioihin, sovelluspalvelimiin ja komponentteihin.
Ylikulutus, josta on parempi keskustella erillisessä kokouksessa.
Oppimishaaste orkestrointina on monimutkainen ekosysteemi.
Alan yleinen ongelma on työkalujen väärinkäyttö.Loput johtopäätökset ovat sinun. Edelleen tuntuu, ettei Docker+Kubernetes-yhdistelmästä ole helppoa tulla järjestelmän "keskeiseksi" osaksi. Esimerkiksi käyttöjärjestelmät asennetaan ensin laitteistolle, mitä ei voida sanoa konteista ja orkestraatiosta. Ehkä tulevaisuudessa käyttöjärjestelmät ja kontit sulautuvat pilvihallintaohjelmistoihin.
KuvaHaluaisin käyttää tilaisuutta hyväkseni ja tervehtiä äitiäni ja muistuttaa, että meillä on Facebook-ryhmä , kanava mielenkiintoisia julkaisuja eri teknologiablogeista. Ja kanavani , jossa puhun tuoteyritysten kehityksen johtamisesta.
Lähde: will.com