🥇Przegląd Kubecost w celu oszczędności na Kubernetes w chmurach

W obecnych czasach coraz więcej firm przenosi swoją infrastrukturę z serwerów fizycznych i własnych wirtualek do chmur. Takie rozwiązanie jest łatwe do wytłumaczenia: nie ma potrzeby zajmować się sprzętem, klaster można łatwo skonfigurować na wiele różnych sposobów... a co najważniejsze, dostępne technologie (takie jak Kubernetes) umożliwiają łatwe skalowanie mocy obliczeniowej w zależności od obciążenia.

Zawsze ważnym aspektem jest także aspekt finansowy. Narzędzie, o którym będzie mowa w tym artykule, ma na celu umożliwienie oszczędności budżetowych podczas korzystania z infrastruktury chmurowej z Kubernetes.

Wprowadzenie

Kubecost — kalifornijski startup założony przez byłych pracowników Google, tworzący rozwiązanie do obliczania kosztów infrastruktury w usługach chmurowych (wewnątrz klastra Kubernetes + zasoby wspólne), poszukiwania wąskich gardeł w ustawieniach klastra i wysyłania odpowiednich powiadomień do Slacka.

Mamy klientów z Kubernetes zarówno w popularnych chmurach AWS i GCP, jak i w mniej typowej dla społeczności Linux Azure — ogólnie, na wszystkich platformach wspieranych przez Kubecost. Dla niektórych z nich obliczamy koszty wewnętrznych usług klastra samodzielnie (według metodyki podobnej do tej stosowanej przez Kubecost), a także monitorujemy wydatki na infrastrukturę i staramy się je optymalizować. Dlatego logiczne, że zainteresowała nas możliwość automatyzacji takich zadań.

Kod źródłowy głównego modułu Kubecost jest otwarty na zasadach licencji Open Source (Apache License 2.0). Można go używać swobodnie, a dostępnych funkcji powinno wystarczyć do małych projektów. Jednak biznes to biznes: reszta produktu jest zamknięta, można z niej skorzystać na płatnych subskrypcjach, które również obejmują wsparcie komercyjne. Ponadto autorzy oferują darmową licencję dla małych klastrów (1 klaster z 10 węzłami — w momencie pisania tego artykułu ten limit rozszerzył się do 20 węzłów) oraz okres próbny z pełnymi możliwościami na 1 miesiąc.

Jak to wszystko działa

Zatem główną częścią Kubecost jest aplikacja cost-model, napisana w Go. Helm chart, który opisuje cały system, nazywa się cost-analyzer i w swojej istocie jest zbiorem cost-model z Prometheus, Grafana i kilkoma dashboardami.

Ogólnie rzecz biorąc, model kosztów ma swój interfejs webowy, który pokazuje wykresy oraz szczegółowe statystyki wydatków w formie tabelarycznej, a także oczywiście porady dotyczące optymalizacji kosztów. Zgromadzone na pulpitach Grafana są wcześniejszym etapem rozwoju Kubecost i zawierają w dużej mierze te same dane, co model kosztów, uzupełniając je o standardową statystykę zużycia CPU/pamięci/sieci/pojemności dyskowej w klastrze i jego składnikach.

Jak działa Kubecost?

Model kosztów otrzymuje ceny za usługi poprzez API dostawców chmury.
Następnie, w zależności od typu sprzętu węzła i regionu, obliczana jest kosztowność dla węzłów.
Na podstawie kosztu pracy węzłów każdy końcowy pod dostaje koszt za godzinę użycia procesora, zużycia gigabajta pamięci oraz koszt godziny przechowywania gigabajta danych — w zależności od węzła, na którym działał, lub klasy przechowywania.
Na podstawie kosztów pracy poszczególnych podów oblicza się opłaty według przestrzeni nazw, usług, wdrożeń, StatefulSetów.
Do obliczenia statystyk używane są metryki dostarczane przez kube-state-metrics oraz node-exporter.

Ważne jest, aby pamiętać, że Kubecost domyślnie liczy tylko zasoby dostępne w Kubernetesie. Zewnętrzne bazy danych, serwery GitLab, magazyny S3 i inne usługi, które nie znajdują się w klastrze (nawet jeśli są w tej samej chmurze), są dla niego niewidoczne. Chociaż dla GCP i AWS można dodać klucze własnych kont serwisowych i obliczyć wszystko razem.

Instalacja

Do działania Kubecost wymagane są:

Kubernetes w wersji 1.8 i wyższej;
kube-state-metrics;
Prometheus;
node-exporter.

Tak się złożyło, że w naszych klastrach te wszystkie warunki były spełnione wcześniej, dlatego wystarczyło jedynie wskazać prawidłowy punkt końcowy do dostępu w Prometheusie. Niemniej jednak, oficjalny Helm chart kubecost zawiera wszystko, co potrzebne, aby uruchomić się nawet na „gołym” klastrze.

Można zainstalować Kubecost na kilka sposobów:

Standardowy sposób instalacji opisany w instrukcją na stronie dewelopera. Należy dodać do repozytorium Helm cost-analyzer, a następnie zainstalować chart. Wystarczy tylko przekierować port i dostosować ustawienia do pożądanego stanu ręcznie (za pomocą kubectl) i/lub za pomocą interfejsu webowego modelu kosztów.
Nie próbowaliśmy tego podejścia, ponieważ nie używamy gotowych konfiguracji od zewnętrznych dostawców, jednak wygląda to jak dobry sposób na "spróbowanie dla siebie". Jeśli masz już zainstalowaną część komponentów systemu lub chcesz bardziej szczegółowej konfiguracji, lepiej rozważyć drugą opcję.
Używać w zasadzie tego samego wykresu, ale skonfigurować i zainstalować go samodzielnie w dowolny wygodny sposób.
Jak już wspomniano, poza samym kubecostem, ten wykres zawiera wykresy Grafana i Prometheus, które również można skonfigurować według własnych potrzeb.
Wykres zawiera values.yaml dla cost-analyzer umożliwia konfigurację:
- listy komponentów cost-analyzer, które mają być uruchomione;
- swój punkt końcowy dla Prometheus (jeśli już go masz);
- domeny i inne ustawienia ingressów dla cost-model i Grafana;
- adnotacje dla podów;
- konieczność użycia trwałych magazynów i ich rozmiar.
Pełna lista dostępnych opcji konfiguracji z opisem znajduje się w dokumentacji.
Ponieważ kubecost w podstawowej wersji nie ma funkcji ograniczania dostępu, konieczne będzie natychmiastowe skonfigurowanie basic-auth dla panelu webowego.
Zainstalować tylko rdzeń systemu — cost-model. W tym celu należy mieć w klastrze zainstalowany Prometheus i podać odpowiednią wartość jego adresu w zmiennej prometheusEndpoint dla Helma. Następnie zastosuj zestaw konfiguracji YAML w klastrze.
Znowu, trzeba będzie ręcznie dodać Ingress z basic-auth. I w końcu, konieczne będzie dodanie sekcji do zbierania metryk cost-model w extraScrapeConfigs w konfiguracji 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
```

Co uzyskujemy?

Przy pełnej instalacji mamy do dyspozycji panel webowy kubecost i Grafana z zestawem pulpitów.

Całkowity koszt, wyświetlany na ekranie głównym, w rzeczywistości pokazuje szacunkowy koszt zasobów za miesiąc. To prognozowana cena, która pokazuje koszt korzystania z klastra (w miesiącu) przy obecnym poziomie zużycia zasobów.

Ta metryka jest bardziej do analizy wydatków i ich optymalizacji. Ogólne wydatki za hipotetyczny lipiec w kubecost nie są łatwe do zobaczenia: w tym celu trzeba będzie przejść do rozliczenia. Jednak można zobaczyć wydatki z podziałem na przestrzenie nazw, etykiety, pody za 1/2/7/30/90 dni, czego rozliczenie nigdy nie pokaże.

A propos etykiet. Od razu warto przejść do ustawień i ustawić nazwy etykiet, które będą używane jako dodatkowe kategorie do grupowania wydatków:

Można przypisać do nich dowolne etykiety — to wygodne, jeśli masz już własny system oznaczania.

Można również zmienić adres punktu końcowego API, do którego łączy się model kosztów, dostosować wielkość zniżki w GCP oraz ustawić własne ceny za zasoby i walutę do ich pomiaru (ta funkcja z jakiegoś powodu nie wpływa na całkowity koszt).

Kubecost potrafi pokazywać różne problemy w klastrze (a nawet wysyłać powiadomienia w przypadku zagrożenia). Niestety, opcja nie jest konfigurowalna, więc jeśli masz środowiska deweloperskie i są one używane, możesz ciągle obserwować coś podobnego:

Ważnym narzędziem jest Cluster Savings. Mierzy ono aktywność podów (zużycie zasobów, w tym też sieciowych), a także oblicza, ile pieniędzy i na czym można zaoszczędzić.

Może się wydawać, że porady dotyczące optymalizacji — to dość oczywiste rzeczy, jednak doświadczenie podpowiada, że i tak warto zwrócić na to uwagę. W szczególności śledzi się aktywność sieciową podów (Kubecost sugeruje zwrócenie uwagi na nieaktywnych), porównuje zapotrzebowanie i rzeczywiste zużycie pamięci i CPU, a także CPU używane przez węzły klastra (sugeruje zredukowanie kilku węzłów do jednego), obciążenie dysków oraz jeszcze kilkanaście innych parametrów.

Tak jak w każdym przypadku związanym z optymalizacją, do optymalizacji zasobów na podstawie danych Kubecost należy podchodzić ostrożnie. Na przykład, Cluster Savings sugeruje usunięcie węzłów, twierdząc, że jest to bezpieczne, jednak nie uwzględnia istnienia wyborów węzłów podów i taintów, które nie występują na pozostałych węzłach. Poza tym, nawet autorzy produktu w swojej niedawnym artykule (przy okazji, może być to bardzo przydatne dla tych, którzy interesują się tematem projektu) zalecają, aby nie rzucać się na optymalizację wydatków, lecz podchodzić do tego zagadnienia z rozwagą.

Podsumowanie

Po używaniu kubecost przez miesiąc na kilku projektach możemy stwierdzić, że to interesujące (a także łatwe do nauczenia i zainstalowania) narzędzie do analizy i optymalizacji wydatków na usługi dostawców chmury używanych dla klastrów Kubernetes. Obliczenia są dość precyzyjne: w naszych eksperymentach zgadzały się z tym, co w rzeczywistości wymagali dostawcy.

Nie obyło się bez wad: występują drobne błędy, a możliwości funkcjonalne w niektórych miejscach nie pokrywają specyficznych potrzeb niektórych projektów. Jednak jeśli chcesz szybko zrozumieć, gdzie wydawane są pieniądze i co można „obciąć”, aby stabilnie obniżyć rachunki za usługi chmurowe o 5-30% (co miało miejsce w naszym przypadku) — to świetna opcja.