
În prezent, tot mai multe companii își mută infrastructura de pe servere fizice și virtuale proprii în clouduri. Această decizie poate fi explicată ușor: nu este necesar să te îngrijorezi de hardware, iar clusterul poate fi configurat în numeroase moduri... iar cel mai important — tehnologia disponibilă (cum ar fi Kubernetes) permite scalarea ușoară a resurselor de calcul în funcție de sarcină.
Aspectul financiar este întotdeauna important. Instrumentul despre care vom vorbi în acest articol este destinat să ajute la reducerea bugetelor prin utilizarea infrastructurii cloud cu Kubernetes.
Introducere
— o startup din California fondată de foști angajați Google, care creează o soluție pentru calcularea costurilor infrastructurii în servicii cloud (în interiorul clusterului Kubernetes + resurse comune), identificarea punctelor slabe în setările clusterului și trimiterea notificărilor corespunzătoare în Slack.
Avem clienți cu Kubernetes în atât de obișnuitele clouduri AWS și GCP, cât și în Azure, care este mai rar întâlnit în comunitatea Linux — în general, pe toate platformele acceptate de Kubecost. Pentru unii dintre aceștia, evaluăm costurile pentru serviciile interne ale clusterului autonom (printr-o metodă similară celei folosite de Kubecost) și, de asemenea, monitorizăm cheltuielile pentru infrastructură și încercăm să le optimizăm. Prin urmare, este logic că ne-a interesat posibilitatea de a automatiza aceste sarcini.
Codul sursă al modulului principal Kubecost este deschis sub licență Open Source (Licența Apache 2.0). Poate fi utilizat liber, iar funcțiile disponibile ar trebui să fie suficiente pentru proiecte mici. Totuși, afacerea este afacere: restul produsului este închis și poate fi accesat prin , care implică, de asemenea, suport comercial. În plus, autorii oferă o licență gratuită pentru clustere mici (1 cluster cu 10 noduri — la momentul redactării acestui articol, acest limit a fost extins la 20 de noduri) sau un period de probă cu acces complet timp de 1 lună.
Cum este organizat totul
Așadar, partea principală a Kubecost este o aplicație , scrisă în Go. Helm chart-ul care descrie întregul sistem se numește și, în esență, este o combinație între cost-model, Prometheus, Grafana și câteva tablouri de bord.
În general, cost-model are o interfață web care afișează grafice și statistici detaliate despre cheltuieli în format tabelar, precum și, desigur, sfaturi pentru optimizarea costurilor. Dashboard-urile prezentate în Grafana sunt un stadiu mai timpuriu al dezvoltării Kubecost și conțin în mare parte aceleași date ca și cost-model, completându-le cu statistici obișnuite despre consumul de CPU/memorie/rețea/spațiu pe disc în cluster și componentele acestuia.
Cum funcționează Kubecost?
- Cost-model obține prețurile de întreținere prin API-ul providerilor de cloud.
- Ulterior, în funcție de tipul de hardware al nodului și regiune, se calculează costul pe noduri.
- Pe baza costului de funcționare al nodurilor, fiecare pod final primește un cost pe oră pentru utilizarea procesorului, pentru un gigabyte de memorie consumat și pentru ora de stocare a unui gigabyte de date, în funcție de nodul pe care a funcționat sau de clasa de stocare.
- Pe baza costului de funcționare al podurilor individuale, se calculează plata pe spațiile de nume, servicii, Deployment-uri, StatefulSet-uri.
- Pentru a calcula statisticile sunt utilizate metrici furnizate de kube-state-metrics și node-exporter.
Este important de menționat că Kubecost prin default consideră doar resursele disponibile în Kubernetes. Baze de date externe, servere GitLab, stocări S3 și alte servicii care nu sunt prezente în cluster (chiar și cele din același cloud) nu sunt vizibile pentru el. Cu toate acestea, pentru GCP și AWS se pot adăuga cheile conturilor de serviciu și se poate calcula totul împreună.
Instalare
Pentru a funcționa Kubecost sunt necesare:
- Kubernetes versiunea 1.8 și mai recentă;
- kube-state-metrics;
- Prometheus;
- node-exporter.
Așa s-a întâmplat că în clusterele noastre toate aceste condiții au fost respectate anterior, așa că s-a dovedit a fi suficient doar să specificăm endpoint-ul corect pentru accesul în Prometheus. Cu toate acestea, chart-ul Helm oficial al kubecost conține tot ceea ce este necesar pentru a porni chiar și într-un cluster 'gol'.
Kubecost poate fi instalat în mai multe moduri:
- Calea standard de instalare, descrisă în pe site-ul dezvoltatorului. Este necesar să adăugați în Helm repository-ul cost-analyzer, după care să instalați chart-ul. Nu va rămâne decât să redirecționați portul și să finalizați setările manual (prin kubectl) și/sau cu ajutorul interfeței web a cost-model.
Această metodă nu am încercat-o, deoarece nu folosim configurații gata făcute din exterior, dar pare o opțiune bună „doar pentru a încerca”. Dacă deja aveți instalate unele componente ale sistemului sau doriți o configurare mai detaliată, ar fi mai bine să luați în considerare a doua opțiune.
- A folosi, de fapt , dar să-l configurați și să-l instalați singuri în orice mod convenabil.
Așa cum s-a menționat, pe lângă kubecost-ul propriu-zis, acest chart conține chart-uri pentru Grafana și Prometheus, care pot fi, de asemenea, configurate după dorința dumneavoastră.
Include în chart
values.yamlpentru cost-analyzer permite configurarea:- lista componentelor cost-analyzer care trebuie desfășurate;
- endpointul dumneavoastră pentru Prometheus (dacă deja aveți unul);
- domeniile și alte setări pentru ingress-uri pentru cost-model și Grafana;
- anotații pentru pod-uri;
- necesitatea de a folosi stocări permanente și dimensiunea acestora.
Lista completă a opțiunilor disponibile pentru configurare este în .
Deoarece kubecost, în varianta sa de bază, nu limitează accesul, va trebui să configurați mai întâi basic-auth pentru panoul web.
- Instalează doar nucleul sistemului — cost-model. Pentru aceasta, trebuie să aveți Prometheus instalat în cluster și să specificați adresa sa în variabila
prometheusEndpointpentru Helm. După aceea — aplicați în cluster.Din nou, va trebui să adăugați manual Ingress cu basic-auth. Și, în final, va trebui să adăugați o secțiune pentru colectarea metricilor cost-model în
extraScrapeConfigsdin configurația Prometheus:- job_name: kubecost honor_labels: true scrape_interval: 1m scrape_timeout: 10s metrics_path: /metrics scheme: http dns_sd_configs: - names: - type: 'A' port: 9003
Ce obținem?
În cazul unei instalări complete, vom avea la dispoziție panoul web kubecost și Grafana cu un set de dashboard-uri.
Cost total, afișat pe ecranul principal, arată practic costul estimat al resurselor pe lună. Acesta este un preț prognozat care reflectă costul utilizării clusterului (pe lună) la nivelul curent de consum al resurselor.
Această metrică este mai mult pentru analiza cheltuielilor și optimizarea acestora. Cheltuielile totale pentru luna abstractă iulie în kubecost nu sunt foarte ușor de urmărit: va trebui să mergeți la facturare. Totuși, puteți vedea cheltuielile defalcate pe spații de nume, etichete, pod-uri pe 1/2/7/30/90 zile, ceea ce facturarea nu vă va arăta niciodată.

Cât despre etichete. Este bine să accesați imediat setările și să specificați denumirile etichetelor care vor fi utilizate ca categorii suplimentare pentru gruparea cheltuielilor:

Pe acestea se pot atașa orice etichete — convenabil dacă aveți deja propriul sistem de etichetare.
De asemenea, acolo puteți schimba adresa endpoint-ului API la care se conectează cost-model, să setați discount-ul în GCP și să specificați prețurile proprii pentru resurse și moneda pentru măsurarea acestora (funcționalitatea nu afectează Total cost din motive inexplicabile).
Kubecost poate arăta diferite probleme în cluster (și chiar să alerteze în caz de pericol). Din păcate, opțiunea nu este configurabilă, așa că, dacă aveți medii pentru dezvoltatori și acestea sunt utilizate, veți putea observa constant ceva de genul:

Un instrument important — Cluster Savings. Acesta măsoară activitatea pod-urilor (consumul de resurse, inclusiv cel de rețea) și calculează cât de mulți bani se pot economisi și pe ce.
Poate părea că sfaturile pentru optimizare sunt destul de evidente, totuși experiența sugerează că tot există lucruri de observat. În special, se monitorizează activitatea de rețea a pod-urilor (Kubecost sugerează să se acorde atenție celor inactive), se compară consumul solicitat și cel real de memorie și CPU, precum și CPU-ul utilizat de nodurile clusterului (sugerează comprimarea mai multor noduri într-unul), sarcina pe discuri și încă câteva zeci de parametri.
Ca în orice problemă legată de optimizare, optimizarea resurselor bazată pe datele Kubecost trebuie manipulată cu precauție. De exemplu, Cluster Savings sugerează să se elimine noduri, afirmând că este sigur, însă nu ia în considerare existența selecțiilor de noduri și a taint-urilor la pod-urile desfășurate pe acestea, care nu există pe celelalte noduri. În plus, chiar și autorii produsului în propria lor (de altfel, aceasta poate fi foarte utilă celor interesați de subiectul proiectului) recomandă să nu se arunce cu capul înainte în optimizarea cheltuielilor, ci să se abordeze această problemă cu atenție.
Concluzii
După utilizarea kubecost timp de o lună pe câteva proiecte, putem concluziona că acesta este un instrument interesant (și de asemenea ușor de învățat și instalat) pentru analiza și optimizarea cheltuielilor pentru serviciile furnizorilor de cloud utilizate pentru clusterele Kubernetes. Calculul este destul de precis: în experimentele noastre s-a potrivit cu ceea ce cer furnizorii în realitate.
Nu au lipsit nici minusurile: există erori necritice, funcționalitățile nu acoperă uneori nevoile specifice ale anumitor proiecte. Totuși, dacă trebuie să înțelegi rapid unde se duc banii și ce poți 'tăia' pentru a reduce constant factura pentru serviciile cloud cu 5-30% (așa s-a întâmplat în cazul nostru), este o opțiune excelentă.
P.S.
Citiți și în blogul nostru:
- «»;
- «»;
- «».
Sursa: habr.com
