Fy enw i yw Viktor Yagofarov, ac rwy'n datblygu platfform Kubernetes yn DomClick fel rheolwr datblygu technegol yn y tîm Ops (gweithrediad). Hoffwn siarad am strwythur ein prosesau Dev <-> Ops, nodweddion gweithredu un o'r clystyrau k8s mwyaf yn Rwsia, yn ogystal â'r arferion DevOps / ARhPh y mae ein tîm yn eu cymhwyso.
Tîm Gweithrediadau
Ar hyn o bryd mae gan dîm yr Ops 15 o bobl. Mae tri ohonynt yn gyfrifol am y swyddfa, dau yn gweithio mewn parth amser gwahanol ac ar gael, gan gynnwys gyda'r nos. Felly, mae rhywun o Ops bob amser wrth y monitor ac yn barod i ymateb i ddigwyddiad o unrhyw gymhlethdod. Nid oes gennym ni shifftiau nos, sy'n cadw ein psyche ac yn rhoi cyfle i bawb gael digon o gwsg a threulio amser hamdden nid yn unig wrth y cyfrifiadur.
Mae gan bawb gymwyseddau gwahanol: rhwydwaithwyr, DBAs, arbenigwyr pentwr ELK, gweinyddwyr / datblygwyr Kubernetes, monitro, rhithwiroli, arbenigwyr caledwedd, ac ati. Mae un peth yn uno pawb - gall pawb ddisodli unrhyw un ohonom i raddau: er enghraifft, cyflwyno nodau newydd i'r clwstwr k8s, diweddaru PostgreSQL, ysgrifennu piblinell CI/CD + Ansible, awtomeiddio rhywbeth yn Python/Bash/Go, cysylltu caledwedd i Canolfan ddata. Nid yw cymwyseddau cryf mewn unrhyw faes yn eich atal rhag newid cyfeiriad eich gweithgaredd a dechrau gwella mewn rhyw faes arall. Er enghraifft, ymunais â chwmni fel arbenigwr PostgreSQL, ac yn awr fy mhrif faes cyfrifoldeb yw clystyrau Kubernetes. Yn y tîm, croesewir unrhyw uchder ac mae'r ymdeimlad o drosoledd yn ddatblygedig iawn.
Gyda llaw, rydym yn hela. Mae'r gofynion ar gyfer ymgeiswyr yn eithaf safonol. I mi yn bersonol, mae'n bwysig bod person yn ffitio i mewn i'r tîm, yn ddi-wrthdaro, ond hefyd yn gwybod sut i amddiffyn ei safbwynt, eisiau datblygu ac nid yw'n ofni gwneud rhywbeth newydd, yn cynnig ei syniadau. Hefyd, mae angen sgiliau rhaglennu mewn ieithoedd sgriptio, gwybodaeth am hanfodion Linux a Saesneg. Mae angen Saesneg yn syml fel bod person mewn achos o fakap yn gallu googleio datrysiad i'r broblem mewn 10 eiliad, ac nid mewn 10 munud. Mae bellach yn anodd iawn dod o hyd i arbenigwyr sydd â gwybodaeth ddofn am Linux: mae'n ddoniol, ond ni all dau o bob tri ymgeisydd ateb y cwestiwn “Beth yw Cyfartaledd Llwyth? O beth mae wedi'i wneud?”, ac mae'r cwestiwn “Sut i gydosod dymp craidd o raglen C” yn cael ei ystyried yn rhywbeth o fyd y supermen... neu ddeinosoriaid. Mae'n rhaid i ni ddioddef hyn, oherwydd fel arfer mae gan bobl gymwyseddau eraill hynod ddatblygedig, ond byddwn yn addysgu Linux. Bydd yn rhaid gadael yr ateb i'r cwestiwn "pam mae angen i beiriannydd DevOps wybod hyn i gyd ym myd modern y cymylau" y tu allan i gwmpas yr erthygl, ond mewn tri gair: mae hyn i gyd yn angenrheidiol.
Offer Tîm
Mae tîm Tools yn chwarae rhan arwyddocaol mewn awtomeiddio. Eu prif dasg yw creu offer graffigol a CLI cyfleus ar gyfer datblygwyr. Er enghraifft, mae ein Confer datblygu mewnol yn caniatáu ichi gyflwyno cais yn llythrennol i Kubernetes gyda dim ond ychydig o gliciau llygoden, ffurfweddu ei adnoddau, allweddi o gladdgell, ac ati. Cyn hynny, roedd Jenkins + Helm 2, ond bu'n rhaid i mi ddatblygu fy erfyn fy hun i ddileu copi-gludo a dod ag unffurfiaeth i gylch bywyd y meddalwedd.
Nid yw tîm yr Ops yn ysgrifennu piblinellau ar gyfer datblygwyr, ond gallant roi cyngor ar unrhyw faterion yn eu hysgrifennu (mae gan rai pobl Helm 3 o hyd).
DevOps
O ran DevOps, rydyn ni'n ei weld fel hyn:
Timau datblygu yn ysgrifennu cod, ei gyflwyno trwy Confer i dev -> qa/stage -> prod. Y timau Datblygu a Gweithrediadau sy'n gyfrifol am sicrhau nad yw'r cod yn arafu ac nad yw'n cynnwys gwallau. Yn ystod y dydd, dylai’r person sydd ar ddyletswydd o’r tîm Gweithrediadau ymateb yn gyntaf i ddigwyddiad gyda’i gais, a gyda’r nos a gyda’r nos, dylai’r gweinyddwr ar ddyletswydd (Ops) ddeffro’r datblygwr sydd ar ddyletswydd os yw’n gwybod am hynny. yn siŵr nad yw’r broblem yn yr isadeiledd. Mae'r holl fetrigau a rhybuddion wrth fonitro yn ymddangos yn awtomatig neu'n lled-awtomatig.
Mae maes cyfrifoldeb Ops yn dechrau o'r eiliad y mae'r cais yn cael ei gyflwyno i gynhyrchu, ond nid yw cyfrifoldeb Dev yn dod i ben yno - rydym yn gwneud yr un peth ac rydym yn yr un cwch.
Mae datblygwyr yn cynghori gweinyddwyr os oes angen help arnynt i ysgrifennu microwasanaeth gweinyddol (er enghraifft, Go backend + HTML5), ac mae gweinyddwyr yn cynghori datblygwyr ar unrhyw faterion seilwaith neu faterion sy'n ymwneud â k8s.
Gyda llaw, nid oes gennym monolith o gwbl, dim ond microwasanaethau. Mae eu nifer hyd yn hyn yn amrywio rhwng 900 a 1000 yn y clwstwr prod k8s, os caiff ei fesur yn ôl rhif defnyddio. Mae nifer y codennau'n amrywio rhwng 1700 a 2000. Ar hyn o bryd mae tua 2000 o godennau yn y clwstwr prod.
Ni allaf roi union niferoedd, gan ein bod yn monitro microwasanaethau diangen ac yn eu torri allan yn lled-awtomatig. Mae K8s yn ein helpu i gadw golwg ar endidau diangen , sy'n arbed llawer o adnoddau ac arian.
Rheoli adnoddau
Monitro
Mae monitro strwythuredig ac addysgiadol yn dod yn gonglfaen gweithrediad clwstwr mawr. Nid ydym eto wedi dod o hyd i ateb cyffredinol a fyddai'n cwmpasu 100% o'r holl anghenion monitro, felly rydym o bryd i'w gilydd yn creu gwahanol atebion arferol yn yr amgylchedd hwn.
- Zabbix. Hen waith monitro da, a fwriedir yn bennaf i olrhain cyflwr cyffredinol y seilwaith. Mae'n dweud wrthym pan fydd nod yn marw o ran prosesu, cof, disgiau, rhwydwaith, ac ati. Dim byd goruwchnaturiol, ond mae gennym hefyd DaemonSet o asiantau ar wahân, gyda chymorth y rhain, er enghraifft, rydym yn monitro cyflwr DNS yn y clwstwr: rydym yn edrych am godennau coredns dwp, rydym yn gwirio argaeledd gwesteiwyr allanol. Mae'n ymddangos mai pam trafferthu â hyn, ond gyda llawer iawn o draffig mae'r gydran hon yn bwynt methiant difrifol. Rwyf eisoes , sut yr oeddwn yn cael trafferth gyda pherfformiad DNS mewn clwstwr.
- Gweithredwr Prometheus. Mae set o allforwyr gwahanol yn rhoi trosolwg mawr o holl gydrannau'r clwstwr. Nesaf, rydym yn delweddu hyn i gyd ar ddangosfyrddau mawr yn Grafana, ac yn defnyddio rheolwr rhybuddio ar gyfer rhybuddion.
Teclyn defnyddiol arall i ni oedd . Fe wnaethon ni ei ysgrifennu ar ôl i ni ddod ar draws sefyllfa sawl gwaith lle roedd un tîm yn gorgyffwrdd â llwybrau Ingress tîm arall, gan arwain at wallau 50x. Nawr cyn anfon i gynhyrchu, mae datblygwyr yn gwirio na fydd unrhyw un yn cael ei effeithio, ac ar gyfer fy nhîm mae hwn yn arf da ar gyfer diagnosis cychwynnol o broblemau gydag Ingresses. Mae'n ddoniol ei fod wedi'i ysgrifennu ar gyfer gweinyddwyr ar y dechrau ac roedd yn edrych braidd yn “trwsgl”, ond ar ôl i'r timau datblygu syrthio mewn cariad â'r teclyn, fe newidiodd lawer a dechreuodd edrych yn wahanol i “gweinyddwr wedi gwneud wyneb gwe i weinyddwyr. ” Yn fuan byddwn yn rhoi'r gorau i'r offeryn hwn a bydd sefyllfaoedd o'r fath yn cael eu dilysu hyd yn oed cyn i'r biblinell gael ei chyflwyno.
Adnoddau tîm yn y Ciwb
Cyn inni fynd i mewn i’r enghreifftiau, mae’n werth egluro sut rydym yn dyrannu adnoddau ar ei gyfer microwasanaethau.
Deall pa dimau ac ym mha niferoedd sy'n defnyddio eu adnoddau (prosesydd, cof, SSD lleol), rydym yn dyrannu pob gorchymyn ei hun gofod enwau yn y “Cube” a chyfyngu ar ei alluoedd mwyaf posibl o ran prosesydd, cof a disg, ar ôl trafod anghenion y timau yn flaenorol. Yn unol â hynny, ni fydd un gorchymyn, yn gyffredinol, yn rhwystro'r clwstwr cyfan i'w ddefnyddio, gan ddyrannu miloedd o greiddiau a terabytes cof. Rhoddir mynediad i ofod enwau trwy AD (rydym yn defnyddio RBAC). Ychwanegir gofodau enwau a'u terfynau trwy gais tynnu i'r gadwrfa GIT, ac yna caiff popeth ei gyflwyno'n awtomatig trwy'r biblinell Ansible.
Enghraifft o ddyrannu adnoddau i dîm:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Ceisiadau a therfynau
Ciwb" Cais yw nifer yr adnoddau neilltuedig gwarantedig ar gyfer pod (un neu fwy o gynwysyddion docwyr) mewn clwstwr. Mae terfyn yn uchafswm heb ei warantu. Yn aml, gallwch weld ar y graffiau sut mae rhai tîm wedi gosod gormod o geisiadau iddo'i hun ar gyfer ei holl gymwysiadau ac ni allant ddefnyddio'r cymhwysiad i'r “Cube”, gan fod pob cais o dan eu gofod enw eisoes wedi'i “wario”.
Y ffordd gywir allan o'r sefyllfa hon yw edrych ar y defnydd gwirioneddol o adnoddau a'i gymharu â'r swm y gofynnwyd amdano (Cais).
Yn y sgrinluniau uchod gallwch weld bod CPUs "Gofynnwyd" yn cyfateb i'r nifer go iawn o edafedd, a gall Terfynau fod yn fwy na'r nifer go iawn o edafedd CPU =)
Nawr, gadewch i ni edrych ar rai gofod enwau yn fanwl (dewisais enw gofod kube-system - gofod enw'r system ar gyfer cydrannau'r “Cube” ei hun) a gweld cymhareb amser a chof prosesydd a ddefnyddir mewn gwirionedd i'r un y gofynnwyd amdani:
Mae'n amlwg bod llawer mwy o gof a CPU wedi'u cadw ar gyfer gwasanaethau system nag a ddefnyddir mewn gwirionedd. Yn achos y system kube, mae hyn wedi'i gyfiawnhau: digwyddodd bod rheolwr mynediad nginx neu nodelocaldns ar eu hanterth wedi cyrraedd y CPU ac yn bwyta llawer o RAM, felly mae cyfiawnhad dros gronfa wrth gefn o'r fath. Yn ogystal, ni allwn ddibynnu ar siartiau am y 3 awr ddiwethaf: mae'n ddymunol gweld metrigau hanesyddol dros gyfnod mawr o amser.
Datblygwyd system o “argymhellion”. Er enghraifft, yma gallwch weld pa adnoddau fyddai'n well eu byd i godi'r “terfynau” (y bar uchaf a ganiateir) fel nad yw “gwthio” yn digwydd: yr eiliad pan fydd adnodd eisoes wedi treulio CPU neu gof yn y sleis amser penodedig a yn aros nes y bydd yn “heb ei rewi”:
A dyma'r codennau a ddylai ffrwyno eu harchwaeth:
Про throtling + monitro adnoddau, gallwch ysgrifennu mwy nag un erthygl, felly gofynnwch gwestiynau yn y sylwadau. Mewn ychydig eiriau, gallaf ddweud bod y dasg o awtomeiddio metrigau o'r fath yn anodd iawn ac yn gofyn am lawer o amser a chydbwyso gweithredu gyda swyddogaethau "ffenestr" a "CTE" Prometheus / VictoriaMetrics (mae'r termau hyn mewn dyfyniadau, gan fod bron dim byd fel hyn yn PromQL, ac mae'n rhaid i chi rannu ymholiadau brawychus yn sawl sgrin o destun a'u optimeiddio).
O ganlyniad, mae gan ddatblygwyr offer ar gyfer monitro eu gofodau enwau yn Ciwb, a gallant ddewis drostynt eu hunain ble ac ar ba amser pa gymwysiadau y gall eu hadnoddau eu “torri,” a pha weinyddion y gellir rhoi'r CPU cyfan iddynt trwy'r nos.
Methodolegau
Yn y cwmni fel y mae yn awr ffasiynol, glynwn wrth DevOps- a ARhPh-ymarferydd Pan fydd gan gwmni 1000 o ficrowasanaethau, tua 350 o ddatblygwyr a 15 gweinyddwr ar gyfer y seilwaith cyfan, mae'n rhaid i chi "fod yn ffasiynol": y tu ôl i'r holl “geiriau sylfaen” hyn mae angen dybryd i awtomeiddio popeth a phawb, ac ni ddylai gweinyddwyr fod yn dagfa. mewn prosesau.
Fel Ops, rydym yn darparu amrywiol fetrigau a dangosfyrddau ar gyfer datblygwyr sy'n ymwneud â chyfraddau ymateb gwasanaeth a gwallau.
Rydym yn defnyddio methodolegau fel: , и trwy eu cyfuno gyda'i gilydd. Rydym yn ceisio lleihau nifer y dangosfyrddau fel ei bod yn amlwg ar unwaith pa wasanaeth sy'n diraddiol ar hyn o bryd (er enghraifft, codau ymateb yr eiliad, amser ymateb gan 99ain canradd), ac ati. Cyn gynted ag y bydd angen rhai metrigau newydd ar gyfer dangosfyrddau cyffredinol, rydym yn tynnu llun ac yn eu hychwanegu ar unwaith.
Dydw i ddim wedi llunio graffiau ers mis. Mae'n debyg bod hyn yn arwydd da: mae'n golygu bod y rhan fwyaf o'r “eisiau” eisoes wedi'u gwireddu. Digwyddodd y byddwn yn llunio graff newydd o leiaf unwaith y dydd yn ystod yr wythnos.
Mae'r canlyniad canlyniadol yn werthfawr oherwydd nawr anaml y mae datblygwyr yn mynd at weinyddwyr gyda chwestiynau “ble i edrych ar ryw fath o fetrig.”
Gweithredu Rhwyll Gwasanaeth dim ond rownd y gornel a dylai wneud bywyd yn llawer haws i bawb, mae cydweithwyr o Tools eisoes yn agos at weithredu'r haniaethol “Istio person iach”: bydd cylch bywyd pob cais HTTP(s) yn weladwy wrth fonitro, ac mae'n Bydd bob amser yn bosibl deall “ar ba gam y torrodd popeth” yn ystod rhyngweithio rhwng gwasanaethau (ac nid yn unig). Tanysgrifiwch i newyddion o ganolbwynt DomClick. =)
Cymorth seilwaith Kubernetes
Yn hanesyddol, rydym yn defnyddio'r fersiwn glytiog Ciwbspray — Rôl addas ar gyfer lleoli, ymestyn a diweddaru Kubernetes. Ar ryw adeg, torrwyd cefnogaeth ar gyfer gosodiadau di-kubeadm o'r brif gangen, ac ni chynigiwyd y broses o newid i kubeadm. O ganlyniad, gwnaeth cwmni Southbridge ei fforch ei hun (gyda chefnogaeth kubeadm ac ateb cyflym ar gyfer problemau critigol).
Mae'r broses ar gyfer diweddaru pob clwstwr k8s yn edrych fel hyn:
- Cymerwch Ciwbspray o Southbridge, gwiriwch gyda'n edefyn, Merjim.
- Rydym yn cyflwyno'r diweddariad i Straen- “Cube”.
- Rydyn ni'n cyflwyno'r diweddariad un nod ar y tro (yn Ansible dyma “gyfres: 1”) i mewn Dyfais- “Cube”.
- Rydym yn diweddaru Prod ar nos Sadwrn un nod ar y tro.
Mae cynlluniau i'w disodli yn y dyfodol Ciwbspray am rywbeth cyflymach ac ewch i kubeadm.
Mae gennym ni dri “Cubes” i gyd: Straen, Dev a Prod. Rydym yn bwriadu lansio un arall (wrth gefn poeth) Prod-“Cube” yn yr ail ganolfan ddata. Straen и Dyfais byw mewn “peiriannau rhithwir” (oVirt for Stress a VMWare cloud for Dev). Prod- Mae “Cube” yn byw ar “fetel noeth”: mae'r rhain yn nodau union yr un fath gyda 32 edafedd CPU, 64-128 GB o gof a 300 GB SSD RAID 10 - mae yna 50 ohonyn nhw i gyd. Mae tri nod “tenau” wedi'u cysegru i “feistri” Prod- “Cuba”: 16 GB o gof, 12 edafedd CPU.
Ar gyfer gwerthu, mae'n well gennym ddefnyddio "metel noeth" ac osgoi haenau diangen fel OpenStack: nid oes angen “cymdogion swnllyd” a CPU arnom dwyn amser. Ac mae cymhlethdod gweinyddu yn dyblu fwy neu lai yn achos OpenStack mewnol.
Ar gyfer “Cubic” CI/CD a chydrannau seilwaith eraill rydym yn defnyddio gweinydd GIT ar wahân, Helm 3 (roedd yn drawsnewidiad poenus braidd o Helm 2, ond rydym yn hapus iawn gyda'r opsiynau atomig), Jenkins, Ansible a Docker. Rydyn ni'n caru canghennau nodwedd a'u lleoli i wahanol amgylcheddau o un gadwrfa.
Casgliad
Dyma, yn gyffredinol, sut olwg sydd ar broses DevOps yn DomClick o safbwynt peiriannydd gweithrediadau. Trodd yr erthygl yn llai technegol nag yr oeddwn yn ei ddisgwyl: felly, dilynwch y newyddion DomClick ar Habré: bydd mwy o erthyglau “craidd caled” am Kubernetes a mwy.
Ffynhonnell: hab.com