Ես Վիկտոր Յագոֆարովն եմ, և ես մշակում եմ Kubernetes հարթակը DomClick-ում՝ որպես Ops (գործառնական) թիմում տեխնիկական զարգացման մենեջեր: Ես կցանկանայի խոսել մեր Dev <-> Ops գործընթացների կառուցվածքի, Ռուսաստանում ամենամեծ k8s կլաստերներից մեկի շահագործման առանձնահատկությունների, ինչպես նաև մեր թիմի կիրառած DevOps/SRE պրակտիկայի մասին:
Ops Team
Ops թիմը ներկայումս ունի 15 մարդ: Նրանցից երեքը պատասխանատու են գրասենյակի համար, երկուսն աշխատում են տարբեր ժամային գոտում և հասանելի են, այդ թվում՝ գիշերը։ Այսպիսով, Ops-ից ինչ-որ մեկը միշտ մոնիտորի մոտ է և պատրաստ է արձագանքել ցանկացած բարդության միջադեպին: Մենք չունենք գիշերային հերթափոխ, որը պահպանում է մեր հոգեկանը և բոլորին հնարավորություն է տալիս բավականաչափ քնել և ազատ ժամանակ անցկացնել ոչ միայն համակարգչի մոտ։
Յուրաքանչյուր ոք ունի տարբեր իրավասություններ՝ ցանցային աշխատողներ, DBA-ներ, ELK stack մասնագետներ, Kubernetes-ի ադմիններ/մշակողներ, մոնիտորինգ, վիրտուալիզացիա, ապարատային մասնագետներ և այլն: Մեկ բան միավորում է բոլորին՝ յուրաքանչյուրը կարող է ինչ-որ չափով փոխարինել մեզանից յուրաքանչյուրին. օրինակ՝ ներմուծել նոր հանգույցներ k8s կլաստերում, թարմացնել PostgreSQL, գրել CI/CD + Ansible խողովակաշար, ավտոմատացնել ինչ-որ բան Python/Bash/Go-ում, միացնել ապարատը։ Տվյալների կենտրոն. Որևէ ոլորտում ուժեղ կարողությունները ձեզ չեն խանգարում փոխել ձեր գործունեության ուղղությունը և սկսել կատարելագործվել որևէ այլ ոլորտում: Օրինակ, ես միացա ընկերություն որպես PostgreSQL մասնագետ, և այժմ իմ հիմնական պատասխանատվության ոլորտը Kubernetes կլաստերներն են: Թիմում ցանկացած բարձրություն ողջունելի է, իսկ լծակների զգացումը շատ զարգացած է։
Ի դեպ, մենք որս ենք անում։ Թեկնածուներին ներկայացվող պահանջները բավականին ստանդարտ են: Անձամբ ինձ համար կարևոր է, որ մարդը տեղավորվի թիմում, չկոնֆլիկտային լինի, բայց նաև իմանա ինչպես պաշտպանել իր տեսակետը, ցանկանա զարգանալ և չվախենա նոր բան անելուց և առաջարկի իր գաղափարները։ Պահանջվում է նաև ծրագրավորման հմտություններ սկրիպտային լեզուներով, Linux-ի և անգլերենի հիմունքների իմացություն: Անգլերենը պետք է ուղղակի, որպեսզի մարդը ֆակապի դեպքում խնդրի լուծումը գուգլի 10 վայրկյանում, ոչ թե 10 րոպեում։ Այժմ շատ դժվար է գտնել Linux-ի խորը իմացությամբ մասնագետներ. դա ծիծաղելի է, բայց երեք թեկնածուներից երկուսը չեն կարող պատասխանել «Ի՞նչ է միջին ծանրաբեռնվածությունը» հարցին: Ինչի՞ց է այն պատրաստված», իսկ «Ինչպես հավաքել միջուկը C ծրագրից» հարցը համարվում է սուպերմենների... կամ դինոզավրերի աշխարհից: Մենք պետք է համակերպվենք դրա հետ, քանի որ սովորաբար մարդիկ ունեն բարձր զարգացած այլ իրավասություններ, բայց մենք կսովորեցնենք Linux-ը: «Ինչու՞ DevOps-ի ինժեներին պետք է այս ամենը իմանա ժամանակակից ամպերի աշխարհում» հարցի պատասխանը պետք է դուրս մնա հոդվածի շրջանակից, բայց երեք բառով՝ այս ամենն անհրաժեշտ է:
Թիմային գործիքներ
Tools թիմը զգալի դեր է խաղում ավտոմատացման գործում: Նրանց հիմնական խնդիրն է ստեղծել հարմար գրաֆիկական և CLI գործիքներ մշակողների համար։ Օրինակ, մեր ներքին զարգացման Confer-ը թույլ է տալիս բառացիորեն մի քանի մկնիկի կտտոցով հավելվածներ տեղադրել Kubernetes-ում, կարգավորել դրա ռեսուրսները, պահոցից ստեղները և այլն: Նախկինում կար Jenkins + Helm 2, բայց ես ստիպված էի մշակել իմ սեփական գործիքը, որը վերացնում է copy-paste-ը և միատեսակություն բերում ծրագրային ապահովման կյանքի ցիկլին:
Ops-ի թիմը չի գրում ծրագրավորողների համար խողովակաշարեր, բայց կարող է խորհուրդ տալ իրենց գրավոր ցանկացած հարցի վերաբերյալ (որոշ մարդիկ դեռ ունեն Helm 3):
DevOps
Ինչ վերաբերում է DevOps-ին, մենք դա տեսնում ենք այսպես.
Մշակողների թիմերը գրում են կոդը, այն տարածում են Confer to dev -> qa/stage -> prod. Պատասխանատվությունն ապահովելու համար, որ կոդը չի դանդաղում և չի պարունակում սխալներ, պատկանում է Dev և Ops թիմերին: Ցերեկը Ops թիմի հերթապահը պետք է առաջին հերթին արձագանքի իր դիմումով միջադեպին, իսկ երեկոյան և գիշերը հերթապահ ադմինիստրատորը (Ops) պետք է արթնացնի հերթապահ ծրագրավորողին, եթե նա գիտի. վստահ եմ, որ խնդիրը ենթակառուցվածքի մեջ չէ։ Մոնիտորինգի բոլոր չափորոշիչները և ազդանշանները հայտնվում են ավտոմատ կամ կիսաավտոմատ կերպով:
Ops-ի պատասխանատվության ոլորտը սկսվում է այն պահից, երբ հավելվածը թողարկվում է արտադրության մեջ, բայց Dev-ի պատասխանատվությունը դրանով չի ավարտվում. մենք անում ենք նույն բանը և գտնվում ենք նույն նավի մեջ:
Մշակողները խորհուրդ են տալիս ադմինիստրատորներին, եթե նրանք օգնության կարիք ունեն՝ գրելու ադմինիստրատորի միկրոծառայություն (օրինակ՝ Go backend + HTML5), իսկ ադմինները խորհուրդ են տալիս ծրագրավորողներին ցանկացած ենթակառուցվածքի կամ k8s-ի հետ կապված խնդիրների վերաբերյալ:
Ի դեպ, մենք ընդհանրապես մոնոլիտ չունենք, միայն միկրոսերվիսներ են։ Նրանց թիվը մինչ այժմ տատանվում է 900-ից 1000-ի միջև prod k8s կլաստերում, եթե չափվում է թվով: տեղակայությունները. Ծածկույթների թիվը տատանվում է 1700-ից 2000-ի միջև: Ներկայումս արդյունահանվող կլաստերում կա մոտ 2000 պատիճ:
Չեմ կարող ճշգրիտ թվեր տալ, քանի որ մենք վերահսկում ենք ավելորդ միկրոծառայությունները և կիսաավտոմատ կերպով կտրում դրանք։ K8s-ն օգնում է մեզ հետևել ավելորդ սուբյեկտներին , որը խնայում է մեծ ռեսուրսներ և գումար։
Ռեսուրսների կառավարում
Մոնիտորինգ
Լավ կառուցվածքային և տեղեկատվական մոնիտորինգը դառնում է մեծ կլաստերի գործունեության հիմնաքարը: Մենք դեռ չենք գտել համընդհանուր լուծում, որը կբավարարի բոլոր մոնիտորինգի կարիքների 100%-ը, ուստի մենք պարբերաբար տարբեր մաքսային լուծումներ ենք ստեղծում այս միջավայրում:
- Zabbix- ը. Հին լավ մոնիտորինգ, որը նախատեսված է հիմնականում ենթակառուցվածքի ընդհանուր վիճակին հետևելու համար: Այն մեզ ասում է, թե երբ է հանգույցը մեռնում մշակման, հիշողության, սկավառակների, ցանցի և այլնի առումով: Ոչ մի գերբնական բան, բայց մենք ունենք նաև գործակալների առանձին DaemonSet, որի օգնությամբ, օրինակ, մենք վերահսկում ենք DNS-ի վիճակը կլաստերում. մենք փնտրում ենք հիմար coredns pods, մենք ստուգում ենք արտաքին հոսթերների առկայությունը։ Թվում է, թե ինչու անհանգստանալ սրանով, բայց մեծ երթևեկության դեպքում այս բաղադրիչը լուրջ ձախողման կետ է: Նախկինում ես արդեն , ինչպես ես պայքարում էի DNS-ի կատարման հետ կլաստերի մեջ:
- Պրոմեթևսի օպերատոր. Տարբեր արտահանողների հավաքածուն տալիս է կլաստերի բոլոր բաղադրիչների լայն ակնարկ: Հաջորդը, մենք պատկերացնում ենք այս ամենը Grafana-ի մեծ վահանակների վրա և օգտագործում ենք alertmanager-ը ահազանգերի համար:
Մեզ համար մեկ այլ օգտակար գործիք էր . Մենք այն գրեցինք այն բանից հետո, երբ մի քանի անգամ հանդիպեցինք մի իրավիճակի, երբ մի թիմը համընկավ մեկ այլ թիմի ներթափանցման ուղիների հետ, ինչը հանգեցրեց 50 անգամ սխալների: Այժմ, նախքան արտադրության մեջ տեղակայելը, մշակողները ստուգում են, որ ոչ ոք չի տուժի, և իմ թիմի համար սա լավ գործիք է Ingresses-ի հետ կապված խնդիրների նախնական ախտորոշման համար: Զավեշտալի է, որ սկզբում այն գրված էր ադմինների համար և բավականին «անշնորհք» էր թվում, բայց այն բանից հետո, երբ մշակողների թիմերը սիրահարվեցին գործիքին, այն շատ փոխվեց և սկսեց չթվալ, որ «ադմինը ադմինների համար վեբ դեմք է սարքել: » Շուտով մենք կհրաժարվենք այս գործիքից, և նման իրավիճակները կհաստատվեն նույնիսկ մինչև խողովակաշարի գործարկումը:
Թիմային ռեսուրսները Cube-ում
Նախքան օրինակների մեջ մտնելը, արժե բացատրել, թե ինչպես ենք մենք ռեսուրսներ հատկացնում միկրոծառայություններ.
Հասկանալ, թե որ թիմերը և ինչ քանակությամբ են օգտագործում իրենց ռեսուրսներ (պրոցեսոր, հիշողություն, տեղային SSD), մենք յուրաքանչյուր հրաման հատկացնում ենք իրենը անուն տարածություն «Cube»-ում և սահմանափակել դրա առավելագույն հնարավորությունները պրոցեսորի, հիշողության և սկավառակի առումով՝ նախապես քննարկելով թիմերի կարիքները: Համապատասխանաբար, մեկ հրաման, ընդհանուր առմամբ, չի արգելափակի ամբողջ կլաստերը տեղակայման համար՝ հատկացնելով հազարավոր միջուկներ և տերաբայթ հիշողություն: Անվանատարածք մուտքը տրվում է AD-ի միջոցով (մենք օգտագործում ենք RBAC): Անվանատարածքները և դրանց սահմանները ավելացվում են GIT շտեմարան ձգվող հարցման միջոցով, այնուհետև ամեն ինչ ավտոմատ կերպով դուրս է բերվում Ansible խողովակաշարով:
Թիմին ռեսուրսների բաշխման օրինակ.
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Դիմումներ և սահմանափակումներ
խորանարդիկ» Հարցում համար երաշխավորված պահուստային ռեսուրսների քանակն է պատիճ (մեկ կամ ավելի դոկեր կոնտեյներ) կլաստերի մեջ: Սահմանաչափը չերաշխավորված առավելագույնն է: Դուք հաճախ կարող եք տեսնել գծապատկերների վրա, թե ինչպես է ինչ-որ թիմ իրեն չափազանց շատ հարցումներ է սահմանել իր բոլոր հավելվածների համար և չի կարողանում հավելվածը տեղակայել «Cube»-ում, քանի որ իրենց անվանատարածքի տակ գտնվող բոլոր հարցումներն արդեն «ծախսվել են»:
Այս իրավիճակից ճիշտ ելքը ռեսուրսների իրական սպառումը նայելն ու պահանջվող գումարի հետ համեմատելն է (Request):
Վերևի սքրինշոթներում դուք կարող եք տեսնել, որ «Հայցվող» պրոցեսորները համընկնում են շղթաների իրական թվի հետ, և սահմանաչափերը կարող են գերազանցել պրոցեսորների իրական թվին =)
Հիմա եկեք մանրամասն նայենք որոշ անվանատարածքներին (ես ընտրել եմ անվանատարածք kube-system - համակարգի անվանումների տարածքը հենց «Cube»-ի բաղադրիչների համար) և տեսնել իրականում օգտագործված պրոցեսորի ժամանակի և հիշողության հարաբերակցությունը պահանջվողին.
Ակնհայտ է, որ շատ ավելի շատ հիշողություն և պրոցեսոր է պահվում համակարգային ծառայությունների համար, քան իրականում օգտագործվում է: Kube-system-ի դեպքում սա արդարացված է. պատահել է, որ nginx ingress կարգավորիչը կամ nodelocaldns-ն իրենց գագաթնակետին հարվածել են պրոցեսորին և շատ օպերատիվ հիշողություն սպառել, ուստի այստեղ նման ռեզերվը արդարացված է: Բացի այդ, մենք չենք կարող հիմնվել գծապատկերների վրա վերջին 3 ժամվա ընթացքում. ցանկալի է տեսնել պատմական ցուցանիշները մեծ ժամանակահատվածում:
Մշակվեց «առաջարկությունների» համակարգ։ Օրինակ, այստեղ դուք կարող եք տեսնել, թե որ ռեսուրսներն ավելի լավ կլիներ բարձրացնել «սահմանները» (վերին թույլատրելի սանդղակը), որպեսզի «թուլացում» չառաջանա. այն պահը, երբ ռեսուրսը արդեն ծախսել է պրոցեսորը կամ հիշողությունը հատկացված ժամանակի հատվածում և սպասում է մինչև այն «ապասառեցվի».
Եվ ահա այն պատիճները, որոնք պետք է զսպեն նրանց ախորժակը.
Մոտ շնչափող + ռեսուրսների մոնիտորինգ, կարող եք գրել մեկից ավելի հոդված, այնպես որ հարցեր տվեք մեկնաբանություններում: Մի քանի խոսքով, կարող եմ ասել, որ նման չափումների ավտոմատացման խնդիրը շատ դժվար է և պահանջում է շատ ժամանակ և հավասարակշռող գործողություն «պատուհան» գործառույթների և «CTE» Prometheus / VictoriaMetrics-ի հետ (այս տերմինները չակերտների մեջ են, քանի որ կա գրեթե PromQL-ում նման բան չկա, և դուք պետք է վախեցնող հարցումները բաժանեք տեքստի մի քանի էկրանների և օպտիմալացնեք դրանք):
Արդյունքում, մշակողները գործիքներ ունեն՝ վերահսկելու իրենց անվանատարածքները Cube-ում, և նրանք կարող են ինքնուրույն ընտրել, թե որտեղ և որ ժամին որ հավելվածները կարող են «կտրել» իրենց ռեսուրսները, և որ սերվերներին կարելի է տրամադրել ամբողջ պրոցեսորը ողջ գիշեր:
Մեթոդաբանություններ
Ընկերությունում, ինչպես հիմա է նորաձեւ, մենք հավատարիմ ենք DevOps-ին և ՍԻՐ- պրակտիկ Երբ ընկերությունն ունի 1000 միկրոսերվիս, մոտ 350 ծրագրավորող և 15 ադմին ամբողջ ենթակառուցվածքի համար, դու պետք է «նորաձև լինես». գործընթացներում։
Որպես Ops, մենք տրամադրում ենք տարբեր չափումներ և վահանակներ ծրագրավորողների համար՝ կապված ծառայության արձագանքման տեմպերի և սխալների հետ:
Մենք օգտագործում ենք այնպիսի մեթոդներ, ինչպիսիք են. , и դրանք համատեղելով: Մենք փորձում ենք նվազագույնի հասցնել վահանակների քանակը, որպեսզի մի հայացքից պարզ լինի, թե որ ծառայությունն է ներկայումս ստորացուցիչ (օրինակ՝ պատասխանի կոդերը վայրկյանում, արձագանքման ժամանակը 99-րդ տոկոսով) և այլն։ Հենց որ որոշ նոր չափումներ անհրաժեշտ են դառնում ընդհանուր վահանակների համար, մենք անմիջապես նկարում և ավելացնում ենք դրանք:
Մեկ ամիս է՝ գրաֆիկներ չեմ նկարել։ Սա, հավանաբար, լավ նշան է. նշանակում է, որ «ցանկությունների» մեծ մասն արդեն իրականացվել է: Պատահում էր, որ շաբաթվա ընթացքում գոնե օրը մեկ անգամ ինչ-որ նոր գրաֆիկ էի նկարում։
Ստացված արդյունքը արժեքավոր է, քանի որ այժմ մշակողները շատ հազվադեպ են դիմում ադմինիստրատորներին՝ «որտեղ դիտարկել ինչ-որ չափանիշ» հարցերով:
Իրականացում Սպասարկման ցանց մոտ անկյունում է և պետք է կյանքը շատ ավելի դյուրին դարձնի բոլորի համար, Tools-ի գործընկերներն արդեն մոտ են «Առողջ մարդու Istio»-ի աբստրակտ ներդրմանը. յուրաքանչյուր HTTP(ների) հարցումների կյանքի ցիկլը տեսանելի կլինի մոնիտորինգում, և այն Միշտ հնարավոր կլինի հասկանալ, թե «որ փուլում է ամեն ինչ կոտրվել» միջսպասարկման (և ոչ միայն) փոխգործակցության ընթացքում։ Բաժանորդագրվեք DomClick կենտրոնի նորություններին: =)
Kubernetes ենթակառուցվածքի աջակցություն
Պատմականորեն մենք օգտագործում ենք կարկատված տարբերակը Կուբեսփրեյ — Հասանելի դեր Kubernetes-ի տեղակայման, ընդլայնման և թարմացման համար: Ինչ-որ պահի հիմնական ճյուղից կտրվեց ոչ-kubeadm կայանքների աջակցությունը, և kubeadm-ին անցնելու գործընթացը չառաջարկվեց: Արդյունքում Southbridge ընկերությունը պատրաստեց իր սեփական պատառաքաղը (kubeadm-ի աջակցությամբ և կրիտիկական խնդիրների արագ շտկումով):
Բոլոր k8s կլաստերների թարմացման գործընթացը հետևյալն է.
- Վերցրեք Կուբեսփրեյ Սաութբրիջից, ստուգեք մեր թեմայով, Մերջիմ:
- Մենք տրամադրում ենք թարմացումը Շեշտ- «Խորանարդ»:
- Մենք թողարկում ենք թարմացումը մեկ-մեկ հանգույցում (Ansible-ում սա «սերիական է՝ 1» է) Դեւ- «Խորանարդ»:
- Մենք թարմացնում ենք Գրգռել շաբաթ երեկոյան մեկ հանգույց:
Ապագայում այն փոխարինելու ծրագրեր կան Կուբեսփրեյ ավելի արագ ինչ-որ բանի համար և գնացեք kubeadm.
Ընդհանուր առմամբ մենք ունենք երեք «խորանարդ»՝ սթրես, մշակում և պրոդ. Մենք նախատեսում ենք գործարկել ևս մեկը (տաք սպասման ռեժիմ) Prod-«Cube» երկրորդ տվյալների կենտրոնում: Շեշտ и Դեւ ապրել «վիրտուալ մեքենաներում» (oVirt՝ սթրեսի համար և VMWare ամպ՝ Dev-ի համար): Գրգռել- «Cube»-ն ապրում է «մերկ մետաղի» վրա. սրանք միանման հանգույցներ են՝ 32 պրոցեսորի թելերով, 64-128 ԳԲ հիշողությամբ և 300 ԳԲ SSD RAID 10. ընդհանուր առմամբ դրանցից 50-ը կա: Երեք «բարակ» հանգույցներ նվիրված են «վարպետներին». Գրգռել- «Կուբա»՝ 16 ԳԲ հիշողություն, 12 պրոցեսորի թելեր:
Վաճառքի համար մենք նախընտրում ենք օգտագործել «մերկ մետաղ» և խուսափել նման ավելորդ շերտերից OpenStackՄեզ պետք չեն «աղմկոտ հարևաններ» և պրոցեսոր ժամանակ գողանալ. Իսկ կառավարման բարդությունը մոտավորապես կրկնապատկվում է ներքին OpenStack-ի դեպքում:
CI/CD «Cubic» և այլ ենթակառուցվածքային բաղադրիչների համար մենք օգտագործում ենք առանձին GIT սերվեր՝ Helm 3 (դա բավականին ցավոտ անցում էր Helm 2-ից, բայց մենք շատ գոհ ենք տարբերակներից։ ատոմային), Ջենկինս, Անսիբլ և Դոկեր։ Մենք սիրում ենք գործառույթների ճյուղերը և տեղակայումը տարբեր միջավայրերում մեկ պահոցից:
Ամփոփում
Սա, ընդհանուր առմամբ, այսպիսին է DevOps գործընթացը DomClick-ում՝ գործառնական ինժեների տեսանկյունից: Հոդվածն ավելի քիչ տեխնիկական էր, քան ես սպասում էի, հետևաբար հետևեք Habré-ի DomClick նորություններին. կլինեն ավելի շատ «հարդքոր» հոդվածներ Kubernetes-ի մասին և ավելին:
Source: www.habr.com