Ներկայումս ավելի ու ավելի շատ ընկերություններ են փոխանցում իրենց ենթակառուցվածքը ապարատային սերվերներից և սեփական վիրտուալ մեքենաներից դեպի ամպ: Այս լուծումը հեշտ է բացատրել. սարքաշարի մասին անհանգստանալու կարիք չկա, կլաստերը հեշտությամբ կազմաձևվում է տարբեր ձևերով... և ամենակարևորը, գոյություն ունեցող տեխնոլոգիաները (ինչպես Kubernetes-ը) հնարավորություն են տալիս պարզապես մեծացնել հաշվողական հզորությունը՝ կախված ծանրաբեռնվածությունից։ .
Ֆինանսական կողմը միշտ կարևոր է։ Այս հոդվածում քննարկված գործիքը նախատեսված է օգնելու կրճատել բյուջեները Kubernetes-ի հետ ամպային ենթակառուցվածք օգտագործելիս:
Ներածություն
Կալիֆորնիայի ստարտափ է Google-ից, որը լուծում է ստեղծում ամպային ծառայություններում ենթակառուցվածքի ծախսերը հաշվարկելու համար (Kubernetes կլաստերի + ընդհանուր ռեսուրսների շրջանակներում), կլաստերի կարգավորումներում խոչընդոտներ որոնելու և Slack-ին համապատասխան ծանուցումներ ուղարկելու համար:
Մենք ունենք հաճախորդներ Kubernetes-ի հետ և՛ ծանոթ AWS և GCP ամպերում, և՛ ավելի հազվադեպ Linux համայնքի համար՝ Azure-ը, ընդհանրապես՝ Kubecost-ի կողմից աջակցվող բոլոր հարթակներում: Նրանցից մի քանիսի համար մենք ինքներս ենք հաշվում ներկլաստերային ծառայությունների ծախսերը (օգտագործելով Kubecost-ի կողմից օգտագործվող մեթոդի նման), ինչպես նաև վերահսկում ենք ենթակառուցվածքի ծախսերը և փորձում օպտիմալացնել դրանք: Հետեւաբար, տրամաբանական է, որ մեզ հետաքրքրում էր նման առաջադրանքների ավտոմատացման հնարավորությունը։
Հիմնական Kubecost մոդուլի սկզբնական կոդը բաց է բաց կոդով լիցենզիայի պայմաններով (Apache License 2.0): Այն կարող է ազատորեն օգտագործվել, և առկա հնարավորությունները պետք է բավարար լինեն փոքր նախագծերի համար: Այնուամենայնիվ, բիզնեսը բիզնես է. մնացած ապրանքը փակ է, այն կարող է օգտագործվել , ինչը ենթադրում է նաև կոմերցիոն աջակցություն։ Բացի այդ, հեղինակներն առաջարկում են անվճար լիցենզիա փոքր կլաստերների համար (1 կլաստեր 10 հանգույցով. այս հոդվածը գրելու ընթացքում այս սահմանաչափը ընդլայնվել է մինչև 20 հանգույց) կամ փորձնական շրջան՝ 1 ամսվա ընթացքում լիարժեք հնարավորություններով:
Ինչպես է ամեն ինչ աշխատում
Այսպիսով, Kubecost-ի հիմնական մասը հավելվածն է , գրված է Go-ում։ Սաղավարտի աղյուսակը, որը նկարագրում է ամբողջ համակարգը, կոչվում է և դրա հիմքում պրոմեթևսի, Գրաֆանայի և մի քանի վահանակների հետ կապված ծախսային մոդելի հավաքումն է:
Ընդհանուր առմամբ, ծախսերի մոդելն ունի իր սեփական վեբ ինտերֆեյսը, որը ցույց է տալիս աղյուսակային գծապատկերներ և ծախսերի մանրամասն վիճակագրություն, ինչպես նաև, իհարկե, ծախսերի օպտիմալացման խորհուրդներ: Grafana-ում ներկայացված վահանակները Kubecost-ի մշակման ավելի վաղ փուլն են և պարունակում են նույն տվյալները, ինչ ծախսերի մոդելը՝ լրացնելով դրանք կլաստերում պրոցեսորի/հիշողության/ցանցի/սկավառակի տարածության սպառման սովորական վիճակագրությամբ և դրա բաղադրիչներով: .
Ինչպե՞ս է աշխատում Kubecost-ը:
- Cost-model-ը ծառայությունների գները ստանում է ամպային մատակարարների API-ի միջոցով:
- Ավելին, կախված հանգույցի երկաթի տեսակից և տարածաշրջանից, հաշվարկվում է մեկ հանգույցի արժեքը:
- Ելնելով գործարկվող հանգույցների արժեքից՝ յուրաքանչյուր տերևային պատիճ ստանում է CPU-ի օգտագործման մեկ ժամի, սպառված հիշողության մեկ գիգաբայթի և պահվող տվյալների մեկ գիգաբայթի մեկ ժամի արժեքը՝ կախված այն հանգույցից, որի վրա աշխատում էր կամ պահեստավորման դասից:
- Ելնելով առանձին բլոկների շահագործման արժեքից՝ վճարումը հաշվարկվում է անունների տարածքների, ծառայությունների, տեղակայումների, StatefulSets-ների համար:
- Վիճակագրությունը հաշվարկվում է՝ օգտագործելով kube-state-metrics-ի և node-exporter-ի տրամադրած չափումները:
Կարևոր է հաշվի առնել, որ Կուբեկոստը լռելյայնորեն հաշվում է միայն Kubernetes-ում հասանելի ռեսուրսները. Արտաքին տվյալների բազաները, GitLab սերվերները, S3 պահեստները և այլ ծառայություններ, որոնք կլաստերի մեջ չեն (նույնիսկ եթե գտնվում են նույն ամպում), տեսանելի չեն դրա համար: Չնայած GCP-ի և AWS-ի համար կարող եք ավելացնել ձեր սպասարկման հաշիվների բանալիները և միասին հաշվարկել ամեն ինչ:
Տեղակայում
Kubecost-ը պահանջում է.
- Kubernetes տարբերակ 1.8 և ավելի բարձր;
- kube-state-metrics;
- Պրոմեթևս;
- հանգույց-արտահանող.
Այնպես եղավ, որ մեր կլաստերներում այս բոլոր պայմանները նախապես բավարարված էին, ուստի պարզվեց, որ բավական է պարզապես նշել ճիշտ վերջնակետը Պրոմեթևս մուտք գործելու համար: Այնուամենայնիվ, kubecost Helm-ի պաշտոնական աղյուսակը պարունակում է այն ամենը, ինչ ձեզ անհրաժեշտ է մերկ կլաստերի վրա աշխատելու համար:
Kubecost-ը տեղադրելու մի քանի եղանակ կա.
- Ստանդարտ տեղադրման մեթոդը նկարագրված է մշակողի կայքում: Պահանջվում է ավելացրեք ծախսերի վերլուծիչի պահոցը Helm-ում, այնուհետև տեղադրեք աղյուսակը. Մնում է միայն փոխանցել ձեր նավահանգիստը և հարմարեցնել կարգավորումները ցանկալի վիճակին ձեռքով (kubectl-ի միջոցով) և/կամ օգտագործելով ծախսային մոդելի վեբ ինտերֆեյսը:
Մենք նույնիսկ չենք փորձել այս մեթոդը, քանի որ մենք չենք օգտագործում երրորդ կողմի պատրաստի կոնֆիգուրացիաներ, բայց կարծես լավ «պարզապես փորձեք ինքներդ ձեզ» տարբերակ: Եթե դուք արդեն ունեք տեղադրված համակարգի որոշ բաղադրիչներ կամ ցանկանում եք ավելի լավ կարգավորել, ապա ավելի լավ է դիտարկել երկրորդ ուղին:
- Օգտագործեք ըստ էության , բայց կարգավորեք և տեղադրեք այն ինքներդ ցանկացած հարմար եղանակով։
Ինչպես արդեն նշվեց, բացի բուն kubecost-ից, այս աղյուսակը պարունակում է Grafana և Prometheus աղյուսակներ, որոնք նույնպես կարող են հարմարեցվել ըստ ցանկության:
Հասանելի է գծապատկերում
values.yamlհամար ծախսերի անալիզատորը թույլ է տալիս կարգավորել.- ծախսերի վերլուծիչի բաղադրիչների ցանկ, որոնք պետք է տեղակայվեն.
- ձեր վերջնակետը Պրոմեթևսի համար (եթե արդեն ունեք մեկը);
- տիրույթներ և այլ մուտքային կարգավորումներ ծախսերի մոդելի և Grafana-ի համար;
- ծանոթագրություններ պատիճների համար;
- մշտական պահեստի օգտագործման անհրաժեշտությունը և դրա չափը.
Հասանելի կազմաձևման ընտրանքների ամբողջական ցանկը նկարագրություններով հասանելի է այստեղ .
Քանի որ kubecost-ն իր հիմնական տարբերակում չի կարող սահմանափակել մուտքը, դուք պետք է անմիջապես կարգավորեք հիմնական-auth-ը վեբ վահանակի համար:
- Տեղադրելու համար միայն համակարգի միջուկը - ծախսային մոդել: Դա անելու համար դուք պետք է Prometheus-ը տեղադրեք կլաստերում և նշեք դրա հասցեի համապատասխան արժեքը փոփոխականում:
prometheusEndpointՀելմի համար: Դրանից հետո - դիմել կլաստերի մեջ։Կրկին, դուք ստիպված կլինեք ձեռքով ավելացնել Ingress-ը հիմնական-auth-ով: Ի վերջո, դուք պետք է ավելացնեք բաժին ծախսերի մոդելի չափումներ հավաքելու համար
extraScrapeConfigsՊրոմեթևսի կազմաձևում.- job_name: kubecost honor_labels: true scrape_interval: 1m scrape_timeout: 10s metrics_path: /metrics scheme: http dns_sd_configs: - names: - <адрес вашего сервиса kubecost> type: 'A' port: 9003
Ի՞նչ ենք մենք ստանում:
Ամբողջական տեղադրմամբ մենք մեր տրամադրության տակ ունենք kubecost և Grafana վեբ վահանակը վահանակների հավաքածուով:
Ընդհանուր արժեքը, որը ցուցադրվում է հիմնական էկրանին, իրականում ցույց է տալիս ամսվա համար ռեսուրսների գնահատված արժեքը: Սա նախագծված գինը, որն արտացոլում է կլաստերի օգտագործման արժեքը (ամսական) ռեսուրսների սպառման ներկա մակարդակում:
Այս չափիչն ավելի շատ ծախսերը վերլուծելու և դրանք օպտիմալացնելու համար է: Շատ հարմար չէ Kubecost-ում վերացական հուլիս ամսվա ընդհանուր ծախսերը դիտարկել. դուք ստիպված կլինեք դա անել. գնալ բիլինգի. Բայց դուք կարող եք տեսնել ծախսերը՝ բաժանված ըստ անվանատարածքների, պիտակների, պատիճների 1/2/7/30/90 օրվա համար, որոնք հաշիվը երբեք ձեզ ցույց չի տա:
Խոսելով Պիտակներ. Դուք պետք է անմիջապես անցնեք կարգավորումներ և սահմանեք այն պիտակների անունները, որոնք կօգտագործվեն որպես լրացուցիչ կատեգորիաներ ծախսերի խմբավորման համար.
Դուք կարող եք դրանց վրա կախել ցանկացած պիտակ՝ հարմար, եթե արդեն ունեք ձեր սեփական պիտակավորման համակարգը:
Նաև այնտեղ կարող եք փոխել API-ի վերջնակետի հասցեն, որին միանում է ծախսերի մոդելը, կարգավորել զեղչի չափը GCP-ում և սահմանել ռեսուրսների և արժույթի ձեր սեփական գները դրանց չափման համար (ինչ-ինչ պատճառներով հատկանիշը չի ազդում Ընդհանուր արժեքի վրա):
Kubecost-ը կարող է տարբեր լինել խնդիրներ կլաստերում (և նույնիսկ զգոն վտանգի դեպքում): Ցավոք, տարբերակը կարգավորելի չէ, և, հետևաբար, եթե ունեք միջավայրեր մշակողների համար և օգտվում դրանք, դուք անընդհատ կտեսնեք նման բան.
Կարևոր գործիք - Կլաստերային խնայողություններ. Այն չափում է պատիճների ակտիվությունը (ռեսուրսների սպառումը, ներառյալ ցանցայինը), ինչպես նաև հաշվարկում է, թե որքան գումար և ինչի վրա կարող եք խնայել:
Կարող է թվալ, որ օպտիմալացման խորհուրդները բավականին ակնհայտ են, բայց փորձը ցույց է տալիս, որ դեռ պետք է նայելու բան: Մասնավորապես, վերահսկվում է փոդերի ցանցային ակտիվությունը (Kubecost-ն առաջարկում է ուշադրություն դարձնել ոչ ակտիվներին), համեմատվում է պահանջվող և փաստացի հիշողության և պրոցեսորի սպառումը, ինչպես նաև կլաստերային հանգույցների կողմից օգտագործվող պրոցեսորը (առաջարկում է մի քանի հանգույցների փլուզում), սկավառակը: ծանրաբեռնվածություն և ևս մի քանի տասնյակ պարամետր:
Ինչպես ցանկացած օպտիմալացման հարցում, Kubecost-ի տվյալների վրա հիմնված ռեսուրսների օպտիմալացումը պահանջում է. զգուշությամբ վերաբերվեք. Օրինակ, Cluster Savings-ն առաջարկում է ջնջել հանգույցները՝ պնդելով, որ դա անվտանգ է, բայց հաշվի չի առնում հանգույցների ընտրիչների և դրանց վրա տեղադրված բլոկների առկայությունը, որոնք հասանելի չեն այլ հանգույցներում: Եվ ընդհանրապես, նույնիսկ ապրանքի հեղինակներն իրենց (ի դեպ, դա կարող է շատ օգտակար լինել նրանց համար, ովքեր հետաքրքրված են նախագծի թեմայով) խորհուրդ է տրվում գլխիվայր չշտապել ծախսերի օպտիմալացման մեջ, այլ մտածված մոտենալ հարցին։
Արդյունքները
Մի քանի նախագծերում kubecost-ը մեկ ամիս օգտագործելուց հետո մենք կարող ենք եզրակացնել, որ այն հետաքրքիր (և նաև հեշտ է սովորել և տեղադրել) գործիք է՝ վերլուծելու և օպտիմալացնելու ծախսերը ամպային մատակարարների ծառայությունների համար, որոնք օգտագործվում են Kubernetes կլաստերների համար: Պարզվում է, որ հաշվարկները շատ ճշգրիտ են. մեր փորձերում դրանք համընկնում էին այն բանի հետ, ինչ իրականում պահանջում էին մատակարարները:
Կան նաև բացասական կողմեր. կան ոչ կրիտիկական սխալներ, և որոշ տեղերում ֆունկցիոնալությունը չի բավարարում որոշ նախագծերի կարիքները: Այնուամենայնիվ, եթե դուք պետք է արագ հասկանաք, թե ուր են գնում գումարները և ինչ կարելի է «կտրել», որպեսզի հետևողականորեն նվազեցնեք ամպային ծառայությունների հաշիվը 5-30% -ով (սա այն է, ինչ տեղի ունեցավ մեր դեպքում), սա հիանալի տարբերակ է: .
PS
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «.
Source: www.habr.com