Kubernetes-ը հիանալի գործիք է Docker կոնտեյներները կլաստերային արտադրական միջավայրում գործարկելու համար: Այնուամենայնիվ, կան խնդիրներ, որոնք Kubernetes-ը չի կարող լուծել։ Արտադրության հաճախակի տեղակայման համար մեզ անհրաժեշտ է լիովին ավտոմատացված Կապույտ/Կանաչ տեղակայում, որպեսզի խուսափենք գործընթացի խափանումներից, որը նաև պետք է կարգավորի արտաքին HTTP հարցումները և կատարի SSL բեռնաթափումներ: Սա պահանջում է ինտեգրում բեռի հավասարակշռող սարքի հետ, ինչպիսին է ha-proxy-ը: Մեկ այլ խնդիր է Kubernetes կլաստերի կիսաավտոմատ մասշտաբը, երբ աշխատում է ամպային միջավայրում, օրինակ՝ գիշերային ժամերին կլաստերի մասամբ փոքրացումը:
Թեև Kubernetes-ը չունի այս հնարավորությունները, այն տրամադրում է API, որը դուք կարող եք օգտագործել նմանատիպ խնդիրներ լուծելու համար: Գործիքներ ավտոմատացված Կապույտ/Կանաչ տեղակայման և Kubernetes կլաստերի մասշտաբավորման համար մշակվել են որպես Cloud RTI նախագծի մի մաս, որը ստեղծվել է բաց կոդով:
Այս հոդվածը՝ տեսագրությունը, ցույց է տալիս, թե ինչպես կարգավորել Kubernetes-ը բաց կոդով այլ բաղադրիչների հետ՝ ստեղծելու արտադրության համար պատրաստ միջավայր, որն ընդունում է կոդը git commit-ից՝ առանց արտադրության ժամանակի ընդհատման:
Այսպիսով, երբ արտաքին աշխարհից մուտք գործեք ձեր հավելվածները, կարող եք սկսել ամբողջությամբ կարգավորել ավտոմատացումը, այսինքն՝ այն հասցնել այն փուլին, որտեղ կարող եք կատարել git commit և համոզվել, որ այս git commit-ն ավարտվում է արտադրության մեջ: Բնականաբար, այս քայլերն իրականացնելիս, տեղակայումն իրականացնելիս մենք չենք ցանկանում հանդիպել պարապուրդի: Այսպիսով, Kubernetes-ում ցանկացած ավտոմատացում սկսվում է API-ից:
Kubernetes-ը գործիք չէ, որը կարող է արդյունավետորեն օգտագործվել տուփից դուրս: Իհարկե, դուք կարող եք դա անել, օգտագործել kubectl և այլն, բայց այնուամենայնիվ API-ն այս հարթակի ամենահետաքրքիրն ու օգտակարն է: Օգտագործելով API-ն որպես գործառույթների մի շարք, դուք կարող եք մուտք գործել գրեթե այն ամենը, ինչ ցանկանում եք անել Kubernetes-ում: Kubectl-ն ինքը նույնպես օգտագործում է REST API-ն:
Սա REST-ն է, այնպես որ դուք կարող եք օգտագործել ցանկացած լեզու կամ գործիք այս API-ի հետ աշխատելու համար, բայց ձեր կյանքը շատ ավելի կհեշտացվի հատուկ գրադարանների շնորհիվ: Իմ թիմը գրել է 2 այդպիսի գրադարան՝ մեկը Java/OSGi-ի և մեկը Go-ի համար: Երկրորդը հաճախ չի օգտագործվում, բայց ամեն դեպքում ձեր տրամադրության տակ կան այս օգտակար բաները։ Դրանք մասամբ լիցենզավորված բաց կոդով նախագիծ են: Կան բազմաթիվ նման գրադարաններ տարբեր լեզուների համար, այնպես որ կարող եք ընտրել ձեզ առավել հարմար գրադարանները:
Այսպիսով, նախքան ձեր տեղակայման ավտոմատացումը սկսելը, դուք պետք է համոզվեք, որ գործընթացը չի ենթարկվի որևէ խափանման: Օրինակ, մեր թիմը արտադրական տեղակայումներ է իրականացնում օրվա կեսին, երբ մարդիկ ամենաշատն են օգտագործում հավելվածները, ուստի կարևոր է խուսափել գործընթացի հետաձգումներից: Դատապարտումից խուսափելու համար օգտագործվում է 2 մեթոդ՝ կապույտ/կանաչ տեղակայում կամ շարժվող թարմացում։ Վերջին դեպքում, եթե դուք ունեք գործող հավելվածի 5 կրկնօրինակ, դրանք հաջորդաբար թարմացվում են մեկը մյուսի հետևից: Այս մեթոդը հիանալի է աշխատում, բայց այն հարմար չէ, եթե տեղակայման գործընթացում միաժամանակ գործում են հավելվածի տարբեր տարբերակներ: Այս դեպքում դուք կարող եք թարմացնել օգտատիրոջ միջերեսը, մինչ հետնախագիծն աշխատում է հին տարբերակով, և հավելվածը կդադարի աշխատել: Հետեւաբար, ծրագրավորման տեսանկյունից նման պայմաններում աշխատելը բավականին դժվար է։
Սա պատճառներից մեկն է, թե ինչու մենք նախընտրում ենք օգտագործել կապույտ/կանաչ տեղակայումը մեր հավելվածների տեղակայումն ավտոմատացնելու համար: Այս մեթոդով դուք պետք է ապահովեք, որ հավելվածի միայն մեկ տարբերակն ակտիվ է միաժամանակ:
Կապույտ/կանաչ տեղակայման մեխանիզմն այսպիսի տեսք ունի. Մենք մեր հավելվածների համար տրաֆիկ ենք ստանում ha-proxy-ի միջոցով, որն այն փոխանցում է նույն տարբերակի հավելվածի գործող կրկնօրինակներին:
Երբ նոր տեղակայում է կատարվում, մենք օգտագործում ենք Deployer-ը, որին տրվում են նոր բաղադրիչներ և տեղակայում է նոր տարբերակը: Հավելվածի նոր տարբերակի տեղակայումը նշանակում է, որ կրկնօրինակների նոր հավաքածու է «բարձրացվում», որից հետո նոր տարբերակի այս կրկնօրինակները գործարկվում են առանձին, նոր պատիճով: Այնուամենայնիվ, ha-proxy-ն ոչինչ չգիտի նրանց մասին և դեռևս որևէ ծանրաբեռնվածություն չի ուղղորդում նրանց:
Հետևաբար, առաջին հերթին անհրաժեշտ է կատարել առողջության ստուգման նոր տարբերակների կատարողականի ստուգում` համոզվելու համար, որ կրկնօրինակները պատրաստ են սպասարկելու բեռը:
Տեղակայման բոլոր բաղադրիչները պետք է ապահովեն առողջության ստուգման որևէ ձև: Սա կարող է լինել շատ պարզ HTTP զանգի ստուգում, երբ դուք ստանում եք կոդ 200 կարգավիճակով, կամ ավելի խորը ստուգում, որտեղ դուք ստուգում եք կրկնօրինակների կապը տվյալների բազայի և այլ ծառայությունների հետ, դինամիկ միջավայրի միացումների կայունությունը: , և արդյոք ամեն ինչ սկսվում և աշխատում է ճիշտ: Այս գործընթացը կարող է բավականին բարդ լինել:
Այն բանից հետո, երբ համակարգը կհաստատի, որ բոլոր թարմացված կրկնօրինակներն աշխատում են, Deployer-ը կթարմացնի կազմաձևը և կփոխանցի ճիշտ confd-ը, որը կվերակազմավորի ha-proxy-ը:
Միայն դրանից հետո երթևեկությունը կուղղվի դեպի նոր տարբերակի կրկնօրինակներով երթևեկությունը, և հին պատիճը կվերանա:
Այս մեխանիզմը Kubernetes-ի առանձնահատկությունը չէ։ Կապույտ/կանաչ տեղակայման հայեցակարգը գոյություն ունի բավականին երկար ժամանակ և այն միշտ օգտագործել է բեռի հավասարակշռող սարք: Նախ, դուք ամբողջ տրաֆիկը ուղղում եք հավելվածի հին տարբերակին, իսկ թարմացումից հետո այն ամբողջությամբ տեղափոխում եք նոր տարբերակ։ Այս սկզբունքը կիրառվում է ոչ միայն Kubernetes-ում։
Այժմ ես ձեզ կներկայացնեմ նոր տեղակայման բաղադրիչ՝ Deployer, որը կատարում է առողջական ստուգումներ, վերակազմավորում է պրոքսիները և այլն: Սա հասկացություն է, որը չի վերաբերում արտաքին աշխարհին և գոյություն ունի Kubernetes-ի ներսում։ Ես ձեզ ցույց կտամ, թե ինչպես կարող եք ստեղծել ձեր սեփական Deployer հայեցակարգը՝ օգտագործելով բաց կոդով գործիքներ:
Այսպիսով, առաջին բանը, ինչ անում է Deployer-ը, RC կրկնօրինակման վերահսկիչ ստեղծելն է՝ օգտագործելով Kubernetes API: Այս API-ն ստեղծում է pods և ծառայություններ հետագա տեղակայման համար, այսինքն՝ ստեղծում է բոլորովին նոր կլաստեր մեր հավելվածների համար: Հենց որ RC-ն համոզվի, որ կրկնօրինակները սկսվել են, այն կկատարի առողջության ստուգում դրանց ֆունկցիոնալության վերաբերյալ: Դա անելու համար Deployer-ն օգտագործում է GET /health հրամանը: Այն գործարկում է համապատասխան սկանավորման բաղադրիչները և ստուգում է բոլոր տարրերը, որոնք աջակցում են կլաստերի աշխատանքին:
Այն բանից հետո, երբ բոլոր բլոկները զեկուցեն իրենց առողջական վիճակի մասին, Deployer-ը ստեղծում է նոր կազմաձևման տարր՝ etcd բաշխված պահեստավորում, որն օգտագործվում է ներսից Kubernetes-ի կողմից՝ ներառյալ բեռնվածության հավասարակշռիչի կոնֆիգուրացիան պահելու համար: Մենք տվյալները գրում ենք etcd-ում, և մի փոքրիկ գործիք, որը կոչվում է confd monitors etcd նոր տվյալների համար:
Եթե այն հայտնաբերում է նախնական կազմաձևման որևէ փոփոխություն, այն ստեղծում է նոր կարգավորումների ֆայլ և փոխանցում այն ha-proxy-ին: Այս դեպքում ha-proxy-ը վերագործարկում է առանց որևէ կապ կորցնելու և բեռը ուղղում է նոր ծառայություններին, որոնք հնարավորություն են տալիս աշխատելու մեր հավելվածների նոր տարբերակին:
Ինչպես տեսնում եք, չնայած բաղադրիչների առատությանը, այստեղ ոչ մի բարդ բան չկա: Պարզապես պետք է ավելի շատ ուշադրություն դարձնել API-ին և այլն: Ես ուզում եմ ձեզ պատմել բաց կոդով մշակողի մասին, որը մենք ինքներս ենք օգտագործում՝ Amdatu Kubernetes Deployer:
Այն Kubernetes-ի տեղակայումները կազմակերպելու գործիք է և ունի հետևյալ հատկանիշները.
- Կապույտ/Կանաչ տեղակայում;
- արտաքին բեռի հավասարակշռության տեղադրում;
- տեղակայման նկարագրիչի կառավարում;
- իրական տեղակայման կառավարում;
- տեղակայման ընթացքում Առողջապահական ստուգումների ֆունկցիոնալության ստուգում.
- շրջակա միջավայրի փոփոխականների ներդրումը պատյանների մեջ:
Այս Deployer-ը կառուցված է Kubernetes API-ի վերևում և տրամադրում է REST API՝ բռնակների և տեղակայումների կառավարման համար, ինչպես նաև Websocket API՝ տեղակայման գործընթացում հոսքային տեղեկամատյանների համար:
Այն տեղադրում է բեռի հավասարակշռիչի կազմաձևման տվյալները etcd-ի մեջ, այնպես որ դուք ստիպված չեք լինի օգտագործել ha-proxy-ն առանց տուփի աջակցությամբ, այլ հեշտությամբ օգտագործել ձեր սեփական բեռնաչափի կազմաձևման ֆայլը: Amdatu Deployer-ը գրված է Go-ում, ինչպես Kubernetes-ը, և լիցենզավորված է Apache-ի կողմից:
Նախքան սկսեի օգտագործել տեղադրողի այս տարբերակը, ես օգտագործեցի հետևյալ տեղակայման նկարագրիչը, որը սահմանում է ինձ անհրաժեշտ պարամետրերը:
Այս կոդի կարևոր պարամետրերից մեկը «useHealthCheck» դրոշակի ակտիվացումն է։ Մենք պետք է հստակեցնենք, որ տեղակայման գործընթացում պետք է կատարվի առողջական վիճակի ստուգում: Այս կարգավորումը կարող է անջատվել, երբ տեղակայումն օգտագործում է երրորդ կողմի կոնտեյներներ, որոնք ստուգման կարիք չունեն: Այս նկարագրիչը նաև ցույց է տալիս կրկնօրինակների քանակը և ճակատային URL-ը, որն անհրաժեշտ է ha-proxy-ին: Վերջում դրված է «podspec» տիպի դրոշակը, որը զանգահարում է Kubernetes՝ պորտի կազմաձևման, պատկերի և այլնի մասին տեղեկություններ ստանալու համար: Սա բավականին պարզ JSON նկարագրիչ է:
Մեկ այլ գործիք, որը բաց կոդով Amdatu նախագծի մի մասն է, Deploymentctl-ն է: Այն ունի ինտերֆեյս՝ տեղակայումները կարգավորելու համար, պահում է տեղակայման պատմությունը և պարունակում է վեբ-կեռիկներ՝ երրորդ կողմի օգտատերերի և մշակողների կողմից հետ կանչելու համար: Դուք կարող եք չօգտագործել միջերեսը, քանի որ Amdatu Deployer-ն ինքնին REST API է, բայց այս ինտերֆեյսը կարող է շատ ավելի հեշտացնել տեղակայումը ձեզ համար՝ առանց որևէ API ներգրավելու: Deploymentctl-ը գրված է OSGi/Vertx-ում՝ օգտագործելով Angular 2:
Այժմ ես կցուցադրեմ վերը նշվածը էկրանին՝ օգտագործելով նախապես ձայնագրված ձայնագրությունը, որպեսզի սպասել չլինի: Մենք կտեղակայենք պարզ Go հավելված: Մի անհանգստացեք, եթե նախկինում չեք փորձել Go-ն, դա շատ պարզ ծրագիր է, այնպես որ դուք պետք է կարողանաք պարզել այն:
Այստեղ մենք ստեղծում ենք HTTP սերվեր, որն արձագանքում է միայն /health-ին, ուստի այս հավելվածը միայն թեստավորում է առողջության ստուգումը և ուրիշ ոչինչ: Եթե ստուգումն անցնում է, ապա օգտագործվում է ստորև ներկայացված JSON կառուցվածքը: Այն պարունակում է հավելվածի տարբերակը, որը կտեղակայվի տեղակայողի կողմից, հաղորդագրությունը, որը դուք տեսնում եք ֆայլի վերևում, և բուլյան տվյալների տեսակը՝ արդյոք մեր հավելվածն աշխատում է, թե ոչ:
Ես մի փոքր խաբեցի վերջին տողով, քանի որ ֆայլի վերևում տեղադրեցի ֆիքսված բուլյան արժեք, որը հետագայում կօգնի ինձ տեղակայել նույնիսկ «անառողջ» հավելվածը: Սրանով կզբաղվենք ավելի ուշ:
Այսպիսով, եկեք սկսենք: Սկզբում մենք ստուգում ենք ցանկացած գործարկվող pods-ի առկայությունը՝ օգտագործելով ~ kubectl get pods հրամանը և, հիմնվելով frontend URL-ից պատասխանի բացակայության վրա, մենք համոզվում ենք, որ ներկայումս տեղակայումներ չեն իրականացվում:
Հաջորդը էկրանին տեսնում եք իմ նշած Deploymentctl ինտերֆեյսը, որում տեղադրվում են տեղակայման պարամետրերը. անվանատարածք, հավելվածի անվանում, տեղակայման տարբերակ, կրկնօրինակների քանակ, ճակատային URL, կոնտեյների անվանում, պատկեր, ռեսուրսների սահմանաչափեր, առողջության ստուգման պորտի համարը, և այլն։ Ռեսուրսների սահմանափակումները շատ կարևոր են, քանի որ դրանք թույլ են տալիս օգտագործել սարքավորումների առավելագույն հնարավոր քանակությունը: Այստեղ կարող եք նաև դիտել տեղակայման մատյանը:
Եթե հիմա կրկնում եք ~ kubectl get pods հրամանը, ապա կարող եք տեսնել, որ համակարգը «սառեցնում է» 20 վայրկյան, որի ընթացքում ha-proxy-ը վերակազմավորվում է: Դրանից հետո սկսվում է պատիճը, և մեր կրկնօրինակը կարելի է տեսնել տեղակայման մատյանում:
Տեսանյութից կտրեցի 20 վայրկյան սպասելը, և այժմ էկրանին կարող եք տեսնել, որ հավելվածի առաջին տարբերակը տեղակայվել է: Այս ամենն արվել է միայն UI-ի միջոցով:
Հիմա փորձենք երկրորդ տարբերակը։ Դա անելու համար ես փոխում եմ հավելվածի հաղորդագրությունը «Բարև, Կուբերնետես»: «Բարև, Deployer!» վրա, համակարգը ստեղծում է այս պատկերը և տեղադրում այն Docker ռեեստրում, որից հետո մենք պարզապես կրկին կտտացնում ենք «Deploy» կոճակը Deploymentctl պատուհանում: Այս դեպքում տեղակայման մատյանը ավտոմատ կերպով գործարկվում է այնպես, ինչպես դա տեղի ունեցավ հավելվածի առաջին տարբերակի տեղակայման ժամանակ:
~ kubectl get pods հրամանը ցույց է տալիս, որ ներկայումս գործում է հավելվածի 2 տարբերակ, բայց ճակատը ցույց է տալիս, որ մենք դեռ աշխատում ենք 1-ին տարբերակը:
Բեռի հավասարակշռիչը սպասում է, որ առողջական ստուգումն ավարտվի՝ նախքան երթևեկությունը նոր տարբերակի վերահղումը: 20 վայրկյան անց մենք անցնում ենք curl-ի և տեսնում ենք, որ այժմ ունենք հավելվածի 2-րդ տարբերակը, իսկ առաջինը ջնջվել է:
Սա «առողջ» հավելվածի տեղակայումն էր։ Տեսնենք, թե ինչ կլինի, եթե հավելվածի նոր տարբերակի համար ես Healthy պարամետրը ճիշտից փոխեմ կեղծի, այսինքն՝ փորձեմ տեղակայել անառողջ հավելված, որը ձախողել է առողջության ստուգումը: Դա կարող է տեղի ունենալ, եթե մշակման փուլում հավելվածում կատարվել են որոշ կոնֆիգուրացիայի սխալներ, և այն ուղարկվել է արտադրության այս ձևով:
Ինչպես տեսնում եք, տեղակայումն անցնում է վերը նշված բոլոր քայլերով, և ~kubectl get pods-ը ցույց է տալիս, որ երկու պատիճներն էլ աշխատում են: Բայց ի տարբերություն նախորդ տեղակայման, գրանցամատյանը ցույց է տալիս ժամանակի ավարտի կարգավիճակը: Այսինքն՝ առողջության ստուգման ձախողման պատճառով հավելվածի նոր տարբերակը չի կարող տեղակայվել։ Արդյունքում տեսնում եք, որ համակարգը վերադարձել է հավելվածի հին տարբերակի օգտագործմանը, իսկ նոր տարբերակը պարզապես հեռացվել է:
Սրա լավն այն է, որ նույնիսկ եթե դուք ունեք ահռելի քանակությամբ միաժամանակյա հարցումներ, որոնք մտնում են հավելվածի մեջ, նրանք նույնիսկ չեն նկատի անգործության ժամանակը տեղակայման ընթացակարգն իրականացնելիս: Եթե դուք փորձարկեք այս հավելվածը՝ օգտագործելով Gatling շրջանակը, որն ուղարկում է այն հնարավորինս շատ հարցումներ, ապա այս հարցումներից ոչ մեկը չի հեռացվի: Սա նշանակում է, որ մեր օգտատերերը նույնիսկ չեն նկատի իրական ժամանակում տարբերակների թարմացումները: Եթե այն չհաջողվի, աշխատանքը կշարունակվի հին տարբերակի վրա, եթե այն հաջող լինի, օգտվողները կանցնեն նոր տարբերակին:
Կա միայն մեկ բան, որը կարող է ձախողվել՝ եթե առողջության ստուգումը հաջողվի, բայց դիմումը ձախողվի, հենց որ ծանրաբեռնվի դրա վրա, այսինքն՝ փլուզումը տեղի կունենա միայն տեղակայման ավարտից հետո: Այս դեպքում դուք ստիպված կլինեք ձեռքով վերադառնալ հին տարբերակին: Այսպիսով, մենք նայեցինք, թե ինչպես օգտագործել Kubernetes-ը դրա համար նախատեսված բաց կոդով գործիքներով: Տեղակայման գործընթացը շատ ավելի հեշտ կլինի, եթե դուք կառուցեք այս գործիքները ձեր Build/Deploy խողովակաշարերում: Միևնույն ժամանակ, տեղակայումը սկսելու համար կարող եք օգտագործել կամ օգտագործողի միջերեսը կամ ամբողջությամբ ավտոմատացնել այս գործընթացը՝ օգտագործելով, օրինակ, commit to master-ը:
Մեր Build Server-ը կստեղծի Docker պատկեր, այն կմղի Docker Hub կամ ձեր օգտագործած ցանկացած ռեեստրի մեջ: Docker Hub-ն աջակցում է webhook-ին, այնպես որ մենք կարող ենք գործարկել հեռակա տեղակայումը Deployer-ի միջոցով վերը նշված ձևով: Այս կերպ Դուք կարող եք լիովին ավտոմատացնել ձեր հավելվածի տեղակայումը պոտենցիալ արտադրության մեջ:
Անցնենք հաջորդ թեմային՝ Kubernetes կլաստերի մասշտաբավորում: Նկատի ունեցեք, որ kubectl հրամանը մասշտաբային հրաման է: Ավելի շատ օգնությամբ մենք հեշտությամբ կարող ենք ավելացնել կրկնօրինակների թիվը մեր գոյություն ունեցող կլաստերում: Այնուամենայնիվ, գործնականում մենք սովորաբար ցանկանում ենք ավելացնել հանգույցների թիվը, այլ ոչ թե պատյաններին:
Միևնույն ժամանակ, աշխատանքային ժամերին կարող է անհրաժեշտ լինել ավելացնել, իսկ գիշերը, Amazon-ի ծառայությունների արժեքը նվազեցնելու համար, հնարավոր է, որ անհրաժեշտ լինի նվազեցնել գործարկվող հավելվածների քանակը: Սա չի նշանակում, որ միայն պատիճների քանակի մասշտաբը բավարար կլինի, քանի որ նույնիսկ եթե հանգույցներից մեկը անգործուն է, դուք դեռ պետք է դրա համար վճարեք Amazon-ին: Այսինքն՝ պատիճների մասշտաբը մեծացնելու հետ մեկտեղ պետք է չափել օգտագործվող մեքենաների քանակը:
Սա կարող է դժվար լինել, քանի որ անկախ նրանից՝ մենք օգտագործում ենք Amazon-ը կամ այլ ամպային ծառայություն, Kubernetes-ը ոչինչ չգիտի օգտագործվող մեքենաների քանակի մասին: Այն չունի գործիք, որը թույլ է տալիս համակարգը մասշտաբավորել հանգույցի մակարդակով:
Այսպիսով, մենք ստիպված կլինենք հոգ տանել ինչպես հանգույցների, այնպես էլ պատիճների մասին: Մենք հեշտությամբ կարող ենք մեծացնել նոր հանգույցների գործարկումը՝ օգտագործելով AWS API և Scaling խմբի մեքենաները՝ Kubernetes աշխատող հանգույցների թիվը կարգավորելու համար: Կարող եք նաև օգտագործել cloud-init կամ նմանատիպ սցենար՝ Kubernetes կլաստերում հանգույցներ գրանցելու համար:
Նոր մեքենան գործարկվում է Scaling խմբում, սկսում է իրեն որպես հանգույց, գրանցվում է վարպետի ռեեստրում և սկսում է աշխատել։ Դրանից հետո դուք կարող եք ավելացնել կրկնօրինակների քանակը՝ ստացված հանգույցների վրա օգտագործելու համար: Նվազեցումը պահանջում է ավելի շատ ջանք, քանի որ դուք պետք է համոզվեք, որ նման քայլը չի հանգեցնի արդեն գործող հավելվածների ոչնչացմանը «ավելորդ» մեքենաներն անջատելուց հետո: Նման սցենարը կանխելու համար անհրաժեշտ է հանգույցները դնել «չպլանավորված» կարգավիճակի: Սա նշանակում է, որ լռելյայն ժամանակացույցը անտեսելու է այս հանգույցները DaemonSet պատիճները պլանավորելիս: Ժամանակացույցը ոչինչ չի ջնջի այս սերվերներից, բայց նաև այնտեղ նոր բեռնարկղեր չի գործարկի: Հաջորդ քայլը ջրահեռացման հանգույցը հեռացնելն է, այսինքն՝ վազող բլոկները դրանից մեկ այլ մեքենա կամ այլ հանգույցներ, որոնք դրա համար բավարար հզորություն ունեն: Երբ համոզվեք, որ այս հանգույցներում այլևս բեռնարկղեր չկան, կարող եք դրանք հեռացնել Kubernetes-ից: Սրանից հետո դրանք պարզապես կդադարեն գոյություն ունենալ Kubernetes-ի համար։ Հաջորդը, դուք պետք է օգտագործեք AWS API-ն՝ անհարկի հանգույցները կամ մեքենաներն անջատելու համար:
Դուք կարող եք օգտագործել Amdatu Scalerd-ը՝ մեկ այլ բաց կոդով չափման գործիք, որը նման է AWS API-ին: Այն ապահովում է CLI՝ կլաստերի մեջ հանգույցներ ավելացնելու կամ հեռացնելու համար: Դրա հետաքրքիր առանձնահատկությունն այն է, որ ժամանակացույցը կարգավորելու ունակությունն է՝ օգտագործելով հետևյալ json ֆայլը։
Ցուցադրված կոդը նվազեցնում է կլաստերի հզորությունը գիշերվա ընթացքում կիսով չափ: Այն կարգավորում է ինչպես հասանելի կրկնօրինակների քանակը, այնպես էլ Amazon կլաստերի ցանկալի հզորությունը: Այս ժամանակացույցի օգտագործումը ավտոմատ կերպով կնվազեցնի հանգույցների թիվը գիշերը և կավելացնի դրանք առավոտյան՝ խնայելով Amazon-ի նման ամպային ծառայության հանգույցների օգտագործման ծախսերը: Այս հատկությունը ներկառուցված չէ Kubernetes-ում, սակայն Scalerd-ի օգտագործումը թույլ կտա ձեզ մեծացնել այս հարթակը, ինչպես ցանկանում եք:
Կցանկանայի նշել, որ շատերն ինձ ասում են. «Ամեն ինչ լավ է, բայց ի՞նչ կասես իմ տվյալների բազայի մասին, որը սովորաբար ստատիկ է»: Ինչպե՞ս կարող եք նման բան գործարկել Kubernetes-ի նման դինամիկ միջավայրում: Իմ կարծիքով, դուք չպետք է դա անեք, չպետք է փորձեք տվյալների պահեստ գործարկել Kubernetes-ում: Դա տեխնիկապես հնարավոր է, և ինտերնետում կան ձեռնարկներ այս թեմայով, բայց դա լրջորեն կբարդացնի ձեր կյանքը:
Այո, Kubernetes-ում կա մշտական խանութների հայեցակարգ, և դուք կարող եք փորձել գործարկել տվյալների խանութներ, ինչպիսիք են Mongo-ն կամ MySQL-ը, բայց սա բավականին աշխատատար խնդիր է: Դա պայմանավորված է նրանով, որ տվյալների պահեստները լիովին չեն աջակցում դինամիկ միջավայրի հետ փոխգործակցությանը: Տվյալների բազաների մեծ մասը պահանջում է զգալի կոնֆիգուրացիա, ներառյալ կլաստերի ձեռքով կազմաձևումը, չեն սիրում ավտոմատ մասշտաբավորում և այլ նմանատիպ բաներ:
Հետևաբար, չպետք է բարդացնեք ձեր կյանքը՝ փորձելով գործարկել տվյալների պահեստը Kubernetes-ում: Կազմակերպեք նրանց աշխատանքը ավանդական եղանակով՝ օգտագործելով ծանոթ ծառայություններ և պարզապես տրամադրեք Kubernetes-ին դրանք օգտագործելու հնարավորություն:
Թեման ավարտելու համար ցանկանում եմ ձեզ ներկայացնել Kubernetes-ի վրա հիմնված Cloud RTI հարթակը, որի վրա աշխատում է իմ թիմը։ Այն ապահովում է կենտրոնացված անտառահատումներ, հավելվածների և կլաստերի մոնիտորինգ, և շատ այլ օգտակար հատկություններ, որոնք օգտակար կլինեն: Այն օգտագործում է տարբեր բաց կոդով գործիքներ, ինչպիսիք են Grafana-ն՝ մոնիտորինգը ցուցադրելու համար:
Հարց կար, թե ինչու օգտագործել ha-proxy load balancer-ը Kubernetes-ի հետ: Լավ հարց է, քանի որ ներկայումս բեռների հավասարակշռման 2 մակարդակ կա: Kubernetes ծառայությունները դեռևս գտնվում են վիրտուալ IP հասցեների վրա: Դուք չեք կարող դրանք օգտագործել արտաքին հոսթ մեքենաների նավահանգիստների համար, քանի որ եթե Amazon-ը ծանրաբեռնի իր ամպային հոսթինգը, հասցեն կփոխվի: Ահա թե ինչու մենք տեղադրում ենք ha-proxy-ը ծառայությունների դիմաց՝ ավելի ստատիկ կառուցվածք ստեղծելու համար, որպեսզի երթևեկությունը անխափան շփվի Kubernetes-ի հետ:
Մեկ այլ լավ հարց է, թե ինչպես կարող եք հոգալ տվյալների բազայի սխեմայի փոփոխությունները կապույտ/կանաչ տեղակայում կատարելիս: Փաստն այն է, որ անկախ Kubernetes-ի օգտագործումից, տվյալների բազայի սխեման փոխելը բարդ խնդիր է։ Դուք պետք է համոզվեք, որ հին և նոր սխեման համատեղելի են, որից հետո կարող եք թարմացնել տվյալների բազան և այնուհետև թարմացնել հենց հավելվածները: Դուք կարող եք տաք փոխանակում կատարել տվյալների բազան և այնուհետև թարմացնել հավելվածները: Ես գիտեմ մարդկանց, ովքեր բացել են տվյալների բազայի բոլորովին նոր կլաստեր նոր սխեմայով, սա տարբերակ է, եթե դուք ունեք առանց սխեմայի տվյալների բազա, ինչպիսին Mongo-ն է, բայց ամեն դեպքում դա հեշտ գործ չէ: Եթե լրացուցիչ հարցեր չունեք, շնորհակալություն ուշադրության համար:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com