🥇Преглед на Kubecost за спестяване на средства в Kubernetes в облака

В настоящия момент все повече компании прехвърлят своята инфраструктура от физически сървъри и собствени виртуални машини в облака. Такова решение е лесно за обяснение: няма нужда да се притеснявате за хардуера, кластерът лесно се конфигурира по множество различни начини… а най-важното — наличните технологии (като Kubernetes) позволяват просто да се мащабира изчислителната мощност в зависимост от натоварването.

Винаги е важен и финансовият аспект. Инструментът, за който ще стане въпрос в тази статия, е предназначен да помогне за намаляване на бюджета при използването на облачна инфраструктура с Kubernetes.

Въведение

Kubecost — калифорнийски стартъп от хора, работили в Google, създаващ решение за проследяване на разходите за инфраструктура в облачни услуги (вътре в кластер Kubernetes + общи ресурси), откриване на проблемни места в настройките на кластера и изпращане на съответни известия в Slack.

Имаме клиенти с Kubernetes както в известните облаци AWS и GCP, така и в по-рядко срещаната за Linux общността Azure — по принцип на всички платформи, поддържани от Kubecost. За някои от тях изчисляваме разходите за вътрешнокластерни услуги самостоятелно (по методология, подобна на използваната от Kubecost), а също така следим разходите за инфраструктура и се опитваме да ги оптимизираме. Ето защо е логично, че се заинтересувахме от възможността да автоматизираме такива задачи.

Изходният код на основния модул на Kubecost е отворен на условията на лицензия с отворен код (Apache License 2.0). Може да се използва свободно, а наличните функции би трябвало да са достатъчни за малки проекти. Обаче бизнесът е бизнес: останалата част от продукта е затворена и може да се ползва по платени абонаменти, които също предвиждат търговска поддръжка. Освен това, авторите предлагат безплатна лицензия за малки клъстери (1 клъстер с 10 възли — по времето на написването на статията този лимит се увеличи до 20 възли) или пробен период с пълни възможности за 1 месец.

Как е устроено всичко

И така, основната част на Kubecost — това е приложението cost-model, написано на Go. Helm чартът, описващ цялата система, се нарича cost-analyzer и по същество представлява сборка от cost-model с Prometheus, Grafana и няколко табла за управление.

Като цяло, cost-model разполага с уеб интерфейс, който показва графики и детайлна статистика за разходите в табличен вид, а също така и, разбира се, съвети за оптимизиране на разходите. Показаните в Grafana табла са по-ранен етап от развитието на Kubecost и съдържат до известна степен същите данни, каквито предлага cost-model, допълнени с познатата статистика за употребата на CPU/памет/мрежа/дисково пространство в кластера и неговите компоненти.

Как работи Kubecost?

Cost-model получава цените за поддръжка чрез API на облачни доставчици.
След това, в зависимост от типа на хардуера и региона, се изчислява цената по възли.
На базата на цената за работа на възлите, всеки конечен pod получава цена за час за използването на процесор, разход на гигабайт памет и цена на час за съхранение на гигабайт данни — в зависимост от възела, на който е работил, или класа на хранилището.
Съобразно цената на работа на отделни pod’ове, се изчислява плащането по пространства имена, услуги, Deployment-и, StatefulSet-и.
За изчисляване на статистиката се използват метрики, предоставяни от kube-state-metrics и node-exporter.

Важно е да се има предвид, че Kubecost по подразбиране взема предвид само ресурсите, налични в Kubernetes. Външни бази данни, сървъри GitLab, хранилища S3 и други услуги, които не са налични в кластера (въпреки че са в същия облак), не са видими за него. Въпреки това, за GCP и AWS можете да добавите ключове на вашите сервис-акаунти и да изчислите всичко заедно.

Инсталиране на

За функционирането на Kubecost са необходими:

Kubernetes версия 1.8 и по-висока;
kube-state-metrics;
Prometheus;
node-exporter.

Случи се така, че в нашите клъстери всички тези условия бяха спазени предварително, така че се оказа достатъчно просто да укажем правилния endpoint за достъп до Prometheus. Въпреки това, официалният Helm чарт kubecost съдържа всичко необходимо, за да стартира и на „гол” кластер.

Можете да инсталирате Kubecost по няколко начина:

Стандартният метод за инсталиране, описан в инструкцията на сайта на разработчика. Необходимо е да добавите в Helm репозиторий cost-analyzer, след което да инсталирате чарта. Остава само да пренасочите порта и да настроите настройките до желаното състояние ръчно (чрез kubectl) и/или с помощта на уеб интерфейса на cost-model.
Този метод дори не сме опитвали, тъй като не използваме готови конфигурации от трети страни, но изглежда като добър вариант „просто да опитате сами“. Ако вече имате инсталирана част от компонентите на системата или искате по-фина настройка, по-добре е да обмислите втория вариант.
Да се използва по същество същия чарт, но да го конфигурирате и инсталирате сами по удобен за вас начин.
Както вече споменахме, освен самия kubecost, този чарт съдържа чартове на Grafana и Prometheus, които също могат да бъдат настроени по ваше желание.
Наличният в чарта values.yaml за cost-analyzer позволява конфигуриране:
- списък на компонентите на cost-analyzer, които трябва да се развият;
- ваш endpoint за Prometheus (ако вече имате такъв);
- домейни и други настройки за ingress'и за cost-model и Grafana;
- анотации за pod'овете;
- нуждата от използване на постоянни хранилища и техния размер.
Пълен списък с налични опции за конфигуриране с описание можете да намерите в документацията.
Тъй като kubecost в базовия си вариант не може да ограничава достъпа, ще се наложи веднага да настроите basic-auth за уеб панела.
Инсталирайте само ядрото на системата — cost-model. За целта е необходимо да имате инсталиран Prometheus в клъстера и да зададете съответното му адресно значение в променливата prometheusEndpoint за Helm. След това - приложете набор от YAML конфигурации в клъстера.
Отново, ще се наложи да добавите ръчно Ingress с basic-auth. И накрая, ще трябва да добавите секция за събиране на метрики на cost-model в extraScrapeConfigs в конфигурацията на 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
```

Какво получаваме?

При пълна инсталация в нашите ръце се оказва уеб панел kubecost и Grafana с набор от dashboard'ове.

Обща цена, показана на главния екран, всъщност показва изчислената стойност на ресурсите за месец. Това е прогнозираната цена, отразяваща разходите за използване на клъстера (на месец) при текущото ниво на потребление на ресурси.

Тази метрика е повече за анализ на разходите и тяхната оптимизация. Общите разходи за абстрактния юли в kubecost не се гледат много удобно: за това ще трябва да отидете в billing. Затова можете да видите разходите с разбивка по пространства от имена, етикети, pod'ове за 1/2/7/30/90 дни, което billing никога няма да ви покаже.

Да кажем дума за етикетите. Веднага е добре да се влезе в настройките и да се зададат имената на етикетите, които ще се използват като допълнителни категории за групиране на разходите:

На тях може да се закачат всякакви етикети — удобно е, ако вече имате своя система за маркировка.

Също така там може да се смени адресът на API endpoint, към който се свързва cost-model, да се настрои размерът на отстъпката в GCP и да се зададат собствени цени за ресурси и валута за тяхното измерване (тази функция по някаква причина не влияе на общата цена).

Kubecost може да показва различни проблеми в клъстера (и дори да отправя предупреждение в случай на опасност). За съжаление, опцията не може да се настрои, затова — ако имате среди за разработчици и те се използват, ще можете постоянно да наблюдавате нещо подобно:

Важен инструмент — Cluster Savings. Той измерва активността на pod-овете (консумация на ресурси, включително мрежови), както и изчислява, колко пари и на какво може да се спести.

Може да изглежда, че съветите за оптимизация са доста очевидни, обаче опитът показва, че все пак има какво да се види. В частност, проследява се мрежовата активност на pod-овете (Kubecost предлага да се обърне внимание на неактивните), сравнява се запитаният и реалния разход на памет и CPU, а също така CPU, използван от възлите на клъстера (предлага да се свият няколко възла в един), натоварването на дисковете и още няколко десетки параметри.

Както и при всеки въпрос, свързан с оптимизацията, оптимизацията на ресурсите на базата на данни от Kubecost трябва да се подходи с внимание. Например, Cluster Savings предлага да се премахнат възли, твърдейки, че това е безопасно, но не взима предвид наличието на pod-ове с node-selector и taint, които не са налични на другите възли. И изобщо, дори авторите на продукта в своята недавна статия (между другото, тя може да бъде доста полезна за тези, които се интересуват от темата на проекта) препоръчват да не се хвърляте с глава в оптимизацията на разходите, а да се подходи към въпроса обмислено.

Резюме

След като използвахме kubecost в продължение на месец за няколко проекта, можем да заключим, че това е интересен (а също така лесен за усвояване и инсталиране) инструмент за анализ и оптимизация на разходите за услуги на облачни доставчици, използвани за Kubernetes клъстери. Изчисленията се оказват доста точни: в нашите експерименти те съвпаднаха със същото, което реално изискваха доставчиците.

Не мина и без недостатъци: налични са некритични грешки, функционалните възможности на места не покриват специфичните нужди на някои проекти. Въпреки това, ако е необходимо бързо да разберете къде отиват парите и какво може да се „режат“, за да се намали стабилно сметката за облачни услуги с 5-30% (както се случи в нашия случай) — това е отличен вариант.