Jina langu ni Viktor Yagofarov, na ninatengeneza jukwaa la Kubernetes katika DomClick kama meneja wa maendeleo ya kiufundi katika timu ya Ops (operesheni). Ningependa kuzungumzia muundo wa michakato yetu ya Dev <-> Ops, vipengele vya kuendesha mojawapo ya makundi makubwa zaidi ya k8s nchini Urusi, pamoja na mbinu za DevOps/SRE ambazo timu yetu inatumika.
Timu ya Ops
Timu ya Ops kwa sasa ina watu 15. Watatu kati yao wanajibika kwa ofisi, wawili wanafanya kazi katika eneo tofauti la wakati na wanapatikana, ikiwa ni pamoja na usiku. Kwa hivyo, mtu kutoka Ops yuko kwenye mfuatiliaji kila wakati na yuko tayari kujibu tukio la utata wowote. Hatuna mabadiliko ya usiku, ambayo huhifadhi psyche yetu na huwapa kila mtu fursa ya kupata usingizi wa kutosha na kutumia muda wa burudani si tu kwenye kompyuta.
Kila mtu ana uwezo tofauti: wanamtandao, DBA, wataalamu wa rafu wa ELK, wasimamizi/wasanidi wa Kubernetes, ufuatiliaji, uboreshaji, wataalamu wa maunzi, n.k. Jambo moja linaunganisha kila mtu - kila mtu anaweza kuchukua nafasi ya yeyote kati yetu kwa kiwango fulani: kwa mfano, anzisha nodi mpya kwenye nguzo ya k8s, sasisha PostgreSQL, andika bomba la CI/CD + Ansible, badilisha kitu kwenye Python/Bash/Go, unganisha vifaa kwa Kituo cha data. Uwezo mkubwa katika eneo lolote haukuzuii kubadilisha mwelekeo wako wa shughuli na kuanza kuboresha katika eneo lingine. Kwa mfano, nilijiunga na kampuni kama mtaalamu wa PostgreSQL, na sasa eneo langu kuu la uwajibikaji ni nguzo za Kubernetes. Katika timu, urefu wowote unakaribishwa na hisia ya kujiinua inakuzwa sana.
Kwa njia, tunawinda. Mahitaji ya wagombea ni ya kawaida kabisa. Kwa mimi binafsi, ni muhimu kwamba mtu anafaa katika timu, sio mgongano, lakini pia anajua jinsi ya kutetea maoni yake, anataka kuendeleza na haogopi kufanya kitu kipya, hutoa mawazo yake. Pia, ujuzi wa programu katika lugha za scripting, ujuzi wa misingi ya Linux na Kiingereza inahitajika. Kiingereza kinahitajika kwa urahisi ili mtu katika tukio la fakap aweze kutumia google suluhisho la shida kwa sekunde 10, na sio kwa dakika 10. Sasa ni vigumu sana kupata wataalamu wenye ujuzi wa kina wa Linux: inachekesha, lakini watahiniwa wawili kati ya watatu hawawezi kujibu swali "Wastani wa Mzigo ni nini? Inafanywa na nini?", Na swali "Jinsi ya kukusanya taka ya msingi kutoka kwa programu ya C" inachukuliwa kuwa kitu kutoka kwa ulimwengu wa supermen ... au dinosaurs. Tunapaswa kuvumilia hili, kwa kuwa kwa kawaida watu wana ujuzi mwingine wenye maendeleo, lakini tutafundisha Linux. Jibu la swali "kwa nini mhandisi wa DevOps anahitaji kujua haya yote katika ulimwengu wa kisasa wa mawingu" italazimika kuachwa nje ya wigo wa kifungu, lakini kwa maneno matatu: yote haya ni muhimu.
Vyombo vya Timu
Timu ya Zana ina jukumu muhimu katika uwekaji otomatiki. Kazi yao kuu ni kuunda zana rahisi za picha na CLI kwa watengenezaji. Kwa mfano, Confer yetu ya usanidi wa ndani hukuruhusu kusambaza programu kwa Kubernetes kwa mibofyo michache tu ya kipanya, kusanidi rasilimali zake, vitufe kutoka kwa vault, n.k. Hapo awali, kulikuwa na Jenkins + Helm 2, lakini ilibidi nitengeneze zana yangu mwenyewe ili kuondoa kunakili-kubandika na kuleta usawa kwa mzunguko wa maisha wa programu.
Timu ya Ops haiandiki mabomba kwa wasanidi programu, lakini inaweza kushauri kuhusu masuala yoyote katika uandishi wao (baadhi ya watu bado wana Helm 3).
DevOps
Kuhusu DevOps, tunaiona kama hii:
Timu za wasanidi programu huandika msimbo, kuisambaza kupitia Confer to dev -> qa/stage -> prod. Wajibu wa kuhakikisha kuwa msimbo haupunguzi kasi na hauna hitilafu ni wa timu za Dev na Ops. Wakati wa mchana, mtu aliye zamu kutoka kwa timu ya Ops anapaswa kwanza kujibu tukio na maombi yake, na jioni na usiku, msimamizi wa zamu (Ops) anapaswa kumwamsha msanidi wa zamu ikiwa anajua. uhakika kwamba tatizo si katika miundombinu. Vipimo na arifa zote katika ufuatiliaji huonekana kiotomatiki au nusu kiotomatiki.
Eneo la uwajibikaji la Ops huanza tangu wakati maombi yanapotolewa katika uzalishaji, lakini jukumu la Dev haliishii hapo - tunafanya jambo lile lile na tuko kwenye mashua moja.
Wasanidi programu huwashauri wasimamizi ikiwa wanahitaji usaidizi wa kuandika huduma ndogo ya msimamizi (kwa mfano, Go backend + HTML5), na wasimamizi huwashauri wasanidi programu kuhusu masuala yoyote ya miundombinu au masuala yanayohusiana na k8s.
Kwa njia, hatuna monolith kabisa, tu microservices. Idadi yao kufikia sasa inabadilika kati ya 900 na 1000 katika nguzo ya prod k8s, ikiwa inapimwa kwa nambari. kupelekwa. Idadi ya maganda hubadilika-badilika kati ya 1700 na 2000. Kwa sasa kuna takriban maganda 2000 kwenye nguzo ya uzalishaji.
Siwezi kutoa nambari kamili, kwani tunafuatilia huduma ndogo zisizohitajika na kuzikata nusu moja kwa moja. K8s hutusaidia kufuatilia huluki zisizo za lazima , ambayo huokoa rasilimali nyingi na pesa.
Usimamizi wa rasilimali
Ufuatiliaji
Ufuatiliaji ulioandaliwa vyema na wenye taarifa unakuwa msingi katika uendeshaji wa nguzo kubwa. Bado hatujapata suluhisho la jumla ambalo lingetosheleza 100% ya mahitaji yote ya ufuatiliaji, kwa hivyo mara kwa mara tunaunda masuluhisho tofauti tofauti katika mazingira haya.
- Zabbix. Ufuatiliaji mzuri wa zamani, ambao unakusudiwa kimsingi kufuatilia hali ya jumla ya miundombinu. Inatuambia wakati nodi inapokufa kwa suala la usindikaji, kumbukumbu, disks, mtandao, na kadhalika. Hakuna kitu kisicho cha kawaida, lakini pia tuna DaemonSet tofauti ya mawakala, kwa msaada ambao, kwa mfano, tunafuatilia hali ya DNS kwenye nguzo: tunatafuta maganda ya coredns ya kijinga, tunaangalia upatikanaji wa majeshi ya nje. Inaweza kuonekana kuwa kwa nini unajisumbua na hii, lakini kwa idadi kubwa ya trafiki sehemu hii ni hatua kubwa ya kutofaulu. Mimi tayari , jinsi nilivyotatizika na utendaji wa DNS kwenye nguzo.
- Prometheus Opereta. Seti ya wasafirishaji tofauti inatoa muhtasari mkubwa wa vipengele vyote vya nguzo. Kisha, tunaona haya yote kwenye dashibodi kubwa huko Grafana, na kutumia alertmanager kwa arifa.
Chombo kingine chenye manufaa kwetu kilikuwa . Tuliandika baada ya mara kadhaa kukumbana na hali ambapo timu moja ilipishana njia za Ingress za timu nyingine, na kusababisha makosa 50x. Sasa kabla ya kupeleka kwa uzalishaji, watengenezaji huangalia kuwa hakuna mtu atakayeathiriwa, na kwa timu yangu hii ni chombo kizuri cha utambuzi wa awali wa matatizo na Ingresses. Inafurahisha kwamba mwanzoni iliandikwa kwa ajili ya wasimamizi na ilionekana kama "shida", lakini baada ya timu za wasanidi kupenda zana hiyo, ilibadilika sana na ikaanza kuonekana sio kama "msimamizi alitengeneza uso wa wavuti kwa wasimamizi. β Hivi karibuni tutaacha chombo hiki na hali kama hizo zitathibitishwa hata kabla ya bomba kusambaza.
Rasilimali za timu katika Mchemraba
Kabla ya kuingia katika mifano, inafaa kuelezea jinsi tunavyogawa rasilimali huduma ndogo ndogo.
Ili kuelewa ni timu zipi na kwa idadi gani hutumia yao rasilimali (processor, kumbukumbu, SSD ya ndani), tunatenga kila amri yake mwenyewe nafasi ya jina katika "Cube" na kupunguza uwezo wake wa juu katika suala la processor, kumbukumbu na disk, baada ya kujadiliwa hapo awali mahitaji ya timu. Ipasavyo, amri moja, kwa ujumla, haitazuia nguzo nzima kwa ajili ya kupelekwa, ikitenga maelfu ya cores na terabytes ya kumbukumbu. Ufikiaji wa nafasi ya majina unatolewa kupitia AD (tunatumia RBAC). Nafasi za majina na mipaka yao huongezwa kupitia ombi la kuvuta kwenye hazina ya GIT, na kisha kila kitu kinatolewa kiotomatiki kupitia bomba la Ansible.
Mfano wa kugawa rasilimali kwa timu:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Maombi na mipaka
Cubed" Kuomba ni idadi ya rasilimali zilizohifadhiwa zilizohakikishwa sufuria (chombo kimoja au zaidi cha docker) kwenye nguzo. Kikomo ni kiwango cha juu ambacho hakijathibitishwa. Mara nyingi unaweza kuona kwenye grafu jinsi baadhi ya timu imejiwekea maombi mengi sana kwa programu zake zote na haiwezi kupeleka programu kwenye "Cube", kwa kuwa maombi yote chini ya nafasi yao ya majina tayari "yametumika".
Njia sahihi ya kutoka kwa hali hii ni kuangalia matumizi halisi ya rasilimali na kulinganisha na kiasi kilichoombwa (Ombi).
Katika picha za skrini hapo juu unaweza kuona kwamba CPU "Zilizoombwa" zinalinganishwa na idadi halisi ya nyuzi, na Mipaka inaweza kuzidi idadi halisi ya nyuzi za CPU =)
Sasa hebu tuangalie nafasi fulani ya majina kwa undani (nilichagua nafasi ya majina kube-system - nafasi ya jina ya mfumo kwa vipengele vya "Cube" yenyewe) na tuone uwiano wa muda wa kichakataji uliotumika na kumbukumbu kwa ile iliyoombwa:
Ni dhahiri kwamba kumbukumbu nyingi zaidi na CPU zimehifadhiwa kwa huduma za mfumo kuliko inavyotumika. Kwa upande wa mfumo wa kube, hii inahesabiwa haki: ilitokea kwamba kidhibiti cha ingress cha nginx au nodelocaldns kwenye kilele chao kiligonga CPU na kutumia RAM nyingi, kwa hivyo hifadhi kama hiyo inahesabiwa haki. Kwa kuongeza, hatuwezi kutegemea chati kwa saa 3 zilizopita: ni vyema kuona vipimo vya kihistoria kwa muda mrefu.
Mfumo wa "mapendekezo" ulitengenezwa. Kwa mfano, hapa unaweza kuona ni rasilimali zipi zingekuwa bora zaidi kuinua "mipaka" (bar ya juu inayoruhusiwa) ili "kutetemeka" kusitokee: wakati ambapo rasilimali tayari imetumia CPU au kumbukumbu kwenye kipande cha wakati kilichowekwa na. inangojea hadi "itakuwa haijagandishwa":
Na hapa kuna maganda ambayo yanapaswa kupunguza hamu yao:
juu ya kuteleza + ufuatiliaji wa rasilimali, unaweza kuandika zaidi ya nakala moja, kwa hivyo uliza maswali kwenye maoni. Kwa maneno machache, naweza kusema kwamba kazi ya kusanidi metriki kama hizo ni ngumu sana na inahitaji muda mwingi na kusawazisha kitendo na kazi za "dirisha" na "CTE" Prometheus / VictoriaMetrics (maneno haya yako katika nukuu, kwani kuna karibu hakuna kitu kama hiki kwenye PromQL, na lazima ugawanye maswali ya kutisha katika skrini kadhaa za maandishi na kuyaboresha).
Kwa hivyo, watengenezaji wana zana za kufuatilia nafasi zao za majina katika Cube, na wanaweza kuchagua wenyewe wapi na kwa wakati gani ni programu gani zinaweza "kukatwa" rasilimali zao, na seva gani zinaweza kupewa CPU nzima usiku kucha.
Mbinu
Katika kampuni kama ilivyo sasa mtindo, tunafuata DevOps- na SRE-fanya kazi Wakati kampuni ina huduma ndogo 1000, watengenezaji wapatao 350 na wasimamizi 15 kwa miundombinu yote, lazima uwe "mtindo": nyuma ya "baswords" hizi zote kuna hitaji la haraka la kubinafsisha kila kitu na kila mtu, na wasimamizi hawapaswi kuwa kizuizi. katika michakato.
Kama Ops, tunatoa vipimo na dashibodi mbalimbali kwa wasanidi programu zinazohusiana na viwango vya majibu ya huduma na hitilafu.
Tunatumia mbinu kama vile: , ΠΈ kwa kuziunganisha pamoja. Tunajaribu kupunguza idadi ya dashibodi ili kwa mtazamo tu iwe wazi ni huduma gani inashusha hadhi kwa sasa (kwa mfano, misimbo ya majibu kwa sekunde, muda wa majibu kwa asilimia 99), na kadhalika. Mara tu baadhi ya vipimo vipya vinapokuwa muhimu kwa dashibodi za jumla, tunachora na kuziongeza mara moja.
Sijachora grafu kwa mwezi mmoja. Labda hii ni ishara nzuri: inamaanisha kuwa "matakwa" mengi tayari yamepatikana. Ilifanyika kwamba wakati wa juma ningechora grafu mpya angalau mara moja kwa siku.
Matokeo yake ni muhimu kwa sababu sasa wasanidi programu ni nadra sana kwenda kwa wasimamizi wakiwa na maswali "mahali pa kuangalia aina fulani ya vipimo."
Utekelezaji Mesh ya Huduma iko karibu na inapaswa kurahisisha maisha kwa kila mtu, wafanyakazi wenzako kutoka Zana tayari wako karibu kutekeleza dhahania ya "Istio ya mtu mwenye afya": mzunguko wa maisha wa kila ombi la HTTP(za) utaonekana katika ufuatiliaji, na itawezekana kila wakati kuelewa "katika hatua gani kila kitu kilivunjika" wakati wa mwingiliano wa huduma (na sio tu). Jiandikishe kwa habari kutoka kwa kitovu cha DomClick. =)
Msaada wa miundombinu ya Kubernetes
Kihistoria, tunatumia toleo lililotiwa viraka Kubespray - Jukumu linalofaa la kupeleka, kupanua na kusasisha Kubernetes. Wakati fulani, usaidizi wa mitambo isiyo ya kubeadm ulikatwa kutoka kwa tawi kuu, na mchakato wa kubadili kubeadm haukupendekezwa. Kama matokeo, kampuni ya Southbridge ilitengeneza uma yake (kwa usaidizi wa kubeadm na utatuzi wa haraka wa shida muhimu).
Mchakato wa kusasisha nguzo zote za k8s inaonekana kama hii:
- Chukua Kubespray kutoka Southbridge, angalia na uzi wetu, Merjim.
- Tunasambaza sasisho kwa Stress- "Mchemraba".
- Tunatoa sasisho nodi moja kwa wakati mmoja (katika Ansible hii ni "serial: 1") ndani Dev- "Mchemraba".
- Tunasasisha Prod Jumamosi jioni nodi moja baada ya nyingine.
Kuna mipango ya kuibadilisha katika siku zijazo Kubespray kwa kitu haraka na kwenda kubeadm.
Kwa jumla tuna "Cubes" tatu: Stress, Dev na Prod. Tunapanga kuzindua nyingine (kusubiri moto) Prod-βCubeβ katika kituo cha pili cha data. Stress ΠΈ Dev kuishi katika "mashine pepe" (oVirt kwa Stress na VMWare wingu kwa Dev). Prod- "Cube" inaishi kwenye "chuma tupu": hizi ni nodi zinazofanana na nyuzi 32 za CPU, kumbukumbu ya 64-128 GB na 300 GB SSD RAID 10 - kuna 50 kati yao kwa jumla. Nodi tatu "nyembamba" zimetolewa kwa "mabwana" Prod- "Cuba": 16 GB ya kumbukumbu, nyuzi 12 za CPU.
Kwa mauzo, tunapendelea kutumia "chuma tupu" na epuka tabaka zisizo za lazima kama OpenStack: hatuhitaji "majirani wenye kelele" na CPU kuiba wakati. Na utata wa utawala takriban mara mbili katika kesi ya OpenStack ya ndani.
Kwa CI/CD "Cubic" na vifaa vingine vya miundombinu tunatumia seva tofauti ya GIT, Helm 3 (ilikuwa mabadiliko ya uchungu kutoka kwa Helm 2, lakini tunafurahiya sana chaguzi. atomiki), Jenkins, Ansible na Docker. Tunapenda matawi ya vipengele na kupelekwa kwa mazingira tofauti kutoka hazina moja.
Hitimisho
Hii ni, kwa maneno ya jumla, jinsi mchakato wa DevOps unavyoonekana katika DomClick kutoka kwa mtazamo wa mhandisi wa shughuli. Makala hayakuwa ya kiufundi kuliko nilivyotarajia: kwa hivyo, fuata habari za DomClick kuhusu HabrΓ©: kutakuwa na makala "hardcore" zaidi kuhusu Kubernetes na zaidi.
Chanzo: mapenzi.com