Kubernetes Domklik'is: kuidas rahulikult magada, hallates 1000 mikroteenuse klastrit

Minu nimi on Viktor Jagofarov ja olen Domklik'i Kubernetes platvormi arenduse tehniline juht Ops meeskonnas. Soovin rääkida meie Dev <-> Ops protsesside korraldusest, Venemaa ühe suurima k8s-klastri haldamise eripäradest ning DevOps/SRE praktikatest, mida meie meeskond rakendab.

Ops meeskond

Ops meeskonnas töötab hetkel 15 inimest. Kolm neist vastutavad büroo eest, kaks töötavad teises ajavööndis ning on saadaval, sealhulgas öösiti. Nii on alati keegi Ops'ist monitori taga, valmis reageerima igasuguste õnnetuste korral. Öösiti valveid meil ei ole, mis kaitseb meie vaimu ja annab võimaluse kõigile korralikult magada ja nautida vaba aega mitte ainult arvuti taga.

Kompetentsid on kõikidel erinevad: võrguinsenerid, DBA-d, ELK-i virna spetsialistid, Kubernetes-i administraatorid/aruandjad, jälgimise, virtualiseerimise ja riistvara spetsialistid jne. Ühendab kõiki üks asi — igaüks võib mingil määral asendada teist: näiteks lisada uusi sõlme k8s klastri, värskendada PostgreSQL, kirjutada CI/CD pipeline'i + Ansible, automatiseerida midagi Pythonis/Bashis/Go-s, ühendada riistvara andmekeskusesse. Tugevad kompetentsid mingis valdkonnas ei takista suunda muuta ja alustada õppimist mõnes teises valdkonnas. Näiteks, töötasin algselt ettevõttes PostgreSQL spetsialistina, kuid nüüd on minu peamine vastutusvaldkond Kubernetes klastri juhtimine. Meeskonnas on iga areng alati teretulnud ja ühtekuuluvustunne on väga tugevalt väljendatud.

Muide, me otsime uut talenti. Kandidaatidelt ootused on üsna standardsed. Minu jaoks on oluline, et inimene sobituks meeskonda, oleks konfliktivaba, kuid oskaks ka oma seisukohti kaitsta, sooviks areneda ja ei kardaks uut proovida ning tooks oma ideid lauale. Samuti on vajalikud programmimise oskused skriptikeeltes, teadmised Linuxi põhialustest ja inglise keel. Inglise keel on vajalik, et inimene saaks probleemide lahendamiseks kiiresti internetti otsida, mitte ei raiskaks sellele 10 minutit. Sügavate Linuxi teadmisteta spetsialiste on hetkel väga keeruline leida: naljakas, aga kaks kandidaati kolmest ei oska vastata küsimusele „Mis on Load Average? Millest see koosneb?”, ja küsimust „Kuidas koguda core dump C-programmist” peavad nad millegiks üleinimlikuks… või dinosauruste maailmast. Selle olukorraga tuleb leppida, kuna enamasti on inimestel teised oskused tugevalt arenenud, ning „liinukse” õpetame me ära. Vastus küsimusele „miks seda kõike peaks DevOps-insener tänapäeva pilveteenustes teadma” peab jääma artikli raames arutlemiseks, kuid kolme sõnaga: see on kõik vajalik.

Tööriistade meeskond

Automatiseerimises mängib olulist rolli Tools'i meeskond. Nende peamine ülesanne on luua arendajatele mugavaid graafilisi ja CLI-tööriistu. Näiteks võimaldab meie sisearendus Confer mõne hiireklõpsuga rakendust Kubernetesesse välja lasta, seadistada selle ressursid, võtmed vaultist jne. Varasemalt oli kasutusel Jenkins + Helm 2, kuid pidime arendama oma tööriista, et välistada kopeerimise ja kleepimise vajadus ning tuua tarkvaraarendusse ühtsust.

Ops'i meeskond ei kirjuta arendajate jaoks pipeline'e, kuid nad saavad anda nõu kõigis küsimustes nende kirjutamise osas (mõnel on veel Helm 3).

DevOps

Mis puutub DevOps'i, siis näeme seda sellisena:

Dev meeskonnad kirjutavad koodi, deployivad seda läbi Confer dev -> qa/stage -> prod. Vastutus selle eest, et kood ei tarduks ega viskaks vigu, lasub Dev ja Ops tiimidel. Päevasel ajal peab probleemide korral reageerima oma rakendusele esmajärjekorras Opsi dežuurija ja õhtuti ning öösel peab dežuuradmin (Ops) äratama dežuurarendaja, kui ta on kindel, et probleem ei ole infrastruktuuris. Kõik mõõdikud ja alertid monitoris tekivad automaatselt või poolautomaatsetena.

Opsi vastutus algab hetkest, kui rakendus saadetakse tootmisse, kuid Devi vastutus ei lõpe sellega — me teeme ühte asja ja oleme ühes paadis.

Arendajad konsulteerivad adminne, kui vajavad abi adminni mikroteenuse kirjutamisel (näiteks Go backend + HTML5), ning adminnid konsulteerivad arendajaid mis tahes infrastruktuuri või k8s-i seotud küsimustes.

Muide, meil ei ole üldse monoliiti, ainult mikroteenused. Nende arv on hetkel tootmis-k8s klastris vahemikus 900 kuni 1000, kui mõõta arvu järgi. deployments. Poodide arv varieerub 1700 ja 2000 vahel. Prod-klastris on hetkel umbes 2000 poodi.

Konkreetseid numbreid ma öelda ei saa, kuna jälgime tarbetuks osutunud mikroteenuseid ja eemaldame neid poolautomaatse režiimi abil. Tarbetute üksuste jälgimisel k8s aitab meid useless-operator, mis säästab suurel määral ressursse ja raha.

Ressursside haldamine

Jälgimine

Suure klastrihalduse nurgakiviks on õigesti üles ehitatud ja informatiivne jälgimine. Me ei ole veel leidnud universaalset lahendust, mis kataks 100% meie jälgimise soovidest, seega loome aeg-ajalt erinevaid kohandatud lahendusi selles keskkonnas.

• Zabbix. Hea, vana monitorimine, mis on mõeldud eelkõige infrastruktuuri üldise seisundi jälgimiseks. See ütleb meile, kui node sureb protsessori, mälu, ketaste, võrgu jne tõttu. Mitte midagi ülisuurt, kuid meil on ka eraldi DaemonSet agentidest, millega näiteks jälgime DNS-seisundit klastris: otsime coredns'i aeglustunud pods'e, kontrollime väliste hostide kätte saadavust. Tundub, et milleks selle pärast vaeva näha, kuid suurte andmemahtude korral on see komponent tõsine tõrkekoht. Varasemalt olen juba kirjeldanud, kuidas ma võitlen klastris DNS-i jõudlusprobleemidega.
• Prometheus Operator. Erinevate eksportijate kogum annab suure ülevaate kogu klastrist. Edasi visualiseerime kõik selle suurelt armatuurlaudades Grafanas, ja teatiste jaoks kasutame alertmanager'i.

Veel üheks kasulikuks tööriistaks meie jaoks sai list-ingress. Kirjutasime selle pärast seda, kui olime paar korda kokku puutunud olukorraga, kus üks meeskond kattis teise meeskonna Ingressi enda teed pidi, mis põhjustas 50x vigu. Nüüd kontrollivad arendajad enne tootmisesse üleviimist, et keegi ei jääks kõrvale, ja see on minu meeskonna jaoks hea tööriist Ingressi probleemide esialgseks diagnoosimiseks. Naljakas, et algselt kirjutati see administraatoritele ja see nägi välja üsna „puine”, kuid pärast seda, kui tööriist meeldis arendusmeeskondadele, muutus see oluliselt ja enam ei näe välja nagu „administraator tegi administraatoritele veebiliidese”. Peagi loobume sellest tööriistast ja sarnased olukorrad valideeritakse enne torujuhtme väljalaskmist.

Meeskondade ressursid «Kubes»

Enne näidete juurde asumist tasub selgitada, kuidas meil toimub ressursside eraldamine mikroteenustena.

Selleks, et mõista, millised meeskonnad ja kui palju kasutavad oma ressursse (protsessor, mälu, kohalik SSD), eraldame iga meeskonna jaoks oma namespace Kubes on maksime võimalused protsessori, mälu ja ketta osas eelnevalt arutades meeskondade vajadusi. Seetõttu ei saa üks meeskond üldiselt blokeerida kogu klastrit, eraldades endale tuhandeid tuumasid ja tera byte mälu. Namespace'ide juurdepääsud antakse välja AD kaudu (kasutame RBAC-d). Namespace'id ja nende piirangud lisatakse GIT-repositorisse läbi pull-request'ide, pärast mida rakendatakse kõik automaatselt Ansible'i pipeline'i kaudu.

Näide ressursside eraldamisest meeskonnale:

namespaces:

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

Request’id ja limiidid

Kubes Request — see on garantiseeritud reservatsioonide arv pod (üks või rohkem docker-konteinerit) klaster. Limit on mittegarantiseeritud maksimaalne väärtus. Sageli võib näha graafikutelt, kuidas mõni rühm seadis endale liiga palju request’e kõigile oma rakendustele ja ei saa rakendust Kubesse juurutada, kuna nende namespace'i kõik request'id on juba "kulutatud".

Sellest olukorrast õige lahendus: vaadata tegelikku ressursi tarbimist ja võrrelda seda nõutud kogusega (Request).

Ülalolevates ekraanipiltides on näha, et „taotletud” (Requested) CPU-d kohandatakse tegeliku lõimearvuga, samas kui Limits võivad ületada tegelikku protsessorite lõimearvu =)

Nüüd vaatame põhjalikult ühte namespace'i (valisin namespace kube-system — süsteeminamespace Kuberi komponentidele) ja vaatame, kuidas võrreldakse tegelikult kasutatud protsessoriaega ja mälu taotletuga:

On ilmne, et süsteemsete teenuste jaoks on reserveeritud palju rohkem mälu ja CPU-d kui tegelikult kasutatakse. Kube-systemi puhul on see õigustatud: on olnud aegu, kus nginx ingress controller või nodelocaldns on tipptundidel CPU-le kinni jäänud ja kasutanud väga palju RAM-i, seega on siin selline varu õigustatud. Pealegi ei saa me toetuda viimase 3 tunni graafikutele: soovitav on näha ajaloolisi mõõdikuid pikema aja jooksul.

On välja töötatud soovituste süsteem. Näiteks siin on näha, milliseid ressursse tasuks „piiride” (ülemine lubatud tase) tõstmiseks, et vältida „trotlingut” (throttling): hetke, kui juba on kulunud CPU või mälu ettenähtud ajakvotal ja oodatakse, kuni nad „lahendatakse”:

Siin on podid, mida tasuks natuke piirata:

Umbes throttling + ressursside jälgimine on laiem teema, mille kohta võiks kirjutada mitmeid artikleid, seega küsige julgelt kommentaarides. Lühidalt ütlen, et selliste metrikate automatiseerimine on keeruline ülesanne, mis nõuab palju aega ja oskusi, sealhulgas „akna“ funktsioone ja „CTE“ Prometheus / VictoriaMetrics (need terminid on jutumärkides, kuna PromQL-s ei ole praktiliselt midagi sarnast ja tuleb kirjutada hirmuäratavaid päringuid, mis ulatuvad mitme ekraani pikkuseks ja optimeerida neid).

Lõpuks on arendajatel tööriistad oma namespaces'i jälgimiseks „Kube'is“ ning nad saavad ise valida, kus ja millal milliste rakenduste puhul ressursse „lõigata“, ja millistele podidele võib kogu CPU ööseks üle anda.

Metoodikad

Praegu ettevõttes on moes, järgime DevOps- ja SRE-praktikaid. Kui ettevõttes on 1000 mikroteenust, umbes 350 arendajat ja 15 administraatorit kogu infrastruktuuri jaoks, tuleb „olla moes“: nende „buzzwordide“ taga peitub terav vajadus kõike automatiseerida ja administraatorid ei tohi olla protsesside pudelikael.

Opsina me, pakume arendajatele erinevaid mõõdikuid ja juhtpaneele, mis on seotud teenuste vastuse kiirus ja tõrgetega.

Kasutame järgmisi metoodikaid: RED, USE ja Kuldse Signaalid, kombineerides need kokku. Püüame vähendada juhtpaneelide arvu nii, et ühest pilgust oleks selge, milline teenus on hetkel halvenemas (näiteks vastuse koodid sekundis, vastuse aeg 99. protsentiili järgi) jne. Kui vajame uusi mõõdikuid üldistele juhtpaneelidele, siis joonistame need kohe ja lisame.

Ma ei ole kuu aega graafikuid joonistanud. See on ilmselt hea märk: see tähendab, et enamik "soove" on juba ellu viidud. Oli aegu, kus ma vähemalt kord päevas olen näinud uue graafiku joonistamist.

Saavutatud tulemus on väärtuslik, kuna nüüd käivad arendajad üsna harva administraatorite juures küsimustega "kust vaadata mingit mõõdikut".

Rakendamine Teenuste Mesh ei ole kaugel ja peaks kõigile elu oluliselt lihtsamaks tegema, Tools'i kolleegid on juba lähedal «terve inimese Istio» rakendamisele: iga HTTP(s) päringu elutsükkel on nähtav jälgimises ja alati saab aru, «millisel etapil kõik katki läks» teenuste vahelisel (ja mitte ainult) suhtlemisel. Liituge DomKliki uudiskirjaga. =)

Kubernetes'i infrastruktuuri tugi

Ajalooliselt on meil kasutuses patcheeritud versioon Kubespray — Ansible'i roll Kubernetes'i juurutamiseks, laiendamiseks ja uuendamiseks. Mingil hetkel eemaldati põhiharust tugi non-kubeadm installatsioonidele ning ülemineku protsessi kubeadm'e peale ei pakutud välja. Lõppkokkuvõttes tegi ettevõte Southbridge oma fork'i (kubeadm toe ja kiire kriitiliste probleemide lahendamisega).

Kõikide k8s klastrite uuendamisprotsess välja näeb selline:

• Võtame Kubespray Southbridge'ist, kontrollime meie haru vastu, mergime.
• Toome uuenduse välja Stress- «Kast».
• Toome uuenduse välja ühele nodile (Ansible'is on see «serial: 1») igaühele Dev- «Kast».
• Uuendame Prod laupäeva õhtul ühele nodile.

Tulevikus on plaanid asendada Kubespray millegagi kiiremaga ja minna üle kubeadm'ile..

Kokku on meil kolm „Kubi”: Stress, Dev ja Prod. Plaanime veel ühe käivitada (kuum varu) Prod-„Kubi” teises andmekeskuses. Stress ja Dev Elame „virtuaalides” (oVirt Stress jaoks ja VMWare cloud Dev jaoks). Prod-„Kubi” elab „paljas rauas”: need on ühesugused nodid, millel on 32 CPU lõime, 64-128 GB mälu ja 300 GB SSD RAID 10 — kokku on neid 50. Kolm „õhukest” nodi on reserveeritud „meistritele” Prod-„Kubides”: 16 GB mälu, 12 CPU lõime.

Müügi puhul eelistame kasutada „paljast rauast” ja vältida liigseid kihte nagu OpenStack: me ei vaja „mürarikkaid naabreid” ja CPU aeg varastama. Ja keerukus haldamine suureneb umbes kaks korda juhul, kui kasutatakse OpenStacki enda majas.

CI/CD „Kubi” ja teiste infrastruktuuri komponentide jaoks kasutame eraldi GIT-serverit, Helm 3 (üleminek Helm 2-lt oli üsna valus, kuid oleme väga rahul valikuga aatomiline), Jenkins, Ansible ja Docker. Armastame feature-oksi ja juurutamist erinevatesse keskkondadesse ühest repost.

Kokkuvõte

Nii paistab, üldiselt, ettevõttes DomKlik, DevOpsi protsess tööinseneri vaatepunktist. Artikkel osutus vähem tehniliseks kui ootasin: seega jälgige DomKli uudiseid Habrilt: tuleb rohkem „hädas” artikleid Kubernetesest ja mitte ainult.

Allikas: habr.com