🥇Översikt av Kubecost för kostnadsbesparing på Kubernetes i molnet

Fler och fler företag flyttar för närvarande sin infrastruktur från fysiska servrar och egna virtuella maskiner till molnet. Det är lätt att förklara detta beslut: det finns inget behov av att ta hand om hårdvaran, klustret kan enkelt konfigureras på många olika sätt... och viktigast av allt — de befintliga teknologierna (som Kubernetes) gör det möjligt att enkelt skala beräkningskapaciteten efter belastningen.

Den ekonomiska aspekten är alltid viktig. Verktyget som kommer att diskuteras i denna artikel syftar till att bidra till budgetbesparingar vid användning av molninfrastruktur med Kubernetes.

Introduktion

Kubecost — en kalifornisk startup från tidigare Google-anställda som skapar en lösning för kostnadsberäkning av infrastruktur i molntjänster (inom Kubernetes-klustret + gemensamma resurser), identifiering av flaskhalsar i klusterinställningar och sändning av relevanta meddelanden till Slack.

Vi har kunder med Kubernetes både i vanliga moln som AWS och GCP, samt i det mer sällsynta för Linux-gemenskapen Azure — på alla plattformar som stöds av Kubecost. För vissa av dem beräknar vi kostnader för interna klustertjänster på egen hand (med en metodik liknande den som Kubecost använder), samt övervakar infrastrukturen och försöker optimera kostnaderna. Därför är det logiskt att vi blev intresserade av möjligheten att automatisera sådana uppgifter.

Källkoden för huvudmodulen av Kubecost är öppen under en Open Source-licens (Apache License 2.0). Den kan användas fritt, och de tillgängliga funktionerna bör räcka för små projekt. Men affärer är affärer: resten av produkten är stängd och kan användas genom betalda prenumerationer, som också innebär kommersiellt stöd. Dessutom erbjuder författarna en gratis licens för små kluster (1 kluster med 10 noder — vid tidpunkten för artikelskrivningen hade denna gräns utvidgats till 20 noder) eller en provperiod med fulla funktioner under 1 månad.

Så här är det uppbyggt

Så, den huvudsakliga delen av Kubecost är en applikation cost-model, skriven i Go. Helm-diagrammet som beskriver hela systemet kallas cost-analyzer och är i huvudsak en sammansättning av cost-model med Prometheus, Grafana och flera instrumentpaneler.

Rent generellt har kostnadsmodellen sitt eget webbgränssnitt som visar diagram och detaljerad statistik över kostnader i tabellformat, samt självklart råd för att optimera utgifter. De dashboards som presenteras i Grafana är en tidigare utvecklingsfas av Kubecost och innehåller till stor del samma data som kostnadsmodellen, kompletterat med den vanliga statistiken för användning av CPU/minne/nätverks- och lagringsutrymme i klustret och dess komponenter.

Hur fungerar Kubecost?

Kostnadsmodellen får priser för drift via API:er från molnleverantörer.
Därefter beräknas kostnaden per nod beroende på hårdvarutyp och region.
Baserat på kostnaden för nodernas arbete får varje slutgiltig pod en kostnad per timme för användning av processorn, minnesanvändning per gigabyte och kostnad per timme för lagring av en gigabyte data — beroende på noden som den körs på, eller lagringstyp.
Baserat på kostnaden för individuella poddar beräknas avgiften per namnrymd, tjänster, distributioner och StatefulSets.
För att beräkna statistiken används metrik som tillhandahålls av kube-state-metrics och node-exporter.

Det är viktigt att notera att Kubecost som standard bara räknar resurser som är tillgängliga i Kubernetes. Externa databaser, GitLab-servrar, S3-lagring och andra tjänster som inte finns i klustret (även om de finns i samma moln) är osynliga för det. Men för GCP och AWS kan man lägga till nycklar till sina tjänstekonton och räkna allt tillsammans.

Installation

För att Kubecost ska fungera krävs:

Kubernetes version 1.8 eller högre;
kube-state-metrics;
Prometheus;
node-exporter.

Det visade sig att alla dessa villkor redan var uppfyllda i våra kluster, så det var bara nödvändigt att ange rätt slutpunkt för att få tillgång till Prometheus. Ändå innehåller den officiella Helm-diagrammet för kubecost allt som behövs för att starta även på en 'ren' kluster.

Kubecost kan installeras på flera sätt:

Den standardmetod för installation som beskrivs i instruktionerna på utvecklarens webbplats. Man måste lägga till Helm-repot för kostnadsanalys, och därefter installera diagrammet. Det återstår bara att mappa en port och justera inställningarna manuellt (via kubectl) och/eller med hjälp av webbgränssnittet för kostnadsmodellen.
Denna metod har vi inte ens prövat, eftersom vi inte använder några externa färdiga konfigurationer, men den verkar vara ett bra alternativ för "att bara testa själv". Om du redan har installerat delar av systemkomponenterna eller om du vill ha en mer detaljerad konfiguration, är det bättre att överväga det andra alternativet.
Använda i huvudsak samma chart, men konfigurera och installera det själva på vilket sätt som helst.
Som redan nämnts innehåller detta chart förutom kubecost även charts för Grafana och Prometheus, vilka också kan anpassas efter behov.
Det som ingår i chartet values.yaml för cost-analyzer tillåter att konfigurera:
- listan över komponenterna i cost-analyzer som behöver deployas;
- din egen endpoint för Prometheus (om du redan har en);
- domäner och andra ingångsinställningar för cost-model och Grafana;
- annoteringar för poddar;
- behovet av att använda permanenta lagringsenheter och deras storlek.
En fullständig lista över tillgängliga konfigurationsalternativ med beskrivning finns i dokumentationen.
Eftersom kubecost i sin grundversion inte kan begränsa åtkomst, måste basic-auth för webbpanelen konfigureras direkt.
Installera bara kärnan i systemet — cost-model. För detta krävs att Prometheus är installerad i klustret och att motsvarande värde för dess adress anges i variabeln prometheusEndpoint för Helm. Efter det — tillämpa uppsättningen av YAML-konfigurationer i klustret.
Återigen måste Ingress med basic-auth läggas till manuellt. Slutligen måste en sektion för insamling av metrik för cost-model läggas till i extraScrapeConfigs i Prometheus-konfigurationen:
```
- 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
```

Vad får vi?

Vid en fullständig installation får vi tillgång till webbpanelen kubecost och Grafana med en uppsättning dashboards.

Total kostnad, som visas på huvudskärmen, visar faktiskt den beräknade kostnaden för resurser under en månad. Detta är den prognostiserade prisen, som visar kostnaden för att använda klustret (per månad) vid nuvarande resursanvändningsnivå.

Denna metrik är främst för att analysera utgifter och deras optimering. Att se de totala kostnaderna för en abstrakt juli i kubecost är inte särskilt bekvämt: för det tvingas du gå till faktureringen. Men du kan se utgifterna uppdelat efter namnrymder, etiketter och poddar över 1/2/7/30/90 dagar, vilket faktureringen aldrig kommer att visa.

För att inte tala om etiketter. Gör en direkt ingång i inställningarna och ställ in namnen på etiketter som kommer att användas som ytterligare kategorier för gruppering av kostnader:

På dem kan du hänga vilka etiketter som helst - praktiskt om du redan har ditt eget märkningssystem.

Där kan du också ändra adressen till API-endpointen som cost-model ansluter till, ställa in storleken på rabatten i GCP och ange egna priser på resurser och valuta för deras mätning (funktionen påverkar av någon anledning inte den totala kostnaden).

Kubecost kan visa olika problem i klustret (och till och med larma vid fara). Tyvärr kan alternativet inte ställas in, så om du har miljöer för utvecklare och de används, kan du kontinuerligt bevaka något liknande:

Ett viktigt verktyg är Cluster Savings. Det mäter aktiviteten hos poddar (resursförbrukning, inklusive nätverksanvändning), samt beräknar hur mycket pengar och på vad som kan sparas.

Det kan verka som att optimeringsråden är ganska uppenbara, men erfarenhet visar att det fortfarande finns mycket att titta på. I synnerhet spåras nätverksaktiviteten hos poddar (Kubecost föreslår att du uppmärksammar inaktiva), jämförs begärd och verklig förbrukning av minne och CPU, samt CPU som används av klustrets noder (föreslår att flera noder kan slås ihop till en), belastningen på diskarna och ett par dussin andra parametrar.

Som med alla frågor som rör optimering, bör optimering av resurser baserad på data från Kubecost behandlas med försiktighet. Till exempel föreslår Cluster Savings att ta bort noder och hävdar att detta är säkert, men tar inte hänsyn till att de distribuerade poddarna har node-selectors och taints som saknas på de andra noderna. Dessutom rekommenderar även produktens skapare i sin en nyligen publicerad artikel (för övrigt kan den vara ganska användbar för dem som är intresserade av projektets ämne) att man inte ska ge sig hän åt kostnadsoptimering utan att tänka efter.

Sammanfattning

Efter att ha använt kubecost under en månad på några projekt kan vi konstatera att det är ett intressant (och lätt att lära sig och installera) verktyg för analys och optimering av kostnader för tjänster från molnleverantörer som används för Kubernetes-kluster. Beräkningarna visar sig vara ganska exakta: i våra experiment matchade de vad leverantörerna faktiskt krävde.

Det finns också nackdelar: det finns vissa mindre kritiska buggar och funktionerna täcker ibland inte de specifika behoven för vissa projekt. Men om du snabbt behöver förstå vart pengarna går och vad som kan "skäras ner" för att stabilt sänka kostnaden för molntjänster med 5-30 % (vilket hände i vårt fall), så är detta ett utmärkt alternativ.

P.S.

Läs även i vår blogg:

Källa: habr.com

Översikt av Kubecost för att spara pengar på Kubernetes i moln