Kubernetes në DomClick: si të flini në mënyrë paqësore duke menaxhuar një grup prej 1000 mikroshërbimesh

Emri im është Viktor Yagofarov dhe po zhvilloj platformën Kubernetes në DomClick si menaxher i zhvillimit teknik në ekipin e Ops (operacionit). Do të doja të flisja për strukturën e proceseve tona Dev <-> Ops, veçoritë e funksionimit të një prej grupimeve më të mëdha k8s në Rusi, si dhe praktikat DevOps/SRE që zbaton ekipi ynë.

Команда Ops

В команде Ops на данный момент работает 15 человек. Трое из них отвечают за офис, двое работают в другом часовом поясе и доступны, в том числе, и ночью. Таким образом, всегда кто-то из Ops находится у монитора и готов среагировать на инцидент любой сложности. Ночных дежурств у нас нет, что сохраняет нашу психику и даёт возможность всем высыпаться и проводить досуг не только за компьютером.

Të gjithë kanë kompetenca të ndryshme: rrjetëzues, DBA, specialistë të stakut ELK, administratorë/zhvillues të Kubernetes, monitorim, virtualizim, specialistë harduerësh, etj. Një gjë i bashkon të gjithë - të gjithë mund të zëvendësojnë cilindo prej nesh në një farë mase: për shembull, futni nyje të reja në grupin k8s, përditësoni PostgreSQL, shkruani një tubacion CI/CD + Ansible, automatizoni diçka në Python/Bash/Go, lidhni harduerin me Qendra e të dhënave. Kompetencat e forta në asnjë fushë nuk ju pengojnë të ndryshoni drejtimin e aktivitetit dhe të filloni të përmirësoheni në ndonjë fushë tjetër. Për shembull, unë iu bashkua një kompanie si specialist PostgreSQL dhe tani fusha ime kryesore e përgjegjësisë janë grupimet Kubernetes. Në ekip, çdo lartësi është e mirëpritur dhe ndjenja e levës është shumë e zhvilluar.

Nga rruga, ne jemi duke gjuajtur. Kërkesat për kandidatët janë mjaft standarde. Për mua personalisht është e rëndësishme që një person të përshtatet në ekip, të mos jetë konfliktual, por edhe të dijë të mbrojë këndvështrimin e tij, dëshiron të zhvillohet dhe të mos ketë frikë të bëjë diçka të re, të ofrojë idetë e tij. Gjithashtu, kërkohen aftësi programimi në gjuhët e skriptimit, njohuri të bazave të Linux-it dhe anglishtes. Anglishtja është e nevojshme thjesht në mënyrë që një person në rast të një fakap të mund të gjejë në google zgjidhjen e problemit në 10 sekonda, dhe jo në 10 minuta. Tani është shumë e vështirë të gjesh specialistë me njohuri të thella të Linux: është qesharake, por dy nga tre kandidatë nuk mund t'i përgjigjen pyetjes "Çfarë është Load Average? Nga çfarë përbëhet?”, dhe pyetja “Si të montoni një deponi thelbësore nga një program C” konsiderohet diçka nga bota e supermenëve... apo dinosaurëve. Ne duhet ta durojmë këtë, pasi zakonisht njerëzit kanë kompetenca të tjera shumë të zhvilluara, por ne do të mësojmë Linux. Përgjigja e pyetjes "pse një inxhinier DevOps duhet t'i dijë të gjitha këto në botën moderne të reve" do të duhet të lihet jashtë objektit të artikullit, por me tre fjalë: e gjithë kjo është e nevojshme.

Mjetet e ekipit

Ekipi i Mjeteve luan një rol të rëndësishëm në automatizimin. Detyra e tyre kryesore është të krijojnë mjete të përshtatshme grafike dhe CLI për zhvilluesit. Për shembull, Confer e zhvillimit tonë të brendshëm ju lejon të hapni fjalë për fjalë një aplikacion në Kubernetes me vetëm disa klikime të miut, të konfiguroni burimet e tij, çelësat nga kasaforta, etj. Më parë, ishte Jenkins + Helm 2, por më duhej të zhvilloja mjetin tim për të eliminuar copy-paste dhe për të sjellë uniformitet në ciklin e jetës së softuerit.

Команда Ops не пишет пайплайны за разработчиков, но может проконсультировать по любым вопросам в их написании (у кое-кого еще остался Helm 3).

DevOps

Sa për DevOps, ne e shohim kështu:

Ekipet e zhvilluesit shkruajnë kodin, e shpërndajnë atë përmes Confer to dev -> qa/stage -> prod. Përgjegjësia për të siguruar që kodi të mos ngadalësohet dhe të mos përmbajë gabime i takon ekipeve Dev dhe Ops. Gjatë ditës, personi në detyrë nga ekipi Ops duhet para së gjithash t'i përgjigjet një incidenti me aplikacionin e tij, dhe në mbrëmje dhe natën, administratori në detyrë (Ops) duhet të zgjojë zhvilluesin në detyrë nëse ai e di për i sigurt se problemi nuk është në infrastrukturë. Të gjitha metrikat dhe sinjalizimet në monitorim shfaqen automatikisht ose gjysmë automatikisht.

Fusha e përgjegjësisë së Ops fillon që nga momenti kur aplikacioni del në prodhim, por përgjegjësia e Dev nuk përfundon këtu - ne bëjmë të njëjtën gjë dhe jemi në të njëjtën varkë.

Разработчики консультируют админов, если нужна помощь в написании админского микросервиса (например, Go backend + HTML5), а админы консультируют разработчиков по любым инфраструктурным вопросам, или вопросам, связанным с k8s.

Nga rruga, ne nuk kemi një monolit fare, vetëm mikroshërbime. Numri i tyre deri tani luhatet midis 900 dhe 1000 në grupin prod k8s, nëse matet me numër vendosjet. Numri i bishtajave luhatet midis 1700 dhe 2000. Aktualisht ka rreth 2000 bishtaja në grupin e prodeve.

Nuk mund të jap numra të saktë, pasi ne monitorojmë mikroshërbimet e panevojshme dhe i ndërpresim ato në mënyrë gjysmë automatike. K8s na ndihmon të mbajmë gjurmët e entiteteve të panevojshme i padobishëm-operator, e cila kursen shumë burime dhe para.

Manaxhimi i burimeve

Monitorimi

Краеугольным камнем в эксплуатации большого кластера становится грамотно выстроенный и информативный мониторинг. Мы пока не нашли универсального решения, которое покрыло бы 100 % всех «хотелок» по мониторингу, поэтому периодически клепаем разные кастомные решения в этой среде.

• Zabbix. Monitorimi i mirë i vjetër, i cili synon kryesisht të gjurmojë gjendjen e përgjithshme të infrastrukturës. Ai na tregon kur një nyje vdes për sa i përket përpunimit, kujtesës, disqeve, rrjetit etj. Asgjë e mbinatyrshme, por ne kemi gjithashtu një grup të veçantë agjentësh Daemon, me ndihmën e të cilit, për shembull, monitorojmë gjendjen e DNS në grup: ne kërkojmë pods budallaqe coredns, kontrollojmë disponueshmërinë e hosteve të jashtëm. Duket se pse të shqetësoheni me këtë, por me vëllime të mëdha trafiku ky komponent është një pikë serioze dështimi. Unë tashmë përshkruar, si kam luftuar me performancën DNS në një grup.
• Operatori Prometheus. Një grup eksportuesish të ndryshëm jep një pasqyrë të gjerë të të gjithë komponentëve të grupit. Më pas, ne i vizualizojmë të gjitha këto në panele të mëdha në Grafana dhe përdorim alertmanager për sinjalizime.

Еще одним полезным инструментом для нас стал list-ingress. E kemi shkruar pasi disa herë kemi hasur në një situatë ku një ekip ka mbivendosur shtigjet e hyrjes së një ekipi tjetër, duke rezultuar në 50 herë gabime. Tani përpara se të vendoset në prodhim, zhvilluesit kontrollojnë që askush të mos preket dhe për ekipin tim ky është një mjet i mirë për diagnozën fillestare të problemeve me Ingresses. Është qesharake që në fillim ishte shkruar për administratorët dhe dukej mjaft "i ngathët", por pasi ekipet e zhvilluesve ranë në dashuri me mjetin, ai ndryshoi shumë dhe filloi të mos dukej si "një administrator bëri një faqe interneti për administratorët. ” Së shpejti ne do ta braktisim këtë mjet dhe situata të tilla do të vërtetohen edhe para se të hapet tubacioni.

Burimet e ekipit në Kub

Para se të hyjmë në shembujt, ia vlen të shpjegohet se si i shpërndajmë burimet mikroshërbime.

Për të kuptuar se cilat ekipe dhe në çfarë sasie i përdorin ato burimet (procesori, memoria, SSD lokale), ne caktojmë secilën komandë të vetën namespace në "Cube" dhe kufizoni aftësitë e tij maksimale për sa i përket procesorit, memories dhe diskut, duke diskutuar më parë nevojat e ekipeve. Prandaj, një komandë, në përgjithësi, nuk do të bllokojë të gjithë grupin për vendosje, duke ndarë mijëra bërthama dhe terabajt memorie. Qasja në hapësirën e emrave jepet përmes AD (ne përdorim RBAC). Hapësirat e emrave dhe kufijtë e tyre shtohen nëpërmjet një kërkese tërheqëse në depon e GIT, dhe më pas gjithçka shpërndahet automatikisht përmes tubacionit Ansible.

Një shembull i shpërndarjes së burimeve për një ekip:

namespaces:

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

Kërkesat dhe kufizimet

në kubik" Kërkesa është numri i burimeve të rezervuara të garantuara për mbulesë (një ose më shumë kontejnerë docker) në një grup. Kufiri është një maksimum i pagarantuar. Shpesh mund të shihni në grafikët se si një ekip i ka vendosur vetes shumë kërkesa për të gjitha aplikacionet e tij dhe nuk mund ta vendosë aplikacionin në "Cube", pasi të gjitha kërkesat nën hapësirën e tyre të emrave tashmë janë "shpenzuar".

Mënyra e duhur për të dalë nga kjo situatë është të shikoni konsumin aktual të burimit dhe ta krahasoni atë me shumën e kërkuar (Kërkesë).

Në pamjet e mësipërme mund të shihni se CPU-të "të kërkuara" përputhen me numrin real të thread-eve dhe Limitet mund të tejkalojnë numrin real të thread-ve të CPU =)

Tani le të shohim në detaje hapësirën e emrave (kam zgjedhur kube-sistemin e hapësirës së emrave - hapësirën e emrave të sistemit për komponentët e vetë "Cube") dhe të shohim raportin e kohës dhe memorjes së procesorit të përdorur në të vërtetë me atë të kërkuar:

Është e qartë se shumë më tepër memorie dhe CPU rezervohet për shërbimet e sistemit sesa përdoret në të vërtetë. Në rastin e sistemit kube, kjo është e justifikuar: ndodhi që kontrolluesi i hyrjes nginx ose nodelocaldns në kulmin e tyre goditën CPU-në dhe konsumuan shumë RAM, kështu që këtu një rezervë e tillë justifikohet. Për më tepër, nuk mund të mbështetemi në grafikët për 3 orët e fundit: është e dëshirueshme të shohim metrikë historike për një periudhë të madhe kohore.

U zhvillua një sistem "rekomandimesh". Për shembull, këtu mund të shihni se cilat burime do të ishte më mirë të rrisni "kufijtë" (shiritin e sipërm të lejuar) në mënyrë që "mbytja" të mos ndodhë: momenti kur burimi ka shpenzuar tashmë CPU ose memorie për pjesën e caktuar kohore. dhe po pret derisa të "zhbrohet":

А вот поды, которым следовало бы умерить аппетиты:

në mbytëse + monitorimi i burimeve, mund të shkruani më shumë se një artikull, kështu që bëni pyetje në komente. Me pak fjalë, mund të them se detyra e automatizimit të matjeve të tilla është shumë e vështirë dhe kërkon shumë kohë dhe veprim balancues me funksionet "dritare" dhe "CTE" Prometheus / VictoriaMetrics (këto terma janë në thonjëza, pasi ka pothuajse asgjë si kjo në PromQL, dhe ju duhet t'i ndani pyetjet e frikshme në disa ekrane teksti dhe t'i optimizoni ato).

Si rezultat, zhvilluesit kanë mjete për të monitoruar hapësirat e tyre të emrave në Cube, dhe ata janë në gjendje të zgjedhin vetë se ku dhe në çfarë ore se cilat aplikacione mund t'i "prehen" burimet e tyre dhe cilët serverë mund t'i jepet i gjithë CPU-së gjatë gjithë natës.

Metodologjitë

Në kompani siç është tani fashionably, ne i përmbahemi DevOps- dhe SRE-praktikues Kur një kompani ka 1000 mikroshërbime, rreth 350 zhvillues dhe 15 administratorë për të gjithë infrastrukturën, duhet të jesh "modë": pas gjithë këtyre "thënieve" ekziston një nevojë urgjente për të automatizuar gjithçka dhe të gjithë, dhe administratorët nuk duhet të jenë një pengesë. në procese.

Si Ops, ne ofrojmë metrika dhe panele të ndryshme për zhvilluesit në lidhje me normat e përgjigjes së shërbimit dhe gabimet.

Ne përdorim metodologji të tilla si: KUQ, PËRDORIMI и Golden Signalsduke i kombinuar së bashku. Ne përpiqemi të minimizojmë numrin e paneleve, në mënyrë që me një shikim të jetë e qartë se cili shërbim po degradon aktualisht (për shembull, kodet e përgjigjes për sekondë, koha e përgjigjes me përqindjen e 99-të), e kështu me radhë. Sapo disa metrika të reja bëhen të nevojshme për panelet e përgjithshme, ne i vizatojmë dhe i shtojmë menjëherë.

Unë nuk kam vizatuar grafikë për një muaj. Kjo është ndoshta një shenjë e mirë: do të thotë se shumica e "dëshirave" tashmë janë realizuar. Ndodhte që gjatë javës të vizatoja ndonjë grafik të ri të paktën një herë në ditë.

Rezultati që rezulton është i vlefshëm sepse tani zhvilluesit shumë rrallë shkojnë te administratorët me pyetje "ku të shikojmë një lloj metrike".

futja e Rrjetë e shërbimit është afër qoshes dhe duhet ta bëjë jetën shumë më të lehtë për të gjithë, kolegët nga Tools janë tashmë afër zbatimit të abstraktit "Istio e një personi të shëndetshëm": cikli i jetës së çdo kërkese HTTP(s) do të jetë i dukshëm në monitorim, dhe ai do të jetë gjithmonë e mundur të kuptohet "në çfarë faze u prish gjithçka" gjatë ndërveprimit ndër-shërbues (dhe jo vetëm). Abonohu ​​në lajmet nga qendra DomClick. =)

Mbështetje për infrastrukturën Kubernetes

Исторически сложилось так, что мы используем патченную версию Kubespray — Rol i mundshëm për vendosjen, zgjerimin dhe përditësimin e Kubernetes. Në një moment, mbështetja për instalimet jo-kubeadm u ndërpre nga dega kryesore dhe procesi i kalimit në kubeadm nuk u propozua. Si rezultat, kompania Southbridge bëri pirunin e saj (me mbështetje kubeadm dhe një rregullim të shpejtë për problemet kritike).

Procesi për përditësimin e të gjitha grupimeve k8s duket si ky:

• marr Kubespray nga Southbridge, kontrollo me fillin tonë, Merjim.
• Ne po nxjerrim përditësimin në Stres- "Kub".
• Выкатываем обновление по одной ноде (в Ansible это «serial: 1») в Dev- "Kub".
• Ne përditësojmë stimuloj të shtunën në mbrëmje një nyje në një kohë.

В будущем есть планы заменить Kubespray на что-нибудь более быстрое и перейти на kubeadm.

Në total kemi tre "Kuba": Stresi, Dev dhe Prod. Ne po planifikojmë të lançojmë një tjetër (gatishmëri e nxehtë) Prod-“Cube” në qendrën e dytë të të dhënave. Stres и Dev jetoni në "makinat virtuale" (oVirt për stresin dhe cloud VMWare për Dev). stimuloj- "Cube" jeton në "metal të zhveshur": këto janë nyje identike me 32 fije CPU, 64-128 GB memorie dhe 300 GB SSD RAID 10 - gjithsej janë 50 prej tyre. Tre nyje "të holla" u dedikohen "mjeshtrave" stimuloj-«Куба»: 16 Гб памяти, 12 CPU threads.

Për shitje, ne preferojmë të përdorim "metal të zhveshur" dhe të shmangim shtresat e panevojshme si OpenStack: nuk kemi nevojë për "fqinjë të zhurmshëm" dhe CPU vjedhin kohë. Dhe kompleksiteti i administrimit afërsisht dyfishohet në rastin e OpenStack të brendshëm.

Për CI/CD "Cubic" dhe komponentë të tjerë të infrastrukturës ne përdorim një server të veçantë GIT, Helm 3 (ishte një tranzicion mjaft i dhimbshëm nga Helm 2, por ne jemi shumë të kënaqur me opsionet atomik), Jenkins, Ansible dhe Docker. Ne i duam degët e veçorive dhe vendosjen në mjedise të ndryshme nga një depo.

Përfundim

Kjo është, në terma të përgjithshëm, si duket procesi DevOps në DomClick nga këndvështrimi i një inxhinieri operacionesh. Artikulli doli të ishte më pak teknik nga sa prisja: prandaj, ndiqni lajmet e DomClick në Habré: do të ketë më shumë artikuj "hardcore" rreth Kubernetes dhe më shumë.

Burimi: www.habr.com