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

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

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

Въведение

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

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

Исходният код на основния модул на Kubecost е отворен под условията на Open Source лиценз (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 chart на kubecost съдържа всичко необходимо, за да стартира и на "гол" клъстер.

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

Стандартен метод на инсталиране, описан в инструкции на сайта на разработчика. Необходимо е да добавите в Helm репозитория cost-analyzer, след което да инсталирате chart. Остава само да пренасочите порт и да довършите настройките до желаното състояние ръчно (чрез 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 с набор от табла за управление.

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

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

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

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

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

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

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

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

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

Итог

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

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