Nimeni on Viktor Yagofarov, ja olen kehittämässä Kubernetes-alustaa DomClickissä teknisenä kehityspäällikkönä Ops (operation) -tiimissä. Haluaisin puhua Dev <-> Ops -prosessiemme rakenteesta, Venäjän yhden suurimmista k8s-klusterien toiminnasta sekä tiimimme soveltamista DevOps/SRE-käytännöistä.
Ops-tiimi
Ops-tiimissä on tällä hetkellä 15 henkilöä. Kolme heistä vastaa toimistosta, kaksi työskentelee eri aikavyöhykkeellä ja ovat tavoitettavissa myös yöllä. Siten joku Opsista on aina monitorissa ja valmis vastaamaan kaikenlaisiin tapauksiin. Meillä ei ole yövuoroja, mikä säilyttää psyykemme ja antaa jokaiselle mahdollisuuden nukkua riittävästi ja viettää vapaa-aikaa paitsi tietokoneen ääressä.
Jokaisella on erilainen kompetenssi: verkottajat, tietopohjaiset asiantuntijat, ELK-pinoasiantuntijat, Kubernetes-järjestelmänvalvojat/kehittäjät, monitorointi, virtualisointi, laitteistoasiantuntijat jne. Yksi asia yhdistää kaikkia - jokainen voi jossain määrin korvata kenet tahansa meistä: esimerkiksi tuoda uusia solmuja k8s-klusteriin, päivittää PostgreSQL, kirjoittaa CI/CD + Ansible-putki, automatisoida jotain Pythonissa/Bash/Gossa, yhdistää laitteistoa Datakeskus. Vahva osaaminen millään alueella ei estä sinua vaihtamasta toimintasuuntaasi ja ryhtymästä kehittymään jollain muulla alueella. Liityin esimerkiksi yritykseen PostgreSQL-asiantuntijaksi, ja nyt päävastuualueeni ovat Kubernetes-klusterit. Joukkueessa kaikki korkeudet ovat tervetulleita ja vipuvaikutus on erittäin kehittynyt.
Me muuten metsästämme. Vaatimukset ehdokkaille ovat melko vakioita. Minulle henkilökohtaisesti on tärkeää, että henkilö sopii tiimiin, on konfliktiton, mutta osaa myös puolustaa näkökantansa, haluaa kehittyä eikä pelkää tehdä jotain uutta, tarjoaa ideoitaan. Lisäksi edellytetään ohjelmointitaitoa skriptikielillä, Linuxin ja englannin perusteiden tuntemusta. Englanti tarvitaan yksinkertaisesti siksi, että henkilö fakapin sattuessa voi googlettaa ratkaisun ongelmaan 10 sekunnissa, ei 10 minuutissa. Nyt on erittäin vaikea löytää asiantuntijoita, joilla on syvällinen Linux-tuntemus: se on hauskaa, mutta kaksi kolmesta ehdokkaista ei voi vastata kysymykseen "Mikä on kuormituskeskiarvo? Mistä se on tehty?", ja kysymystä "Kuinka koota ytimen kaatopaikka C-ohjelmasta" pidetään jotain supermiesten... tai dinosaurusten maailmasta. Meidän on siedettävä tätä, koska yleensä ihmisillä on korkeasti kehittynyt muu kompetenssi, mutta opetamme Linuxia. Vastaus kysymykseen "miksi DevOps-insinöörin pitää tietää tämä kaikki nykyaikaisessa pilvimaailmassa" on jätettävä artikkelin ulkopuolelle, mutta kolmella sanalla: kaikkea tätä tarvitaan.
Joukkueen työkalut
Tools-tiimillä on merkittävä rooli automaatiossa. Niiden päätehtävänä on luoda käteviä graafisia ja CLI-työkaluja kehittäjille. Esimerkiksi sisäisen kehitystyömme Conferin avulla voit kirjaimellisesti ottaa käyttöön sovelluksen Kubernetesiin vain muutamalla hiiren napsautuksella, määrittää sen resurssit, avaimet varastosta jne. Aikaisemmin oli Jenkins + Helm 2, mutta minun piti kehittää oma työkaluni poistaakseni copy-paste ja tuoda yhdenmukaisuutta ohjelmiston elinkaareen.
Ops-tiimi ei kirjoita putkia kehittäjille, mutta voi neuvoa kaikissa kirjoitusasioissa (joillakin ihmisillä on edelleen Helm 3).
DevOps
Mitä tulee DevOpsiin, näemme sen seuraavasti:
Kehittäjätiimit kirjoittavat koodin, julkaisevat sen Confer to dev -> qa/stage -> prod -toiminnolla. Kehittäjä- ja Ops-tiimien vastuulla on varmistaa, että koodi ei hidastu eikä sisällä virheitä. Päivällä Ops-tiimin päivystävän tulee ensin reagoida tapaukseen sovelluksellaan, ja illalla ja yöllä päivystävän pääkäyttäjän (Ops) tulee herättää päivystävä kehittäjä, jos hän tietää Varmista, että ongelma ei ole infrastruktuurissa. Kaikki mittarit ja hälytykset näkyvät automaattisesti tai puoliautomaattisesti.
Opsin vastuualue alkaa siitä hetkestä, kun sovellus otetaan tuotantoon, mutta Devin vastuu ei lopu siihen – teemme saman asian ja olemme samassa veneessä.
Kehittäjät neuvovat järjestelmänvalvojia, jos he tarvitsevat apua järjestelmänvalvojan mikropalvelun kirjoittamisessa (esimerkiksi Go backend + HTML5), ja järjestelmänvalvojat neuvovat kehittäjiä kaikissa infrastruktuuriongelmissa tai k8s:iin liittyvissä ongelmissa.
Muuten, meillä ei ole monoliittia ollenkaan, vain mikropalvelut. Niiden määrä vaihtelee toistaiseksi 900 ja 1000 8 välillä prod kXNUMXs -klusterissa, jos numerolla mitataan käyttöönotot. Palojen määrä vaihtelee 1700:n ja 2000:n välillä. Tällä hetkellä tuoteklusterissa on noin 2000 paloa.
Tarkkoja lukuja en osaa antaa, koska valvomme tarpeettomia mikropalveluita ja leikkaamme ne puoliautomaattisesti. K8s auttaa meitä pitämään kirjaa tarpeettomista kokonaisuuksista , mikä säästää paljon resursseja ja rahaa.
Resurssienhallinta
seuranta
Hyvin jäsennellystä ja informatiivisesta seurannasta tulee ison klusterin toiminnan kulmakivi. Emme ole vielä löytäneet universaalia ratkaisua, joka kattaisi 100 % kaikista valvontatarpeista, joten luomme ajoittain erilaisia räätälöityjä ratkaisuja tähän ympäristöön.
- Zabbix. Vanha kunnon seuranta, jonka tarkoituksena on ensisijaisesti seurata infrastruktuurin yleistä kuntoa. Se kertoo meille, kun solmu kuolee prosessorin, muistin, levyjen, verkon ja niin edelleen. Ei mitään yliluonnollista, mutta meillä on myös erillinen DaemonSet agentteja, joiden avulla valvomme esimerkiksi DNS:n tilaa klusterissa: etsimme typeriä coredns podeja, tarkistamme ulkoisten isäntien saatavuuden. Vaikuttaa siltä, että miksi vaivautua tähän, mutta suurilla liikennemäärillä tämä komponentti on vakava vikakohta. Olen jo , kuinka kamppailin DNS-suorituskyvyn kanssa klusterissa.
- Prometheus-operaattori. Eri viejien joukko antaa laajan yleiskatsauksen klusterin kaikista komponenteista. Seuraavaksi visualisoimme tämän Grafanan suurilla koontipaneeleilla ja käytämme hälytyksiin alertmanageria.
Toinen hyödyllinen työkalu meille oli . Kirjoitimme sen sen jälkeen, kun kohtasimme useita kertoja tilanteen, jossa yksi joukkue meni päällekkäin toisen joukkueen sisääntulopolkujen kanssa, mikä johti 50-kertaisiin virheisiin. Nyt ennen tuotantoon käyttöönottoa kehittäjät tarkistavat, ettei se vaikuta keneenkään, ja tiimilleni tämä on hyvä työkalu Ingresses-ongelmien alustavaan diagnoosiin. Hassua, että se oli aluksi kirjoitettu järjestelmänvalvojille ja se näytti melko "kömpelöltä", mutta kun kehitystiimit rakastuivat työkaluun, se muuttui paljon ja alkoi näyttää siltä, että "järjestelmänvalvoja teki verkkokasvot ylläpitäjille. ” Pian hylkäämme tämän työkalun ja tällaiset tilanteet validoidaan jo ennen putkilinjan käyttöönottoa.
Tiimin resurssit kuutiossa
Ennen kuin siirrymme esimerkkeihin, on syytä selittää, miten resursseja kohdennetaan mikropalvelut.
Ymmärtää, mitkä joukkueet ja missä määrin käyttävät niitä ресурсы (prosessori, muisti, paikallinen SSD), varaamme jokaiselle komennon oman nimiavaruus "Kuutiossa" ja rajoittaa sen maksimikapasiteettia prosessorin, muistin ja levyn suhteen, keskusteltuaan aiemmin tiimien tarpeista. Näin ollen yksi komento ei yleensä estä koko klusteria käyttöönottoa varten ja varaa tuhansia ytimiä ja teratavuja muistia. Pääsy nimiavaruuteen myönnetään AD:n kautta (käytämme RBAC:tä). Nimiavaruudet ja niiden rajat lisätään vetopyynnön kautta GIT-tietovarastoon, ja sitten kaikki julkaistaan automaattisesti Ansible-putken kautta.
Esimerkki resurssien jakamisesta tiimille:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Pyynnöt ja rajoitukset
kuutioitu" Pyydä on taattujen varattujen resurssien määrä palko (yksi tai useampi telakointikontti) klusterissa. Raja on takaamaton enimmäismäärä. Voit usein nähdä kaavioista, kuinka joku tiimi on asettanut itselleen liian monta pyyntöä kaikille sovelluksilleen eikä voi ottaa sovellusta käyttöön "Kuutiossa", koska kaikki heidän nimiavaruutensa alaiset pyynnöt on jo "käytetty".
Oikea tapa päästä tästä tilanteesta on tarkastella todellista resurssien kulutusta ja verrata sitä pyydettyyn summaan (Pyyntö).
Yllä olevista kuvakaappauksista näet, että "Pyydetyt" CPU:t on sovitettu todelliseen säikeiden määrään, ja rajat voivat ylittää CPU-säikeiden todellisen määrän =)
Tarkastellaan nyt jotain nimiavaruutta yksityiskohtaisesti (valitsin nimiavaruuden kube-system - järjestelmän nimiavaruuden itse "Kuution" komponenteille) ja katsotaan todellisuudessa käytetyn prosessorin ajan ja muistin suhde pyydettyyn:
On selvää, että järjestelmäpalveluille on varattu paljon enemmän muistia ja prosessoria kuin todellisuudessa käytetään. Kube-järjestelmän tapauksessa tämä on perusteltua: tapahtui, että nginx-ingress-ohjain tai nodelocaldns huipussaan osuivat prosessoriin ja kuluttivat paljon RAM-muistia, joten tässä tällainen varaus on perusteltu. Lisäksi emme voi luottaa kaavioihin viimeisen 3 tunnin ajalta: on toivottavaa nähdä historiallisia mittareita pitkältä ajanjaksolta.
Kehitettiin "suositusten" järjestelmä. Esimerkiksi tästä voit nähdä, mitkä resurssit kannattaisivat nostaa "rajoja" (ylempi sallittu palkki), jotta "kuristusta" ei tapahdu: hetki, jolloin resurssi on jo käyttänyt CPU:ta tai muistia varatulla aikaviipaleella ja odottaa, kunnes se "purkaa":
Ja tässä on paloja, joiden pitäisi hillitä heidän ruokahaluaan:
Про kuristus + resurssien seuranta, voit kirjoittaa useamman kuin yhden artikkelin, joten kysy kysymyksiä kommenteissa. Muutamalla sanalla voin sanoa, että tällaisten mittareiden automatisointi on erittäin vaikeaa ja vaatii paljon aikaa ja tasapainottamista "ikkuna"-toimintojen ja "CTE" Prometheus / VictoriaMetricsin kanssa (nämä termit ovat lainausmerkeissä, koska siellä on melkein mitään tällaista PromQL:ssä, ja sinun on jaettava pelottavat kyselyt useisiin tekstinäyttöihin ja optimoitava ne).
Tämän seurauksena kehittäjillä on työkalut nimiavaruuksiensa seurantaan Cubessa ja he voivat itse valita, missä ja milloin minkä sovelluksen resursseja voidaan "leikata" ja mille palvelimille voidaan antaa koko CPU koko yön.
Menetelmät
Yrityksessä sellaisena kuin se nyt on muodikas, noudatamme DevOps- ja SRE-harjoittaja Kun yrityksellä on 1000 mikropalvelua, noin 350 kehittäjää ja 15 järjestelmänvalvojaa koko infrastruktuurille, täytyy olla "muodikas": kaikkien näiden "bassanojen" takana on kiireellinen tarve automatisoida kaikki ja kaikki, eikä ylläpitäjien pitäisi olla pullonkaula. prosesseissa.
Opsina tarjoamme kehittäjille erilaisia mittareita ja kojetauluja, jotka liittyvät palvelun vastausprosentteihin ja virheisiin.
Käytämme menetelmiä, kuten: , и yhdistämällä ne yhteen. Pyrimme minimoimaan kojetaulujen määrän, jotta yhdellä silmäyksellä on selvää, mikä palvelu on tällä hetkellä huonontunut (esimerkiksi vastauskoodit sekunnissa, vasteaika 99. prosenttipisteellä) ja niin edelleen. Heti kun joitain uusia mittareita tulee tarpeellisiksi yleisissä koontipaneeleissa, piirrämme ja lisäämme ne välittömästi.
En ole piirtänyt kaavioita kuukauteen. Tämä on luultavasti hyvä merkki: se tarkoittaa, että suurin osa "toiveista" on jo toteutunut. Sattui, että viikon aikana piirsin jonkun uuden kaavion ainakin kerran päivässä.
Tuloksena oleva tulos on arvokas, koska nykyään kehittäjät menevät melko harvoin järjestelmänvalvojien puoleen kysymyksillä "mistä katsoa jonkinlaista mittaria".
käyttöönotto Palveluverkko on aivan nurkan takana ja sen pitäisi helpottaa huomattavasti kaikkien elämää, Toolsin kollegat ovat jo lähellä abstraktin "terveen ihmisen istion" käyttöönottoa: jokaisen HTTP-pyynnön elinkaari näkyy seurannassa, ja se on aina mahdollista ymmärtää "missä vaiheessa kaikki meni rikki" yksiköiden välisen (eikä vain) vuorovaikutuksen aikana. Tilaa uutisia DomClick-keskuksesta. =)
Kubernetes-infrastruktuurin tuki
Historiallisesti käytämme korjattua versiota Kubespray — Sopiva rooli Kubernetesin käyttöönotossa, laajentamisessa ja päivittämisessä. Jossain vaiheessa tuki ei-kubeadm-asennuksille leikattiin päähaaralta, eikä kubeadmiin siirtymistä ehdotettu. Tämän seurauksena Southbridge-yritys teki oman haarukan (kubeadm-tuella ja pikakorjauksella kriittisiin ongelmiin).
Kaikkien k8s-klusterien päivitysprosessi näyttää tältä:
- ottaa Kubespray Southbridgestä, tarkista viestiketjumme, Merjim.
- Otamme päivityksen käyttöön Stressi- "Kuutio".
- Julkaisemme päivityksen yksi solmu kerrallaan (Ansiblessa tämä on "sarja: 1"). dev- "Kuutio".
- Päivitämme Prod lauantai-iltana yksi solmu kerrallaan.
Suunnitelmissa on korvata se tulevaisuudessa Kubespray jotain nopeampaa ja mene kubeadm.
Yhteensä meillä on kolme "kuutiota": Stress, Dev ja Prod. Suunnittelemme käynnistämään toisen (kuuma valmiustila) Prod-"Cube" toisessa datakeskuksessa. Stressi и dev elää "virtuaalisissa koneissa" (oVirt for Stress ja VMWare pilvi Deville). Prod- "Cube" elää "paljaalla metallilla": nämä ovat identtisiä solmuja, joissa on 32 CPU-säiettä, 64-128 Gt muistia ja 300 Gt SSD RAID 10 - niitä on yhteensä 50. Kolme "ohutta" solmua on omistettu "mestareille" Prod- "Kuuba": 16 Gt muistia, 12 CPU-säiettä.
Myynnissä käytämme mieluummin "paljasta metallia" ja vältämme tarpeettomia kerroksia, kuten OpenStack: emme tarvitse "meluisia naapureita" ja prosessoria varastaa aikaa. Ja hallinnon monimutkaisuus noin kaksinkertaistuu sisäisen OpenStackin tapauksessa.
CI/CD "Cubic" ja muut infrastruktuurikomponentit käytämme erillistä GIT-palvelinta Helm 3 (se oli melko tuskallinen siirtyminen Helm 2:sta, mutta olemme erittäin tyytyväisiä vaihtoehtoihin atomi-), Jenkins, Ansible ja Docker. Rakastamme ominaisuushaaroja ja käyttöönottoa eri ympäristöissä yhdestä arkistosta.
Johtopäätös
Yleisesti ottaen DevOps-prosessi näyttää tältä DomClickissä käyttöinsinöörin näkökulmasta. Artikkeli osoittautui vähemmän tekniseksi kuin odotin: siksi seuraa DomClick-uutisia Habresta: Kubernetesista tulee lisää "kovaa" artikkeleita ja paljon muuta.
Lähde: will.com