Ang pangalan ko ay Viktor Yagofarov, at binubuo ko ang Kubernetes platform sa DomClick bilang isang technical development manager sa Ops (operation) team. Gusto kong pag-usapan ang tungkol sa istruktura ng aming mga proseso ng Dev <-> Ops, ang mga feature ng pagpapatakbo ng isa sa pinakamalaking k8s cluster sa Russia, pati na rin ang mga kasanayan sa DevOps/SRE na inilalapat ng aming team.
Ops Team
Ang koponan ng Ops ay kasalukuyang mayroong 15 katao. Tatlo sa kanila ang may pananagutan sa opisina, dalawa ang nagtatrabaho sa magkaibang time zone at available, kasama na sa gabi. Kaya, ang isang tao mula sa Ops ay palaging nasa monitor at handang tumugon sa isang insidente ng anumang kumplikado. Wala kaming mga night shift, na nagpapanatili sa aming pag-iisip at nagbibigay sa lahat ng pagkakataon na makakuha ng sapat na tulog at gumugol ng oras sa paglilibang hindi lamang sa computer.
Ang bawat isa ay may iba't ibang kakayahan: mga networker, DBA, ELK stack specialist, Kubernetes admin/developer, monitoring, virtualization, hardware specialist, atbp. Isang bagay ang nagkakaisa sa lahat - lahat ay maaaring palitan ang sinuman sa atin sa ilang lawak: halimbawa, ipakilala ang mga bagong node sa k8s cluster, i-update ang PostgreSQL, magsulat ng CI/CD + Ansible pipeline, i-automate ang isang bagay sa Python/Bash/Go, ikonekta ang hardware sa Data center. Ang malakas na kakayahan sa anumang lugar ay hindi pumipigil sa iyo na baguhin ang iyong direksyon ng aktibidad at magsimulang umunlad sa ibang lugar. Halimbawa, sumali ako sa isang kumpanya bilang isang PostgreSQL specialist, at ngayon ang pangunahing lugar ng responsibilidad ko ay ang mga Kubernetes cluster. Sa koponan, ang anumang taas ay malugod na tinatanggap at ang pakiramdam ng pagkilos ay lubos na binuo.
Siyanga pala, nangangaso kami. Ang mga kinakailangan para sa mga kandidato ay medyo pamantayan. Para sa akin personal, mahalaga na ang isang tao ay umaangkop sa koponan, ay hindi salungatan, ngunit alam din kung paano ipagtanggol ang kanyang pananaw, gustong umunlad at hindi natatakot na gumawa ng bago, nag-aalok ng kanyang mga ideya. Gayundin, ang mga kasanayan sa programming sa mga wika ng script, ang kaalaman sa mga pangunahing kaalaman ng Linux at Ingles ay kinakailangan. Ang Ingles ay kailangan lamang upang ang isang tao sa kaganapan ng isang fakap ay makapag-google ng solusyon sa problema sa loob ng 10 segundo, at hindi sa loob ng 10 minuto. Napakahirap na ngayon na makahanap ng mga espesyalista na may malalim na kaalaman sa Linux: nakakatuwa ito, ngunit dalawa sa tatlong kandidato ay hindi makasagot sa tanong na βAno ang Load Average? Ano ang gawa nito?", at ang tanong na "Paano mag-assemble ng core dump mula sa isang C program" ay itinuturing na isang bagay mula sa mundo ng mga superhuman... o mga dinosaur. Kailangan nating tiisin ito, dahil kadalasan ang mga tao ay may mataas na pag-unlad ng iba pang mga kakayahan, ngunit ituturo namin ang Linux. Ang sagot sa tanong na "bakit kailangang malaman ng isang DevOps engineer ang lahat ng ito sa modernong mundo ng mga ulap" ay kailangang iwanan sa labas ng saklaw ng artikulo, ngunit sa tatlong salita: lahat ng ito ay kinakailangan.
Mga Tool ng Koponan
Ang koponan ng Tools ay gumaganap ng isang mahalagang papel sa automation. Ang kanilang pangunahing gawain ay lumikha ng maginhawang graphical at CLI na mga tool para sa mga developer. Halimbawa, binibigyang-daan ka ng aming internal development Confer na literal na ilunsad ang isang application sa Kubernetes sa ilang pag-click lang ng mouse, i-configure ang mga mapagkukunan nito, mga key mula sa vault, atbp. Dati, mayroong Jenkins + Helm 2, ngunit kailangan kong bumuo ng sarili kong tool upang maalis ang copy-paste at magdala ng pagkakapareho sa lifecycle ng software.
Ang Ops team ay hindi nagsusulat ng mga pipeline para sa mga developer, ngunit maaaring magpayo sa anumang mga isyu sa kanilang pagsulat (ang ilang mga tao ay mayroon pa ring Helm 3).
DevOps
Tulad ng para sa DevOps, nakikita natin itong ganito:
Sumulat ng code ang mga dev team, i-roll out ito sa pamamagitan ng Confer to dev -> qa/stage -> prod. Ang responsibilidad para sa pagtiyak na ang code ay hindi bumagal at hindi naglalaman ng mga error ay nasa mga Dev at Ops team. Sa araw, ang taong naka-duty mula sa Ops team ay dapat unang tumugon sa isang insidente kasama ang kanyang aplikasyon, at sa gabi at sa gabi, dapat gisingin ng administrator on duty (Ops) ang developer na naka-duty kung alam niya para sigurado na ang problema ay wala sa imprastraktura. Lahat ng sukatan at alerto sa pagsubaybay ay awtomatikong o semi-awtomatikong lumalabas.
Ang lugar ng responsibilidad ng Ops ay nagsisimula mula sa sandaling ang application ay inilunsad sa produksyon, ngunit ang responsibilidad ni Dev ay hindi nagtatapos doon - ginagawa namin ang parehong bagay at nasa parehong bangka.
Pinapayuhan ng mga developer ang mga admin kung kailangan nila ng tulong sa pagsusulat ng admin microservice (halimbawa, Go backend + HTML5), at pinapayuhan ng mga admin ang mga developer sa anumang isyu sa imprastraktura o isyung nauugnay sa k8s.
Siyanga pala, wala kaming monolith, mga microservice lang. Ang kanilang bilang sa ngayon ay nagbabago sa pagitan ng 900 at 1000 sa prod k8s cluster, kung sinusukat ng numero mga pag-deploy. Ang bilang ng mga pod ay nagbabago sa pagitan ng 1700 at 2000. Sa kasalukuyan ay may humigit-kumulang 2000 na mga pod sa prod cluster.
Hindi ako makapagbigay ng eksaktong mga numero, dahil sinusubaybayan namin ang mga hindi kinakailangang microservice at semi-awtomatikong pinuputol ang mga ito. Tinutulungan kami ng K8s na subaybayan ang mga hindi kinakailangang entity , na nakakatipid ng maraming mapagkukunan at pera.
Pamamahala ng mapagkukunan
Pagsubaybay
Ang mahusay na istruktura at nagbibigay-kaalaman na pagsubaybay ay nagiging pundasyon sa pagpapatakbo ng isang malaking kumpol. Hindi pa kami nakakahanap ng unibersal na solusyon na sasakupin ang 100% ng lahat ng pangangailangan sa pagsubaybay, kaya pana-panahon kaming gumagawa ng iba't ibang custom na solusyon sa kapaligirang ito.
- Zabbix. Magandang lumang pagsubaybay, na pangunahing nilayon upang subaybayan ang pangkalahatang kondisyon ng imprastraktura. Sinasabi nito sa amin kapag ang isang node ay namatay sa mga tuntunin ng pagproseso, memorya, mga disk, network, at iba pa. Walang supernatural, ngunit mayroon din kaming hiwalay na DaemonSet ng mga ahente, sa tulong kung saan, halimbawa, sinusubaybayan namin ang estado ng DNS sa cluster: naghahanap kami ng mga bobo na coredns pod, sinusuri namin ang pagkakaroon ng mga panlabas na host. Mukhang bakit ito mag-abala, ngunit sa malaking dami ng trapiko ang bahaging ito ay isang seryosong punto ng pagkabigo. Dati ako na , kung paano ako nahirapan sa pagganap ng DNS sa isang kumpol.
- Operator ng Prometheus. Ang isang hanay ng iba't ibang mga exporter ay nagbibigay ng isang malaking pangkalahatang-ideya ng lahat ng mga bahagi ng cluster. Susunod, nakikita namin ang lahat ng ito sa malalaking dashboard sa Grafana, at gumagamit ng alertmanager para sa mga alerto.
Ang isa pang kapaki-pakinabang na tool para sa amin ay . Isinulat namin ito pagkatapos ng ilang beses na nakatagpo kami ng sitwasyon kung saan nag-overlap ang isang team sa mga path ng Ingress ng isa pang team, na nagresulta sa 50x na mga error. Ngayon bago i-deploy sa produksyon, tinitingnan ng mga developer na walang maaapektuhan, at para sa aking koponan ito ay isang mahusay na tool para sa paunang pagsusuri ng mga problema sa Ingresses. Nakakatuwa na noong una ay isinulat ito para sa mga admin at mukhang βclumsyβ ito, ngunit pagkatapos na mahalin ng mga dev team ang tool, malaki ang pinagbago nito at nagsimulang magmukhang hindi βisang admin ang gumawa ng web face para sa mga admin. β Sa lalong madaling panahon ay aabandonahin namin ang tool na ito at ang mga ganitong sitwasyon ay mapapatunayan bago pa man ilunsad ang pipeline.
Mga mapagkukunan ng koponan sa Cube
Bago tayo pumasok sa mga halimbawa, sulit na ipaliwanag kung paano tayo naglalaan ng mga mapagkukunan mga microservice.
Upang maunawaan kung aling mga koponan at sa kung anong dami ang gumagamit ng mga ito mapagkukunan (processor, memory, lokal na SSD), inilalaan namin ang bawat utos ng sarili nitong namespace sa "Cube" at limitahan ang pinakamataas na kakayahan nito sa mga tuntunin ng processor, memorya at disk, na tinalakay dati ang mga pangangailangan ng mga koponan. Alinsunod dito, ang isang utos, sa pangkalahatan, ay hindi haharang sa buong kumpol para sa pag-deploy, na naglalaan ng libu-libong mga core at terabytes ng memorya. Ang access sa namespace ay ibinibigay sa pamamagitan ng AD (ginagamit namin ang RBAC). Ang mga namespace at ang kanilang mga limitasyon ay idinaragdag sa pamamagitan ng isang pull request sa GIT repository, at pagkatapos ay awtomatikong ilalabas ang lahat sa pamamagitan ng Ansible pipeline.
Isang halimbawa ng paglalaan ng mga mapagkukunan sa isang koponan:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Mga kahilingan at limitasyon
Cubed" Hiling ay ang bilang ng mga garantisadong nakalaan na mapagkukunan para sa balat (isa o higit pang mga docker container) sa isang cluster. Ang limitasyon ay hindi garantisadong maximum. Madalas mong makikita sa mga graph kung paano itinakda ng ilang koponan ang sarili nitong napakaraming kahilingan para sa lahat ng mga application nito at hindi maaaring i-deploy ang application sa "Cube", dahil ang lahat ng kahilingan sa ilalim ng kanilang namespace ay "ginastos na".
Ang tamang paraan sa labas ng sitwasyong ito ay tingnan ang aktwal na pagkonsumo ng mapagkukunan at ihambing ito sa hiniling na halaga (Kahilingan).
Sa mga screenshot sa itaas makikita mo na ang "Hinihiling" na mga CPU ay itinugma sa tunay na bilang ng mga thread, at ang mga Limitasyon ay maaaring lumampas sa tunay na bilang ng mga CPU thread =)
Ngayon tingnan natin ang ilang namespace nang detalyado (pinili ko ang namespace kube-system - ang namespace ng system para sa mga bahagi ng "Cube" mismo) at tingnan ang ratio ng aktwal na ginamit na oras ng processor at memorya sa hiniling:
Malinaw na mas maraming memorya at CPU ang nakalaan para sa mga serbisyo ng system kaysa sa aktwal na ginagamit. Sa kaso ng kube-system, ito ay makatwiran: nangyari na ang nginx ingress controller o nodelocaldns sa kanilang peak ay tumama sa CPU at kumonsumo ng maraming RAM, kaya narito ang gayong reserba ay nabigyang-katwiran. Bilang karagdagan, hindi kami maaaring umasa sa mga chart sa huling 3 oras: ito ay kanais-nais na makita ang mga makasaysayang sukatan sa loob ng mahabang panahon.
Isang sistema ng "mga rekomendasyon" ang binuo. Halimbawa, dito makikita mo kung aling mga mapagkukunan ang mas mahusay na itaas ang "mga limitasyon" (ang pinahihintulutang bar sa itaas) upang hindi mangyari ang "throttling": ang sandali na ang isang mapagkukunan ay gumastos na ng CPU o memorya sa inilaang oras ng slice at ay naghihintay hanggang sa ito ay "i-unfrozen":
At narito ang mga pods na dapat hadlangan ang kanilang mga gana:
Tungkol sa throttling + pagsubaybay sa mapagkukunan, maaari kang magsulat ng higit sa isang artikulo, kaya magtanong sa mga komento. Sa ilang salita, masasabi ko na ang gawain ng pag-automate ng mga naturang sukatan ay napakahirap at nangangailangan ng maraming oras at pagbabalanse ng pagkilos sa mga function ng "window" at "CTE" Prometheus / VictoriaMetrics (ang mga terminong ito ay nasa mga panipi, dahil halos mayroong walang ganito sa PromQL, at kailangan mong hatiin ang mga nakakatakot na query sa ilang screen ng text at i-optimize ang mga ito).
Bilang resulta, ang mga developer ay may mga tool para sa pagsubaybay sa kanilang mga namespace sa Cube, at nagagawa nilang pumili para sa kanilang sarili kung saan at sa anong oras kung aling mga application ang maaaring magkaroon ng kanilang mga mapagkukunan na "maputol," at kung aling mga server ang maaaring ibigay sa buong CPU sa buong magdamag.
Mga pamamaraan
Sa kumpanya gaya ngayon uso, sumunod kami sa DevOps- at SRE-practitioner Kapag ang isang kumpanya ay may 1000 microservices, humigit-kumulang 350 developer at 15 admin para sa buong imprastraktura, kailangan mong "maging sunod sa moda": sa likod ng lahat ng "basword" na ito ay may kagyat na pangangailangan na i-automate ang lahat at lahat, at ang mga admin ay hindi dapat maging bottleneck sa mga proseso.
Bilang Ops, nagbibigay kami ng iba't ibang sukatan at dashboard para sa mga developer na nauugnay sa mga rate ng pagtugon sa serbisyo at mga error.
Gumagamit kami ng mga pamamaraan tulad ng: , ΠΈ sa pamamagitan ng pagsasama-sama ng mga ito. Sinusubukan naming bawasan ang bilang ng mga dashboard upang sa isang sulyap ay malinaw kung aling serbisyo ang kasalukuyang nagpapababa (halimbawa, mga response code bawat segundo, oras ng pagtugon sa pamamagitan ng 99th percentile), at iba pa. Sa sandaling kailanganin ang ilang bagong sukatan para sa mga pangkalahatang dashboard, agad naming iguguhit at idaragdag ang mga ito.
Isang buwan na akong hindi gumuhit ng mga graph. Malamang na ito ay isang magandang senyales: nangangahulugan ito na ang karamihan sa mga "gusto" ay natanto na. Nangyari na sa loob ng linggo ay gumuhit ako ng ilang bagong graph kahit isang beses sa isang araw.
Ang resulta ay mahalaga dahil ngayon ang mga developer ay bihirang pumunta sa mga admin na may mga tanong na "kung saan titingnan ang ilang uri ng sukatan."
Pagpapatupad Serbisyo Mesh malapit na at dapat na gawing mas madali ang buhay para sa lahat, ang mga kasamahan mula sa Tools ay malapit na sa pagpapatupad ng abstract na "Istio ng isang malusog na tao": ang siklo ng buhay ng bawat (mga) HTTP na kahilingan ay makikita sa pagsubaybay, at palaging magiging posible na maunawaan "sa anong yugto nasira ang lahat" sa panahon ng inter-service (at hindi lamang) interaksyon. Mag-subscribe sa balita mula sa DomClick hub. =)
Suporta sa imprastraktura ng Kubernetes
Sa kasaysayan, ginagamit namin ang patched na bersyon Kubespray β Makatutulong na tungkulin para sa pag-deploy, pagpapalawak at pag-update ng Kubernetes. Sa ilang mga punto, ang suporta para sa mga pag-install na hindi kubeadm ay pinutol mula sa pangunahing sangay, at ang proseso ng paglipat sa kubeadm ay hindi iminungkahi. Bilang resulta, gumawa ang kumpanya ng Southbridge ng sarili nitong tinidor (na may suporta sa kubeadm at mabilis na pag-aayos para sa mga kritikal na problema).
Ang proseso para sa pag-update ng lahat ng k8s cluster ay ganito:
- Kumuha Kubespray mula sa Southbridge, suriin sa aming thread, Merjim.
- Inilalabas namin ang update sa Diin- "Kubo".
- Inilunsad namin ang update nang paisa-isa (sa Ansible ito ay "serial: 1") sa Dev- "Kubo".
- Nag-update kami Mag-udyok sa Sabado ng gabi ng isang node sa isang pagkakataon.
May mga planong palitan ito sa hinaharap Kubespray para sa isang bagay na mas mabilis at pumunta sa kubeadm.
Sa kabuuan mayroon kaming tatlong "Cube": Stress, Dev at Prod. Nagpaplano kaming maglunsad ng isa pa (mainit na standby) Prod-βCubeβ sa pangalawang data center. Diin ΠΈ Dev nakatira sa "mga virtual machine" (oVirt para sa Stress at VMWare cloud para sa Dev). Mag-udyok- Ang "Cube" ay nabubuhay sa "bare metal": ito ay magkaparehong mga node na may 32 CPU thread, 64-128 GB ng memorya at 300 GB SSD RAID 10 - mayroong 50 sa kanila sa kabuuan. Tatlong "manipis" na mga node ay nakatuon sa "mga master" Mag-udyok- "Cuba": 16 GB ng memorya, 12 CPU thread.
Para sa mga benta, mas gusto naming gumamit ng "bare metal" at iwasan ang mga hindi kinakailangang layer tulad ng OpenStack: hindi namin kailangan ng "maingay na kapitbahay" at CPU magnakaw ng oras. At ang pagiging kumplikado ng pangangasiwa ay humigit-kumulang na doble sa kaso ng in-house na OpenStack.
Para sa CI/CD "Cubic" at iba pang mga bahagi ng imprastraktura, gumagamit kami ng hiwalay na GIT server, Helm 3 (ito ay isang medyo masakit na paglipat mula sa Helm 2, ngunit kami ay napakasaya sa mga pagpipilian atomiko), Jenkins, Ansible at Docker. Gustung-gusto namin ang mga sangay ng tampok at pag-deploy sa iba't ibang mga kapaligiran mula sa isang repositoryo.
Konklusyon
Ito, sa pangkalahatan, kung ano ang hitsura ng proseso ng DevOps sa DomClick mula sa pananaw ng isang operations engineer. Ang artikulo ay naging hindi gaanong teknikal kaysa sa inaasahan ko: samakatuwid, sundin ang balita ng DomClick sa HabrΓ©: magkakaroon ng higit pang mga "hardcore" na artikulo tungkol sa Kubernetes at higit pa.
Pinagmulan: www.habr.com