Այսօր ես նախատեսում եմ խոսել այն մասին, թե ինչպես գրել հավելվածներ և որոնք են պահանջները, որպեսզի ձեր հավելվածը լավ աշխատի Kubernetes-ում: Որպեսզի հավելվածի հետ կապված գլխացավեր չլինի, որպեսզի ստիպված չլինեք դրա շուրջ որևէ «ճեղքվածք» հորինել և կառուցել, և ամեն ինչ աշխատում է այնպես, ինչպես ինքն էր Kubernetes-ը նախատեսել:
Այս դասախոսությունը մաս է կազմում «« Կարող եք դիտել Երեկոյան դպրոցի բաց տեսական դասախոսությունները . Նրանց համար, ովքեր նախընտրում են տեքստը, քան տեսանյութը, մենք պատրաստել ենք այս հոդվածը:
Ես Պավել Սելիվանովն եմ, ներկայումս Mail.ru Cloud Solutions-ում DevOps-ի առաջատար ինժեներն եմ, մենք ամպեր ենք պատրաստում, կառավարման կուբերնետներ և այլն: Այժմ իմ առաջադրանքները ներառում են աջակցություն զարգացմանը, այս ամպերի տարածումը, մեր գրած հավելվածների տարածումը և այն գործիքների անմիջական զարգացումը, որոնք մենք տրամադրում ենք մեր օգտատերերին:
Ես անում եմ DevOps, կարծում եմ վերջին, հավանաբար, երեք տարին: Բայց, սկզբունքորեն, ես անում եմ այն, ինչ անում է DevOps-ը, հավանաբար մոտ հինգ տարի: Մինչ այդ ես հիմնականում զբաղվում էի ադմինիստրատորներով։ Ես սկսել եմ աշխատել Kubernetes-ի հետ շատ վաղուց. հավանաբար մոտ չորս տարի է անցել, ինչ սկսել եմ աշխատել դրա հետ:
Ընդհանրապես, ես սկսել եմ այն ժամանակ, երբ Kubernetes-ը 1.3 տարբերակ էր, հավանաբար, և գուցե 1.2-ը, երբ այն դեռ իր սկզբնական շրջանում էր: Այժմ այն այլևս իր սկզբնական շրջանում չէ, և ակնհայտ է, որ շուկայում մեծ պահանջարկ կա ինժեներների համար, ովքեր կցանկանային կարողանան զբաղվել Kubernetes-ով: Իսկ ընկերությունները նման մարդկանց նկատմամբ շատ մեծ պահանջարկ ունեն։ Հետեւաբար, փաստորեն, այս դասախոսությունը հայտնվեց.
Եթե խոսենք ըստ պլանի, թե ինչի մասին կխոսեմ, ապա այն կարծես այսպես է, փակագծերում գրված է (TL;DR) - «շատ երկար; մի կարդա»: Իմ այսօրվա շնորհանդեսը բաղկացած է լինելու անվերջ ցուցակներից։
Իրականում, ես ինքս չեմ սիրում նման շնորհանդեսներ, երբ դրանք արվում են, բայց սա այնպիսի թեմա է, որ երբ ես պատրաստում էի այս շնորհանդեսը, ես պարզապես իրականում չէի պատկերացնում, թե ինչպես կազմակերպել այս տեղեկատվությունը այլ կերպ:
Որովհետև, մեծ հաշվով, այս տեղեկատվությունը «ctrl+c, ctrl+v» է, ի թիվս այլ բաների, մեր Wiki-ից DevOps բաժնում, որտեղ մենք գրավոր պահանջներ ունենք մշակողների համար. «տղե՛րք, որպեսզի մենք գործարկենք ձեր հավելվածը: Կուբերնետես, այսպես պետք է լինի»։
Ահա թե ինչու շնորհանդեսն այդքան մեծ ցուցակ ստացվեց։ Ներողություն. Կփորձեմ հնարավորինս շատ պատմել, որ հնարավորության դեպքում ձանձրալի չլինի։
Այն, ինչ մենք այժմ դիտելու ենք.
- սրանք, առաջին հերթին, տեղեկամատյաններ են (կիրառական տեղեկամատյաններ), ինչ անել նրանց հետ Kubernetes-ում, ինչ անել նրանց հետ, ինչ պետք է լինեն;
- ինչ անել Kubernetes-ի կոնֆիգուրացիաների հետ, որո՞նք են Kubernetes-ի հավելվածը կարգավորելու լավագույն և վատագույն եղանակները.
- Եկեք խոսենք այն մասին, թե ընդհանրապես ինչ են մատչելիության ստուգումները, ինչպիսին պետք է լինեն դրանք;
- եկեք խոսենք այն մասին, թե ինչ է նրբագեղ անջատումը.
- եկեք նորից խոսենք ռեսուրսների մասին;
- Եվս մեկ անգամ անդրադառնանք տվյալների պահպանման թեմային;
- և վերջում ես ձեզ կասեմ, թե ինչ տերմին է այս առեղծվածային ամպի բնիկ հավելվածը: Ամպամածություն՝ որպես այս տերմինի ածական։
Տեղեկամատյանները
Ես առաջարկում եմ սկսել տեղեկամատյաններից, որտեղից պետք է այս տեղեկամատյանները տեղափոխել Kubernetes-ում: Այժմ դուք գործարկել եք հավելված Kubernetes-ում: Ըստ դասականների՝ նախկինում հավելվածները միշտ ֆայլի մեջ ինչ-որ տեղ տեղեկամատյաններ էին գրում։ Վատ հավելվածները տեղեկամատյաններ են գրել հավելվածը գործարկող ծրագրավորողի գլխավոր գրացուցակում գտնվող ֆայլում: Լավ հավելվածները ինչ-որ տեղ տեղեկամատյաններ էին գրում ֆայլում /var/log.
Հետևաբար, լավ ադմինիստրատորներն իրենց ենթակառուցվածքներում կարգավորել են որոշ բաներ, որոնք այս տեղեկամատյանները կարող են պտտել. նույն rsyslog-ը, որը նայում է այս տեղեկամատյաններին և երբ նրանց հետ ինչ-որ բան է պատահում, դրանք շատ են, այն ստեղծում է պահուստային պատճեններ, տեղադրում տեղեկամատյաններ: , ջնջում է հին ֆայլերը, ավելի քան մեկ շաբաթ, վեց ամիս և ավելին: Տեսականորեն մենք պետք է ունենանք դրույթներ, որպեսզի պարզապես այն պատճառով, որ հավելվածը գրում է logs, արտադրական սերվերների (մարտական սերվերների՞) տարածքը չսպառվի։ Եվ, համապատասխանաբար, ամբողջ արտադրությունը չդադարեց գերանների պատճառով։
Երբ մենք տեղափոխվում ենք Կուբերնետեսի աշխարհ և նույն բանն այնտեղ ենք գործարկում, առաջին բանը, որին դուք կարող եք ուշադրություն դարձնել, այն է, որ մարդիկ, քանի որ նրանք ֆայլում տեղեկամատյաններ են գրել, շարունակում են գրել դրանք:
Ստացվում է, որ եթե մենք խոսում ենք Kubernetes-ի մասին, ապա դոկեր կոնտեյներից ինչ-որ տեղ տեղեկամատյաններ գրելու ճիշտ տեղը պարզապես դրանք հավելվածից այսպես կոչված Stdout/Stderr գրելն է, այսինքն՝ օպերացիոն համակարգի ստանդարտ ելքային հոսքերը, ստանդարտ սխալի ելք: Սա Docker-ում և կոնկրետ Kubernetis-ում տեղեկամատյանները սկզբունքորեն տեղադրելու ամենաճիշտ, ամենապարզ և տրամաբանական եղանակն է: Քանի որ, եթե ձեր հավելվածը գրանցամատյաններ է գրում Stdout/Stderr-ում, ապա Docker-ը և Kubernetes հավելումը պետք է որոշեն, թե ինչ անել այս տեղեկամատյանների հետ: Docker-ը լռելյայնորեն կստեղծի իր հատուկ ֆայլերը JSON ձևաչափով:
Այստեղ հարց է առաջանում՝ ի՞նչ եք անելու հետո այս գերանների հետ։ Ամենահեշտ ճանապարհը պարզ է, մենք դրա հնարավորությունն ունենք kubectl logs և նայեք այս «ջարդերի» գերաններին: Բայց, հավանաբար, սա այնքան էլ լավ տարբերակ չէ, այլ բան է պետք անել տեղեկամատյանների հետ:
Առայժմ եկեք խոսենք միևնույն ժամանակ, քանի որ մենք անդրադարձել ենք տեղեկամատյանների թեմային, այնպիսի բանի մասին, ինչպիսին պետք է լինի տեղեկամատյանները: Այսինքն, սա ուղղակիորեն չի վերաբերում Kubernetes-ին, բայց երբ մենք սկսում ենք մտածել, թե ինչ անել լոգերի հետ, լավ կլինի մտածել նաև այս մասին։
Մեզ պետք է ինչ-որ գործիք, բարեկամաբար, որը կվերցնի այս տեղեկամատյանները, որոնք մեր դոկերը դնում է իր ֆայլերի մեջ և կուղարկի դրանք ինչ-որ տեղ: Մեծ հաշվով, մենք սովորաբար գործարկում ենք ինչ-որ գործակալ Kubernetes-ի ներսում DaemonSet-ի տեսքով՝ տեղեկամատյանների կոլեկցիոներ, որին պարզապես ասվում է, թե որտեղ են գտնվում Docker-ի հավաքած տեղեկամատյանները: Եվ հավաքող այս գործակալը պարզապես վերցնում է դրանք, գուցե նույնիսկ ինչ-որ կերպ վերլուծում է դրանք ճանապարհին, գուցե հարստացնում է որոշ լրացուցիչ մետատեղեկատվությամբ և, ի վերջո, դրանք ուղարկում է ինչ-որ տեղ պահեստավորման: Այնտեղ արդեն հնարավոր են տատանումներ։ Ամենատարածվածը, հավանաբար, Elasticsearch-ն է, որտեղ դուք կարող եք պահել տեղեկամատյանները և կարող եք հեշտությամբ առբերել դրանք այնտեղից: Այնուհետև, օգտագործելով հարցումը, օգտագործելով Kibana-ն, օրինակ, դրանց հիման վրա կառուցեք գրաֆիկներ, դրանց հիման վրա ստեղծեք ազդանշաններ և այլն։
Ամենակարևոր գաղափարը, ես ուզում եմ նորից կրկնել, այն է, որ Docker-ի ներսում, մասնավորապես Kubernetes-ի ներսում, ձեր տեղեկամատյանները ֆայլում պահելը շատ վատ գաղափար է:
Որովհետև, առաջին հերթին, դժվար է կոնտեյների ներսում տեղեկամատյանները ֆայլի մեջ մտցնել: Դուք նախ պետք է մտնեք կոնտեյների մեջ, գործարկեք այնտեղ, ապա նայեք տեղեկամատյաններին: Հաջորդ կետն այն է, որ եթե դուք ունեք տեղեկամատյաններ ֆայլում, ապա բեռնարկղերը սովորաբար ունեն մինիմալիստական միջավայր և չկան կոմունալ ծառայություններ, որոնք սովորաբար անհրաժեշտ են լոգերի հետ նորմալ աշխատանքի համար: Թաղեք դրանք, նայեք նրանց, բացեք դրանք տեքստային խմբագրիչում: Հաջորդ պահն այն է, երբ մենք ունենք տեղեկամատյաններ մի ֆայլի մեջ կոնտեյների մեջ, եթե այս կոնտեյները ջնջվի, հասկանում եք, լոգերը կմեռնեն դրա հետ միասին: Համապատասխանաբար, կոնտեյների ցանկացած վերագործարկում նշանակում է, որ այլևս տեղեկամատյաններ չկան: Կրկին վատ տարբերակ.
Եվ վերջին կետն այն է, որ կոնտեյներների ներսում դուք սովորաբար ունենում եք ձեր հավելվածը և վերջ, դա սովորաբար միակ գործընթացն է, որն աշխատում է: Ընդհանրապես խոսք չկա որևէ գործընթացի մասին, որը կարող է պտտել ֆայլերը ձեր տեղեկամատյաններով: Հենց որ տեղեկամատյանները սկսեն գրվել ֆայլում, դա նշանակում է, որ, կներեք ինձ, մենք կսկսենք կորցնել արտադրության սերվերը: Քանի որ, նախ, դրանք դժվար է գտնել, ոչ ոք չի հետևում նրանց, գումարած ոչ ոք չի վերահսկում դրանք, համապատասխանաբար, ֆայլը անվերջ աճում է, մինչև սերվերի տարածքը պարզապես սպառվի: Հետևաբար, ես նորից եմ ասում, որ Docker-ում, մասնավորապես Kubernetes-ում, ֆայլ մուտք գործելը վատ գաղափար է:
Հաջորդ կետը, այստեղ ես ուզում եմ նորից խոսել այս մասին. քանի որ մենք շոշափում ենք տեղեկամատյանների թեման, լավ կլինի խոսել այն մասին, թե ինչպես պետք է նայեն տեղեկամատյանները, որպեսզի հարմար լինի դրանց հետ աշխատելը: Ինչպես ասացի, թեման ուղղակիորեն կապված չէ Kubernetes-ի հետ, բայց շատ լավ է առնչվում DevOps-ի թեմային։ Զարգացման մշակույթի և այս երկու տարբեր գերատեսչությունների՝ Dev-ի և Ops-ի միջև բարեկամության թեմայով, որպեսզի բոլորը հարմարավետ լինեն:
Սա նշանակում է, որ իդեալականորեն, այսօր, տեղեկամատյանները պետք է գրվեն JSON ձևաչափով: Եթե դուք ունեք ձեր սեփական անհասկանալի հավելվածը, որը գրում է տեղեկամատյանները անհասկանալի ձևաչափերով, քանի որ դուք տեղադրում եք ինչ-որ տպագիր կամ նման բան, ապա ժամանակն է google-ով փնտրել ինչ-որ շրջանակ, ինչ-որ փաթաթան, որը թույլ է տալիս իրականացնել նորմալ լոգինգ; միացրեք JSON-ում գրանցման պարամետրերը, քանի որ JSON-ը պարզ ձևաչափ է, այն վերլուծելը հեշտ է:
Եթե ձեր JSON-ը չի աշխատում ըստ որոշ չափանիշների, ոչ ոք չգիտի, թե ինչ, ապա գոնե գրեք տեղեկամատյանները այնպիսի ձևաչափով, որը հնարավոր է վերլուծել: Այստեղ, ավելի շուտ, արժե մտածել այն մասին, որ, օրինակ, եթե դուք գործարկում եք մի փունջ բեռնարկղեր կամ պարզապես պրոցեսներ եք անում nginx-ով, և յուրաքանչյուրն ունի իր գրանցման կարգավորումները, ապա հավանաբար թվում է, որ ձեզ համար շատ անհարմար կլինի վերլուծել դրանք: Որովհետև nginx-ի յուրաքանչյուր նոր օրինակի համար պետք է գրել ձեր սեփական վերլուծիչը, քանի որ նրանք այլ կերպ են գրում լոգերը: Կրկին, հավանաբար արժե մտածել այն մասին, որ համոզվեք, որ nginx-ի այս բոլոր օրինակներն ունեն նույն գրանցման կոնֆիգուրացիան և գրել իրենց բոլոր տեղեկամատյանները բացարձակապես միատեսակ: Նույնը վերաբերում է բացարձակապես բոլոր հավելվածներին։
Ի վերջո, ես նաև ուզում եմ կրակի վրա յուղ լցնել, որ իդեալական տարբերակում պետք է խուսափել բազմագիծ ձևաչափի տեղեկամատյաններից: Ահա բանը, եթե դուք երբևէ աշխատել եք գերան հավաքողների հետ, ապա, ամենայն հավանականությամբ, տեսել եք, թե ինչ են նրանք խոստանում ձեզ, որ նրանք կարող են աշխատել բազմաշերտ գերանների հետ, գիտեն, թե ինչպես հավաքել դրանք և այլն: Իրականում, իմ կարծիքով, այսօր ոչ մի կոլեկցիոներ չի կարող նորմալ, ամբողջությամբ և առանց սխալների բազմագիծ տեղեկամատյաններ հավաքել։ Մարդկային ձևով, որպեսզի հարմար լինի և առանց սխալների։
Բայց stack trace-ը միշտ բազմաշերտ տեղեկամատյաններն են և ինչպես խուսափել դրանցից: Այստեղ հարցն այն է, որ տեղեկամատյանը իրադարձության գրառում է, իսկ stactrace-ն իրականում գրանցամատյան չէ: Եթե մենք հավաքում ենք տեղեկամատյանները և դրանք տեղադրում ինչ-որ տեղ Elasticsearch-ում, այնուհետև դրանցից գծապատկերներ ենք նկարում, ձեր կայքում կառուցում ենք օգտատերերի գործունեության մասին որոշ հաշվետվություններ, ապա երբ դուք ստանում եք stack trace, դա նշանակում է, որ ինչ-որ անսպասելի բան է տեղի ունենում. չկառավարվող իրավիճակ ձեր հավելվածում: Եվ իմաստ ունի ինքնաբերաբար վերբեռնել կույտի հետքը ինչ-որ տեղ համակարգում, որը կարող է հետևել դրանց:
Սա ծրագրաշար է (նույն Sentry-ն), որը հատուկ ստեղծված է stack trace-ի հետ աշխատելու համար: Այն կարող է անմիջապես ստեղծել ավտոմատացված առաջադրանքներ, հանձնարարել դրանք ինչ-որ մեկին, զգուշացնել, երբ հայտնվում են stacttraces, խմբավորել այս stacttraces-ը ըստ մեկ տեսակի և այլն: Սկզբունքորեն, անիմաստ է խոսել տեղեկամատյանների մասին, երբ մենք խոսում ենք գերանների մասին, քանի որ դրանք, ի վերջո, տարբեր բաներ են՝ տարբեր նպատակներով:
Տեսիլ
Հաջորդը մենք կխոսենք Kubernetes-ում կազմաձևման մասին. ինչ անել դրա հետ և ինչպես պետք է կարգավորվեն Kubernetes-ի ներսում հավելվածները: Ընդհանրապես, ես սովորաբար ասում եմ, որ Docker-ը կոնտեյներների մասին չէ: Բոլորը գիտեն, որ Docker-ը կոնտեյներների մասին է, նույնիսկ նրանք, ովքեր շատ չեն աշխատել Docker-ի հետ: Կրկնում եմ՝ Docker-ը կոնտեյներների մասին չէ։
Դոկերը, իմ կարծիքով, ստանդարտների մասին է: Եվ գործնականում ամեն ինչի համար կան ստանդարտներ՝ ձեր հավելվածը ստեղծելու ստանդարտներ, ձեր հավելվածը տեղադրելու ստանդարտներ:
Եվ այս բանը, - մենք նախկինում օգտագործում էինք այն, պարզապես այն հատկապես հայտնի դարձավ բեռնարկղերի հայտնվելով, - այս բանը կոչվում է ENV (շրջակա միջավայր) փոփոխականներ, այսինքն ՝ շրջակա միջավայրի փոփոխականներ, որոնք գտնվում են ձեր օպերացիոն համակարգում: Սա, ընդհանուր առմամբ, ձեր հավելվածը կարգավորելու իդեալական միջոց է, քանի որ եթե դուք ունեք հավելվածներ JAVA-ում, Python-ում, Go-ում, Perl-ում, Աստված մի արասցե, և նրանք բոլորը կարող են կարդալ տվյալների բազայի հոսթինգը, տվյալների բազայի օգտագործողը, տվյալների բազայի գաղտնաբառի փոփոխականները, ապա դա իդեալական է: Դուք ունեք հավելվածներ չորս տարբեր լեզուներով, որոնք կազմաձևված են տվյալների բազայի պլանում նույն ձևով: Այլևս տարբեր կոնֆիգուրացիաներ չկան:
Ամեն ինչ կարելի է կարգավորել՝ օգտագործելով ENV փոփոխականները: Երբ մենք խոսում ենք Kubernetes-ի մասին, ENV փոփոխականները հենց Deployment-ի ներսում հայտարարելու հիանալի միջոց կա: Համապատասխանաբար, եթե մենք խոսում ենք գաղտնի տվյալների մասին, ապա մենք կարող ենք անմիջապես գաղտնի տվյալները ENV փոփոխականներից (գաղտնաբառեր տվյալների բազաներին և այլն) մղել գաղտնիքի մեջ, ստեղծել գաղտնի կլաստեր և նշել ENV նկարագրության մեջ Deployment-ում, որ մենք ուղղակիորեն չենք հայտարարում: այս փոփոխականի արժեքը և տվյալների բազայի գաղտնաբառի այս փոփոխականի արժեքը կկարդացվեն գաղտնիքից: Սա ստանդարտ Kubernetes-ի վարքագիծ է: Եվ սա ձեր հավելվածները կարգավորելու ամենաիդեալական տարբերակն է: Պարզապես կոդի մակարդակով, սա կրկին վերաբերում է մշակողներին: Եթե դուք DevOps եք, կարող եք հարցնել. «Տղե՛րք, խնդրում եմ սովորեցրեք ձեր հավելվածին կարդալ շրջակա միջավայրի փոփոխականները: Եվ մենք բոլորս երջանիկ կլինենք»:
Եթե ընկերությունում բոլորը կարդում են նույն անունով շրջակա միջավայրի փոփոխականները, ապա դա հիանալի է: Որպեսզի այնպես չլինի, որ ոմանք սպասում են postgres տվյալների բազային, մյուսները սպասում են տվյալների բազայի անվանմանը, մյուսները սպասում են այլ բանի, մյուսները սպասում են ինչ-որ dbn-ի, որպեսզի, համապատասխանաբար, լինի միատեսակ:
Խնդիրն առաջանում է, երբ դուք ունեք այնքան շատ միջավայրի փոփոխականներ, որ դուք պարզապես բացում եք Deployment-ը, և կան շրջակա միջավայրի փոփոխականների հինգ հարյուր տող: Այս դեպքում, դուք պարզապես գերազանցել եք շրջակա միջավայրի փոփոխականները, և ձեզ այլևս պետք չէ խոշտանգել ձեզ: Այս դեպքում իմաստ կունենա սկսել օգտագործել կոնֆիգուրացիաներ: Այսինքն՝ վարժեցրեք ձեր հավելվածը կոնֆիգուրացիաներ օգտագործելու համար:
Միակ հարցն այն է, որ կոնֆիգուրացիաներն այն չեն, ինչ դուք կարծում եք: Config.pi-ն օգտագործման համար հարմար կոնֆիգուրացիա չէ: Կամ ինչ-որ կոնֆիգուրացիա ձեր սեփական ձևաչափով, այլապես շնորհված, սա նույնպես այն կազմաձևը չէ, որը ես նկատի ունեմ:
Ինչի մասին ես խոսում եմ ընդունելի ձևաչափերով կոնֆիգուրացիան, այսինքն՝ ամենահանրաճանաչ ստանդարտը .yaml ստանդարտն է։ Հասկանալի է, թե ինչպես կարելի է կարդալ, այն ընթեռնելի է մարդու համար, պարզ է, թե ինչպես կարդալ այն հավելվածից։
Համապատասխանաբար, բացի YAML-ից, դուք կարող եք նաև, օրինակ, օգտագործել JSON-ը, վերլուծությունը մոտավորապես նույնքան հարմար է, որքան YAML-ը՝ հավելվածի կոնֆիգուրացիան այնտեղից կարդալու առումով: Մարդկանց համար նկատելիորեն ավելի անհարմար է կարդալ։ Դուք կարող եք փորձել ձևաչափը, a la ini: Մարդկային տեսանկյունից կարդալը բավականին հարմար է, բայց կարող է անհարմար լինել այն ավտոմատ կերպով մշակելը, այն իմաստով, որ եթե երբևէ ցանկանաք ստեղծել ձեր սեփական կոնֆիգուրացիաները, ապա ini ձևաչափը կարող է արդեն անհարմար լինել:
Բայց ամեն դեպքում, ինչ ֆորմատ էլ ընտրես, բանն այն է, որ Կուբերնետեսի տեսանկյունից դա շատ հարմար է։ Դուք կարող եք տեղադրել ձեր ամբողջ կազմաձևը Kubernetes-ի ներսում՝ ConfigMap-ում: Եվ այնուհետև վերցրեք այս կազմաձևման քարտեզը և խնդրեք, որ այն տեղադրվի ձեր pod-ի ներսում ինչ-որ հատուկ գրացուցակում, որտեղ ձեր հավելվածը կկարդա այս կազմաձևի կոնֆիգուրացիան, կարծես այն պարզապես ֆայլ է: Սա, ըստ էության, այն է, ինչ լավ է անել, երբ ձեր հավելվածում կան բազմաթիվ կազմաձևման տարբերակներ: Կամ դա պարզապես ինչ-որ բարդ կառուցվածք է, կա բույն:
Եթե դուք ունեք կազմաձև քարտեզ, ապա կարող եք շատ լավ սովորեցնել ձեր հավելվածին, օրինակ՝ ավտոմատ կերպով հետևել փոփոխություններին այն ֆայլում, որտեղ տեղադրված է կազմաձևի քարտեզը, ինչպես նաև ավտոմատ կերպով վերաբեռնել ձեր հավելվածը, երբ կարգավորումները փոխվեն: Սա, ընդհանուր առմամբ, կլինի իդեալական տարբերակ:
Կրկին, ես արդեն խոսեցի այս մասին. գաղտնի տեղեկատվությունը չկա կոնֆիգմապում, գաղտնի տեղեկատվությունը փոփոխականների մեջ չէ, գաղտնի տեղեկատվությունը գաղտնիքի մեջ չէ: Այնտեղից այս գաղտնի տեղեկությունը միացրեք դիվանագիտությանը։ Սովորաբար մենք պահում ենք Kubernetes-ի օբյեկտների, տեղակայումների, կազմաձևերի, ծառայությունների բոլոր նկարագրությունները git-ում: Համապատասխանաբար, տվյալների բազայի գաղտնաբառը git-ում դնելը, նույնիսկ եթե դա ձեր git-ն է, որը դուք ներսում ունեք ընկերությունում, վատ գաղափար է: Քանի որ, նվազագույնը, git-ը հիշում է ամեն ինչ, և պարզապես գաղտնաբառերը հեռացնելն այդտեղից այնքան էլ հեշտ չէ։
Առողջության ստուգում
Հաջորդ կետը սա է, որը կոչվում է Առողջության ստուգում: Ընդհանուր առմամբ, Առողջության ստուգումը պարզապես ստուգում է, որ ձեր դիմումը աշխատում է: Միևնույն ժամանակ, մենք ամենից հաճախ խոսում ենք որոշակի վեբ հավելվածների մասին, որոնց համար, համապատասխանաբար, առողջության ստուգման տեսանկյունից (ավելի լավ է չթարգմանել այստեղ և հետագա) սա կլինի ինչ-որ հատուկ URL, որը նրանք մշակում են որպես ստանդարտ, նրանք սովորաբար անում են /health.
Այս URL-ը մուտք գործելիս, համապատասխանաբար, մեր հավելվածն ասում է կամ «այո, լավ, ինձ մոտ ամեն ինչ կարգին է, 200» կամ «ոչ, ինձ մոտ ամեն ինչ կարգին չէ, մոտ 500»: Համապատասխանաբար, եթե մեր հավելվածը http չէ, ոչ վեբ հավելված, մենք հիմա խոսում ենք ինչ-որ դեյմոնի մասին, մենք կարող ենք պարզել, թե ինչպես անել առողջական ստուգումներ: Այսինքն՝ պարտադիր չէ, եթե հավելվածը http չէ, ապա ամեն ինչ աշխատում է առանց առողջության ստուգման և դա ոչ մի կերպ չի կարելի անել։ Դուք կարող եք պարբերաբար թարմացնել որոշ տեղեկություններ ֆայլում, կարող եք գալ ինչ-որ հատուկ հրաման ձեր դեյմոնի համար, օրինակ՝ daemon status, որը կասի «այո, ամեն ինչ լավ է, դեյմոնն աշխատում է, այն կենդանի է»:
Ինչի համար է դա? Առաջին և ամենաակնհայտ բանը, հավանաբար, այն է, թե ինչու է անհրաժեշտ առողջության ստուգումը՝ հասկանալու համար, որ հավելվածն աշխատում է: Այսինքն, դա ուղղակի հիմարություն է, երբ այն հիմա աշխատում է, թվում է, որ այն աշխատում է, այնպես որ կարող եք վստահ լինել, որ այն աշխատում է: Եվ պարզվում է, որ հավելվածն աշխատում է, կոնտեյները աշխատում է, օրինակն աշխատում է, ամեն ինչ կարգին է, և այդ ժամանակ օգտատերերն արդեն կտրել են բոլոր հեռախոսահամարները տեխնիկական սպասարկումից և ասում են «ինչ ես…, դու քնել է, ոչինչ չի աշխատում»։
Առողջության ստուգումը հենց այն միջոցն է, որպեսզի օգտագործողի տեսանկյունից համոզվեք, որ այն աշխատում է: Մեթոդներից մեկը. Եկեք այսպես դնենք. Kubernetes-ի տեսանկյունից սա նաև միջոց է հասկանալու, թե երբ է սկսվում հավելվածը, քանի որ մենք հասկանում ենք, որ տարբերություն կա կոնտեյների գործարկման, ստեղծման և մեկնարկի միջև, և երբ հավելվածը գործարկվել է անմիջապես այս կոնտեյներով: Որովհետև եթե վերցնենք միջին java հավելվածը և փորձենք գործարկել այն դոկում, ապա քառասուն վայրկյան, կամ նույնիսկ մեկ րոպե, կամ նույնիսկ տասը, այն կարող է լավ սկսել: Այս դեպքում կարելի է գոնե թակել նրա պորտերը, այնտեղ չի պատասխանի, այսինքն՝ դեռ պատրաստ չէ տրաֆիկ ընդունել։
Կրկին, առողջական ստուգման միջոցով և այն փաստի օգնությամբ, որ մենք շրջվում ենք այստեղ, մենք կարող ենք Kubernetes-ում հասկանալ, որ ոչ միայն կոնտեյները բարձրացել է հավելվածում, այլև հավելվածն ինքն է սկսել, այն արդեն արձագանքում է. առողջության ստուգում, ինչը նշանակում է, որ մենք կարող ենք երթևեկություն ուղարկել այնտեղ:
Այն, ինչի մասին ես հիմա խոսում եմ, կոչվում է Կուբերնետեսի պատրաստականության/կենսունակության թեստեր, համապատասխանաբար, մեր պատրաստվածության թեստերը պատասխանատու են հավասարակշռման մեջ հավելվածի առկայության համար: Այսինքն, եթե հավելվածում կատարվում են պատրաստության թեստեր, ապա ամեն ինչ կարգին է, հաճախորդի տրաֆիկը գնում է դեպի հավելված: Եթե պատրաստվածության թեստեր չեն կատարվում, ապա հավելվածը պարզապես չի մասնակցում, կոնկրետ այս դեպքը չի մասնակցում հավասարակշռմանը, այն հանվում է հավասարակշռումից, հաճախորդի տրաֆիկը չի հոսում։ Համապատասխանաբար, Kubernetes-ում Liveness թեստեր են անհրաժեշտ, որպեսզի եթե հավելվածը խրվի, այն կարողանա վերագործարկվել։ Եթե կենդանիության թեստը չի աշխատում Kubernetes-ում հայտարարված հավելվածի համար, ապա հավելվածը ոչ միայն հեռացվում է հավասարակշռությունից, այլ այն վերագործարկվում է:
Եվ ահա մի կարևոր կետ, որը կուզենայի նշել՝ գործնական տեսանկյունից պատրաստվածության թեստը սովորաբար ավելի հաճախ է օգտագործվում և ավելի հաճախ է անհրաժեշտ, քան աշխուժության թեստը։ Այսինքն, պարզապես անմտածված հայտարարելը թե պատրաստակամության և թե աշխուժության թեստերի մասին, քանի որ Kubernetes-ը կարող է դա անել, և եկեք օգտագործենք այն ամենը, ինչ նա կարող է անել, այնքան էլ լավ գաղափար չէ: Ես կբացատրեմ, թե ինչու: Քանի որ թեստավորման թիվ երկու կետն այն է, որ լավ գաղափար կլինի ստուգել ձեր առողջական ստուգումների հիմքում ընկած ծառայությունը: Սա նշանակում է, որ եթե դուք ունեք վեբ հավելված, որը տալիս է որոշակի տեղեկատվություն, որն իր հերթին, բնականաբար, պետք է վերցնի ինչ-որ տեղից: Տվյալների բազայում, օրինակ. Դե, այն պահպանում է REST API-ի մեջ մտնող տեղեկատվությունը նույն տվյալների բազայում: Այնուհետև, համապատասխանաբար, եթե ձեր առողջության ստուգումը արձագանքում է պարզապես կապված slashhealth-ի պես, հավելվածն ասում է «200, լավ, ամեն ինչ լավ է», և միևնույն ժամանակ ձեր դիմումի տվյալների բազան անհասանելի է, իսկ առողջության ստուգման հավելվածն ասում է՝ «200, լավ, ամեն ինչ լավ է»: - Սա վատ առողջական ստուգում է: Այսպես չպետք է աշխատի։
Այսինքն՝ ձեր դիմումը, երբ դիմում է գալիս դրան /health, այն պարզապես չի պատասխանում, «200, լավ», նա սկզբում գնում է, օրինակ, տվյալների բազա, փորձում է միանալ դրան, այնտեղ շատ տարրական բան է անում, օրինակ՝ ընտրել մեկը, պարզապես ստուգում է, որ կապ կա տվյալների բազայում: տվյալների բազան և կարող եք հարցումներ կատարել տվյալների բազայում: Եթե այս ամենը հաջող էր, ապա պատասխանն է «200, լավ»: Եթե դա հաջող չէ, ասում է, որ սխալ կա, տվյալների բազան անհասանելի է:
Հետևաբար, այս առումով նորից վերադառնում եմ պատրաստակամության/կենսունակության թեստերին. ինչու է ձեզ ամենայն հավանականությամբ պատրաստակամության թեստ պետք, բայց աշխուժության թեստը հարցականի տակ է: Որովհետև եթե նկարագրեք առողջության ստուգումները ճիշտ այնպես, ինչպես ես ասացի, ապա կպարզվի, որ այն հասանելի չէ օրինակի մասում.в или со всех instanceտվյալների բազայում, օրինակ. Երբ դուք հայտարարեցիք պատրաստության թեստ, մեր առողջական ստուգումները սկսեցին ձախողվել, և, համապատասխանաբար, բոլոր հավելվածները, որոնցից տվյալների բազան հասանելի չէ, դրանք պարզապես անջատվում են հավասարակշռությունից և իրականում «կախվում» են պարզապես անտեսված վիճակում և սպասում են, որ իրենց տվյալների բազաները կատարվեն: աշխատանք.
Եթե մենք հայտարարագրել ենք աշխուժության թեստ, ապա պատկերացրեք, որ մեր տվյալների բազան կոտրվել է, և ձեր Kubernetes-ում ամեն ինչի կեսը սկսում է վերագործարկել, քանի որ կենդանիության թեստը ձախողվում է։ Սա նշանակում է, որ դուք պետք է վերագործարկեք: Սա ամենևին էլ ձեր ուզածը չէ, ես նույնիսկ պրակտիկայում անձնական փորձ ունեի։ Մենք ունեինք չաթի հավելված, որը գրված էր JS-ով և սնվում էր Mongo տվյալների բազայում: Եվ խնդիրն այն էր, որ դա Kubernetes-ի հետ իմ աշխատանքի սկզբում էր, մենք նկարագրեցինք թեստերի պատրաստակամությունը, աշխուժությունը այն սկզբունքով, որ Kubernetes-ը կարող է դա անել, ուստի մենք կօգտագործենք այն: Համապատասխանաբար, ինչ-որ պահի Մոնգոն դարձավ մի փոքր «ձանձրալի», և նմուշը սկսեց ձախողվել: Համապատասխանաբար, ըստ անձրևի թեստի, պատիճները սկսեցին «սպանել»:
Ինչպես հասկանում եք, երբ նրանց «սպանում են», սա զրույց է, այսինքն՝ հաճախորդներից շատ կապեր կան դրանից կախված։ Նրանք նույնպես «սպանվում են»՝ ոչ, ոչ հաճախորդներ, միայն կապեր՝ ոչ բոլորը միաժամանակ, և այն պատճառով, որ նրանք միաժամանակ չեն սպանվում, ոմանք ավելի վաղ, ոմանք ավելի ուշ, նրանք չեն սկսում նույնը: ժամանակ. Գումարած ստանդարտ պատահական, մենք չենք կարող ամեն անգամ միլիվայրկյան ճշգրտությամբ կանխատեսել հավելվածի մեկնարկի ժամանակը, այնպես որ նրանք դա անում են մեկ անգամ: Մեկ ինֆո կետը բարձրանում է, ավելանում է բալանսավորմանը, բոլոր հաճախորդները գալիս են այնտեղ, չի դիմանում նման ծանրաբեռնվածությանը, քանի որ մենակ է, և կոպիտ ասած՝ մի տասնյակ մարդ է աշխատում, ընկնում է։ Հաջորդը բարձրանում է, ամբողջ բեռը նրա վրա է, նա էլ է ընկնում։ Դե, այս ջրվեժները պարզապես շարունակում են կասկադը: Ի վերջո, ինչպես դա լուծվեց. մենք պարզապես պետք է խստորեն դադարեցնեինք օգտատերերի երթևեկությունը դեպի այս հավելված, թող բոլոր օրինակները բարձրանան և այնուհետև միանգամից սկսեին օգտվողի ամբողջ տրաֆիկը, որպեսզի այն արդեն բաշխված լիներ բոլոր տասը օրինակների միջև:
Եթե չհայտարարվեր այս աշխուժության թեստը, որը կստիպի վերագործարկել այն, ապա հավելվածը լավ կլուծեր այն: Բայց հավասարակշռումից սկսած ամեն ինչ մեզ համար անջատված է, քանի որ տվյալների բազաները անհասանելի են, և բոլոր օգտատերերը «ընկել են»: Այնուհետև, երբ այս տվյալների բազան հասանելի դառնա, ամեն ինչ ներառված է հավասարակշռման մեջ, բայց հավելվածները նորից սկսելու կարիք չունեն, և դրա վրա ժամանակ և ռեսուրսներ վատնելու կարիք չկա: Նրանք բոլորն արդեն այստեղ են, պատրաստ են երթևեկությանը, այնպես որ երթևեկությունը պարզապես բացվում է, ամեն ինչ կարգին է. հավելվածը տեղում է, ամեն ինչ շարունակում է աշխատել:
Հետևաբար պատրաստության և աշխուժության թեստերը տարբեր են, նույնիսկ ավելին, կարելի է տեսականորեն տարբեր առողջական ստուգումներ անել, օրինակ՝ մի տեսակի շառավիղ, մի տեսակ liv և տարբեր բաներ ստուգել։ Պատրաստության թեստերի ժամանակ ստուգեք ձեր հետին պլանները: Իսկ աշխուժության թեստում, օրինակ, դուք չեք ստուգում այն տեսակետից, որ աշխուժության թեստը, ընդհանուր առմամբ, պարզապես արձագանքող հավելված է, եթե այն ընդհանրապես կարող է արձագանքել։
Քանի որ աշխուժության թեստը, մեծ հաշվով, այն է, երբ մենք «խրված ենք»։ Սկսվել է անվերջ օղակ կամ այլ բան, և այլ հարցումներ չեն մշակվում: Հետևաբար, իմաստ ունի նույնիսկ տարանջատել դրանք, և նրանց մեջ իրականացնել այլ տրամաբանություն։
Ինչ վերաբերում է, թե ինչ պետք է պատասխանեք, երբ թեստ եք անում, երբ առողջական ստուգումներ եք անում։ Դա պարզապես իսկապես ցավ է: Նրանք, ովքեր ծանոթ են դրան, հավանաբար կծիծաղեն, բայց եթե լուրջ, ես իմ կյանքում տեսել եմ ծառայություններ, որոնք 200% դեպքերում պատասխանում են «XNUMX»: Այսինքն՝ ով է հաջողակ։ Բայց միևնույն ժամանակ պատասխանի մարմնում գրում են «այսքան սխալ»։
Այսինքն՝ պատասխանի կարգավիճակը գալիս է քեզ՝ ամեն ինչ հաջող է։ Բայց միևնույն ժամանակ, դուք պետք է վերլուծեք մարմինը, քանի որ մարմինն ասում է «ներողություն, հարցումն ավարտվեց սխալմամբ», և սա պարզապես իրականություն է: Ես սա տեսա իրական կյանքում:
Եվ որպեսզի ոմանց համար դա ծիծաղելի չհամարվի, իսկ ոմանց համար դա շատ ցավալի է, դեռ արժե պահպանել մի պարզ կանոն. Առողջության ստուգումների ժամանակ և սկզբունքորեն վեբ հավելվածների հետ աշխատելիս:
Եթե ամեն ինչ լավ է անցել, ապա պատասխանեք երկու հարյուրերորդ պատասխանով։ Սկզբունքորեն, ցանկացած երկու հարյուրերորդ պատասխանը կհամապատասխանի ձեզ: Եթե դուք շատ լավ եք կարդում կատաղած և գիտեք, որ պատասխանի որոշ ստատուսներ տարբերվում են մյուսներից, պատասխանեք համապատասխաններով՝ 204, 5, 10, 15, ինչ էլ լինի։ Եթե դա այնքան էլ լավ չէ, ապա պարզապես «երկու զրո զրո»: Եթե ամեն ինչ վատ է ընթանում, և առողջական ստուգումը չի արձագանքում, ապա պատասխանեք ցանկացած հինգ հարյուրերորդով: Կրկին, եթե հասկանում եք, թե ինչպես արձագանքել, թե ինչպես են տարբեր արձագանքման կարգավիճակները տարբերվում միմյանցից: Եթե դուք չեք հասկանում, ապա 502-ը ձեր տարբերակն է՝ արձագանքելու առողջության ստուգումներին, եթե ինչ-որ բան սխալ է:
Սա ևս մեկ կետ է, ես ուզում եմ մի փոքր անդրադառնալ հիմքում ընկած ծառայությունները ստուգելու մասին: Եթե դուք սկսեք, օրինակ, ստուգել ձեր դիմումի հետևում կանգնած բոլոր հիմքում ընկած ծառայությունները, ընդհանրապես ամեն ինչ: Այն, ինչ մենք ստանում ենք միկրոսպասարկման ճարտարապետության տեսանկյունից, մենք ունենք այնպիսի հասկացություն, ինչպիսին է «ցածր զուգավորումը», այսինքն, երբ ձեր ծառայությունները նվազագույն կախված են միմյանցից: Եթե դրանցից մեկը ձախողվի, բոլոր մյուսներն առանց այս ֆունկցիոնալության պարզապես կշարունակեն աշխատել: Որոշ գործառույթներ պարզապես չեն աշխատում: Համապատասխանաբար, եթե դուք կապեք բոլոր առողջապահական ստուգումները միմյանց հետ, ապա դուք կհանգեցնեք այն բանին, որ ենթակառուցվածքում մեկ բան է ընկնում, և քանի որ այն ընկել է, բոլոր ծառայությունների առողջապահական ստուգումները նույնպես սկսում են ձախողվել, և ընդհանուր առմամբ ավելի շատ ենթակառուցվածքներ կան: ամբողջ միկրոսպասարկման ճարտարապետություն No. Այնտեղ ամեն ինչ մթնեց։
Հետևաբար, ես ուզում եմ նորից կրկնել, որ դուք պետք է ստուգեք հիմքում ընկած ծառայությունները, առանց որոնց ձեր դիմումը հարյուր տոկոս դեպքերում չի կարող կատարել իր աշխատանքը: Այսինքն՝ տրամաբանական է, որ եթե ունես REST API, որի միջոցով օգտատերը պահում է տվյալների շտեմարան կամ առբերում է տվյալների բազայից, ապա տվյալների բազայի բացակայության դեպքում չես կարող երաշխավորել քո օգտատերերի հետ աշխատանքը։
Բայց եթե ձեր օգտատերերը, երբ դրանք հանում եք տվյալների շտեմարանից, լրացուցիչ հարստացված են որոշ այլ մետատվյալներով՝ մեկ այլ հետնամասից, որը մուտքագրում եք նախքան պատասխանն ուղարկելը ճակատին, և այս հետնամասը հասանելի չէ, դա նշանակում է, որ դուք տալիս եք ձեր պատասխանել առանց մետատվյալների որևէ մասի:
Հաջորդը, մենք ունենք նաև հավելվածներ գործարկելիս ցավոտ խնդիրներից մեկը։
Իրականում, դա մեծ հաշվով վերաբերում է ոչ միայն Kubernetes-ին, այնպես է պատահել, որ ինչ-որ զանգվածային զարգացման մշակույթը և մասնավորապես DevOps-ը սկսեց տարածվել Kubernetes-ի հետ նույն ժամանակաշրջանում: Հետևաբար, մեծ հաշվով, պարզվում է, որ դուք պետք է նրբորեն փակեք ձեր հավելվածը առանց Kubernetes-ի: Նույնիսկ Կուբերնետեսից առաջ մարդիկ դա անում էին, բայց Կուբերնետեսի գալուստով մենք սկսեցինք զանգվածաբար խոսել այդ մասին:
Նրբագեղ անջատում
Ընդհանուր առմամբ, ի՞նչ է Graceful Shutdown-ը և ինչո՞ւ է դա անհրաժեշտ: Սա այն մասին է, երբ ձեր հավելվածը ինչ-ինչ պատճառներով խափանում է, դուք պետք է անեք app stop - կամ դուք ստանում եք, օրինակ, ազդանշան օպերացիոն համակարգից, ձեր հավելվածը պետք է հասկանա դա և ինչ-որ բան անի դրա դեմ: Ամենավատ սցենարը, իհարկե, այն է, երբ ձեր դիմումը ստանում է SIGTERM և նման է «SIGTERM, եկեք կախված լինենք, աշխատենք, ոչինչ չանենք»: Սա միանգամայն վատ տարբերակ է:
Գրեթե նույնքան վատ տարբերակն այն է, երբ ձեր հավելվածը ստանում է SIGTERM և նման է «նրանք ասացին segterm, դա նշանակում է, որ մենք ավարտում ենք, ես չեմ տեսել, ես չգիտեմ օգտվողների հարցումներ, չգիտեմ ինչ տեսակի հարցումները, որոնց վրա ես աշխատում եմ հենց հիմա, նրանք ասացին SIGTERM, դա նշանակում է, որ մենք ավարտում ենք»: Սա նույնպես վատ տարբերակ է։
Ո՞ր տարբերակն է լավը: Առաջին կետը պետք է հաշվի առնել գործողությունների ավարտը: Լավ տարբերակն այն է, որ ձեր սերվերը դեռ հաշվի առնի, թե ինչ է անում, եթե ստանա SIGTERM:
SIGTERM-ը փափուկ անջատում է, հատուկ նախագծված է, կոդի մակարդակով կարելի է գաղտնալսել, մշակել, ասա հիմա, սպասիր, սկզբում մեր ունեցած գործը կավարտենք, հետո դուրս կգանք։
Կուբերնետեսի տեսանկյունից սա այն տեսքն ունի. Երբ մենք ասում ենք մի pod, որն աշխատում է Kubernetes կլաստերում, «խնդրում եմ կանգ առ, հեռացիր», կամ մենք վերագործարկվում ենք, կամ թարմացում է տեղի ունենում, երբ Kubernetes-ը վերստեղծում է պատյանները, Kubernetes-ը նույն SIGTERM հաղորդագրությունն է ուղարկում պատիճ, սպասում է. որոշ ժամանակ, և, սա այն ժամանակն է, որ նա սպասում է, այն նաև կազմաձևված է, դիպլոմների մեջ կա այդպիսի հատուկ պարամետր և այն կոչվում է Graceful ShutdownTimeout: Ինչպես հասկանում եք, դա իզուր չի կոչվում, և իզուր չէ, որ մենք հիմա խոսում ենք դրա մասին:
Այնտեղ մենք կարող ենք կոնկրետ ասել, թե որքան ժամանակ է պետք սպասել SIGTERM հավելվածին ուղարկելու ժամանակի և երբ մենք հասկանում ենք, որ հավելվածը կարծես խելագարվել է ինչ-որ բանի համար կամ «խրված է» և չի ավարտվելու, և մենք պետք է ուղարկիր այն SIGKILL, այսինքն՝ ծանր ավարտիր նրա աշխատանքը: Այսինքն, համապատասխանաբար, մենք ունենք ինչ-որ դեյմոն, որն աշխատում է, այն մշակում է գործողություններ: Մենք հասկանում ենք, որ միջին հաշվով մեր գործողությունները, որոնց վրա աշխատում է դեյմոնը, միաժամանակ չեն տևում ավելի քան 30 վայրկյան: Համապատասխանաբար, երբ SIGTERM-ը ժամանում է, մենք հասկանում ենք, որ մեր դեյմոնը կարող է առավելագույնը ավարտել SIGTERM-ից 30 վայրկյան հետո: Գրում ենք, օրինակ, 45 վայրկյան ամեն դեպքում ու ասում, որ SIGTERM. Դրանից հետո սպասում ենք 45 վայրկյան։ Տեսականորեն այս ընթացքում դևը պետք է ավարտեր իր աշխատանքը և ավարտեր ինքն իրեն։ Բայց եթե հանկարծ այն չկարողանա, դա նշանակում է, որ այն ամենայն հավանականությամբ խրված է. այն այլևս նորմալ չի մշակում մեր հարցումները: Եվ 45 վայրկյանում դուք կարող եք ապահով կերպով, փաստորեն, գամել նրան:
Եվ այստեղ, ըստ էության, կարելի է հաշվի առնել նույնիսկ 2 ասպեկտ. Նախ, հասկացեք, որ եթե հարցում եք ստացել, ինչ-որ կերպ սկսել եք աշխատել դրա հետ և չեք պատասխանել օգտատիրոջը, բայց ստացել եք, օրինակ, SIGTERM: Իմաստ ունի այն կատարելագործել ու պատասխան տալ օգտատիրոջը։ Սա թիվ մեկ կետն է այս առումով։ Այստեղ թիվ երկու կետն այն է, որ եթե դուք գրում եք ձեր սեփական հավելվածը, ընդհանուր առմամբ կառուցում եք ճարտարապետությունը այնպես, որ դուք ստանում եք ձեր հավելվածի հարցումը, ապա սկսում եք ինչ-որ աշխատանք, սկսում եք ինչ-որ տեղից ֆայլեր ներբեռնել, տվյալների բազա ներբեռնել և այլն: Դա. Ընդհանուր առմամբ, ձեր օգտատերը, ձեր հարցումը կախված է կես ժամ և սպասում է, որ դուք պատասխանեք նրան, ապա, ամենայն հավանականությամբ, դուք պետք է աշխատեք ճարտարապետության վրա: Այսինքն, պարզապես հաշվի առեք նույնիսկ ողջախոհությունը, որ եթե ձեր գործողությունները կարճ են, ապա իմաստ ունի անտեսել SIGTERM-ը և փոփոխել այն: Եթե ձեր գործողությունները երկար են, ապա այս դեպքում իմաստ չունի անտեսել SIGTERM-ը: Նման երկար գործողություններից խուսափելու համար իմաստ ունի վերանախագծել ճարտարապետությունը: Որպեսզի օգտվողները պարզապես չշփվեն և չսպասեն: Չգիտեմ, այնտեղ ինչ-որ վեբսոկետ պատրաստեք, դարձրեք հակադարձ կեռիկներ, որոնք ձեր սերվերն արդեն կուղարկի հաճախորդին, որևէ այլ բան, բայց մի ստիպեք օգտագործողին կես ժամ կախել և պարզապես սպասել մի նիստի, մինչև դուք պատասխանիր նրան. Որովհետև անկանխատեսելի է, թե որտեղ կարող է կոտրվել:
Երբ ձեր դիմումը դադարեցվի, դուք պետք է տրամադրեք համապատասխան ելքի կոդ: Այսինքն, եթե ձեր դիմումին խնդրել են փակել, դադարեցնել, և այն կարողացել է նորմալ դադարեցնել ինքն իրեն, ապա ձեզ հարկավոր չէ վերադարձնել ինչ-որ ելքի կոդը 1,5,255 և այլն: Ցանկացած բան, որը զրոյական կոդ չէ, համենայն դեպս, Linux համակարգերում, համոզված եմ, համարվում է անհաջող։ Այսինքն՝ համարվում է, որ Ձեր դիմումն այս դեպքում ավարտվել է սխալմամբ։ Համապատասխանաբար, բարեկամական եղանակով, եթե ձեր դիմումը ավարտվել է առանց սխալի, դուք ասում եք 0 արդյունքի վրա: Եթե ձեր դիմումը ինչ-ինչ պատճառներով ձախողվում է, դուք ելքում ասում եք ոչ 0: Եվ դուք կարող եք աշխատել այս տեղեկատվության հետ:
Եվ վերջին տարբերակը. Վատ է, երբ ձեր օգտատերը հարցում է ուղարկում և կես ժամ կախված է այն մշակելիս: Բայց ընդհանուր առմամբ, ես կցանկանայի նաև ասել, թե ինչն է ընդհանուր առմամբ արժե հաճախորդի կողմից: Կարևոր չէ՝ ունեք բջջային հավելված, ֆրոնտ և այլն։ Պետք է հաշվի առնել, որ ընդհանուր առմամբ օգտագործողի նիստը կարող է դադարեցվել, ամեն ինչ կարող է պատահել։ Հարցումը կարող է ուղարկվել, օրինակ՝ թերմշակված և պատասխան չվերադարձվել: Ձեր ֆրոնդենդը կամ ձեր բջջային հավելվածը՝ ընդհանրապես ցանկացած ճակատային մաս, այսպես ասած, պետք է հաշվի առնի դա: Եթե դուք աշխատում եք վեբ-սոկետների հետ, սա ընդհանուր առմամբ իմ երբևէ ունեցած ամենավատ ցավն է:
Երբ որոշ սովորական չաթերի մշակողները չգիտեն, որ, պարզվում է, վեբսոկետը կարող է կոտրվել: Նրանց համար, երբ ինչ-որ բան տեղի է ունենում վստահված անձի մոտ, մենք պարզապես փոխում ենք կոնֆիգուրգը, և այն վերաբեռնում է: Բնականաբար, բոլոր երկարակյաց սեանսներն այս դեպքում պատռված են։ Մշակողները վազում են մեզ մոտ և ասում. «Տղե՛րք, ի՞նչ եք անում, չաթը խափանվել է մեր բոլոր հաճախորդների համար»: Մենք նրանց ասում ենք. «Ի՞նչ եք անում: Ձեր հաճախորդները չեն կարողանում նորից միանալ: Ասում են՝ ոչ, մեզ պետք է, որ նիստերը չպատռվեն։ Մի խոսքով, սա իրականում անհեթեթություն է։ Հաճախորդի կողմը պետք է հաշվի առնել: Հատկապես, ինչպես ասում եմ, երկարատև սեանսների դեպքում, ինչպիսիք են վեբսոկետները, այն կարող է կոտրվել և, աննկատ օգտագործողի կողմից, դուք պետք է կարողանաք նորից տեղադրել նման նիստերը: Եվ հետո ամեն ինչ կատարյալ է:
Ресурсы
Իրականում, այստեղ ես ձեզ ուղղակի մի պատմություն կպատմեմ. Կրկին իրական կյանքից։ Ամենահիվանդագին բանը, որ ես երբևէ լսել եմ ռեսուրսների մասին:
Ռեսուրսներ այս դեպքում, ես նկատի ունեմ, ինչ-որ հարցումներ, սահմանափակումներ, որոնք դուք կարող եք տեղադրել ձեր Kubernetes կլաստերներում պատյանների վրա: Ամենազվարճալի բանը, որ ես լսել եմ ծրագրավորողից... Նախորդ աշխատավայրում իմ գործընկեր ծրագրավորողներից մեկը մի անգամ ասաց. «Իմ հավելվածը չի սկսվի կլաստերում»: Ես նայեցի, որ տեսնեմ, որ այն չի սկսվում, բայց կամ այն չի տեղավորվում ռեսուրսների մեջ, կամ նրանք շատ փոքր սահմաններ են դրել: Մի խոսքով, հավելվածը չի կարող սկսել ռեսուրսների պատճառով։ Ես ասում եմ. «Դա չի սկսվի ռեսուրսների պատճառով, դուք որոշեք, թե որքան պետք է ձեզ և սահմանեք համապատասխան արժեք»: Ասում է՝ ի՞նչ ռեսուրսներ։ Ես սկսեցի բացատրել նրան, որ Kubernetes, խնդրանքների և բլա, բլա, բլա սահմաններ պետք է սահմանվեն: Մարդը լսեց հինգ րոպե, գլխով արեց և ասաց. Ես եկել եմ այստեղ կոդ գրելու և վերջ»։ Տխուր է. Սա շատ տխուր հայեցակարգ է մշակողի տեսանկյունից: Հատկապես ժամանակակից, այսպես ասած, առաջադեմ դևոպների աշխարհում։
Ինչու՞ են ընդհանրապես անհրաժեշտ ռեսուրսները: Kubernetes-ում կա 2 տեսակի ռեսուրս. Ոմանք կոչվում են հարցումներ, մյուսները՝ սահմաններ: Ռեսուրսներով մենք կհասկանանք, որ հիմնականում միշտ գոյություն ունեն միայն երկու հիմնական սահմանափակումներ. Այսինքն՝ պրոցեսորի ժամանակի և RAM-ի սահմանափակում Kubernetes-ում աշխատող կոնտեյների համար։
Սահմանաչափը վերին սահման է դնում, թե ինչպես կարելի է ռեսուրսը օգտագործել ձեր հավելվածում: Այսինքն՝ համապատասխանաբար, եթե սահմաններում ասեք 1ԳԲ օպերատիվ հիշողություն, ապա ձեր հավելվածը չի կարողանա օգտագործել 1ԳԲ-ից ավելի օպերատիվ հիշողություն։ Եվ եթե նա հանկարծ ցանկանա և փորձի դա անել, ապա մի գործընթաց, որը կոչվում է oom killer, հիշողությունից դուրս, այսինքն, կգա և կսպանի ձեր դիմումը, այսինքն, այն պարզապես կվերսկսվի: Ծրագրերը չեն վերագործարկվի պրոցեսորի հիման վրա: Պրոցեսորի առումով, եթե հավելվածը փորձի շատ բան օգտագործել, ավելին, քան նշված է սահմաններում, ապա պրոցեսորը պարզապես խստորեն կընտրվի: Սա չի հանգեցնում վերագործարկման: Սա սահմանն է - սա վերին սահմանն է:
Եվ կա խնդրանք. Հարցումն այն է, թե ինչպես Kubernetes-ը հասկանում է, թե ինչպես են ձեր Kubernetes կլաստերի հանգույցները համալրված հավելվածներով: Այսինքն՝ խնդրանքը ձեր դիմումի մի տեսակ պարտավորություն է։ Այն ասում է, թե ինչ եմ ուզում օգտագործել. «Ես կցանկանայի, որ դուք այսքան պրոցեսոր և այսքան հիշողություն պահեք ինձ համար»: Նման պարզ անալոգիա. Իսկ եթե մենք ունենք հանգույց, որն ունի, չգիտեմ, ընդհանուր առմամբ 8 պրոցեսոր: Եվ այնտեղ հասնում է մի pod, որի հարցումներն ասում են՝ 1 CPU, ինչը նշանակում է, որ հանգույցին մնացել է 7 CPU: Այսինքն, համապատասխանաբար, հենց որ այս հանգույցը ժամանում է 8 պատիճ, որոնցից յուրաքանչյուրն ունի 1 պրոցեսոր իր հարցումներում, հանգույցը, կարծես Kubernetes-ի տեսանկյունից, սպառվել է պրոցեսորով, և ավելի շատ պոդեր հարցումներով չեն կարող լինել: գործարկվել է այս հանգույցի վրա: Եթե բոլոր հանգույցները սպառվում են պրոցեսորով, ապա Kubernetes-ը կսկսի ասել, որ կլաստերում չկան համապատասխան հանգույցներ՝ ձեր բլոկները գործարկելու համար, քանի որ պրոցեսորը սպառվել է:
Ինչու՞ են անհրաժեշտ հարցումները և ինչու առանց հարցումների, կարծում եմ, կարիք չկա որևէ բան գործարկել Kubernetes-ում: Պատկերացնենք հիպոթետիկ իրավիճակ. Դուք գործարկում եք ձեր հավելվածն առանց հարցումների, Kubernetes-ը չգիտի, թե ձեր ունեցածից որքան է, ինչ հանգույցներ կարող եք մղել այն: Դե, նա հրում է, հրում, հրում է հանգույցների վրա: Ինչ-որ պահի դուք կսկսեք երթևեկություն ստանալ դեպի ձեր հավելվածը: Եվ հավելվածներից մեկը հանկարծ սկսում է ռեսուրսներ օգտագործել մինչև այն սահմանները, որոնք ունի ըստ սահմանների։ Պարզվում է, որ մոտակայքում կա մեկ այլ հավելված և այն նույնպես ռեսուրսների կարիք ունի։ Հանգույցը փաստացի սկսում է ֆիզիկապես սպառվել ռեսուրսներից, օրինակ՝ OP: Հանգույցն իրականում սկսում է ֆիզիկապես սպառվել ռեսուրսներից, օրինակ՝ պատահական մուտքի հիշողությունից (RAM): Երբ հանգույցը սպառվում է, առաջին հերթին կդադարի արձագանքել docker-ը, ապա cubelet-ը, ապա OS-ն: Նրանք պարզապես անգիտակից կլինեն, և ԱՄԵՆ ԻՆՉ հաստատ կդադարի աշխատել ձեզ մոտ։ Այսինքն, դա կհանգեցնի նրան, որ ձեր հանգույցը կխրվի, և դուք պետք է այն վերագործարկեք: Մի խոսքով, վիճակն այնքան էլ լավ չէ։
Եվ երբ դուք ունեք հարցումներ, սահմանները շատ տարբեր չեն, համենայն դեպս, ոչ մի քանի անգամ ավելի, քան սահմանափակումները կամ խնդրանքները, ապա դուք կարող եք ունենալ նման նորմալ, ռացիոնալ դիմումների լրացում Kubernetes կլաստերների հանգույցներում: Միևնույն ժամանակ, Kubernetes-ը մոտավորապես տեղյակ է, թե ինչից ինչքան տեղ է դնում, ինչից որտեղ է օգտագործվում։ Այսինքն՝ հենց այդպիսի պահ է։ Կարևոր է հասկանալ դա։ Եվ կարևոր է վերահսկել, որ դա մատնանշվի։
Տվյալների պահպանում
Մեր հաջորդ կետը տվյալների պահպանման մասին է: Ի՞նչ անել նրանց հետ և ընդհանրապես, ի՞նչ անել համառության հետ Կուբերնետեսում:
Կարծում եմ, կրկին մեր ներսում , Kubernetes-ում շտեմարանի մասին թեմա կար։ Եվ ինձ թվում է, որ ես նույնիսկ մոտավորապես գիտեմ, թե ինչ են ասել քո գործընկերները, երբ հարցրել են. «Հնարավո՞ր է տվյալների բազա գործարկել Kubernetes-ում»: Չգիտես ինչու, ինձ թվում է, որ ձեր գործընկերները պետք է ասեին ձեզ, որ եթե դուք հարց եք տալիս, թե արդյոք հնարավոր է տվյալների բազա գործարկել Kubernetes-ում, ապա դա անհնար է:
Այստեղ տրամաբանությունը պարզ է. Ամեն դեպքում, ես ևս մեկ անգամ կբացատրեմ, եթե դուք իսկապես հիանալի տղա եք, ով կարող է կառուցել բաշխված ցանցային պահեստավորման բավականին սխալ հանդուրժող համակարգ, հասկացեք, թե ինչպես կարելի է տվյալների բազան տեղավորել այս դեպքում, ինչպես պետք է աշխատի կոնտեյներներում ամպային բնիկ: ընդհանուր առմամբ տվյալների բազայում: Ամենայն հավանականությամբ, դուք հարց չունեք, թե ինչպես վարել այն: Եթե դուք ունեք նման հարց, և ցանկանում եք համոզվել, որ այդ ամենը բացվում է և կանգնում է արտադրության մեջ և երբեք չի ընկնում, ապա դա տեղի չի ունենում: Այս մոտեցմամբ դուք երաշխավորված եք կրակելու ձեր ոտքին: Այնպես որ, ավելի լավ է չանել:
Ի՞նչ պետք է անենք այն տվյալների հետ, որոնք մեր հավելվածը կցանկանար պահել, որոշ նկարներ, որոնք օգտատերերը վերբեռնում են, որոշ բաներ, որոնք մեր հավելվածը ստեղծում է իր գործունեության ընթացքում, օրինակ՝ գործարկման ժամանակ: Ի՞նչ անել նրանց հետ Kubernetes-ում:
Ընդհանուր առմամբ, իդեալականորեն, այո, իհարկե, Kubernetes-ը շատ լավ նախագծված է և, ընդհանուր առմամբ, ի սկզբանե ստեղծվել է քաղաքացիություն չունեցող հավելվածների համար: Այսինքն՝ այն հավելվածների համար, որոնք ընդհանրապես տեղեկատվություն չեն պահում։ Սա իդեալական է:
Բայց, իհարկե, իդեալական տարբերակը միշտ չէ, որ գոյություն ունի։ Եւ ինչ? Առաջին և ամենապարզ կետը մի տեսակ S3 վերցնելն է, պարզապես ոչ թե տնական, որը նույնպես անհասկանալի է, թե ինչպես է այն աշխատում, այլ ինչ-որ մատակարարից: Լավ, նորմալ մատակարար և սովորեցրեք ձեր հավելվածին օգտագործել S3: Այսինքն, երբ ձեր օգտվողը ցանկանում է վերբեռնել ֆայլ, ասեք «այստեղ, խնդրում եմ, վերբեռնեք այն S3»: Երբ նա ցանկանում է ստանալ այն, ասեք. «Ահա մի հղում դեպի S3 և վերցրեք այն այստեղից»: Սա իդեալական է:
Եթե հանկարծ ինչ-ինչ պատճառներով այս իդեալական տարբերակը հարմար չէ, դուք ունեք ծրագիր, որը դուք չեք գրել, չեք մշակել, կամ դա ինչ-որ սարսափելի ժառանգություն է, այն չի կարող օգտագործել S3 արձանագրությունը, բայց պետք է աշխատի տեղական դիրեկտորիաների հետ: տեղական թղթապանակներ. Վերցրեք մի քիչ թե շատ պարզ բան, տեղակայեք Kubernetes-ը: Այսինքն՝ Սեֆին անմիջապես ցանկապատել ինչ-որ մինիմալ առաջադրանքների համար, ինձ թվում է, վատ գաղափար է։ Որովհետև Սեֆը, իհարկե, լավն է և մոդայիկ։ Բայց եթե դուք իսկապես չեք հասկանում, թե ինչ եք անում, ապա երբ ինչ-որ բան դնեք Ceph-ի վրա, կարող եք շատ հեշտությամբ և այլևս երբեք այն դուրս չգալ այնտեղից: Քանի որ, ինչպես գիտեք, Ceph-ը տվյալները պահպանում է իր կլաստերում երկուական ձևով, և ոչ թե պարզ ֆայլերի տեսքով: Հետևաբար, եթե հանկարծ Ceph կլաստերը փչանա, ապա կա ամբողջական և մեծ հավանականություն, որ դուք այլևս այնտեղից չեք ստանա ձեր տվյալները։
Մենք դասընթաց կունենանք Ceph-ի վերաբերյալ, դուք կարող եք .
Հետևաբար, ավելի լավ է անել մի պարզ բան, ինչպիսին է NFS սերվերը: Kubernetes-ը կարող է աշխատել նրանց հետ, դուք կարող եք տեղադրել գրացուցակ NFS սերվերի տակ. ձեր հավելվածը նման է տեղական գրացուցակի: Միևնույն ժամանակ, բնականաբար, դուք պետք է հասկանաք, որ նորից պետք է ինչ-որ բան անեք ձեր NFS-ի հետ, պետք է հասկանաք, որ երբեմն այն կարող է անհասանելի դառնալ և հաշվի առնել այն հարցը, թե ինչ եք անելու այս դեպքում: Հավանաբար, այն պետք է ինչ-որ տեղ պահուստավորվի առանձին մեքենայի վրա:
Հաջորդ կետը, որի մասին ես խոսեցի, այն է, թե ինչ անել, եթե ձեր հավելվածը որոշ ֆայլեր գեներացնի շահագործման ընթացքում: Օրինակ, երբ այն սկսվում է, այն առաջացնում է որոշակի ստատիկ ֆայլ, որը հիմնված է որոշ տեղեկատվության վրա, որը հավելվածը ստանում է միայն գործարկման պահին: Ինչպիսի՜ պահ։ Եթե նման շատ տվյալներ չկան, ապա ընդհանրապես պետք չէ անհանգստանալ, պարզապես տեղադրեք այս հավելվածը ձեզ համար և աշխատեք: Այստեղ միայն հարցն այն է, թե ինչ, տեսեք։ Շատ հաճախ, բոլոր տեսակի ժառանգական համակարգերը, ինչպիսիք են WordPress-ը և այլն, հատկապես փոփոխված ինչ-որ խելացի պլագինների, խելացի PHP մշակողների հետ, նրանք հաճախ գիտեն, թե ինչպես դա անել այնպես, որ իրենք իրենց համար ինչ-որ ֆայլ ստեղծեն: Համապատասխանաբար, մեկը ստեղծում է մեկ ֆայլ, երկրորդը ստեղծում է երկրորդ ֆայլ: Նրանք տարբեր են: Հավասարակշռումը տեղի է ունենում հաճախորդների Kubernetes կլաստերում պարզապես պատահաբար: Ըստ այդմ, պարզվում է, որ նրանք չգիտեն, թե ինչպես օրինակ աշխատել միասին։ Մեկը տալիս է մի տեղեկություն, մյուսը՝ օգտատիրոջը մեկ այլ տեղեկություն։ Սա այն է, ինչ դուք պետք է խուսափեք: Այսինքն, Kubernetes-ում այն ամենը, ինչ դուք գործարկում եք, երաշխավորված է, որ կարող է աշխատել մի քանի օրինակներում: Քանի որ Kubernetes-ը շարժվող բան է: Համապատասխանաբար, նա կարող է ցանկացած բան տեղափոխել, երբ ցանկանա, առանց որևէ մեկին հարցնելու։ Հետևաբար, դուք պետք է հույս դրեք դրա վրա: Մեկ օրինակով մեկնարկած ամեն ինչ վաղ թե ուշ ձախողվելու է։ Որքան շատ վերապահումներ ունենաք, այնքան լավ: Բայց էլի եմ ասում, եթե ունես մի քանի նման ֆայլեր, ուրեմն կարող ես հենց տակդ դնել, քիչ են կշռում։ Եթե դրանցից մի փոքր ավելի շատ են, հավանաբար չպետք է դրանք մղել տարայի ներս:
Խորհուրդ կտամ, որ Կուբերնետեսում նման հրաշալի բան կա, կարող ես օգտագործել ծավալը։ Մասնավորապես, կա մի հատոր տիպի դատարկ ռեժ. Այսինքն, պարզապես Kubernetes-ը ավտոմատ կերպով տեղեկատու կստեղծի իր ծառայության դիրեկտորիաներում այն սերվերի վրա, որտեղ դուք սկսել եք: Եվ նա կտա այն ձեզ, որպեսզի դուք կարողանաք օգտագործել այն: Միայն մեկ կարևոր կետ կա. Այսինքն՝ ձեր տվյալները չեն պահվի կոնտեյների ներսում, այլ այն հոսթի վրա, որի վրա դուք աշխատում եք: Ավելին, Kubernetes-ը կարող է կառավարել նման դատարկ դիրիժորները նորմալ կոնֆիգուրացիայի դեպքում և կարողանում է վերահսկել դրանց առավելագույն չափերը և թույլ չտալ, որ դրանք գերազանցեն: Միակ կետն այն է, որ գրածդ դատարկ դիրով չի կորչում pod restart-ների ժամանակ։ Այսինքն, եթե ձեր պատիճը սխալմամբ ընկնի և նորից բարձրանա, դատարկ գրառման տեղեկատվությունը ոչ մի տեղ չի գնա: Նա կարող է նորից օգտագործել այն նոր սկզբում, և դա լավ է: Եթե ձեր պատիճը հեռանում է ինչ-որ տեղ, ապա բնականաբար նա կհեռանա առանց տվյալների: Այսինքն, հենց որ այն հանգույցից, որտեղ այն գործարկվել է դատարկ դիրով, պատը անհետանում է, դատարկ dir-ը ջնջվում է:
Էլ ի՞նչ լավ է դատարկ ռեժը: Օրինակ, այն կարող է օգտագործվել որպես քեշ: Եկեք պատկերացնենք, որ մեր հավելվածը անմիջապես ինչ-որ բան է գեներացնում, տալիս է օգտատերերին և դա անում է երկար ժամանակ: Հետևաբար, հավելվածը, օրինակ, գեներացնում և տալիս է օգտատերերին, և միևնույն ժամանակ այն պահում է ինչ-որ տեղ, որպեսզի հաջորդ անգամ, երբ օգտատերը գա նույն բանի համար, ավելի արագ լինի այն անմիջապես գեներացված տալը։ Դատարկ dir-ը կարող է պահանջվել Kubernetes-ին հիշողության մեջ ստեղծելու համար: Եվ այսպիսով, ձեր քեշերը կարող են ընդհանուր առմամբ աշխատել կայծակնային արագությամբ՝ սկավառակի մուտքի արագության առումով: Այսինքն, դուք ունեք դատարկ dir հիշողության մեջ, ՕՀ-ում այն պահվում է հիշողության մեջ, բայց ձեզ համար, պոդի ներսում գտնվող օգտագործողի համար, այն կարծես թե պարզապես տեղային գրացուցակ լինի: Հավելվածի կարիքը չունեք հատուկ մոգություն սովորեցնելու համար: Դուք ուղղակիորեն վերցնում և տեղադրում եք ձեր ֆայլը գրացուցակում, բայց, ըստ էության, ՕՀ-ի հիշողության մեջ: Սա նույնպես շատ հարմար հատկություն է Kubernetes-ի առումով։
Ի՞նչ խնդիրներ ունի Minio-ն: Minio-ի հիմնական խնդիրն այն է, որ այս բանն աշխատելու համար այն պետք է ինչ-որ տեղ գործարկվի, և պետք է լինի ինչ-որ ֆայլային համակարգ, այսինքն՝ պահեստավորում: Եվ այստեղ մենք բախվում ենք նույն խնդիրների հետ, որոնք ունի Ceph. Այսինքն՝ Minio-ն պետք է իր ֆայլերը մի տեղ պահի։ Դա պարզապես HTTP ինտերֆեյս է ձեր ֆայլերի համար: Ավելին, ֆունկցիոնալությունը ակնհայտորեն ավելի վատ է, քան Amazon-ի S3-ը: Նախկինում այն չէր կարող պատշաճ կերպով լիազորել օգտատիրոջը: Հիմա, որքան գիտեմ, արդեն կարող է տարբեր լիազորություններով դույլեր ստեղծել, բայց նորից ինձ թվում է, որ հիմնական խնդիրը, այսպես ասած, նվազագույնը հիմքում ընկած պահեստային համակարգն է։
Ինչպե՞ս է հիշողության մեջ դատարկ գրությունը ազդում սահմանների վրա: Որևէ կերպ չի ազդում սահմանների վրա: Այն կայանում է տանտիրոջ հիշողության մեջ, և ոչ թե ձեր կոնտեյների հիշողության մեջ: Այսինքն, ձեր կոնտեյները չի տեսնում հիշողության մեջ դատարկ դիրը որպես իր զբաղեցրած հիշողության մաս: Հաղորդավարը սա տեսնում է. Համապատասխանաբար, այո, kubernetes-ի տեսանկյունից, երբ սկսես օգտագործել սա, լավ կլինի հասկանալ, որ հիշողությանդ մի մասը նվիրում ես դատարկ ռեժին։ Եվ համապատասխանաբար, հասկացեք, որ հիշողությունը կարող է սպառվել ոչ միայն հավելվածների պատճառով, այլ նաև այն պատճառով, որ ինչ-որ մեկը գրում է այս դատարկ դիրեկտորներին:
Ամպամածություն
Իսկ վերջնական ենթաթեման այն է, թե ինչ է Cloudnative-ը: Ինչու է դա անհրաժեշտ: Ամպամածություն և այլն:
Այսինքն՝ այն հավելվածները, որոնք ընդունակ են և գրված՝ ժամանակակից ամպային ենթակառուցվածքում աշխատելու համար։ Բայց, փաստորեն, Cloudnative-ն ունի մեկ այլ նման ասպեկտ. Որ սա ոչ միայն ծրագիր է, որը հաշվի է առնում ժամանակակից ամպային ենթակառուցվածքի բոլոր պահանջները, այլ նաև գիտի, թե ինչպես աշխատել այս ժամանակակից ամպային ենթակառուցվածքի հետ, օգտվել այս ամպերում աշխատելու առավելություններից և թերություններից: Պարզապես մի անցեք ծովը և աշխատեք ամպերի մեջ, այլ օգտվեք ամպում աշխատելու առավելություններից:
Եկեք միայն որպես օրինակ վերցնենք Kubernetes-ը: Ձեր հավելվածն աշխատում է Kubernetes-ում: Ձեր հավելվածը միշտ կարող է, ավելի ճիշտ՝ ձեր հավելվածի ադմինիստրատորները, միշտ կարող են ստեղծել ծառայության հաշիվ: Այսինքն՝ իր սերվերում հենց Kubernetes-ում թույլտվության հաշիվ: Այնտեղ ավելացրեք մեզ անհրաժեշտ մի քանի իրավունքներ: Եվ դուք կարող եք մուտք գործել Kubernetes ձեր հավելվածից: Ի՞նչ կարող ես անել այս կերպ: Օրինակ, հավելվածից ստացեք տվյալներ այն մասին, թե որտեղ են գտնվում ձեր մյուս հավելվածները, նմանատիպ այլ օրինակներ, և միասին ինչ-որ կերպ հավաքեք Kubernetes-ի վերևում, եթե այդպիսի անհրաժեշտություն կա:
Նորից բառացիորեն մի դեպք ունեցանք վերջերս։ Մենք ունենք մեկ վերահսկիչ, որը վերահսկում է հերթը: Եվ երբ որոշ նոր առաջադրանքներ հայտնվում են այս հերթում, այն գնում է Kubernetes - և Kubernetes-ի ներսում այն ստեղծում է նոր պատիճ: Այս pod-ին տալիս է մի նոր առաջադրանք և այս pod-ի շրջանակներում pod-ը կատարում է առաջադրանքը, պատասխան է ուղարկում հենց վերահսկիչին, և վերահսկիչն այնուհետև ինչ-որ բան անում է այս տեղեկատվության հետ: Օրինակ, այն ավելացնում է տվյալների բազա: Այսինքն, կրկին, սա պլյուս է այն փաստի, որ մեր հավելվածն աշխատում է Kubernetes-ում: Մենք կարող ենք օգտագործել ներկառուցված Kubernetes ֆունկցիոնալությունը՝ ինչ-որ կերպ ընդլայնելու և մեր հավելվածի ֆունկցիոնալությունը ավելի հարմար դարձնելու համար։ Այսինքն՝ մի թաքցրեք ինչ-որ կախարդանք, թե ինչպես գործարկել հավելվածը, ինչպես գործարկել աշխատողը։ Kubernetes-ում դուք պարզապես հարցում եք ուղարկում հավելվածում, եթե հավելվածը գրված է Python-ով:
Նույնը վերաբերում է, եթե մենք դուրս գանք Kubernetes-ից: Մենք ունենք մեր Kubernetes-ը ինչ-որ տեղ վազում, լավ է, եթե այն ինչ-որ ամպի մեջ է: Կրկին, մենք կարող ենք օգտագործել և նույնիսկ պետք է, կարծում եմ, օգտագործենք հենց ամպի հնարավորությունները, որտեղ մենք աշխատում ենք: Այն տարրական բաներից, որոնք մեզ տալիս է ամպը։ Բալանսավորում, այսինքն՝ մենք կարող ենք ստեղծել ամպային հավասարակշռողներ և օգտագործել դրանք։ Սա ուղղակի առավելություն է այն բանի, ինչ մենք կարող ենք օգտագործել: Քանի որ ամպի հավասարակշռումը, առաջին հերթին, պարզապես հիմարաբար վերացնում է պատասխանատվությունը այն բանի համար, թե ինչպես է այն աշխատում, ինչպես է այն կազմաձևվում: Բացի այդ, դա շատ հարմար է, քանի որ սովորական Kubernetes-ը կարող է ինտեգրվել ամպերի հետ:
Նույնը վերաբերում է մասշտաբին: Սովորական Kubernetes-ը կարող է ինտեգրվել ամպային մատակարարների հետ: Գիտի, թե ինչպես հասկանալ, որ եթե կլաստերին վերջանում են հանգույցները, այսինքն՝ հանգույցի տարածքը սպառվել է, ապա դուք պետք է ավելացնեք. Kubernetes-ն ինքը կավելացնի նոր հանգույցներ ձեր կլաստերին և կսկսի դրանց վրա փոդներ գործարկել: Այսինքն, երբ ձեր բեռը գալիս է, օջախների թիվը սկսում է շատանալ։ Երբ կլաստերի հանգույցները վերջանում են այս պատիճների համար, Kubernetes-ը գործարկում է նոր հանգույցներ, և, համապատասխանաբար, պատյանների թիվը դեռ կարող է աճել: Եվ դա շատ հարմար է: Սա ուղիղ հնարավորություն է կլաստերը թռիչքի ժամանակ մասշտաբավորելու համար: Ոչ շատ արագ, այն իմաստով, որ դա վայրկյան չէ, ավելի շատ նման է մեկ րոպեի՝ նոր հանգույցներ ավելացնելու համար:
Բայց իմ փորձից, կրկին, դա ամենաթեժ բանն է, որ երբևէ տեսել եմ: Երբ Cloudnative կլաստերը մասշտաբավորվեց օրվա ժամի հիման վրա: Դա backend ծառայություն էր, որն օգտագործվում էր հետին գրասենյակի մարդկանց կողմից: Այսինքն՝ նրանք աշխատանքի են գալիս առավոտյան ժամը 9-ին, սկսում են մուտք գործել համակարգ, և, համապատասխանաբար, Cloudnative կլաստերը, որտեղ ամեն ինչ աշխատում է, սկսում է ուռչել՝ գործարկելով նոր պատյաններ, որպեսզի աշխատանքի եկած բոլորը կարողանան աշխատել հավելվածի հետ: Երբ նրանք աշխատանքից հեռանում են երեկոյան 8-ին կամ 6-ին, Kubernetes կլաստերները նկատում են, որ ոչ ոք այլևս չի օգտագործում հավելվածը և սկսում են փոքրանալ: Մինչև 30 տոկոս խնայողություն երաշխավորված է: Այն ժամանակ այն աշխատում էր Ամազոնում, այն ժամանակ Ռուսաստանում չկար մեկը, ով կարողանար այդքան լավ անել։
Ես ձեզ ուղիղ կասեմ, որ խնայողությունները 30 տոկոս են, պարզապես այն պատճառով, որ մենք օգտագործում ենք Kubernetes-ը և օգտվում ենք ամպի հնարավորություններից: Հիմա դա կարելի է անել Ռուսաստանում։ Ես, իհարկե, ոչ մեկին չեմ գովազդի, բայց միայն ասենք, որ կան պրովայդերներ, ովքեր կարող են դա անել, տրամադրել այն անմիջապես կոճակով:
Կա մի վերջին կետ, որի վրա ես նույնպես կցանկանայի ձեր ուշադրությունը հրավիրել. Որպեսզի ձեր հավելվածը, ձեր ենթակառուցվածքը լինի Cloudnative, իմաստ ունի վերջապես սկսել ադապտացնել «Ենթակառուցվածքը որպես կոդ» կոչվող մոտեցումը։ Այսինքն՝ սա նշանակում է, որ ձեր հավելվածը, ավելի ճիշտ՝ ձեր ենթակառուցվածքը, անհրաժեշտ է ճիշտ այնպես, ինչպես կոդը Նկարագրեք ձեր դիմումը, ձեր բիզնեսի տրամաբանությունը կոդի տեսքով: Եվ աշխատեք դրա հետ որպես կոդ, այսինքն՝ փորձարկեք այն, գլորեք այն, պահեք այն git-ում, կիրառեք CICD դրա վրա։
Եվ դա հենց այն է, ինչը թույլ է տալիս, առաջին հերթին, միշտ վերահսկել ձեր ենթակառուցվածքը, միշտ հասկանալ, թե ինչ վիճակում է այն։ Երկրորդ, խուսափեք ձեռքով գործառնություններից, որոնք սխալներ են առաջացնում: Երրորդ, խուսափեք պարզապես այն, ինչ կոչվում է շրջանառություն, երբ դուք անընդհատ պետք է կատարեք նույն ձեռքով առաջադրանքները: Չորրորդ, այն թույլ է տալիս շատ ավելի արագ վերականգնել ձախողման դեպքում: Ռուսաստանում, ամեն անգամ, երբ ես խոսում եմ այս մասին, միշտ կա մեծ թվով մարդիկ, ովքեր ասում են. «Այո, պարզ է, բայց դուք մոտեցումներ ունեք, մի խոսքով, կարիք չկա որևէ բան ուղղելու»: Բայց դա ճիշտ է: Եթե ինչ-որ բան կոտրված է ձեր ենթակառուցվածքում, ապա Cloudnative մոտեցման տեսանկյունից և Ենթակառուցվածքը որպես կոդ, այլ ոչ թե այն շտկելու, գնալու սերվեր, պարզելու, թե ինչն է կոտրվել և ուղղել այն, ավելի հեշտ է: սերվերը ջնջելու և այն նորից ստեղծելու համար: Եվ ես այս ամենը կվերականգնեմ։
Այս բոլոր հարցերը ավելի մանրամասն քննարկվում են այստեղ . Հետևելով հղմանը կարող եք ծանոթանալ ծրագրին և պայմաններին։ Հարմարն այն է, որ Kubernetes-ին կարող ես տիրապետել՝ օրական 1-2 ժամ սովորելով տնից կամ աշխատավայրից։
Source: www.habr.com