I øjeblikket overfører flere og flere virksomheder deres infrastruktur fra hardwareservere og deres egne virtuelle maskiner til skyen. Denne løsning er nem at forklare: der er ingen grund til at bekymre sig om hardware, klyngen er let konfigureret på mange forskellige måder... og vigtigst af alt, eksisterende teknologier (som Kubernetes) gør det muligt simpelthen at skalere computerkraft afhængigt af belastningen .
Det økonomiske aspekt er altid vigtigt. Værktøjet diskuteret i denne artikel er designet til at hjælpe med at reducere budgetter, når du bruger cloud-infrastruktur med Kubernetes.
Indledning
er en californisk startup fra Google, der skaber en løsning til beregning af infrastrukturomkostninger i cloud-tjenester (inden for en Kubernetes-klynge + delte ressourcer), søger efter flaskehalse i klyngeindstillinger og sender passende notifikationer til Slack.
Vi har kunder med Kubernetes både i de velkendte AWS- og GCP-skyer, og, mere sjældent for Linux-fællesskabet, Azure - generelt på alle platforme, der understøttes af Kubecost. For nogle af dem beregner vi selv omkostningerne ved intra-cluster-tjenester (ved hjælp af en metode svarende til den, der bruges af Kubecost), og overvåger også infrastrukturomkostninger og forsøger at optimere dem. Derfor er det logisk, at vi var interesserede i muligheden for at automatisere sådanne opgaver.
Kildekoden til hoved-Kubecost-modulet er åben under vilkårene i Open Source-licensen (Apache License 2.0). Det kan bruges frit, og de tilgængelige funktioner skulle være tilstrækkelige til små projekter. Men forretning er forretning: resten af produktet er lukket, det kan bruges af , hvilket også indebærer kommerciel støtte. Derudover tilbyder forfatterne en gratis licens til små klynger (1 klynge med 10 noder - under skrivningen af denne artikel er denne grænse udvidet til 20 noder) eller en prøveperiode med fuld kapacitet i 1 måned.
Hvordan det hele fungerer
Så hoveddelen af Kubecost er applikationen , skrevet i Go. Et Helm-diagram, der beskriver hele systemet, kaldes og i sin kerne er en samling fra en omkostningsmodel med Prometheus, Grafana og flere dashboards.
Generelt har cost-model sin egen webgrænseflade, som viser grafer og detaljerede statistikker over omkostninger i tabelform, samt naturligvis tips til optimering af omkostninger. Dashboards præsenteret i Grafana er et tidligere trin i udviklingen af Kubecost og indeholder stort set de samme data som omkostningsmodellen og supplerer dem med den sædvanlige statistik over forbruget af CPU/hukommelse/netværk/diskplads i klyngen og dens komponenter. .
Hvordan virker Kubecost?
- Omkostningsmodellen modtager priser for tjenester gennem cloud-udbyderes API.
- Yderligere, afhængigt af knudepunktets jerntype og regionen, beregnes omkostningerne pr. knudepunkt.
- Baseret på omkostningerne ved at køre noder, får hver leaf pod en pris pr. time af CPU-brug, pr. gigabyte forbrugt hukommelse og pr. time pr. gigabyte lagrede data - afhængigt af noden, den kørte på, eller lagerklassen.
- Baseret på omkostningerne ved drift af individuelle pods, beregnes betaling for navnerum, tjenester, implementeringer, StatefulSets.
- Statistikker beregnes ved hjælp af metrics leveret af kube-state-metrics og node-exporter.
Det er vigtigt at overveje, at Kubecost tæller som standard kun tilgængelige ressourcer i Kubernetes. Eksterne databaser, GitLab-servere, S3-lager og andre tjenester, der ikke er i klyngen (selvom de er placeret i samme sky), er ikke synlige for den. Selvom du for GCP og AWS kan tilføje nøglerne til dine servicekonti og beregne alt sammen.
Installation
Kubecost kræver:
- Kubernetes version 1.8 og nyere;
- kube-state-metrics;
- Prometheus;
- node-eksportør.
Det skete sådan, at i vores klynger var alle disse betingelser opfyldt på forhånd, så det viste sig, at det var nok bare at angive det korrekte slutpunkt for adgang til Prometheus. Det officielle kubecost Helm-diagram indeholder dog alt, hvad du behøver for at køre på en blottet klynge.
Der er flere måder at installere Kubecost på:
- Standard installationsmetode beskrevet i på udviklerens websted. Påkrævet tilføj cost-analyzer-lageret til Helm, og installer derefter diagrammet. Det eneste, der er tilbage, er at videresende din port og justere indstillingerne til den ønskede tilstand manuelt (via kubectl) og/eller ved at bruge omkostningsmodellens webgrænseflade.
Vi har ikke engang prøvet denne metode, da vi ikke bruger færdige tredjepartskonfigurationer, men det ser ud til at være en god "prøv det selv" mulighed. Hvis du allerede har nogle af systemkomponenterne installeret, eller du ønsker mere finjustering, er det bedre at overveje den anden vej.
- Brug i det væsentlige , men konfigurer og installer det selv på enhver bekvem måde.
Som allerede nævnt indeholder dette diagram foruden selve kubecosten Grafana og Prometheus diagrammer, som også kan tilpasses efter ønske.
Tilgængelig på diagrammet
values.yamlfor cost-analyzer giver dig mulighed for at konfigurere:- en liste over omkostningsanalysekomponenter, der skal implementeres;
- dit endepunkt for Prometheus (hvis du allerede har et);
- domæner og andre indgangsindstillinger for omkostningsmodel og Grafana;
- anmærkninger til bælg;
- behovet for at bruge permanent opbevaring og dets størrelse.
En komplet liste over tilgængelige konfigurationsmuligheder med beskrivelser er tilgængelig i .
Da kubecost i sin grundlæggende version ikke kan begrænse adgangen, skal du straks konfigurere basic-auth for webpanelet.
- etablere kun systemkernen - omkostningsmodel. For at gøre dette skal du have Prometheus installeret i klyngen og angive den tilsvarende værdi af dens adresse i variablen
prometheusEndpointfor Helm. Derefter - ansøg i klyngen.Igen bliver du nødt til manuelt at tilføje Ingress med basic-auth. Endelig skal du tilføje en sektion til indsamling af omkostningsmodel-metrics i
extraScrapeConfigsi 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
Hvad får vi?
Med en fuld installation har vi kubecost og Grafana webpanel med et sæt dashboards til rådighed.
Samlede omkostninger, der vises på hovedskærmen, viser faktisk de anslåede ressourceomkostninger for måneden. Det her projekteret pris, der afspejler omkostningerne ved at bruge klyngen (pr. måned) på det aktuelle niveau af ressourceforbrug.
Denne metrik er mere til at analysere udgifter og optimere dem. Det er ikke særlig praktisk at se på de samlede omkostninger for abstrakt juli i kubecost: det bliver du nødt til gå til fakturering. Men du kan se omkostninger opdelt efter navnerum, etiketter, pods i 1/2/7/30/90 dage, som fakturering aldrig vil vise dig.
Apropos etiketter. Du skal straks gå til indstillingerne og angive navnene på de etiketter, der skal bruges som ekstra kategorier til gruppering af omkostninger:
Du kan hænge alle etiketter på dem - praktisk, hvis du allerede har dit eget etiketteringssystem.
Også der kan du ændre adressen på API-slutpunktet, som omkostningsmodellen forbinder til, justere rabatstørrelsen i GCP og indstille dine egne priser for ressourcer og valuta til deres måling (af en eller anden grund påvirker funktionen ikke de samlede omkostninger).
Kubecost kan vise forskellige problemer i klyngen (og endda advare i tilfælde af fare). Desværre er muligheden ikke konfigurerbar, og derfor, hvis du har miljøer til udviklere og bruger dem, vil du konstant se noget som dette:
Et vigtigt værktøj - Klyngebesparelser. Den måler aktiviteten af pods (forbrug af ressourcer, inklusive netværk), og beregner også, hvor mange penge og hvad du kan spare på.
Det kan virke som om optimeringstips er ret oplagte, men erfaringen tyder på, at der stadig er noget at se på. Især overvåges netværksaktiviteten af pods (Kubecost foreslår at være opmærksom på inaktive), den anmodede og faktiske hukommelse og CPU-forbrug sammenlignes, såvel som den CPU, der bruges af klynge noder (foreslår at kollapse flere noder til én), disk belastning og et par dusin flere parametre.
Som med ethvert optimeringsproblem kræver optimering af ressourcer baseret på Kubecost-data: behandle med forsigtighed. For eksempel foreslår Cluster Savings at slette noder, idet de hævder, at det er sikkert, men tager ikke højde for tilstedeværelsen af node-vælgere og pletter i de pods, der er installeret på dem, og som ikke er tilgængelige på andre noder. Og generelt, selv forfatterne af produktet i deres (det kan i øvrigt være meget nyttigt for dem, der er interesseret i projektets emne) det anbefales ikke at skynde sig hovedkulds ud i omkostningsoptimering, men at gribe sagen an med omtanke.
Resultaterne af
Efter at have brugt kubecost i en måned på et par projekter, kan vi konkludere, at det er et interessant (og også nemt at lære og installere) værktøj til at analysere og optimere omkostningerne for tjenester fra cloud-udbydere, der bruges til Kubernetes-klynger. Beregningerne viser sig at være meget nøjagtige: I vores eksperimenter faldt de sammen med, hvad udbyderne faktisk krævede.
Der er også nogle ulemper: der er ikke-kritiske fejl, og nogle steder dækker funktionaliteten ikke de behov, der er specifikke for nogle projekter. Men hvis du hurtigt skal forstå, hvor pengene går hen, og hvad der kan "skæres" for konsekvent at reducere regningen for cloud-tjenester med 5-30 % (det er, hvad der skete i vores tilfælde), er dette en fantastisk mulighed .
PS
Læs også på vores blog:
- «";
- «";
- «'.
Kilde: www.habr.com