Kubernetes DomClickis: kuidas rahulikult magada, hallates 1000 mikroteenuse klastrit

Minu nimi on Viktor Yagofarov ja ma olen tehnoloogia juht, kes arendab Kubernetes platvormi ettevõttes DomClick, takistuse Ops meeskonnas. Soovin rääkida meie Dev <-> Ops protsesside struktuurist, ühtedest Venemaa suurimatest k8s klastritest ja ka meie meeskonna rakendatud DevOps/SRE praktikast.

Ops meeskond

Ops meeskonnas töötab hetkel 15 inimest. Kolm neist vastutavad kontori eest, kaks töötavad teises ajavööndis ja on kergesti kättesaadavad, sealhulgas öösel. Seega on alati keegi Opsis monitori ees ja valmis reageerima mis tahes keerukusega juhtumile. Öövahtimisi meil ei ole, mis kaitseb meie vaimu ja võimaldab kõigil piisavalt und saada ning aega veeta mitte ainult arvuti taga.

Kõigil on erinevad oskused: võrguhaldurid, DBA-d, ELK stack spetsialistid, Kubernetes administraatorid/arendajad, jälgimise, virtualiseerimise ja riistvara spetsialistid jne. Ühendab meid see, et igaühel on võimalus kellegi teise rolli mingil määral täita: näiteks uute sõlmede lisamine k8s klastrisse, PostgreSQL uuendamine, CI/CD + Ansible torujuhtme kirjutamine, millegi automatiseerimine Pythonis/Bashis/Go-s, riistvara ühendamine andmekeskuses. Tugevad oskused ühes valdkonnas ei takista suunamuutust ja arengut teises valdkonnas. Näiteks astusin ettevõttesse sisse PostgreSQL spetsialistina, kuid nüüd on minu peamine vastutusala Kubernetes klastrid. Meeskonnas on iga kasv ainult teretulnud ning ühtekuuluvustunne on tugev.

Muide, me otsime töötajaid. Kandidaatide nõudmised on üsna standardsed. Isiklikult on mulle oluline, et inimene sobituks meeskonda, oleks konfliktivaba, kuid oskaks ka oma seisukohti kaitsta, sooviks areneda ja ei kardaks proovida midagi uut, pakkuda oma ideid. Samuti on vajalikud oskused skriptikeelte programmeerimises, Linuxi põhialuste tundmine ja inglise keele oskus. Inglise keelt on vaja lihtsalt selleks, et inimene saaks vajadusel probleemide lahendusi kiiremini googeldada, mitte kulutada sellele 10 minutit. Sügava Linuxi tundmisega spetsialistidega on praegu väga keeruline: naljakas, kuid kaks kolmandikku kandidaatidest ei oska vastata küsimusele „Mis on Load Average? Kuidas see koosneb?”, ja küsimust „Kuidas koguda core dump C-programmist?” peavad nad millegiks üleloomulikuks… või dinosaurusteks. Sellega tuleb leppida, kuna tavaliselt on inimeste muud oskused väga arenenud ja „Linuxit“ õpetame me ise. Küsimusele „miks on see kõik vajalik DevOps insenerile tänapäeva pilve maailmas“ peame vastuse jätma artikli piiresse, kuid kolme sõnaga: kõik see on vajalik.

Tööriistade meeskond

Automatiseerimisel mängib olulist rolli Tööriistade meeskond. Nende peamine eesmärk on luua mugavaid graafilisi ja CLI tööriistu arendajatele. Näiteks meie sisearendus Confer võimaldab tõeliselt paar hiireklõpsu abil rakendust Kubernetesesse välja saata, seadistada ressursid, võtmed vaultist jne. Varem kasutati Jenkins + Helm 2, kuid tuli arendada oma tööriist, et vältida kopeerimist ja kleepimist ning tuua tarkvara elutsüklisse ühtlus.

Ops meeskond ei kirjuta arendajate jaoks torusid, kuid võib anda nõu kõigis nende kirjutamise küsimustes (osadel on veel jäänud Helm 3).

DevOps

Mis puudutab DevOps’i, siis näeme seda sellisena:

Dev meeskonnad kirjutavad koodi ja saadavad selle Conferiga dev -> qa/stage -> prod. Vastutus, et kood ei aeglustuks ja ei viskaks vigu, lasub Dev ja Ops meeskondadel. Päeval peab oma rakenduse probleemi puhul reageerima peamiselt Ops’i vaht, aga õhtul ja öisel ajal peab vahtadmin (Ops) äratama vahtarendaja, kui ta on kindel, et probleem ei ole infrastruktuuris. Kõik mõõdikud ja häired tulevad jälgimisest automaatselt või poolautomaatselt.

Opsi vastutus algab rakenduse kasutuselevõtust, kuid Dev'i vastutus ei lõppe sellega — me teeme sama asja ja oleme samas paadis.

Arendajad nõustavad administraatoreid, kui vajalik on abi administraatori mikroteenuse kirjutamisel (näiteks Go backend + HTML5), ja administraatorid nõustavad arendajaid iga infrastruktuuri või k8s-iga seotud küsimuses.

Üldiselt pole meil monoliiti, vaid ainult mikroteenuseid. Nende arv kõigub praegu 900 ja 1000 vahel prod k8s-klasteres, sõltuvalt arvust. deploymentsPod'i arv kõigub 1700 ja 2000 vahel. Pod'e on praegu umbes 2000 prod-klastri sees.

Exact arve öelda ei saa, kuna jälgime tarbetuid mikroteenuseid ja eemaldame neid poolautomaatse süsteemiga. Tarbetute üksuste jälgimist k8s-is aitab meil teha useless-operator, mis säästab suurepäraselt ressursse ja raha.

Ressursside haldamine

Jälgimine

Suurte klastrite haldamise oluline alus on nõuetekohaselt üles ehitatud ja informatiivne jälgimine. Me ei ole veel leidnud universaalset lahendust, mis kataks 100% kõigist jälgimise soove, seetõttu teeme aeg-ajalt erinevaid kohandatud lahendusi selles valdkonnas.

• Zabbix. Vanakooli jälgimine, mis on peamiselt mõeldud infrastruktuuri üldise oleku jälgimiseks. See teatab meile, kui sõlm hukkub protsessori, mälu, ketaste, võrgu jne osas. Midagi ülemäära erakordset, kuid meil on ka eraldi DaemonSet agendiga, millega jälgime näiteks klastris DNS-i seisundit: otsime coredns'i ummikutega pod'e, kontrollime välistest hostidest juurdepääsu. Tundub, et miks selle üle üldse muretsemine, kuid suurte andmehulkade korral on see komponent tõsine tõrkepunkt. Olen juba varem kirjeldanud, kuidas ma võitlen DNS-i toimivuse nimel klastris.
• Prometheus Operator. Erinevate eksportijate kogum annab suure ülevaate kõigist klastrikomponentidest. Edasi visualiseerime kõik selle suurtes armatuurlaudades Grafanas, ja teavitamiseks kasutame alertmanagerit.

Teine meie jaoks kasulik tööriist on list-ingress. Oleme selle kirjutanud pärast mitmeid kordi, mil üks meeskond kattis oma teed teise meeskonna Ingress'i, mis põhjustas 50x vigu. Praegu kontrollivad arendajad enne tootmisse viimist, et keegi ei kannataks, ja minu jaoks on see hea tööriist Ingress'ide probleemide esmaseks diagnoosimiseks. Naljakas, et see kirjutati esmakordselt administraatoritele ja nägi välja üsna "jämedalt", kuid pärast seda, kui tööriist armus arendusmeeskondadesse, on see tugevalt muutunud ja näeb välja nagu "administraator tegi veebiliidese administraatoritele". Peagi loobume sellest tööriistast ja sarnased olukorrad valideeritakse veel enne torujuhtme väljatõstmist.

Meeskondade ressursid 'Kubes'

Enne näidete vaatamist on mõistlik selgitada, kuidas meie süsteem ressursi eraldamist töötajaile. Mikroteenused.

Et aru saada, millised meeskonnad ja kui palju nad oma ressursse kasutavad ressursid (protsessor, mälu, kohalik SSD), eraldame igale meeskonnale oma namespace Kubes ja piirame selle maksimaalseid võimalusi protsessori, mälu ja ketta osas, eelnevalt arutades meeskondade vajadusi. Seetõttu ei blokeeri ükski meeskond tavaliselt kogu klastrit, eraldades endale tuhandeid tuumasid ja terabaiti mälu. Ning ligipääsud namespace'idele antakse välja AD (me kasutame RBAC). Namespace'id ja nende piirangud lisatakse GIT-reposse puuloomise kaudu, ning seejärel automatiseeritakse kõik Ansible'i torujuhtmega.

Ressursi eraldamise näide meeskonnale:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

Päringud ja piirangud

Kubes Päring — see on garantii, et ressursside kogus on eraldatud pod (üks või mitu Docker'i konteinerit) klastris. Piirang on see, mis ei ole garanteeritud maksimum. Sageli võib graafikutelt näha, kuidas mõni meeskond on seadnud endale liiga palju päringuid kõigi oma rakenduste jaoks ja ei saa rakendust 'Kubes' juurutada, kuna nende namespace'is on kõik päringud juba "kulutatud".

Õige väljapääs sellisest olukorrast: vaadata tegelikku ressursikasutust ja võrrelda seda küsitud kogusega (Päring).

Ülaltoodud ekraanipiltidel on näha, et "küsimustikud" (Requested) protsessorid lähedane reaalsele lõime arvule, samas kui Piirangud võivad ületada reaalseid keskprotsessori lõime arve =)

Nüüd vaatleme üksikasjalikult mõnda namespace'i (valisin namespace kube-system — süsteemi namespace'i "Kubi" komponentide jaoks) ja vaatame, kuidas suhe tegelikult kasutatud protsessorite ja mälu ning küsitud väärtuste vahel on:

On ilmne, et süsteemiteenuste jaoks on reserveeritud palju rohkem mälu ja CPU-d, kui tegelikult kasutatakse. Kube-systemi puhul on see põhjendatud: on juhtunud, et nginx ingress controller või nodelocaldns on tipphetkel jõudnud CPU piirini ja kasutanud väga palju RAM-i, seega on siin selline varu õigustatud. Lisaks ei saa me tugineda viimase kolme tunni graafikutele: oleks soovitav näha ajaloolisi mõõdikuid pikema aja jooksul.

On välja töötatud "soovituste" süsteem. Näiteks on siin näha, milliseid ressursse oleks mõistlik "piirata" (ülemine lubatud tase), et vältida "trotling'ut": hetke, mil juba kulutatud CPU või mälu antud ajakvandi jooksul ning oodata, kuni see "külmutatakse":

Ja siin on podid, millel oleks kasulik oma apetiti mõõta:

Küsimus trotling + ressursimonitoringu kohta saab kirjutada mitmeid artikleid, seega küsige küsimusi kommentaarides. Paar sõna võib öelda, et selliste mõõdikute automatiseerimise ülesanne on üsna keeruline ja nõuab palju aega ja akrobaatikat "aken" funktsioonide ja "CTE" Prometheus / VictoriaMetrics abil (need terminid on siin jutumärkides, kuna PromQL-is pole peaaegu midagi sarnast ning tuleb koostada hirmutavaid päringuid, mis katavad mitu ekraani teksti, ja tegeleda nende optimeerimisega).

Lõppkokkuvõttes on arendajatel tööriistad oma namespace'ide jälgimiseks "Kubis", ja nad saavad ise valida, kus ja millal milliste rakenduste ressursse "lõigata" ning millistele podidele saab kogu CPU öö jooksul anda.

Metodoloogiad

Ettevõttes, nagu nüüd moes, järgime DevOps- ja SRE-praktikaid. Kui ettevõttes on 1000 mikrosüsteemi, umbes 350 arendajat ja 15 administraatorit kogu infrastruktuuri jaoks, peab olema "moes": kõikide nende "buzzwordide" taga peitub äge vajadus automaatika järele, ja administraatorid ei tohi olla pudelikael protsessides.

Opsina anname arendajatele erinevaid mõõdikuid ja juhtpaneele, mis on seotud teenuste vastamise kiirus ja nende vead.

Kasutame selliseid metodoloogiaid nagu: RED, USE ja Golden Signals, kombineerides need koos. Püüame vähendada armatuurlaudade arvu nii, et ühest pilgust oleks selge, milline teenus praegu halveneb (näiteks vastuskoodide hulk sekundis, 99. persenti vastamise aeg) jne. Niipea kui vajame uusi mõõdikuid ühiste armatuurlaudade jaoks, viime need kohe joonistesse ja lisame.

Ma ei ole graafikuid joonistanud juba kuu aega. Arvatavasti on see hea märk: see tähendab, et enamik "soove" on juba ellu viidud. Juhtus, et nädalas joonistasin vähemalt kord päevas mõne uue graafiku.

Saavutatud tulemus on väärtuslik, kuna nüüd esitlevad arendajad üsna harva administratsioonile küsimusi "kus vaadata mõnda mõõdikut".

Rakendamine Service Mesh ei ole kaugel ja peaks kõigile elu oluliselt lihtsustama, kolleegid Toolsist on juba lähedal "terve inimese Istio" rakendamisele: iga HTTP(s) päringu elutsükkel on jälgimise kaudu nähtav ning alati saab aru, "millises etapis kõik läks valesti" teenustevahelises (ja mitte ainult) suhtluses. Liituge DomClicki ettevõtte uudiskirjaga. =)

Kubernetes infrastruktuuri tugi

Ajalooliselt oleme kasutanud patšitud versiooni Kubespray — Ansible'i roll Kubernetes'i käivitamiseks, laiendamiseks ja värskendamiseks. Ühel hetkel eemaldati põhivoolust tugi non-kubeadm installatsioonidele, ja protsessi üleminekut kubeadm-ile ei pakutud. Lõpuks tegi ettevõte Southbridge oma kõrgendatud versiooni (kubeadm toe ja kiire kriitiliste probleemide lahendusega).

Kogu k8s klastrite värskendamisprotsess näeb välja selline:

• Võtame Kubespray Southbridge'ist, kontrollime meie haruga, sulandame.
• Väljastame värskenduse Stress-"Kuppel".
• Väljastame värskenduse ühe nodi kaupa (Ansible'is on see "serial: 1") Dev-"Kuppel".
• Värskendame Prod laupäeva õhtul ühe nodi kaupa.

Tulevikus on plaanis asendada Kubespray millegi kiirema vastu ja liikuda üle kubeadm.

Kokku on meil kolm "Kuppel": Stress, Dev ja Prod. Plaanime käivitada veel ühe (hot standby) Prod-"Kuppel" teises andmekeskuses. Stress ja Dev elavad "virtuaalmasinates" (oVirt Stressi jaoks ja VMWare cloud Dev'i jaoks). Prod-"Kuppel" elab "alumisel raual" (bare metal): need on samasugused nodid, igaühes 32 CPU lõnga, 64-128 GB mälu ja 300 GB SSD RAID 10 — kokku on neid 50. Kolm "pehmed" nodi on määratud "meister" Prod-"Kuppel": 16 GB mälu, 12 CPU lõnga.

Müügis eelistame kasutada "alust rauda" ja vältida liigseid kihtide, nagu OpenStack: meil ei ole vaja "mürarikkaid naabreid" ja CPU steal timeJa keerukus haldamine suureneb umbes kahekordselt in-house OpenStacki puhul.

CI/CD „Kube” ja teiste infrastruktuurikomponentide jaoks kasutame eraldi GIT-serverit, Helm 3 (üleminek Helm 2-st oli üsna vaevaline, kuid oleme väga rahul võimalusega aatomiline), Jenkins, Ansible ja Docker. Me armastame feature-harusid ja juurutamist erinevatesse keskkondadesse ühest hoidlast.

Kokkuvõte

Nii näeb DomClickis inseneri vaatenurgast DevOpsi protsess välja. Artikkel on vähem tehniline, kui ma ootasin: seega, jälgige DomClicki uudiseid Habr's, tulevad rohkem „hardcore” artiklid Kubernetesest ja muust.

Allikas: habr.com