Kubecost recension för att spara pengar på Kubernetes i molnen

För närvarande överför allt fler företag sin infrastruktur från hårdvaruservrar och sina egna virtuella maskiner till molnet. Denna lösning är lätt att förklara: det finns ingen anledning att oroa sig för hårdvara, klustret är enkelt att konfigurera på många olika sätt... och viktigast av allt, befintliga teknologier (som Kubernetes) gör det möjligt att helt enkelt skala datorkraft beroende på belastningen .

Den ekonomiska aspekten är alltid viktig. Verktyget som diskuteras i den här artikeln är utformat för att hjälpa till att minska budgetarna när du använder molninfrastruktur med Kubernetes.

Inledning

Kubecost är en kalifornisk startup från Google, som skapar en lösning för att beräkna infrastrukturkostnader i molntjänster (inom ett Kubernetes-kluster + delade resurser), söker efter flaskhalsar i klusterinställningar och skickar lämpliga aviseringar till Slack.

Vi har kunder med Kubernetes både i de välbekanta AWS- och GCP-molnen, och, mer sällan för Linux-gemenskapen, Azure - i allmänhet på alla plattformar som stöds av Kubecost. För vissa av dem beräknar vi själva kostnaderna för klustertjänster (med en metod liknande den som används av Kubecost), och övervakar även infrastrukturkostnader och försöker optimera dem. Därför är det logiskt att vi var intresserade av möjligheten att automatisera sådana uppgifter.

Källkoden för huvudmodulen Kubecost är öppen under villkoren för Open Source-licensen (Apache License 2.0). Den kan användas fritt och de tillgängliga funktionerna bör vara tillräckliga för små projekt. Men affärer är affärer: resten av produkten är stängd, den kan användas av betalda prenumerationer, vilket också innebär kommersiellt stöd. Dessutom erbjuder författarna en gratis licens för små kluster (1 kluster med 10 noder - under skrivningen av denna artikel har denna gräns utökats till 20 noder) eller en provperiod med full kapacitet i 1 månad.

Hur allt fungerar

Så, huvuddelen av Kubecost är applikationen kostnadsmodell, skrivet i Go. Ett roderdiagram som beskriver hela systemet kallas kostnadsanalysator och kärnan är en montering från en kostnadsmodell med Prometheus, Grafana och flera instrumentpaneler.

Generellt sett har cost-model ett eget webbgränssnitt som visar grafer och detaljerad statistik över kostnader i tabellform, samt givetvis tips för att optimera kostnader. Instrumentpanelerna som presenteras i Grafana är ett tidigare skede i utvecklingen av Kubecost och innehåller mycket av samma data som kostnadsmodellen, och kompletterar dem med den vanliga statistiken över förbrukning av CPU/minne/nätverk/diskutrymme i klustret och dess komponenter.

Hur fungerar Kubecost?

• Kostnadsmodellen får priser för tjänster genom molnleverantörernas API.
• Vidare, beroende på nodens järntyp och regionen, beräknas kostnaden per nod.
• Baserat på kostnaden för att köra noder får varje slutpod en kostnad per timme CPU-användning, per gigabyte förbrukat minne och per timme per gigabyte lagrad data - beroende på noden den kördes på eller lagringsklassen.
• Baserat på kostnaden för att driva enskilda pods, beräknas betalningen för namnutrymmen, tjänster, distributioner, StatefulSets.
• Statistiken beräknas med hjälp av mätvärden som tillhandahålls av kube-state-metrics och node-exporter.

Det är viktigt att tänka på att Kubecost som standard räknar endast resurser som är tillgängliga i Kubernetes. Externa databaser, GitLab-servrar, S3-lagringar och andra tjänster som inte finns i klustret (även om de ligger i samma moln) är inte synliga för det. Även om du för GCP och AWS kan lägga till nycklarna till dina tjänstekonton och beräkna allt tillsammans.

Installation

Kubecost kräver:

• Kubernetes version 1.8 och senare;
• kube-state-metrics;
• Prometheus;
• nod-exportör.

Det hände så att i våra kluster var alla dessa villkor uppfyllda i förväg, så det visade sig att det var tillräckligt att bara ange rätt slutpunkt för åtkomst till Prometheus. Det officiella kubecost Helm-diagrammet innehåller dock allt du behöver för att köra på ett blott kluster.

Det finns flera sätt att installera Kubecost:

1. Standardinstallationsmetod som beskrivs i Avstånd på utvecklarens webbplats. Obligatoriskt lägg till kostnadsanalysarkivet till Helm och installera sedan diagrammet. Allt som återstår är att vidarebefordra din port och justera inställningarna till önskat tillstånd manuellt (via kubectl) och/eller med hjälp av kostnadsmodellens webbgränssnitt.

   Vi har inte ens provat den här metoden, eftersom vi inte använder färdiga konfigurationer från tredje part, men det ser ut som ett bra alternativ "bara prova det själv". Om du redan har några av systemkomponenterna installerade eller om du vill ha mer finjustering är det bättre att överväga den andra vägen.

2. Använd i huvudsak samma diagram, men konfigurera och installera det själv på något bekvämt sätt.

   Som redan nämnts, förutom själva kubecost, innehåller detta diagram Grafana- och Prometheus-diagram, som även kan anpassas efter önskemål.

   Finns på diagrammet values.yaml för kostnadsanalysator kan du konfigurera:

   • en lista över kostnadsanalyskomponenter som behöver distribueras;
   • din slutpunkt för Prometheus (om du redan har en);
   • domäner och andra ingångsinställningar för kostnadsmodell och Grafana;
   • anteckningar för kapslar;
   • behovet av att använda permanent förvaring och dess storlek.

   En komplett lista över tillgängliga konfigurationsalternativ med beskrivningar finns i dokumentation.

   Eftersom kubecost i sin grundversion inte kan begränsa åtkomsten, måste du omedelbart konfigurera basic-auth för webbpanelen.

3. upprätta bara systemkärnan - kostnadsmodell. För att göra detta måste du ha Prometheus installerad i klustret och ange motsvarande värde för dess adress i variabeln prometheusEndpoint för Helm. Efter det - ansök uppsättning YAML-konfigurationer i klustret.

   Återigen måste du lägga till Ingress manuellt med basic-auth. Slutligen måste du lägga till ett avsnitt för att samla in kostnadsmodellmått 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:
       - <адрес вашего сервиса kubecost>
       type: 'A'
       port: 9003

Vad får vi?

Med en komplett installation har vi till vårt förfogande kubecost och Grafana webbpanel med en uppsättning instrumentpaneler.

Total kostnad, som visas på huvudskärmen, visar faktiskt den uppskattade kostnaden för resurser för månaden. Detta förutsägbar pris som återspeglar kostnaden för att använda klustret (per månad) vid den aktuella resursförbrukningen.

Detta mått är mer för att analysera utgifter och optimera dem. Det är inte särskilt bekvämt att titta på de totala kostnaderna för abstrakt juli i kubecost: du måste gå till fakturering. Men du kan se kostnaderna uppdelade efter namnutrymmen, etiketter, poddar för 1/2/7/30/90 dagar, vilket fakturering aldrig kommer att visa dig.

På tal om etiketter. Du bör omedelbart gå till inställningarna och ange namnen på etiketterna som kommer att användas som ytterligare kategorier för grupperingskostnader:

Du kan hänga vilka etiketter som helst på dem - bekvämt om du redan har ett eget etikettsystem.

Även där kan du ändra adressen till API-slutpunkten som kostnadsmodellen ansluter till, justera rabattstorleken i GCP och ställa in dina egna priser för resurser och valuta för deras mätning (av någon anledning påverkar funktionen inte totalkostnaden).

Kubecost kan visa olika problem i klustret (och till och med larma vid fara). Tyvärr är alternativet inte konfigurerbart, och därför, om du har miljöer för utvecklare och använder dem, kommer du ständigt att se något i stil med detta:

Ett viktigt verktyg - Klusterbesparingar. Den mäter aktiviteten hos poddar (resursförbrukning, inklusive nätverksresurser), och beräknar även hur mycket pengar och vad du kan spara på.

Det kan tyckas att optimeringstips är ganska självklara, men erfarenheten talar för att det fortfarande finns något att titta på. Speciellt övervakas nätverksaktiviteten för pods (Kubecost föreslår att man uppmärksammar inaktiva), det begärda och faktiska minnet och CPU-förbrukningen jämförs, liksom CPU:n som används av klusternoder (föreslår att flera noder kollapsar till en), disk belastning och ytterligare ett par dussin parametrar.

Som med alla optimeringsproblem kräver optimering av resurser baserat på Kubecost-data: behandla med försiktighet. Till exempel föreslår Cluster Savings att du tar bort noder, hävdar att det är säkert, men tar inte hänsyn till närvaron av nodväljare och fläckar i podarna som är utplacerade på dem och som inte är tillgängliga på andra noder. Och i allmänhet, även författarna av produkten i deras senaste artikeln (förresten, det kan vara mycket användbart för dem som är intresserade av ämnet för projektet) det rekommenderas att inte rusa handlöst in i kostnadsoptimering, utan att närma sig frågan med eftertänksamhet.

Resultat av

Efter att ha använt kubecost i en månad på ett par projekt kan vi dra slutsatsen att det är ett intressant (och även lätt att lära sig och installera) verktyg för att analysera och optimera kostnader för tjänster från molnleverantörer som används för Kubernetes-kluster. Beräkningarna visar sig vara mycket exakta: i våra experiment sammanföll de med vad leverantörerna faktiskt krävde.

Det finns också några nackdelar: det finns icke-kritiska buggar, och på vissa ställen täcker inte funktionaliteten de behov som är specifika för vissa projekt. Men om du snabbt behöver förstå vart pengarna tar vägen och vad som kan "klippas" för att konsekvent minska räkningen för molntjänster med 5-30 % (detta är vad som hände i vårt fall), är detta ett utmärkt alternativ .

PS

Läs även på vår blogg:

• «Autoskalning och resurshantering i Kubernetes (översikt och videorapport)";
• «Kubernetes äventyr Dailymotion: skapa infrastruktur i molnen + på plats";
• «Kubernetes tips och tricks: om nodtilldelning och webbapplikationsladdningar".

Källa: will.com