Odotettaessa Vitali Habarov haastateltu Dmitri Stolyarov (), Flant-yhtiön tekninen johtaja ja perustaja. Vitaly kysyi Dmitryltä mitä Flant tekee, Kubernetesista, ekosysteemien kehityksestä, tuesta. Keskustelimme siitä, miksi Kubernetesia tarvitaan ja tarvitaanko sitä ollenkaan. Ja myös mikropalveluista, Amazon AWS:stä, "I'll be lucky" -lähestymistavasta DevOpsiin, itse Kubernetesin tulevaisuudesta, miksi, milloin ja miten se valtaa maailman, DevOpsin tulevaisuudennäkymistä ja mihin insinöörien tulisi valmistautua valoisa ja lähitulevaisuus yksinkertaistamisen ja hermoverkkojen avulla.
kuuntele podcastina DevOps Deflopissa - venäjänkielisessä podcastissa DevOpsista, ja alla on tekstiversio.
Täällä ja alla hän kysyy kysymyksiä insinööri Express42:sta.
Tietoja "Flantista"
- Hei Dima. Olet tekninen johtaja""ja myös sen perustaja. Kerro meille, mitä yritys tekee ja mitä olet siinä?
Dmitry: Ulkopuolelta näyttää siltä, että olemme niitä tyyppejä, jotka asentavat Kubernetesia kaikille ja tekevät sillä jotain. Mutta se ei ole totta. Aloitimme Linuxia käsittelevänä yrityksenä, mutta erittäin pitkään päätoimialamme on ollut tuotannon ja suuren kuormituksen avaimet käteen -projektien huolto. Yleensä rakennamme koko infrastruktuurin tyhjästä ja sitten olemme vastuussa siitä pitkään, pitkään. Siksi "Flantin" pääasiallinen työ, josta se saa rahaa, on vastuunotto ja avaimet käteen -tuotannon toteuttaminen.
Yrityksen teknisenä johtajana ja yhtenä perustajista vietän koko päivän ja yön yrittäen selvittää, kuinka lisätä tuotannon saavutettavuutta, yksinkertaistaa sen toimintaa, tehdä ylläpitäjien elämästä helpompaa ja kehittäjien elämästä miellyttävämpää. .
Tietoja Kubernetesista
– Viime aikoina olen nähnyt paljon raportteja Flantista ja Kubernetesista. Miten päädyit siihen?
Dmitry: Olen puhunut tästä jo monta kertaa, mutta en välitä toistaa sitä ollenkaan. Mielestäni on oikein toistaa tämä aihe, koska syyn ja seurauksen välillä on sekaannusta.
Tarvitsimme todella työkalun. Kohtasimme paljon ongelmia, kamppailimme, voitimme ne erilaisilla kainalosauvoilla ja tunsimme työkalun tarpeen. Kävimme läpi monia eri vaihtoehtoja, rakensimme omia polkupyöriä ja saimme kokemusta. Vähitellen pääsimme siihen pisteeseen, että aloimme käyttää Dockeria melkein heti sen ilmestyttyä - noin 2013. Sen ilmestyessä meillä oli jo paljon kokemusta konteista, olimme jo kirjoittaneet "Dockerin" analogin - joitain omia kainalosauvojamme Pythonissa. Dockerin käyttöönoton myötä oli mahdollista heittää pois kainalosauvat ja käyttää luotettavaa ja yhteisön tukemaa ratkaisua.
Kuberneteksen kanssa tarina on samanlainen. Kun se alkoi saada vauhtia - meille tämä on versio 1.2 - meillä oli jo joukko kainalosauvoja sekä Shellissä että Chefissä, joita yritimme jotenkin orkestroida Dockerin kanssa. Etsimme vakavasti Rancheria ja monia muita ratkaisuja, mutta sitten ilmestyi Kubernetes, jossa kaikki on toteutettu juuri niin kuin olisimme tehneet tai jopa paremmin. Ei ole mitään valittamista.
Kyllä, tässä on jonkinlaista epätäydellisyyttä, siellä on jonkinlaista epätäydellisyyttä - puutteita on paljon, ja 1.2 on yleensä kauhea, mutta... Kubernetes on kuin rakenteilla oleva rakennus - katsot projektia ja ymmärrät että siitä tulee siistiä. Jos rakennuksessa on nyt perustus ja kaksi kerrosta, niin ymmärrät, että on parempi olla muuttamatta vielä, mutta ohjelmistossa ei ole tällaisia ongelmia - voit jo käyttää sitä.
Meillä ei ollut hetkeäkään, jolloin ajattelimme käyttää Kubernetesia vai ei. Odotimme sitä kauan ennen kuin se ilmestyi, ja yritimme luoda analogeja itse.
Tietoja Kubernetesista
— Oletko itse suoraan mukana Kuberneteksen kehittämisessä?
Dmitry: Keskiverto. Sen sijaan osallistumme ekosysteemin kehittämiseen. Lähetämme tietyn määrän vetopyyntöjä: Prometheukselle, eri operaattoreille, Helmille - ekosysteemille. Valitettavasti en pysty seuraamaan kaikkea, mitä teemme, ja voin olla väärässä, mutta ytimeen ei ole ainuttakaan poolia.
— Kehitätkö samalla monia työkalujasi Kubernetesin ympärille?
Dmitry: Strategia on tämä: menemme ja vedämme pyyntöjä kaikkeen, mikä on jo olemassa. Jos vetopyyntöjä ei hyväksytä siellä, yksinkertaisesti haarukkaamme ne itse ja elämme, kunnes ne hyväksytään rakennustemme kanssa. Sitten, kun se saavuttaa ylävirran, palaamme takaisin ylävirran versioon.
Meillä on esimerkiksi Prometheus-operaattori, jolla vaihdoimme edestakaisin kokoonpanomme ylävirtaan jo varmaan 5 kertaa. Tarvitsemme jonkinlaisen ominaisuuden, lähetimme vetopyynnön, meidän on otettava se käyttöön huomenna, mutta emme halua odottaa sen julkaisua alkuvaiheessa. Sen mukaisesti kokoamme itsellemme, levitämme kokoonpanomme jostain syystä tarvitsemamme ominaisuudellamme kaikkiin klustereihimme. Sitten he esimerkiksi luovuttavat sen meille ylävirtaan sanoilla: "Kaverit, tehdään se yleisempään tapaukseen", me tai joku muu viimeistelemme sen, ja ajan myötä se sulautuu takaisin.
Yritämme kehittää kaikkea olemassa olevaa. Monet elementit, joita ei vielä ole olemassa, joita ei ole vielä keksitty tai jotka on keksitty, mutta joita ei ole ehtinyt toteuttaa - teemme sen. Eikä siksi, että pidämme prosessista tai polkupyörän rakentamisesta toimialana, vaan yksinkertaisesti siksi, että tarvitsemme tätä työkalua. Usein kysytään, miksi teimme tämän tai sen? Vastaus on yksinkertainen - kyllä, koska meidän piti mennä pidemmälle, ratkaista jokin käytännön ongelma, ja ratkaisimme sen tällä tulalla.
Polku on aina tällainen: etsimme tarkoin ja jos emme löydä ratkaisua, kuinka leivästä raitiovaunua, niin teemme oman leivän ja oman johdinbussin.
Flanta työkalut
— Tiedän, että Flantilla on nyt lisäoperaattoreita, komentotulkkioperaattoreita ja dapp/werf-työkaluja. Ymmärtääkseni tämä on sama instrumentti eri inkarnaatioissa. Ymmärrän myös, että Flauntissa on paljon enemmän erilaisia työkaluja. Tämä on totta?
Dmitry: Meillä on paljon muuta GitHubissa. Nyt muistaakseni meillä on statuskartta - Grafana-paneeli, johon kaikki ovat törmänneet. Se mainitaan lähes joka toisessa artikkelissa Kubernetes-seurannasta Mediumissa. On mahdotonta selittää lyhyesti, mitä tilakartta on - se tarvitsee erillisen artikkelin, mutta se on erittäin hyödyllinen asia tilan seuraamiseen ajan mittaan, koska Kubernetesissa meidän on usein näytettävä tila ajan mittaan. Meillä on myös LogHouse - tämä on ClickHouseen ja mustaan magiaan perustuva juttu tukkien keräämiseen Kubernetesissa.
Paljon apuohjelmia! Ja niitä tulee vielä enemmän, koska useita sisäisiä ratkaisuja julkaistaan tänä vuonna. Erittäin suurista lisäosien operaattoriin perustuvista lisäosista on joukko lisäyksiä Kubernetesille, ai kuinka asentaa sert manager oikein - työkalu varmenteiden hallintaan, kuinka Prometheus asennetaan oikein joukolla lisävarusteita - näitä on noin kaksikymmentä erilaista binäärit, jotka vievät tietoja ja keräävät jotain, tähän Prometheukseen on upeimmat grafiikat ja hälytykset. Kaikki tämä on vain joukko Kubernetesin lisäosia, jotka asennetaan klusteriin, ja se muuttuu yksinkertaisesta viileäksi, kehittyneeksi, automaattiseksi, jossa monet ongelmat on jo ratkaistu. Kyllä, teemme paljon.
Ekosysteemin kehitys
"Minusta tuntuu, että tämä on erittäin suuri panos tämän instrumentin ja sen käyttötapojen kehitykseen." Voitko karkeasti arvioida, kuka muu tekisi saman panoksen ekosysteemin kehitykseen?
Dmitry: Venäjällä markkinoillamme toimivista yrityksistä kukaan ei ole lähelläkään. Tietenkin tämä on äänekäs lausunto, koska on olemassa suuria toimijoita, kuten Mail ja Yandex - he tekevät myös jotain Kubernetesin kanssa, mutta hekään eivät ole lähellä niiden yritysten panosta koko maailmassa, jotka tekevät paljon enemmän kuin me. On vaikea verrata Flantia, jossa on 80 työntekijää, ja Red Hatia, jossa on 300 insinööriä yksin Kubernetesia kohden, jos en erehdy. Sitä on vaikea verrata. Meillä on 6 henkilöä RnD-osastolla, minä mukaan lukien, ja leikkaamme kaikki työkalumme. 6 ihmistä vs. 300 Red Hat -insinööriä - sitä on jotenkin vaikea verrata.
- Kuitenkin, kun nämä 6 henkilöä voivat tehdä jotain todella hyödyllistä ja vieraantuvaa, kun he kohtaavat käytännön ongelman ja tarjoavat ratkaisun yhteisölle - mielenkiintoinen tapaus. Ymmärrän, että suurissa teknologiayrityksissä, joissa on oma Kubernetes-kehitys- ja tukitiimi, voidaan periaatteessa kehittää samoja työkaluja. Tämä on heille esimerkki siitä, mitä voidaan kehittää ja antaa yhteisölle, mikä antaa sysäyksen koko Kubernetesia käyttävälle yhteisölle.
Dmitry: Tämä on luultavasti integraattorin ominaisuus, sen erikoisuus. Meillä on monia projekteja ja näemme monia erilaisia tilanteita. Meille tärkein tapa luoda lisäarvoa on analysoida näitä tapauksia, löytää yhteistä ja tehdä niistä meille mahdollisimman halpoja. Työskentelemme aktiivisesti asian eteen. Minun on vaikea puhua Venäjästä ja maailmasta, mutta yhtiössämme on noin 40 DevOps-insinööriä, jotka työskentelevät Kubernetesin parissa. En usko, että Venäjällä on monia yrityksiä, joilla on vastaava määrä asiantuntijoita, jotka ymmärtävät Kubernetesin, jos ollenkaan.
Ymmärrän kaiken nimikkeestä DevOps-insinööri, kaikki ymmärtävät kaiken ja ovat tottuneet kutsumaan DevOps-insinöörejä DevOps-insinööreiksi, emme keskustele tästä. Kaikki nämä 40 hämmästyttävää DevOps-insinööriä kohtaavat ja ratkaisevat ongelmia joka päivä, me vain analysoimme tämän kokemuksen ja yritämme yleistää. Ymmärrämme, että jos se jää sisällemme, vuoden tai kahden kuluttua työkalu on hyödytön, koska jonnekin yhteisöön ilmestyy valmis Tula. Ei ole mitään järkeä kerätä tätä kokemusta sisäisesti - se yksinkertaisesti kuluttaa energiaa ja aikaa dev/null-arvoon. Ja emme ole pahoillamme siitä ollenkaan. Julkaisemme kaiken suurella ilolla ja ymmärrämme, että sitä on julkaistava, kehitettävä, edistettävä, edistettävä, jotta ihmiset käyttävät sitä ja lisäävät kokemuksiaan - silloin kaikki kasvaa ja elää. Sitten kahden vuoden kuluttua instrumentti ei mene roskakoriin. Ei ole sääli jatkaa voimien kaatamista, koska on selvää, että joku käyttää työkaluasi, ja kahden vuoden kuluttua kaikki käyttävät sitä.
Tämä on osa suurta strategiaamme dapp/werfin kanssa. En muista milloin aloimme tehdä sitä, näyttää siltä kuin 3 vuotta sitten. Aluksi se oli yleensä kuoren päällä. Se oli loistava todiste konseptista, ratkaisimme osan erityisistä ongelmistamme - se toimi! Mutta kuoressa on ongelmia, sitä on mahdotonta laajentaa, ohjelmointi kuoressa on toinen tehtävä. Meillä oli tapana kirjoittaa Rubylla, joten teimme jotain uudelleen Rubylla, kehitimme, kehitimme, kehitimme ja törmäsimme siihen tosiasiaan, että yhteisö, joukko, joka ei sano "haluamme sitä tai emme halua, ” kääntää nenäänsä Rubylle, Miten tämä ei ole hauskaa? Ymmärsimme, että meidän pitäisi kirjoittaa kaikki nämä asiat Go-kirjaan vain täyttääksemme tarkistuslistan ensimmäisen kohdan: DevOps-työkalun tulee olla staattinen binaari. Olla Go vai ei, ei ole niin tärkeää, mutta Go-kielellä kirjoitettu staattinen binaari on parempi.
Käytimme energiaamme, kirjoitimme dappin uudelleen Go:ssa ja kutsuimme sitä werf:ksi. Dappia ei enää tueta, sitä ei kehitetä, se toimii jossain uusimmassa versiossa, mutta siellä on ehdoton päivityspolku huipulle, ja voit seurata sitä.
Miksi dapp luotiin?
— Voitko kertoa lyhyesti, miksi dapp luotiin, mitä ongelmia se ratkaisee?
Dmitry: Ensimmäinen syy on kokoonpanossa. Aluksi meillä oli vakavia ongelmia rakentamisen kanssa, kun Dockerilla ei ollut monivaiheisia ominaisuuksia, joten teimme monivaiheisen itse. Sitten meillä oli paljon enemmän ongelmia kuvan puhdistamisen kanssa. Jokainen CI/CD:tä tekevä kohtaa ennemmin tai myöhemmin sen ongelman, että kerättyjä kuvia on kasa, täytyy jotenkin puhdistaa tarpeettomat ja jättää tarpeeton.
Toinen syy on käyttöönotto. Kyllä, Helm on olemassa, mutta se ratkaisee vain osan ongelmista. Hassua kyllä, siellä on kirjoitettu, että "Helm on Kubernetesin pakettipäällikkö." Juuri mitä "on". Siellä on myös sanat "Pakettipäällikkö" - mitä normaalisti paketinhoitajalta odotetaan? Sanomme: "Paketinhallinta - asenna paketti!" ja odotamme hänen sanovan meille: "Paketti on toimitettu."
On mielenkiintoista, että sanomme: "Helm, asenna paketti", ja kun hän vastaa asentaneensa sen, käy ilmi, että hän juuri aloitti asennuksen - hän osoitti Kubernetesille: "Käynnistä tämä juttu!" ja alkoiko se vai ei. , toimiipa se tai ei, Helm ei ratkaise tätä ongelmaa ollenkaan.
Osoittautuu, että Helm on vain tekstin esikäsittely, joka lataa tietoja Kubernetesiin.
Mutta osana käyttöönottoa haluamme tietää, onko sovellus julkaistu tuotantoon vai ei? Prod-versioksi ottaminen tarkoittaa, että sovellus on siirtynyt sinne, uusi versio on otettu käyttöön, eikä se ainakaan kaatu siellä ja vastaa oikein. Helm ei ratkaise tätä ongelmaa millään tavalla. Sen ratkaisemiseksi sinun on käytettävä paljon vaivaa, koska sinun on annettava Kubernetesille komento ottaa käyttöön ja seurata, mitä siellä tapahtuu - onko se otettu käyttöön vai otettu käyttöön. Ja siellä on myös paljon käyttöönottoon, puhdistukseen ja kokoonpanoon liittyviä tehtäviä.
suunnitelmat
Tänä vuonna aloitamme paikallisen kehittämisen. Haluamme saavuttaa sen, mikä oli aiemmin Vagrantissa - kirjoitimme "vagrant up" ja otimme käyttöön virtuaalikoneita. Haluamme päästä pisteeseen, jossa Gitissä on projekti, kirjoitamme sinne "werf up", ja se tuo esiin tämän projektin paikallisen kopion, joka on otettu käyttöön paikallisessa mini-Kubissa, ja kaikki kehittämiseen sopivat hakemistot on yhdistetty. . Kehityskielestä riippuen tämä tehdään eri tavalla, mutta kuitenkin niin, että paikallinen kehitys onnistuu kätevästi asennettujen tiedostojen alla.
Seuraava askel meille on panostaa kehittäjien mukavuuteen. Jos haluat ottaa projektin nopeasti käyttöön paikallisesti yhdellä työkalulla, kehitä se, työnnä se Gitiin, ja se myös siirtyy vaiheeseen tai testeihin putkistosta riippuen ja käytä sitten samaa työkalua tuotantoon siirtymiseen. Tämä yhtenäisyys, yhtenäisyys, infrastruktuurin toistettavuus paikallisesta ympäristöstä myyntiin on meille erittäin tärkeä asia. Mutta tämä ei ole vielä werfissä - aiomme vain tehdä sen.
Mutta polku dapp/werfiin on aina ollut sama kuin Kubernetesin kanssa alussa. Kohtasimme ongelmia, ratkaisimme ne kiertotapojen avulla – keksimme ratkaisuja itsellemme kuoren pohjalta, mihin tahansa. Sitten he yrittivät jotenkin oikaista näitä kiertotapoja, yleistää ja konsolidoida ne binääritiedostoiksi tässä tapauksessa, jotka me yksinkertaisesti jaamme.
On toinenkin tapa tarkastella tätä koko tarinaa analogioiden avulla.
Kubernetes on auton runko moottorilla. Ei ole ovia, lasia, radiota, joulukuusta - ei mitään. Vain runko ja moottori. Ja siellä on Helm - tämä on ohjauspyörä. Siistiä - siellä on ohjauspyörä, mutta tarvitset myös ohjaustapin, ohjaustangon, vaihdelaatikon ja pyörät, etkä tule toimeen ilman niitä.
Werfin tapauksessa tämä on toinen Kubernetesin komponentti. Vasta nyt esimerkiksi werfin alfaversiossa Helm on käännetty werfin sisään, koska olemme kyllästyneet tekemään sitä itse. Tähän on monia syitä, kerron sinulle yksityiskohtaisesti siitä, miksi kokosimme koko ruorin yhdessä ohjausaisan kanssa werfin sisällä .
Nyt werf on integroidumpi komponentti. Saamme valmiin ohjauspyörän, ohjaustapin - en ole kovin hyvä autoissa, mutta tämä on suuri lohko, joka ratkaisee jo melko laajan valikoiman ongelmia. Meidän ei tarvitse käydä luetteloa läpi itse, valita yhtä osaa toiselle, miettiä, kuinka ne ruuvataan yhteen. Saamme valmiin puimurin, joka ratkaisee suuren määrän ongelmia kerralla. Mutta sisällä se on rakennettu samoista avoimen lähdekoodin komponenteista, se käyttää edelleen Dockeria kokoonpanoon, Helmiä joihinkin toimintoihin ja useita muita kirjastoja. Tämä on integroitu työkalu, jolla saat viileät CI-/CD-levyt pois pakkauksesta nopeasti ja kätevästi.
Onko Kubernetes vaikea ylläpitää?
— Kerrot kokemuksesta, että aloit käyttämään Kubernetesia, tämä on sinulle runko, moottori, ja siihen voi ripustaa paljon erilaisia asioita: rungon, ohjauspyörän, polkimet, istuimet. Herää kysymys - kuinka vaikeaa Kubernetes-tuki on sinulle? Sinulla on paljon kokemusta, kuinka paljon aikaa ja resursseja käytät Kuberneteksen tukemiseen erillään kaikesta muusta?
Dmitry: Tämä on erittäin vaikea kysymys, ja vastataksemme meidän on ymmärrettävä, mitä tuki on ja mitä haluamme Kubernetesilta. Ehkä voit paljastaa?
— Tietääkseni ja nähdäkseni nyt monet joukkueet haluavat kokeilla Kubernetesia. Jokainen valjastaa itsensä siihen, laskee sen polvilleen. Minusta tuntuu, että ihmiset eivät aina ymmärrä tämän järjestelmän monimutkaisuutta.
Dmitry: Se on noin.
— Kuinka vaikeaa on ottaa ja asentaa Kubernetes alusta alkaen tuotantovalmiiksi?
Dmitry: Kuinka vaikeaa luulet sydämen siirtämisen olevan? Ymmärrän, että tämä on kompromissi kysymys. Veitsen käyttäminen ja virheen tekemättä jättäminen ei ole niin vaikeaa. Jos he kertovat sinulle, missä leikata ja missä ommella, itse menettely ei ole monimutkainen. On vaikea taata kerta toisensa jälkeen, että kaikki järjestyy.
Kubernetesin asentaminen ja toimiminen on helppoa: poju! — asennettu, asennustapoja on monia. Mutta mitä tapahtuu, kun ongelmia ilmenee?
Aina herää kysymyksiä - mitä emme ole vielä ottaneet huomioon? Mitä emme ole vielä tehneet? Mitkä Linux-ytimen parametrit määritettiin väärin? Herra, mainitsimmeko edes niitä?! Mitä Kubernetes-komponentteja olemme toimittaneet ja mitä emme? Esiin tulee tuhansia kysymyksiä, ja niihin vastaamiseksi sinun täytyy viettää 15-20 vuotta tällä alalla.
Minulla on tuore esimerkki tästä aiheesta, joka saattaa paljastaa ongelman "Onko Kubernetes vaikea ylläpitää?" Jokin aika sitten pohdimme vakavasti, pitäisikö meidän yrittää toteuttaa Ciliumin verkostona Kubernetesissa.
Selitän, mikä Cilium on. Kubernetesilla on monia erilaisia verkkoalijärjestelmän toteutuksia, ja yksi niistä on erittäin siisti - Cilium. Mikä sen merkitys on? Ytimessä tuli jokin aika sitten mahdolliseksi kirjoittaa ytimelle koukkuja, jotka tavalla tai toisella tunkeutuvat verkkoalijärjestelmään ja useisiin muihin alijärjestelmiin ja mahdollistavat suurten osien ohituksen ytimessä.
Linux-ytimessä on historiallisesti ip-reititys, ylisuodatin, siltoja ja monia erilaisia vanhoja komponentteja, jotka ovat 15, 20, 30 vuotta vanhoja. Yleensä ne toimivat, kaikki on hienoa, mutta nyt he ovat kasaneet kontteja, ja se näyttää 15 tiilen tornilta päällekkäin, ja seisot sen päällä yhdellä jalalla - outo tunne. Tämä järjestelmä on historiallisesti kehittynyt monilla vivahteilla, kuten umpilisäke kehossa. Joissakin tilanteissa on esimerkiksi suorituskykyongelmia.
Siellä on upea BPF ja kyky kirjoittaa koukkuja ytimeen - kaverit kirjoittivat omat koukut ytimeen. Paketti tulee Linux-ytimeen, ne ottavat sen pois heti syötteestä, käsittelevät sen itse niin kuin pitääkin ilman siltoja, ilman TCP:tä, ilman IP-pinoa - lyhyesti sanottuna, ohittavat kaiken, mikä on kirjoitettu Linux-ytimeen, ja sitten sylkevät se ulos säiliöön.
Mitä tapahtui? Erittäin hieno suorituskyky, hienot ominaisuudet - vain siistiä! Mutta katsomme tätä ja näemme, että jokaisessa koneessa on ohjelma, joka muodostaa yhteyden Kubernetes API:hen ja luo C-koodin perusteella C-koodin ja kokoaa ytimeen lataamansa binaarit, jotta nämä koukut toimivat. ydintilassa.
Mitä tapahtuu, jos jokin menee pieleen? Me emme tiedä. Ymmärtääksesi tämän, sinun on luettava koko tämä koodi, ymmärrettävä kaikki logiikka, ja on hämmästyttävää, kuinka vaikeaa se on. Mutta toisaalta, on olemassa näitä siltoja, verkkosuodattimia, ip-reititystä - en ole lukenut niiden lähdekoodia, enkä myöskään ne 40 insinööriä, jotka työskentelevät yrityksessämme. Ehkä vain harvat ymmärtävät joitain osia.
Ja mitä eroa sillä on? Osoittautuu, että on olemassa ip-rout, Linux-ydin ja uusi työkalu - mitä väliä sillä on, emme ymmärrä yhtä tai toista. Mutta pelkäämme käyttää jotain uutta - miksi? Sillä jos työkalu on 30 vuotta vanha, niin 30 vuodessa kaikki viat on löydetty, kaikkiin virheisiin on astuttu, eikä sinun tarvitse tietää kaikesta - se toimii kuin musta laatikko ja toimii aina. Kaikki tietävät, mikä diagnostinen ruuvimeisseli kiinnittää mihin paikkaan, mikä tcpdump on käytettävä millä hetkellä. Kaikki tuntevat diagnostiikkaapuohjelmat hyvin ja ymmärtävät, kuinka tämä komponenttijoukko toimii Linux-ytimessä - ei miten se toimii, vaan kuinka sitä käytetään.
Ja mahtavan siisti Cilium ei ole 30-vuotias, se ei ole vielä vanhentunut. Kubernetesilla on sama ongelma, kopioi. Että Cilium on asennettu täydellisesti, että Kubernetes on asennettu täydellisesti, mutta kun jokin menee pieleen tuotannossa, pystytkö kriittisessä tilanteessa nopeasti ymmärtämään, mikä meni pieleen?
Kun sanomme, onko Kubernetesin ylläpitäminen vaikeaa - ei, se on erittäin helppoa, ja kyllä, se on uskomattoman vaikeaa. Kubernetes toimii loistavasti yksinään, mutta miljardilla vivahteella.
Tietoja "olen onnekas" -lähestymistavasta
— Onko yrityksiä, joissa nämä vivahteet näkyvät lähes taatusti? Oletetaan, että Yandex siirtää yhtäkkiä kaikki palvelut Kubernetesiin, siellä on valtava kuorma.
Dmitry: Ei, tämä ei ole keskustelu kuormasta, vaan yksinkertaisimmista asioista. Meillä on esimerkiksi Kubernetes, otimme sovelluksen käyttöön siellä. Mistä tiedät, että se toimii? Ei yksinkertaisesti ole valmiita työkaluja ymmärtämään, että sovellus ei kaatu. Ei ole olemassa valmista järjestelmää, joka lähettää hälytyksiä, sinun on määritettävä nämä hälytykset ja jokainen aikataulu. Ja päivitämme Kubernetesia.
Minulla on Ubuntu 16.04. Voit sanoa, että tämä on vanha versio, mutta olemme edelleen siinä, koska se on LTS. Siellä on systemd, jonka vivahteena on, että se ei siivoa C-ryhmiä. Kubernetes käynnistää podeja, luo C-ryhmiä, sitten poistaa podeja, ja jotenkin käy ilmi - en muista yksityiskohtia, anteeksi - että systemd-slice-osia on jäljellä. Tämä johtaa siihen, että ajan myötä mikä tahansa auto alkaa hidastua voimakkaasti. Tämä ei ole edes kysymys korkeasta kuormituksesta. Jos esimerkiksi lanseerataan pysyvät podit, jos on Cron Job, joka tuottaa jatkuvasti podeja, Ubuntu 16.04 -kone alkaa hidastua viikon kuluttua. Keskimääräinen kuormitus on jatkuvasti korkea, koska C-ryhmiä on luotu. Tämä on ongelma, jonka jokainen, joka yksinkertaisesti asentaa Ubuntu 16:n ja Kubernetesin päälle, kohtaa.
Oletetaan, että hän päivittää jotenkin systemd tai jotain muuta, mutta Linux-ytimessä 4.16 asti se on vielä hauskempaa - kun poistat C-ryhmiä, ne vuotavat ytimeen, eikä niitä varsinaisesti poisteta. Siksi kuukauden tämän koneen parissa työskentelyn jälkeen on mahdotonta tarkastella tulisijojen muistitilastoja. Otamme tiedoston esiin, rullaamme sitä ohjelmassa ja yksi tiedosto rullaa 15 sekuntia, koska ytimellä kestää hyvin kauan laskea miljoona C-ryhmää itsessään, jotka näyttävät olevan poistettuja, mutta ei - ne vuotavat .
Tällaisia pikkujuttuja on edelleen paljon siellä täällä. Tämä ei ole ongelma, jota jättiläiset yritykset saattavat joskus kohdata erittäin raskaiden kuormien alla - ei, se on jokapäiväistä asiaa. Ihmiset voivat elää tällä tavalla kuukausia - he asensivat Kubernetesin, ottivat sovelluksen käyttöön - se näyttää toimivan. Monille tämä on normaalia. He eivät edes tiedä, että tämä sovellus kaatuu jostain syystä, he eivät saa hälytystä, mutta heille tämä on normi. Aiemmin elimme virtuaalikoneita ilman valvontaa, nyt muutimme Kubernetesiin, myös ilman valvontaa - mitä eroa on?
Kysymys on siitä, että kun kävelemme jäällä, emme koskaan tiedä sen paksuutta, ellemme mittaa sitä etukäteen. Monet ihmiset kävelevät äläkä huoli, koska he ovat kävelleet ennenkin.
Minun näkökulmastani minkä tahansa järjestelmän käytön vivahteena ja monimutkaisuutena on varmistaa, että jään paksuus on juuri riittävä ratkaisemaan ongelmamme. Tästä me puhumme.
IT-alalla minusta näyttää olevan liian monta "minulla on onni" -lähestymistapoja. Monet ihmiset asentavat ohjelmistoja ja käyttävät ohjelmistokirjastoja siinä toivossa, että he menestyvät. Yleisesti ottaen monet ihmiset ovat onnekkaita. Siksi se varmaan toimii.
— Pessimistisen arvioni mukaan se näyttää tältä: kun riskit ovat suuret ja sovelluksen pitää toimia, niin sitten tarvitaan tukea Flauntilta, ehkä Red Hatilta tai sitten tarvitaan oma sisäinen erityisesti Kubernetesille omistettu tiimi, joka on valmis. vetää se pois.
Dmitry: Objektiivisesti näin on. Oman pienen tiimin Kubernetes-tarinaan pääseminen sisältää useita riskejä.
Tarvitsemmeko kontteja?
— Voitko kertoa, kuinka laajalti Kubernetes on Venäjällä?
Dmitry: Minulla ei ole näitä tietoja, enkä ole varma, onko kenelläkään muulla niitä. Sanomme: "Kubernetes, Kubernetes", mutta on olemassa toinen tapa tarkastella tätä asiaa. En myöskään tiedä kuinka laajalle levinneitä kontit ovat, mutta tiedän Internetissä olevista raporteista luvun, jonka mukaan 70 % konteista on Kubernetesin suunnittelemia. Se oli luotettava lähde melko suurelle otokselle ympäri maailmaa.
Sitten toinen kysymys - tarvitsemmeko kontteja? Oma tuntemukseni ja Flant-yhtiön yleinen kanta on, että Kubernetes on tosiasiallinen standardi.
Ei tule muuta kuin Kubernetes.
Tämä on ehdoton muutos infrastruktuurin hallinnan alalla. Vain ehdoton - siinä se, ei enää Ansiblea, Chefiä, virtuaalikoneita, Terraformia. En puhu vanhoista kolhoosimenetelmistä. Kubernetes on ehdoton muuttaja, ja nyt se tulee olemaan vain näin.
On selvää, että toisilla tämän ymmärtäminen vie pari vuotta ja toisilla pari vuosikymmentä. Minulla ei ole epäilystäkään siitä, etteikö tule olemaan muuta kuin Kubernetes ja tämä uusi ulkoasu: emme enää vahingoita käyttöjärjestelmää, vaan käytämme infrastruktuuri koodina, ei vain koodilla, vaan yml:llä - deklaratiivisesti kuvattu infrastruktuuri. Minulla on tunne, että näin tulee aina olemaan.
– Eli ne yritykset, jotka eivät ole vielä vaihtaneet Kubernetesiin, siirtyvät siihen varmasti tai jäävät unohduksiin. ymmärsinkö sinut oikein?
Dmitry: Tämäkään ei ole täysin totta. Esimerkiksi, jos meillä on tehtävänä käyttää DNS-palvelinta, sitä voidaan käyttää FreeBSD 4.10:ssä ja se voi toimia täydellisesti 20 vuotta. Tee vain töitä ja se on siinä. Ehkä 20 vuoden kuluttua jotain on päivitettävä kerran. Jos puhumme ohjelmistosta julkaisussamme muodossa ja se todella toimii monta vuotta ilman päivityksiä, tekemättä muutoksia, niin Kubernetesia ei tietenkään tule olemaan. Häntä ei tarvita siellä.
Kaikki CI/CD:hen liittyvä - kaikkialla, missä tarvitaan jatkuvaa toimitusta, missä pitää päivittää versioita, tehdä aktiivisia muutoksia, missä tahansa pitää rakentaa vikasietoisuutta - vain Kubernetes.
Tietoja mikropalveluista
- Tässä minulla on pieni dissonanssi. Kubernetesin kanssa työskentelyyn tarvitaan ulkoista tai sisäistä tukea - tämä on ensimmäinen kohta. Toiseksi, kun olemme vasta aloittamassa kehitystä, olemme pieni startup, meillä ei ole vielä mitään, Kubernetesin tai mikropalveluarkkitehtuurin kehittäminen yleensä voi olla monimutkaista eikä aina taloudellisesti perusteltua. Olen kiinnostunut mielipiteestäsi - pitääkö startup-yritysten aloittaa heti kirjoittaminen Kubernetesiin tyhjästä, vai voivatko he silti kirjoittaa monoliitin ja tulla vasta sitten Kubernetesiin?
Dmitry: Hieno kysymys. Puhun mikropalveluista Monta kertaa olen tavannut ihmisiä, jotka yrittävät lyödä nauloja mikroskoopilla. Itse lähestymistapa on oikea, me itse suunnittelemme sisäisen ohjelmistomme tällä tavalla. Mutta kun teet tämän, sinun on ymmärrettävä selvästi, mitä teet. Sana, jota vihaan eniten mikropalveluissa, on "mikro". Historiallisesti tämä sana on peräisin sieltä, ja jostain syystä ihmiset ajattelevat, että mikro on hyvin pieni, alle millimetri, kuten mikrometri. Tämä on väärin.
Esimerkiksi on monoliitti, jota on kirjoittanut 300 ihmistä, ja kaikki kehittämiseen osallistuneet ymmärtävät, että siellä on ongelmia ja se pitäisi jakaa mikropaloiksi - noin 10 kappaletta, joista jokainen on kirjoittanut 30 henkilöä. minimiversiossa. Tämä on tärkeää, tarpeellista ja siistiä. Mutta kun meille tulee startup, jossa 3 erittäin siistiä ja lahjakasta kaveria kirjoitti 60 mikropalvelua polvilleen, aina kun etsin Corvalolia.
Minusta tuntuu, että tästä on puhuttu jo tuhansia kertoja - saimme hajautetun monoliitin muodossa tai toisessa. Tämä ei ole taloudellisesti perusteltua, se on yleisesti ottaen erittäin vaikeaa kaikessa. Olen vain nähnyt tämän niin monta kertaa, että se todella satuttaa minua, joten jatkan siitä puhumista.
Alkukysymykseen on ristiriita sen välillä, että toisaalta Kubernetes on pelottavaa käyttää, koska ei ole selvää mikä siellä voi rikkoutua tai ei toimi, toisaalta on selvää, että kaikki menee sinne ja ei ole olemassa mitään muuta kuin Kubernetes. Vastaus - punnita tulevan hyödyn määrää, kuinka paljon tehtäviä voit ratkaista. Tämä on asteikon toisella puolella. Toisaalta on olemassa riskejä, jotka liittyvät seisokkiin tai vasteajan, käytettävyystason lyhenemiseen - suorituskykyindikaattoreiden heikkenemiseen.
Tässä se on - joko liikumme nopeasti ja Kubernetes antaa meille mahdollisuuden tehdä monia asioita paljon nopeammin ja paremmin, tai käytämme luotettavia, aika-testattuja ratkaisuja, mutta etenemme paljon hitaammin. Tämä valinta on jokaisen yrityksen tehtävä. Voit ajatella sitä polkuna viidakossa - kun kävelet ensimmäistä kertaa, voit kohdata käärmeen, tiikerin tai hullun mäyrän, ja kun olet kävellyt 10 kertaa, olet tallannut polun, poistunut oksat ja kävellä helpommin. Joka kerta polku levenee. Sitten se on asfalttitie ja myöhemmin kaunis bulevardi.
Kubernetes ei pysy paikallaan. Kysymys taas: Kubernetes on toisaalta 4-5 binaarista, toisaalta se on koko ekosysteemi. Tämä on käyttöjärjestelmä, joka meillä on koneissamme. Mikä tämä on? Ubuntu vai Curios? Tämä on Linux-ydin, joukko lisäkomponentteja. Kaikki nämä asiat täällä, yksi myrkyllinen käärme heitettiin tieltä, sinne pystytettiin aita. Kubernetes kehittyy erittäin nopeasti ja dynaamisesti, ja riskien volyymi, tuntemattoman volyymi pienenee kuukausittain ja vastaavasti nämä asteikot ovat tasapainottumassa.
Vastaamalla kysymykseen, mitä startup-yrityksen pitäisi tehdä, sanoisin - tule Flauntiin, maksa 150 tuhatta ruplaa ja hanki avaimet käteen -periaatteella toimiva DevOps helppo palvelu. Jos olet pieni startup muutaman kehittäjän kanssa, tämä toimii. Sen sijaan, että palkkaisit omia kehittäjiäsi, joiden on opittava ratkaisemaan ongelmasi ja maksamaan palkka tällä hetkellä, saat avaimet käteen -ratkaisun kaikkiin ongelmiin. Kyllä, on joitain haittoja. Me ulkoistajana emme voi olla niin mukana ja reagoida nopeasti muutoksiin. Mutta meillä on paljon asiantuntemusta ja valmiita käytäntöjä. Takaamme, että kaikissa tilanteissa selvitämme sen varmasti nopeasti ja herätämme Kuberneteet kuolleista.
Suosittelen vahvasti ulkoistamista startup- ja vakiintuneille yrityksille aina sellaiseen kokoon asti, että toimintaan voi omistaa 10 hengen tiimi, koska muuten ei ole mitään järkeä. Tämä on ehdottomasti järkevää ulkoistaa.
Tietoja Amazonista ja Googlesta
— Voidaanko Amazonin tai Googlen ratkaisun isäntä pitää ulkoistajana?
Dmitry: Kyllä, tietysti, tämä ratkaisee useita ongelmia. Mutta taas on vivahteita. Sinun on silti ymmärrettävä, miten sitä käytetään. Esimerkiksi Amazon AWS:n työssä on tuhat pientä asiaa: Load Balancer täytyy lämmittää tai kirjoittaa etukäteen pyyntö, että "kaverit, me vastaanotamme liikennettä, lämmittele Load Balancer meille!" Sinun on tiedettävä nämä vivahteet.
Kun käännyt tähän erikoistuneiden ihmisten puoleen, saat lähes kaikki tyypilliset asiat kiinni. Meillä on nyt 40 insinööriä, vuoden loppuun mennessä luultavasti 60 - olemme varmasti kohdanneet kaikki nämä asiat. Vaikka kohtaisimme tämän ongelman uudelleen jossain projektissa, kysymme nopeasti toisiltamme ja tiedämme kuinka ratkaista se.
Todennäköisesti vastaus on - tietysti isännöity tarina helpottaa osaa. Kysymys kuuluu, oletko valmis luottamaan näihin isännöitsijöihin ja ratkaisevatko he ongelmasi. Amazon ja Google ovat menestyneet hyvin. Kaikille tapauksillemme - täsmälleen. Meillä ei ole enää positiivisia kokemuksia. Kaikki muut pilvet, joiden kanssa yritimme työskennellä, aiheuttavat paljon ongelmia - Ager ja kaikki mitä Venäjällä on, ja kaikenlaiset OpenStack eri toteutuksissa: Headster, Overage - mitä haluat. Ne kaikki luovat ongelmia, joita et halua ratkaista.
Siksi vastaus on kyllä, mutta itse asiassa kypsiä isännöityjä ratkaisuja ei ole kovin montaa.
Kuka Kubernetesia tarvitsee?
— Ja silti, kuka tarvitsee Kubernetesia? Kenen pitäisi jo vaihtaa Kubernetesiin, kuka on tyypillinen Flaunt-asiakas, joka tulee erityisesti Kubernetesiin?
Dmitry: Tämä on mielenkiintoinen kysymys, koska juuri nyt, Kuberneteksen jälkeen, monet ihmiset tulevat meille: "Kaverit, me tiedämme, että teet Kubernetesia, tehkää se meille!" Vastaamme heille: "Hyvät herrat, me emme tee Kubernetesia, teemme prod ja kaikkea siihen liittyvää." Koska tällä hetkellä on yksinkertaisesti mahdotonta tehdä tuotetta tekemättä kaikkea CI:tä/CD:tä ja koko tätä tarinaa. Kaikki ovat siirtyneet pois jaosta, että meillä on kehitys kehitykseltä ja sitten riisto hyväksikäytöltä.
Asiakkaamme odottavat erilaisia asioita, mutta kaikki odottavat jotain hyvää ihmettä, että heillä on tiettyjä ongelmia, ja nyt - hops! — Kubernetes ratkaisee ne. Ihmiset uskovat ihmeisiin. He ymmärtävät mielessään, että ihmettä ei tapahdu, mutta sielussaan he toivovat - mitä jos tämä Kubernetes nyt ratkaisee kaiken puolestamme, he puhuvat siitä niin paljon! Yhtäkkiä hän nyt - aivastaa! - ja hopealuodi, aivastelu! – ja meillä on 100 %:n käyttöaika, kaikki kehittäjät voivat julkaista kaiken, mikä tulee tuotantoon 50 kertaa, eikä se kaadu. Yleisesti ottaen ihme!
Kun sellaiset ihmiset tulevat luoksemme, sanomme: "Anteeksi, mutta ei ole olemassa sellaista asiaa kuin ihme." Ollaksesi terve, sinun tulee syödä hyvin ja liikkua. Jotta tuote olisi luotettava, se on valmistettava luotettavasti. Jotta sinulla olisi kätevä CI/CD, sinun on tehtävä siitä tällainen. Se on paljon työtä, joka on tehtävä.
Vastaus kysymykseen kuka tarvitsee Kubernetesia - kukaan ei tarvitse Kubernetesia.
Joillakin ihmisillä on väärä käsitys, että he tarvitsevat Kubernetesia. Ihmiset tarvitsevat, heillä on syvä tarve lopettaa ajatteleminen, opiskelu ja kiinnostus kaikista infrastruktuurin ongelmista ja sovellusten suorittamisen ongelmista. He haluavat sovellusten vain toimivan ja ottavan käyttöön. Heille Kubernetes on toivo, että he eivät enää kuule tarinaa, että "me makasimme siellä" tai "emme voi rullata ulos" tai jotain muuta.
Tekninen johtaja tulee yleensä meille. He kysyvät häneltä kahta asiaa: toisaalta antaa meille piirteitä ja toisaalta vakautta. Suosittelemme, että otat sen itsellesi ja tee se. Hopealuoti, tai pikemminkin hopeoitu, on se, että lakkaat ajattelemasta näitä ongelmia ja tuhlaamasta aikaa. Sinulla on erityisiä ihmisiä, jotka sulkevat tämän numeron.
Sanamuoto, jonka mukaan me tai joku muu tarvitsee Kubernetesia, on virheellinen.
Järjestelmänvalvojat todella tarvitsevat Kubernetesia, koska se on erittäin mielenkiintoinen lelu, jolla voit leikkiä ja puuhailla. Olkaamme rehellisiä - kaikki rakastavat leluja. Olemme kaikki jossain lapsia, ja kun näemme uuden, haluamme leikkiä sitä. Joillekin tämä on masentunut esimerkiksi hallinnossa, koska he ovat jo pelanneet tarpeeksi ja ovat jo niin väsyneitä, että he eivät yksinkertaisesti halua. Mutta tämä ei ole täysin menetetty kenellekään. Esimerkiksi jos olen jo pitkään ollut kyllästynyt leluihin järjestelmänhallinnan ja DevOps-alalla, niin rakastan edelleen leluja, ostan silti uusia. Kaikki ihmiset, tavalla tai toisella, haluavat silti jonkinlaisia leluja.
Tuotannon kanssa ei tarvitse leikkiä. Mitä tahansa suosittelenkin ehdottomasti tekemättä ja mitä näen nyt massiivisesti: "Voi, uusi lelu!" - He juoksivat ostamaan sen, ostivat sen ja: "Viedään se nyt kouluun ja näyttelemme sitä kaikille ystävillemme." Älä tee tätä. Pyydän anteeksi, lapseni ovat vasta kasvamassa, näen jatkuvasti jotain lapsissa, huomaan sen itsessäni ja sitten yleistän sen muille.
Lopullinen vastaus on: et tarvitse Kubernetesia. Sinun on ratkaistava ongelmasi.
Mitä voit saavuttaa, on:
- prod ei pudota;
- vaikka hän yrittää pudota, tiedämme siitä etukäteen ja voimme laittaa siihen jotain;
- voimme muuttaa sitä nopeudella, jolla liiketoimintamme sitä vaatii, ja voimme tehdä sen kätevästi; se ei aiheuta meille ongelmia.
On olemassa kaksi todellista tarvetta: luotettavuus ja käyttöönoton dynaamisuus/joustavuus. Kaikki, jotka tekevät tällä hetkellä jonkinlaisia IT-projekteja, riippumatta siitä, minkälaisessa liiketoiminnassa - pehmeitä maailman helpottamiseen ja jotka ymmärtävät tämän, on ratkaistava nämä tarpeet. Kubernetes oikealla lähestymistavalla, oikealla ymmärryksellä ja riittävällä kokemuksella auttaa sinua ratkaisemaan ne.
Tietoja palvelimettomasta
— Jos katsot hieman pidemmälle tulevaisuuteen, yritettäessä ratkaista päänsäryn puuttumisen ongelma infrastruktuurilla, käyttöönottonopeudella ja sovellusmuutosten nopeudella, ilmaantuu uusia ratkaisuja, esimerkiksi palvelimettomia. Tunnetko potentiaalia tähän suuntaan ja vaikkapa vaaraa Kubernetesille ja vastaaville ratkaisuille?
Dmitry: Tässä täytyy taas tehdä huomautus, että en ole näkijä, joka katsoo eteenpäin ja sanoo - näin tulee olemaan! Vaikka tein juuri saman. Katson jalkojani ja näen siellä joukon ongelmia, esimerkiksi kuinka transistorit toimivat tietokoneessa. Se on hauska, eikö? Havaitsemme joitain bugeja suorittimessa.
Tee palvelimettomasta melko luotettavasta, halvasta, tehokkaasta ja kätevästä, mikä ratkaisee kaikki ekosysteemiongelmat. Tässä olen samaa mieltä Elon Muskin kanssa siitä, että tarvitaan toinen planeetta luomaan vikasietokyky ihmiskunnalle. Vaikka en tiedä mitä hän sanoo, ymmärrän, että en ole valmis lentämään itse Marsiin, eikä se tapahdu huomenna.
Palvelimeton kanssa on selvästi selvää, että tämä on ideologisesti oikea asia, kuten vikasietoisuus ihmiskunnalle - kaksi planeettaa on parempi kuin yksi. Mutta miten se nyt tehdään? Yhden tutkimusmatkan lähettäminen ei ole ongelma, jos keskityt siihen. Useiden tutkimusretkien lähettäminen ja useiden tuhansien ihmisten sijoittaminen sinne on mielestäni myös realistista. Mutta tehdä siitä täysin vikasietoinen niin, että puolet ihmiskunnasta asuu siellä, on minusta nyt mahdotonta, koska sitä ei harkita.
Palvelimeton yksi vastaan: asia on siisti, mutta se on kaukana vuoden 2019 ongelmista. Lähempänä vuotta 2030 - eletään nähdäksesi se. Minulla ei ole epäilystäkään siitä, että elämme, elämme ehdottomasti (toista ennen nukkumaanmenoa), mutta nyt meidän on ratkaistava muita ongelmia. Se on kuin uskoisi satuponiin Rainbow. Kyllä, pari prosenttia tapauksista ratkeaa, ja ne ratkeavat täydellisesti, mutta subjektiivisesti palvelimeton on sateenkaari... Minulle tämä aihe on liian kaukainen ja liian käsittämätön. En ole valmis puhumaan. Vuonna 2019 et voi kirjoittaa yhtä sovellusta ilman palvelinta.
Miten Kubernetes kehittyy
— Miten uskot Kubernetesin ja sitä ympäröivän ekosysteemin kehittyvän, kun siirrymme kohti tätä mahdollisesti upeaa kaukaista tulevaisuutta?
Dmitry: Olen miettinyt tätä paljon ja minulla on selkeä vastaus. Ensimmäinen on statefull - loppujen lopuksi valtioton on helpompi tehdä. Kubernetes investoi aluksi enemmän tähän, kaikki alkoi siitä. Stateless toimii melkein täydellisesti Kubernetesissa, ei vain ole mitään valittamista. Ongelmia on edelleen paljon, tai pikemminkin vivahteita. Kaikki siellä toimii jo hyvin meillä, mutta se on me. Kestää vielä ainakin pari vuotta, ennen kuin tämä toimii kaikilla. Tämä ei ole laskettu indikaattori, vaan oma tunne päässäni.
Lyhyesti sanottuna statefullin pitäisi - ja tulee kehittymään - erittäin voimakkaasti, koska kaikki sovelluksemme tallentavat tilan, ei ole olemassa tilattomia sovelluksia. Tämä on illuusio; tarvitset aina jonkinlaisen tietokannan ja jotain muuta. Statefullissa on kyse kaiken mahdollisen oikaisemisesta, kaikkien virheiden korjaamisesta, kaikkien tällä hetkellä kohtaavien ongelmien parantamisesta - kutsuttakoon sitä adoptioiksi.
Tuntemattomuuden taso, ratkaisemattomien ongelmien taso, todennäköisyys kohdata jotain laskee merkittävästi. Tämä on tärkeä tarina. Ja operaattorit - kaikki mikä liittyy hallintalogiikan kodifiointiin, ohjauslogiikkaan helpon palvelun saamiseksi: MySQL helppo palvelu, RabbitMQ helppo palvelu, Memcache helppo palvelu - yleensä kaikki nämä komponentit, joiden toimivuuden meidän on taattava laatikko. Tämä vain ratkaisee sen kivun, että haluamme tietokannan, mutta emme halua hallinnoida sitä, tai haluamme Kubernetesin, mutta emme halua hallinnoida sitä.
Tämä tarina operaattorin kehityksestä muodossa tai toisessa on tärkeä parin seuraavan vuoden aikana.
Mielestäni käytön helppouden pitäisi lisääntyä huomattavasti - laatikosta tulee yhä mustempi, luotettavampi ja yksinkertaisemmilla nupeilla.
Kuuntelin kerran vanhan haastattelun Isaac Asimovin kanssa 80-luvulta YouTubessa Saturday Night Livessä - ohjelma, kuten Urgant, vain mielenkiintoinen. He kysyivät häneltä tietokoneiden tulevaisuudesta. Hän sanoi, että tulevaisuus on yksinkertaisuudessa, kuten radiossa. Radiovastaanotin oli alun perin monimutkainen asia. Aallon saamiseksi piti kääntää nuppeja 15 minuuttia, kääntää vartaita ja yleensä tietää kuinka kaikki toimii, ymmärtää radioaaltojen lähetyksen fysiikka. Tämän seurauksena radiossa oli vain yksi nuppi jäljellä.
Mikä radio nyt vuonna 2019? Autossa radiovastaanotin löytää kaikki aallot ja asemien nimet. Prosessin fysiikka ei ole muuttunut 100 vuoteen, mutta helppokäyttöisyys on muuttunut. Nyt, eikä vain nyt, jo vuonna 1980, kun Azimovin haastattelussa oli, kaikki käyttivät radiota, eikä kukaan ajatellut sen toimivuutta. Se toimi aina - se on itsestäänselvyys.
Azimov sanoi sitten, että se olisi sama tietokoneiden kanssa - helppokäyttöisyys paranee. Vaikka vuonna 1980 sinut piti kouluttaa painamaan tietokoneen painikkeita, niin se ei tule olemaan tulevaisuudessa.
Minulla on tunne, että Kuberneteksen ja infrastruktuurin myötä myös käyttömukavuus paranee valtavasti. Tämä on mielestäni ilmeistä - se on pinnalla.
Mitä tehdä insinööreille?
— Mitä Kubernetesia tukeville insinööreille ja järjestelmänvalvojille sitten tapahtuu?
Dmitry: Mitä kirjanpitäjälle tapahtui 1C:n tulon jälkeen? Suunnilleen sama. Ennen tätä he laskivat paperilla - nyt ohjelmassa. Työn tuottavuus on kasvanut suuruusluokkaa, mutta itse työ ei ole kadonnut. Jos ennen hehkulampun ruuvaamiseen tarvittiin 10 insinööriä, nyt yksi riittää.
Ohjelmistojen määrä ja tehtävien määrä minusta tuntuu kasvavan nyt nopeammin kuin uusia DevOppeja ilmestyy ja tehokkuus kasvaa. Markkinoilla on tällä hetkellä erityinen pula ja se kestää pitkään. Myöhemmin kaikki palaa jonkinlaiseen normaaliin, jossa työn tehokkuus kasvaa, palvelimettomuutta tulee yhä enemmän, Kubernetesiin kiinnitetään neuroni, joka valitsee kaikki resurssit juuri tarpeen mukaan ja yleensä tee kaikki itse, kuten pitääkin - henkilö vain astu pois äläkä puutu asiaan.
Mutta jonkun on silti tehtävä päätöksiä. On selvää, että tämän henkilön pätevyys ja erikoistuminen on korkeampi. Nykyään kirjanpidolla ei tarvitse 10 työntekijää pitää kirjanpitoa, jotta kädet eivät väsy. Se ei yksinkertaisesti ole välttämätöntä. Sähköinen asiakirjanhallintajärjestelmä skannaa ja tunnistaa monet asiakirjat automaattisesti. Yksi älykäs pääkirjanpitäjä riittää jo paljon paremmalla taidolla, hyvällä ymmärryksellä.
Yleisesti ottaen tämä on tapa kaikilla toimialoilla. Sama koskee autoja: aiemmin autossa oli mekaanikko ja kolme kuljettajaa. Nykyään autolla ajaminen on yksinkertainen prosessi, johon osallistumme joka päivä. Kukaan ei ajattele, että auto on jotain monimutkaista.
DevOps tai järjestelmäsuunnittelu eivät katoa – korkeatasoinen työ ja tehokkuus lisääntyvät.
– Kuulin myös mielenkiintoisen ajatuksen, että työ todella lisääntyy.
Dmitry: Tietysti sataprosenttisesti! Koska kirjoittamiemme ohjelmistojen määrä kasvaa jatkuvasti. Ohjelmistoilla ratkaisemiemme ongelmien määrä kasvaa jatkuvasti. Työn määrä kasvaa. Nyt DevOps-markkinat ovat hirveän ylikuumentuneet. Tämä näkyy palkkaodotuksissa. Hyvällä tavalla, yksityiskohtiin menemättä, pitäisi olla junioreita, jotka haluavat X, keskimmäisiä, jotka haluavat 1,5X, ja senioreita, jotka haluavat 2X. Ja nyt, jos katsot Moskovan DevOps-palkkamarkkinoita, juniori haluaa X:stä 3X:ään ja seniori X:stä 3X:ään.
Kukaan ei tiedä kuinka paljon se maksaa. Palkkatasoa mitataan luottamuksellasi - täydellinen hulluntalo, rehellisesti sanottuna, hirveän ylikuumentuneet markkinat.
Tietenkin tämä tilanne muuttuu hyvin pian - jonkin verran kyllästymistä pitäisi tapahtua. Ohjelmistokehityksessä näin ei ole - huolimatta siitä, että kaikki tarvitsevat kehittäjiä ja kaikki tarvitsevat hyviä kehittäjiä, markkinat ymmärtävät, kuka on minkä arvoinen - toimiala on rauhoittunut. Näin ei ole DevOpsissa näinä päivinä.
— Kuulemani perusteella päädyin siihen, että nykyisen järjestelmänvalvojan ei kannata murehtia liikaa, vaan on aika päivittää osaamistaan ja valmistautua siihen, että huomenna on enemmän töitä, mutta pätevämpää.
Dmitry: Sata prosenttia. Yleisesti ottaen elämme vuotta 2019 ja elämän sääntö on tämä: elinikäinen oppiminen – opimme koko elämämme ajan. Minusta näyttää siltä, että nyt kaikki tietävät ja tuntevat tämän, mutta ei riitä, että tiedät - sinun on tehtävä se. Joka päivä meidän on muututtava. Jos emme tee tätä, joudumme ennemmin tai myöhemmin ammatin sivuun.
Varaudu jyrkkiin 180 asteen käännöksiin. En sulje pois tilannetta, jossa jokin muuttuu radikaalisti, jotain uutta keksitään - se tapahtuu. Hypätä! - ja nyt toimimme eri tavalla. On tärkeää valmistautua tähän ja olla murehtimatta. Voi käydä niin, että huomenna kaikki tekemäni osoittautuu tarpeettomaksi - ei mitään, olen opiskellut koko ikäni ja olen valmis oppimaan jotain muuta. Se ei ole ongelma. Työturvallisuutta ei tarvitse pelätä, mutta sinun on oltava valmis oppimaan jatkuvasti jotain uutta.
Toiveita ja minuutti mainontaa
- Onko sinulla toiveita?
Dmitry: Kyllä, minulla on useita toiveita.
Ensimmäinen ja kaupallinen - tilaa . Hyvät lukijat, mene YouTubeen ja tilaa kanavamme. Noin kuukauden kuluttua aloitamme videopalvelun aktiivisen laajentamisen, ja meillä on paljon opetuksellista sisältöä Kubernetesista, avointa ja monipuolista: käytännön asioista, aina laboratorioihin, syviin perusteellisiin teoreettisiin asioihin ja Kuberneteksen käyttöön. periaatteiden ja mallien taso.
Toinen kaupallinen toive - mene ja laita tähtiä, koska ruokimme niistä. Jos et anna meille tähtiä, meillä ei ole mitään syötävää. Se on kuin manaa tietokonepelissä. Teemme jotain, teemme, yritämme, joku sanoo, että nämä ovat kauheita polkupyöriä, joku sanoo, että kaikki on täysin pielessä, mutta jatkamme ja toimimme täysin rehellisesti. Näemme ongelman, ratkaisemme sen ja jaamme kokemuksemme. Siksi, anna meille tähti, se ei katoa sinusta, mutta se tulee meille, koska me ruokimme niitä.
Kolmas, tärkeä ja ei enää kaupallinen toive - lakkaa uskomasta satuihin. Olette ammattilaisia. DevOps on erittäin vakava ja vastuullinen ammatti. Lopeta pelaaminen työpaikalla. Anna sen napsauttaa puolestasi, niin ymmärrät sen. Kuvittele, että tulet sairaalaan ja siellä lääkäri kokeilee sinua. Ymmärrän, että tämä voi olla loukkaavaa jollekin, mutta todennäköisesti tämä ei koske sinua, vaan jotakuta toista. Pyydä myös muita lopettamaan. Tämä todella pilaa meidän kaikkien elämän – monet alkavat kohdella operaatioita, järjestelmänvalvojia ja DevOppeja tyyppeinä, jotka ovat taas rikkoneet jotain. Tämä "rikki" useimmiten johtui siitä, että menimme leikkimään, emmekä katsoneet kylmällä tietoisuudella mitä täällä oli ja mitä täällä.
Tämä ei tarkoita, etteikö sinun pitäisi kokeilla. Meidän täytyy kokeilla, teemme sen itse. Ollakseni rehellinen, me itse joskus pelaamme pelejä - tämä on tietysti erittäin huonoa, mutta mikään inhimillinen ei ole meille vieras. Julistetaan vuosi 2019 vakavien, hyvin harkittujen kokeilujen vuodeksi, ei tuotannossa olevien pelien vuodeksi. Luultavasti niin.
- Kiitos paljon!
Dmitry: Kiitos, Vitaly, sekä ajasta että haastattelusta. Hyvät lukijat, kiitos paljon, jos olette yhtäkkiä päässeet tähän pisteeseen. Toivon, että toimme sinulle ainakin pari ajatusta.
Haastattelussa Dmitry käsitteli werf-kysymystä. Nyt tämä on universaali sveitsiläinen veitsi, joka ratkaisee melkein kaikki ongelmat. Mutta se ei aina ollut niin. Päällä festivaaleille Dmitry Stolyarov kertoo sinulle tästä työkalusta yksityiskohtaisesti. raportissa siellä on kaikkea: Kubernetesin ongelmia ja piilotettuja vivahteita, vaihtoehtoja näiden vaikeuksien ratkaisemiseksi ja werfin nykyinen toteutus yksityiskohtaisesti. Liity joukkoomme 27. ja 28. toukokuuta, luomme täydelliset työkalut.
Lähde: will.com