Myn namme is Viktor Yagofarov, en ik ûntwikkelje it Kubernetes-platfoarm by DomClick as in technyske ûntwikkelingsmanager yn it Ops (operaasje) team. Ik wol graach prate oer de struktuer fan ús Dev <-> Ops-prosessen, de funksjes fan it operearjen fan ien fan 'e grutste k8s-klusters yn Ruslân, lykas de DevOps / SRE-praktiken dy't ús team tapast.
Ops Team
It Ops-team hat op it stuit 15 minsken. Trije fan harren binne ferantwurdlik foar it kantoar, twa wurkje yn in oare tiidsône en binne beskikber, ek nachts. Sa is ien fan Ops altyd by de monitor en ree om te reagearjen op in ynsidint fan elke kompleksiteit. Wy hawwe gjin nachttsjinsten, dy't ús psyche behâldt en elkenien de kâns jout om genôch sliep te krijen en frije tiid net allinich by de kompjûter troch te bringen.
Elkenien hat ferskillende kompetinsjes: netwurkers, DBA's, ELK stack spesjalisten, Kubernetes admins / ûntwikkelders, monitoring, virtualisaasje, hardware spesjalisten, ensfh. Ien ding ferienet elkenien - elkenien kin ien fan ús yn guon mjitte ferfange: bygelyks nije knopen yntrodusearje yn it k8s-kluster, PostgreSQL bywurkje, in CI/CD + Ansible pipeline skriuwe, wat automatisearje yn Python/Bash/Go, hardware ferbine mei Datasintrum. Sterke kompetinsjes yn elk gebiet net foarkomme dat jo jo rjochting fan aktiviteit feroarje en begjinne te ferbetterjen op in oar gebiet. Bygelyks, ik kaam by in bedriuw as in PostgreSQL-spesjalist, en no is myn haadgebiet fan ferantwurdlikens Kubernetes-klusters. Yn it team is elke hichte wolkom en it gefoel fan leverage is tige ûntwikkele.
Trouwens, wy binne op jacht. Easken foar kandidaten binne frij standert. Foar my persoanlik is it wichtich dat in persoan yn it team past, net konflikt is, mar ek syn stânpunt wit te ferdigenjen, him ûntwikkelje wol en net bang is om wat nijs te dwaan, syn ideeën oanbiedt. Ek binne programmearfeardigens yn skripttalen, kennis fan 'e basis fan Linux en Ingelsk fereaske. Ingelsk is gewoan nedich sadat in persoan yn it gefal fan in fakap in oplossing foar it probleem yn 10 sekonden kin googleje, en net yn 10 minuten. It is no heul lestich om spesjalisten te finen mei djippe kennis fan Linux: it is grappich, mar twa fan 'e trije kandidaten kinne de fraach "Wat is Load Average" net beantwurdzje? Wat is it makke fan?", En de fraach "Hoe kinne jo in kearndump út in C-programma gearstalle" wurdt beskôge as wat út 'e wrâld fan supermen ... as dinosaurussen. Wy moatte dit opstelle, om't normaal minsken oare kompetinsjes heech ûntwikkele hawwe, mar wy sille Linux leare. It antwurd op de fraach "wêrom moat in DevOps-yngenieur dit alles witte yn 'e moderne wrâld fan wolken" sil bûten it berik fan it artikel moatte wurde litten, mar yn trije wurden: dit alles is nedich.
Team Tools
It Tools-team spilet in wichtige rol yn automatisearring. Har haadtaak is it meitsjen fan handige grafyske en CLI-ark foar ûntwikkelders. Bygelyks, mei ús ynterne ûntwikkeling Confer kinne jo letterlik in applikaasje nei Kubernetes útrolje mei mar in pear mûsklikken, har boarnen konfigurearje, kaaien fan kluis, ensfh. Earder wie d'r Jenkins + Helm 2, mar ik moast myn eigen ark ûntwikkelje om copy-paste te eliminearjen en uniformiteit te bringen oan 'e softwarelibbenssyklus.
It Ops-team skriuwt gjin pipelines foar ûntwikkelders, mar kin advisearje oer alle problemen yn har skriuwen (guon minsken hawwe noch Helm 3).
DevOps
Wat DevOps oangiet, sjogge wy it sa:
Dev-teams skriuwe koade, rôlje it út fia Confer nei dev -> qa/stage -> prod. Ferantwurdlikens foar it garandearjen dat de koade net fertraget en gjin flaters befettet leit by de Dev- en Ops-teams. Oerdei moat de tsjinstferliener fan it Ops-team earst mei syn oanfraach op in ynsidint reagearje, en jûns en nachts moat de tsjinstbehearder (Ops) de tsjinstûntwikkelder wekker meitsje as hy it wit wis dat it probleem net yn 'e ynfrastruktuer is. Alle metriken en warskôgings yn tafersjoch ferskine automatysk as semi-automatysk.
Ops's ferantwurdlikensgebiet begjint fan it momint dat de applikaasje yn produksje wurdt útrôle, mar Dev's ferantwurdlikens einiget dêr net - wy dogge itselde ding en binne yn deselde boat.
Untwikkelders advisearje admins as se help nedich hawwe by it skriuwen fan in admin-mikrotsjinst (bygelyks Go backend + HTML5), en admins advisearje ûntwikkelders oer alle ynfrastruktuerproblemen of problemen yn ferbân mei k8s.
Trouwens, wy hawwe hielendal gjin monolith, allinich mikrotsjinsten. Harren oantal fluktuearret oant no ta tusken 900 en 1000 yn it prod k8s-kluster, as mjitten troch nûmer ynset. It tal podden skommelet tusken de 1700 en 2000. Der sitte op it stuit sa'n 2000 podden yn it prodkluster.
Ik kin gjin krekte sifers jaan, om't wy unnedige mikrotsjinsten kontrolearje en se semi-automatysk útknipe. K8s helpt ús te hâlden spoar fan ûnnedige entiteiten , dy't in protte middels en jild besparret.
Resource behear
Monitoring
Goed strukturearre en ynformative tafersjoch wurdt de hoekstien yn de eksploitaasje fan in grut kluster. Wy hawwe noch gjin universele oplossing fûn dy't 100% fan alle tafersjochferlet soe dekke, dus meitsje wy periodyk ferskate oanpaste oplossingen yn dizze omjouwing.
- Zabbix. Goede âlde monitoring, dy't foaral bedoeld is om de algemiene tastân fan de ynfrastruktuer te folgjen. It fertelt ús wannear't in knooppunt stjert yn termen fan ferwurking, ûnthâld, skiven, netwurk, ensfh. Neat boppenatuerlik, mar wy hawwe ek in aparte DaemonSet fan aginten, mei help wêrfan wy bygelyks de steat fan DNS yn it kluster kontrolearje: wy sykje nei domme coredns pods, wy kontrolearje de beskikberens fan eksterne hosts. It soe lykje dat wêrom lestich falle mei dit, mar mei grutte folumes fan ferkear dizze komponint is in serieus punt fan mislearring. Ik al , Hoe't ik stride mei DNS-prestaasjes yn in kluster.
- Prometheus Operator. In set fan ferskate eksporteurs jout in grut oersjoch fan alle komponinten fan it kluster. Dêrnei fisualisearje wy dit alles op grutte dashboards yn Grafana, en brûke alertmanager foar warskôgings.
In oar nuttich ark foar ús wie . Wy skreaunen it neidat wy ferskate kearen in situaasje tsjinkamen dêr't ien team de Ingress-paden fan in oar team oerlape, wat resultearre yn 50x flaters. No foardat se ynset wurde nei produksje, kontrolearje ûntwikkelders dat gjinien sil wurde beynfloede, en foar myn team is dit in goed ark foar de earste diagnoaze fan problemen mei Ingresses. It is grappich dat it earst skreaun waard foar admins en it seach nochal "onhandig", mar nei't de dev-teams fereale waarden op it ark, feroare it in protte en begon net te lykjen as "in admin makke in webgesicht foar admins. ” Meikoarten sille wy dit ark ferlitte en sokke situaasjes sille wurde validearre noch foardat de pipeline wurdt útrôle.
Team boarnen yn de kubus
Foardat wy yn 'e foarbylden komme, is it de muoite wurdich út te lizzen hoe't wy boarnen tawize foar mikrotsjinsten.
Om te begripen hokker teams en yn hokker hoemannichten har brûke boarnen (prosessor, ûnthâld, lokale SSD), wy jouwe elk kommando syn eigen nammeromte yn de "Cube" en beheine syn maksimale mooglikheden yn termen fan prosessor, ûnthâld en skiif, nei't earder besprutsen de behoeften fan de teams. Dêrtroch sil ien kommando, yn 't algemien, it heule kluster net blokkearje foar ynset, en tûzenen kearnen en terabytes oan ûnthâld tawize. Tagong ta nammeromte wurdt ferliend fia AD (wy brûke RBAC). Namespaces en harren grinzen wurde tafoege fia in pull fersyk oan de GIT repository, en dan alles wurdt automatysk rôle út troch de Ansible pipeline.
In foarbyld fan it tawizen fan middels oan in team:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Fersiken en grinzen
Cubed" Fersyk is it oantal garandearre reservearre middels foar pod (ien of mear docker containers) yn in kluster. Limyt is in net-garandearre maksimum. Jo kinne faaks op 'e grafiken sjen hoe't guon teams harsels tefolle oanfragen ynsteld hawwe foar al har applikaasjes en de applikaasje net kinne ynsette nei de "Cube", om't alle oanfragen ûnder har nammeromte al "bestege" binne.
De juste manier út dizze situaasje is om te sjen nei it eigentlike boarneferbrûk en te fergelykjen mei it frege bedrach (Request).
Yn 'e skermôfbyldings hjirboppe kinne jo sjen dat "Ferfrege" CPU's oerienkomme mei it echte oantal threads, en Limits kinne it echte oantal CPU-threads oerskriuwe =)
Litte wy no wat nammeromte yn detail besjen (ik keas nammeromte kube-systeem - de systeemnammeromte foar de komponinten fan 'e "Cube" sels) en sjoch de ferhâlding fan feitlik brûkte prosessortiid en ûnthâld nei de frege:
It is fanselssprekkend dat folle mear ûnthâld en CPU is reservearre foar systeemtsjinsten as dat eins brûkt wurdt. Yn it gefal fan it kube-systeem is dit terjochte: it barde dat nginx-yngongskontrôler of nodelocaldns op har hichtepunt de CPU sloegen en in protte RAM konsumeare, dus hjir is sa'n reserve terjochte. Derneist kinne wy de lêste 3 oeren net fertrouwe op charts: it is winsklik om histoaryske metriken oer in grutte perioade te sjen.
In systeem fan "oanbefellings" waard ûntwikkele. Hjir kinne jo bygelyks sjen hokker boarnen it better wêze kinne om de "grinzen" (de boppeste tastiene balke) te ferheegjen sadat "throttling" net foarkomt: it momint dat in boarne al CPU of ûnthâld hat bestege yn 'e tawiisde tiidslice en wachtet oant it "ûnbeferzen" wurdt:
En hjir binne de peulen dy't har appetit moatte beheine:
op throttling + boarnemonitoring, jo kinne mear dan ien artikel skriuwe, dus stel fragen yn 'e opmerkings. Yn in pear wurden kin ik sizze dat de taak fan it automatisearjen fan sokke metriken heul lestich is en in protte tiid en balânsjen fereasket mei "finster" funksjes en "CTE" Prometheus / VictoriaMetrics (dizze termen binne yn oanhalingstekens, om't der hast neat as dit yn PromQL, en jo moatte enge query's ferdielen yn ferskate skermen fan tekst en optimalisearje se).
As gefolch hawwe ûntwikkelders ark foar it kontrolearjen fan har nammeromten yn Cube, en se binne by steat om sels te kiezen wêr en op hokker tiid hokker applikaasjes har boarnen "besnije kinne", en hokker servers de hiele CPU de hiele nacht krije kinne.
Methodologyen
Yn it bedriuw sa't it no is moade, wy hâlde oan DevOps- en SRE-praktyk As in bedriuw 1000 mikrotsjinsten hat, sawat 350 ûntwikkelders en 15 admins foar de hiele ynfrastruktuer, dan moatte jo "modieuze" wêze: efter al dizze "baswords" is d'r in driuwende needsaak om alles en elkenien te automatisearjen, en admins moatte gjin knelpunt wêze yn prosessen.
As Ops leverje wy ferskate metriken en dashboards foar ûntwikkelders yn ferbân mei tsjinstreaksjesifers en flaters.
Wy brûke metoaden lykas: , и troch se tegearre te kombinearjen. Wy besykje it oantal dashboards te minimalisearjen sadat yn ien eachopslach dúdlik is hokker tsjinst op it stuit degradearret (bygelyks antwurdkoades per sekonde, antwurdtiid troch 99e percentile), ensfh. Sadree't guon nije metriken nedich wurde foar algemiene dashboards, tekenje en foegje wy se fuortendaliks ta.
Ik haw al in moanne gjin grafiken tekene. Dit is wierskynlik in goed teken: it betsjut dat de measte "wollen" al realisearre binne. It barde dat ik yn 'e wike op syn minst ien kear deis in nije grafyk tekenje soe.
It resultearjende resultaat is weardefol, om't ûntwikkelders no frij komselden nei admins geane mei fragen "wêr te sjen nei in soarte fan metrik."
Útfiering Service Mesh is krekt om 'e hoeke en moat it libben folle makliker meitsje foar elkenien, kollega's fan Tools binne al tichtby de ymplemintaasje fan' e abstrakte "Istio fan in sûn persoan": de libbenssyklus fan elke HTTP(s)-oanfraach sil sichtber wêze yn monitoring, en it sil altyd mooglik wêze om te begripen "yn hokker stadium alles bruts" tidens ynter-tsjinst (en net allinich) ynteraksje. Abonnearje op nijs fan 'e DomClick-hub. =)
Kubernetes ynfrastruktuer stipe
Histoarysk brûke wy de patched ferzje Kubespray - Ansible rol foar it ynsetten, útwreidzjen en bywurkjen fan Kubernetes. Op in stuit waard stipe foar net-kubeadm-ynstallaasjes ôfsnien fan 'e haadtûke, en it proses fan wikseljen nei kubeadm waard net foarsteld. As gefolch makke it bedriuw Southbridge har eigen gabel (mei kubeadm-stipe en in flugge oplossing foar krityske problemen).
It proses foar it bywurkjen fan alle k8s-klusters sjocht der sa út:
- Nim Kubespray út Southbridge, kontrolearje mei ús tried, Merjim.
- Wy rôlje de fernijing út nei Klam- "Kube".
- Wy rôlje de fernijing ien knooppunt op in tiid út (yn Ansible is dit "searje: 1") yn dev- "Kube".
- Wy fernije Prod op sneontejûn ien knooppunt tagelyk.
Der binne plannen om it yn 'e takomst te ferfangen Kubespray foar wat flugger en gean nei kubeadm.
Yn totaal hawwe wy trije "kubussen": Stress, Dev en Prod. Wy binne fan plan om noch ien te lansearjen (hot standby) Prod-"Cube" yn it twadde datasintrum. Klam и dev libje yn "firtuele masines" (oVirt foar Stress en VMWare wolk foar Dev). Prod- "Cube" libbet op "keale metaal": dit binne identike knopen mei 32 CPU-threads, 64-128 GB ûnthâld en 300 GB SSD RAID 10 - d'r binne 50 fan har yn totaal. Trije "tinne" knopen binne wijd oan "masters" Prod- "Kuba": 16 GB ûnthâld, 12 CPU-threads.
Foar ferkeap brûke wy leaver "keale metaal" en foarkomme ûnnedige lagen lykas OpenStack: wy hawwe gjin "lawaaiige buorlju" en CPU nedich stelle tiid. En de kompleksiteit fan administraasje ferdûbelet sawat yn it gefal fan eigen OpenStack.
Foar CI / CD "Cubic" en oare ynfrastruktuerkomponinten brûke wy in aparte GIT-tsjinner, Helm 3 (it wie in nochal pynlike oergong fan Helm 2, mar wy binne tige bliid mei de opsjes atoom), Jenkins, Ansible en Docker. Wy hâlde fan funksje-tûken en ynset nei ferskate omjouwings fan ien repository.
konklúzje
Dit is, yn algemiene termen, hoe't it DevOps-proses derút sjocht by DomClick út it perspektyf fan in operaasje-yngenieur. It artikel blykte minder technysk te wêzen as ik ferwachte: folgje dêrom it DomClick-nijs op Habré: d'r sille mear "hardcore" artikels oer Kubernetes en mear wêze.
Boarne: www.habr.com