Kubecost-anmeldelse for å spare penger på Kubernetes i skyene

For tiden overfører flere og flere selskaper sin infrastruktur fra maskinvareservere og egne virtuelle maskiner til skyen. Denne løsningen er enkel å forklare: det er ingen grunn til å bekymre seg for maskinvare, klyngen konfigureres enkelt på mange forskjellige måter... og viktigst av alt, eksisterende teknologier (som Kubernetes) gjør det mulig å enkelt skalere datakraft avhengig av belastningen .

Det økonomiske aspektet er alltid viktig. Verktøyet som diskuteres i denne artikkelen er utviklet for å redusere budsjetter når du bruker skyinfrastruktur med Kubernetes.

Innledning

Kubecost er en kalifornisk oppstart fra Google, som lager en løsning for å beregne infrastrukturkostnader i skytjenester (innenfor en Kubernetes-klynge + delte ressurser), søker etter flaskehalser i klyngeinnstillinger og sender passende varsler til Slack.

Vi har kunder med Kubernetes både i de kjente AWS- og GCP-skyene, og, mer sjeldent for Linux-fellesskapet, Azure – generelt på alle plattformer som støttes av Kubecost. For noen av dem beregner vi kostnadene for intra-klyngetjenester selv (ved hjelp av en metode som ligner på den som brukes av Kubecost), og overvåker også infrastrukturkostnadene og prøver å optimalisere dem. Derfor er det logisk at vi var interessert i muligheten for å automatisere slike oppgaver.

Kildekoden til hovedmodulen til Kubecost er åpen under vilkårene for Open Source-lisensen (Apache License 2.0). Den kan brukes fritt og de tilgjengelige funksjonene skal være tilstrekkelige for små prosjekter. Imidlertid er virksomhet forretning: resten av produktet er stengt, det kan brukes av betalte abonnementer, som også innebærer kommersiell støtte. I tillegg tilbyr forfatterne en gratis lisens for små klynger (1 klynge med 10 noder - under skrivingen av denne artikkelen har denne grensen utvidet seg til 20 noder) eller en prøveperiode med full kapasitet i 1 måned.

Hvordan alt fungerer

Så hoveddelen av Kubecost er applikasjonen kostnadsmodell, skrevet i Go. Et rordiagram som beskriver hele systemet kalles kostnadsanalysator og i kjernen er en sammenstilling fra en kostnadsmodell med Prometheus, Grafana og flere dashbord.

Generelt sett har cost-model et eget webgrensesnitt, som viser grafer og detaljert statistikk over kostnader i tabellform, samt selvfølgelig tips for å optimalisere kostnadene. Dashboardene som presenteres i Grafana er et tidligere stadium i utviklingen av Kubecost og inneholder mye de samme dataene som kostnadsmodellen, og supplerer dem med vanlig statistikk om forbruk av CPU/minne/nettverk/diskplass i klyngen og dens komponenter. .

Hvordan fungerer Kubecost?

• Kostnadsmodell mottar priser for tjenester gjennom APIen til skyleverandører.
• Videre, avhengig av jerntypen til noden og regionen, beregnes kostnaden per node.
• Basert på kostnadene for å kjøre noder, får hver bladpod en kostnad per time CPU-bruk, per gigabyte forbrukt minne og per time per gigabyte data lagret - avhengig av noden den kjørte på eller lagringsklassen.
• Basert på kostnadene ved drift av individuelle pods, beregnes betaling for navneområder, tjenester, distribusjoner, StatefulSets.
• Statistikk beregnes ved hjelp av beregninger levert av kube-state-metrics og node-exporter.

Det er viktig å tenke på at Kubecost som standard teller kun ressurser tilgjengelig i Kubernetes. Eksterne databaser, GitLab-servere, S3-lagringer og andre tjenester som ikke er i klyngen (selv om de ligger i samme sky) er ikke synlige for den. Selv om du for GCP og AWS kan legge til nøklene til tjenestekontoene dine og beregne alt sammen.

Installasjon

Kubecost krever:

• Kubernetes versjon 1.8 og høyere;
• kube-state-metrikker;
• Prometheus;
• node-eksportør.

Det skjedde slik at i våre klynger var alle disse betingelsene oppfylt på forhånd, så det viste seg at det var nok å bare spesifisere riktig endepunkt for tilgang til Prometheus. Det offisielle kubecost Helm-diagrammet inneholder imidlertid alt du trenger for å kjøre på en naken klynge.

Det er flere måter å installere Kubecost på:

1. Standard installasjonsmetode beskrevet i instruksjoner på utviklerens nettsted. Obligatorisk legg til kostnadsanalyselageret til Helm, og installer deretter diagrammet. Alt som gjenstår er å videresende porten din og justere innstillingene til ønsket tilstand manuelt (via kubectl) og/eller ved å bruke kostnadsmodellens webgrensesnitt.

   Vi har ikke engang prøvd denne metoden, siden vi ikke bruker ferdige konfigurasjoner fra tredjeparter, men det ser ut som et godt alternativ "bare prøv det selv". Hvis du allerede har noen av systemkomponentene installert eller du vil ha mer finjustering, er det bedre å vurdere den andre banen.

2. Bruk i hovedsak samme diagram, men konfigurer og installer det selv på en hvilken som helst praktisk måte.

   Som allerede nevnt, i tillegg til selve kubecost, inneholder dette diagrammet Grafana- og Prometheus-diagrammer, som også kan tilpasses etter ønske.

   Tilgjengelig på diagrammet values.yaml for kostnadsanalysator lar deg konfigurere:

   • en liste over kostnadsanalysatorkomponenter som må distribueres;
   • endepunktet ditt for Prometheus (hvis du allerede har et);
   • domener og andre inngangsinnstillinger for kostnadsmodell og Grafana;
   • merknader for pods;
   • behovet for å bruke permanent lagring og dens størrelse.

   En komplett liste over tilgjengelige konfigurasjonsalternativer med beskrivelser er tilgjengelig i dokumentasjon.

   Siden kubecost i sin grunnleggende versjon ikke kan begrense tilgangen, må du umiddelbart konfigurere basic-auth for nettpanelet.

3. Installere bare systemkjernen - kostnadsmodell. For å gjøre dette må du ha Prometheus installert i klyngen og spesifisere den tilsvarende verdien til adressen i variabelen prometheusEndpoint for Helm. Etter det - søk sett med YAML-konfigurasjoner i klyngen.

   Igjen, du må legge til Ingress manuelt med basic-auth. Til slutt må du legge til en seksjon for å samle kostnadsmodellberegninger i extraScrapeConfigs i Prometheus-konfigurasjonen:

   - 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

Hva får vi?

Med full installasjon disponerer vi kubecost og Grafana webpanel med et sett med dashbord.

Total kostnad, som vises på hovedskjermen, viser faktisk de estimerte ressurskostnadene for måneden. Dette prosjektert pris som reflekterer kostnaden ved å bruke klyngen (per måned) på dagens nivå av ressursforbruk.

Denne beregningen er mer for å analysere utgifter og optimalisere dem. Det er ikke veldig praktisk å se på de totale kostnadene for abstrakt juli i kubecost: du må gjøre dette gå til fakturering. Men du kan se kostnadene fordelt på navneområder, etiketter, pods for 1/2/7/30/90 dager, som fakturering aldri vil vise deg.

Apropos etiketter. Du bør umiddelbart gå til innstillingene og angi navnene på etikettene som skal brukes som tilleggskategorier for grupperingskostnader:

Du kan henge alle etiketter på dem - praktisk hvis du allerede har ditt eget merkesystem.

Også der kan du endre adressen til API-endepunktet som kostnadsmodellen kobles til, justere rabattstørrelsen i GCP og angi dine egne priser for ressurser og valuta for måling (av en eller annen grunn påvirker ikke funksjonen totalkostnad).

Kubecost kan vise ulike problemer i klyngen (og til og med varsle i tilfelle fare). Dessverre er alternativet ikke konfigurerbart, og derfor, hvis du har miljøer for utviklere og bruker dem, vil du stadig se noe slikt:

Et viktig verktøy - Klyngesparing. Den måler aktiviteten til pods (forbruk av ressurser, inkludert nettverk), og beregner også hvor mye penger og hva du kan spare på.

Det kan virke som om optimaliseringstips er ganske åpenbare, men erfaringen tilsier at det fortsatt er noe å se på. Spesielt overvåkes nettverksaktiviteten til pods (Kubecost foreslår å ta hensyn til inaktive), det forespurte og faktiske minnet og CPU-forbruket sammenlignes, samt CPU-en som brukes av klyngenoder (antyder å kollapse flere noder til én), disk belastning og et par dusin flere parametere.

Som med ethvert optimaliseringsproblem krever optimalisering av ressurser basert på Kubecost-data: behandle med forsiktighet. For eksempel foreslår Cluster Savings å slette noder, og hevder at det er trygt, men tar ikke hensyn til tilstedeværelsen av nodevelgere og flekker i podene som er utplassert på dem som ikke er tilgjengelige på andre noder. Og generelt, selv forfatterne av produktet i deres nylig artikkel (det kan forresten være veldig nyttig for de som er interessert i temaet for prosjektet) det anbefales å ikke skynde seg hodestups inn i kostnadsoptimalisering, men å nærme seg problemet med omtanke.

Resultater av

Etter å ha brukt kubecost i en måned på et par prosjekter, kan vi konkludere med at det er et interessant (og også enkelt å lære og installere) verktøy for å analysere og optimalisere kostnader for tjenestene til skyleverandører som brukes for Kubernetes-klynger. Beregningene viser seg å være svært nøyaktige: I våre eksperimenter falt de sammen med det leverandørene faktisk krevde.

Det er også noen ulemper: det er ikke-kritiske feil, og noen steder dekker ikke funksjonaliteten de behovene som er spesifikke for enkelte prosjekter. Men hvis du raskt trenger å forstå hvor pengene går og hva som kan "kuttes" for å konsekvent redusere regningen for skytjenester med 5-30 % (dette er hva som skjedde i vårt tilfelle), er dette et flott alternativ .

PS

Les også på bloggen vår:

• «Autoskalering og ressursadministrasjon i Kubernetes (oversikt og videorapport)";
• «Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt";
• «Kubernetes tips og triks: om nodetildeling og lasting av nettapplikasjoner'.

Kilde: www.habr.com