Revizio de Kubecost por ŝpari monon en Kubernetes en la nuboj

Revizio de Kubecost por ŝpari monon en Kubernetes en la nuboj

Nuntempe, pli kaj pli da kompanioj transdonas sian infrastrukturon de aparataj serviloj kaj siaj propraj virtualaj maŝinoj al la nubo. Ĉi tiu solvo estas facile klarigebla: ne necesas zorgi pri aparataro, la areto estas facile agordita en multaj malsamaj manieroj... kaj plej grave, ekzistantaj teknologioj (kiel Kubernetes) ebligas simple skali komputadpotencon depende de la ŝarĝo. .

La financa aspekto ĉiam gravas. La ilo diskutita en ĉi tiu artikolo estas dizajnita por helpi redukti buĝetojn kiam vi uzas nuban infrastrukturon kun Kubernetes.

Enkonduko

Kubecost estas kalifornia noventrepreno de Google, kreanta solvon por kalkuli infrastrukturkostojn en nubaj servoj (ene de Kubernetes-areo + komunaj rimedoj), trovi proplempunktojn en la agordoj de la grapo kaj sendi taŭgajn sciigojn al Slack.

Ni havas klientojn kun Kubernetes kaj en la konataj AWS kaj GCP-nuboj, kaj, pli malofte por la Linukso-komunumo, Azure - ĝenerale, sur ĉiuj platformoj subtenataj de Kubecost. Por iuj el ili, ni mem kalkulas la kostojn de intra-clusteraj servoj (uzante metodon similan al tiu uzata de Kubecost), kaj ankaŭ kontrolas infrastrukturkostojn kaj provas optimumigi ilin. Tial, estas logike, ke ni interesiĝis pri la ebleco aŭtomatigi tiajn taskojn.

La fontkodo de la ĉefa Kubecost-modulo estas malfermita laŭ la kondiĉoj de la Malferma Fonta permesilo (Apache License 2.0). Ĝi povas esti uzata libere kaj la disponeblaj funkcioj estu sufiĉaj por malgrandaj projektoj. Tamen, komerco estas komerco: la resto de la produkto estas fermita, ĝi povas esti uzata de pagitaj abonoj, kiuj ankaŭ implicas komercan subtenon. Krome, la aŭtoroj ofertas senpagan permesilon por malgrandaj aretoj (1 areto kun 10 nodoj - dum la verkado de ĉi tiu artikolo, ĉi tiu limo vastiĝis al 20 nodoj) aŭ provperiodo kun plenaj kapabloj por 1 monato.

Kiel ĉio funkcias

Do, la ĉefa parto de Kubecost estas la aplikaĵo kost-modelo, skribita en Go. Helm-diagramo kiu priskribas la tutan sistemon estas nomita kost-analizilo kaj ĉe ĝia kerno estas asembleo de kostmodelo kun Prometheus, Grafana kaj pluraj instrumentpaneloj.

Ĝenerale, kost-modelo havas sian propran retinterfacon, kiu montras grafikaĵojn kaj detalajn statistikojn pri kostoj en tabelforma formo, kaj ankaŭ, kompreneble, konsiletojn por optimumigi kostojn. La paneloj prezentitaj en Grafana estas pli frua etapo en la evoluo de Kubecost kaj enhavas multon da la samaj datumoj kiel la kostmodelo, kompletigante ilin per la kutimaj statistikoj pri la konsumo de CPU/memoro/reto/diska spaco en la areto kaj ĝia. komponantoj.

Kiel funkcias Kubecost?

  • Kosto-modelo ricevas prezojn por servoj per la API de nubaj provizantoj.
  • Plue, depende de la ferspeco de la nodo kaj la regiono, la kosto per nodo estas kalkulita.
  • Surbaze de la kosto de kurado de nodoj, ĉiu foliokapsulo ricevas koston je horo de CPU-uzo, je gigabajto da memoro konsumita, kaj je horo je gigabajto da datenoj stokitaj - depende de la nodo sur kiu ĝi funkciis aŭ la klaso de stokado.
  • Surbaze de la kosto de funkciigado de individuaj podoj, pago estas kalkulita por nomspacoj, servoj, Deplojoj, StatefulSets.
  • Statistikoj estas kalkulitaj uzante metrikojn provizitajn de kube-state-metrics kaj node-exporter.

Gravas konsideri tion Kubecost defaŭlte nur kalkulas rimedojn disponeblajn en Kubernetes. Eksteraj datumbazoj, GitLab-serviloj, S3-stokoj kaj aliaj servoj kiuj ne estas en la areto (eĉ se troviĝas en la sama nubo) ne estas videblaj al ĝi. Kvankam por GCP kaj AWS vi povas aldoni la ŝlosilojn de viaj servokontoj kaj kalkuli ĉion kune.

fikso

Kubecost postulas:

  • Kubernetes versio 1.8 kaj pli alta;
  • kube-state-metrics;
  • Prometeo;
  • nodo-eksportisto.

Okazis, ke en niaj aretoj ĉiuj ĉi tiuj kondiĉoj estis plenumitaj anticipe, do montriĝis, ke sufiĉas nur specifi la ĝustan finpunkton por aliro al Prometeo. Tamen, la oficiala kubecost Helm-diagramo enhavas ĉion, kion vi bezonas por funkcii sur nuda areto.

Estas pluraj manieroj instali Kubecost:

  1. Norma instala metodo priskribita en instrukcioj en la retejo de la programisto. Bezonata aldonu la deponejon de kost-analizilo al Helm, kaj poste instalu la diagramon. Restas nur plusendi vian havenon kaj ĝustigi la agordojn al la dezirata stato permane (per kubectl) kaj/aŭ uzante la kostmodelan retinterfacon.

    Ni eĉ ne provis ĉi tiun metodon, ĉar ni ne uzas triajn pretajn agordojn, sed ĝi aspektas kiel bona opcio "nur provu ĝin mem". Se vi jam havas iujn el la sistemaj komponantoj instalitaj aŭ vi volas pli agordi, estas pli bone konsideri la duan vojon.

  2. Uzu esence la sama diagramo, sed agordu kaj instalu ĝin mem en iu ajn oportuna maniero.

    Kiel jam menciite, krom la kubecost mem, ĉi tiu diagramo enhavas Grafana kaj Prometheus-leterojn, kiuj ankaŭ povas esti personecigitaj laŭdezire.

    Disponebla sur la diagramo values.yaml por kost-analizilo permesas vin agordi:

    • listo de kost-analizilaj komponentoj kiuj devas esti deplojitaj;
    • via finpunkto por Prometeo (se vi jam havas tian);
    • domajnoj kaj aliaj enir-agordoj por kost-modelo kaj Grafana;
    • komentarioj por podoj;
    • la bezono uzi konstantan stokadon kaj ĝian grandecon.

    Kompleta listo de disponeblaj agordaj elektoj kun priskriboj estas disponebla en dokumentado.

    Ĉar kubecost en ĝia baza versio ne povas limigi aliron, vi devos tuj agordi basic-auth por la retpanelo.

  3. Instali nur la sistemkerno - kost-modelo. Por fari tion, vi devas havi Prometheus instalita en la areto kaj specifi la respondan valoron de ĝia adreso en la variablo. prometheusEndpoint por Helm. Post tio - apliki aro de YAML-agordoj en la areto.

    Denove, vi devos permane aldoni Ingress kun basic-auth. Fine, vi devos aldoni sekcion por kolekti kostmodelan metrikon extraScrapeConfigs en la agordo de Prometheus:

    - 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

Kion ni ricevas?

Kun plena instalado, ni havas je nia dispono la retan panelon kubecost kaj Grafana kun aro da paneloj.

Tuta kosto, montrata sur la ĉefa ekrano, fakte montras la taksitan koston de rimedoj por la monato. Ĉi tio projektita prezo reflektanta la koston uzi la areton (monate) ĉe la nuna nivelo de konsumo de rimedoj.

Ĉi tiu metriko estas pli por analizi elspezojn kaj optimumigi ilin. Ne estas tre oportune rigardi la totalajn kostojn por abstrakta julio en kubecost: vi devos iru al fakturado. Sed vi povas vidi kostojn dividitajn laŭ nomspacoj, etikedoj, podoj dum 1/2/7/30/90 tagoj, kiujn fakturado neniam montros al vi.

Revizio de Kubecost por ŝpari monon en Kubernetes en la nuboj

Parolante pri etikedoj. Vi devas tuj iri al la agordoj kaj agordi la nomojn de la etikedoj, kiuj estos uzataj kiel pliaj kategorioj por grupaj kostoj:

Revizio de Kubecost por ŝpari monon en Kubernetes en la nuboj

Vi povas pendigi ajnajn etikedojn sur ili - oportune se vi jam havas vian propran etikedsistemon.

Ankaŭ tie vi povas ŝanĝi la adreson de la API-finpunkto al kiu la kostmodelo konektas, ĝustigi la rabatan grandecon en GCP kaj agordi viajn proprajn prezojn por rimedoj kaj valuto por ilia mezurado (ial la funkcio ne influas Tutan koston).

Kubecost povas montri diversajn problemoj en la areto (kaj eĉ vigla kaze de danĝero). Bedaŭrinde, la opcio ne estas agordebla, kaj tial, se vi havas mediojn por programistoj kaj uzas ilin, vi konstante vidos ion tian:

Revizio de Kubecost por ŝpari monon en Kubernetes en la nuboj

Grava ilo - Grapoŝparoj. Ĝi mezuras la agadon de podoj (konsumo de rimedoj, inkluzive de retaj), kaj ankaŭ kalkulas kiom da mono kaj pri kio vi povas ŝpari.

Eble ŝajnas, ke optimumigaj konsiletoj estas sufiĉe evidentaj, sed sperto sugestas, ke ankoraŭ estas io por rigardi. Precipe, la reto-agado de podoj estas monitorita (Kubecost sugestas atenti neaktivajn), la petita kaj reala memoro kaj CPU-konsumo estas komparata, same kiel la CPU uzata de grapolnodoj (sugestas kolapsigi plurajn nodojn en unu), disko. ŝarĝo kaj kelkaj dekduoj pliaj parametroj.

Kiel kun ajna optimumiga problemo, optimumigo de rimedoj bazitaj sur Kubecost-datumoj postulas: trakti singarde. Ekzemple, Cluster Savings sugestas forigi nodojn, asertante ke ĝi estas sekura, sed ne konsideras la ĉeeston de nod-elektiloj kaj makuloj deplojitaj sur ili kiuj ne estas haveblaj sur aliaj nodoj. Kaj ĝenerale, eĉ la aŭtoroj de la produkto en ilia lastatempa artikolo (cetere, ĝi povas esti tre utila por tiuj, kiuj interesiĝas pri la temo de la projekto) oni rekomendas ne rapidi al kosto optimumigo, sed pripense alproksimiĝi al la afero.

Rezultoj

Post uzi kubecost dum unu monato en kelkaj projektoj, ni povas konkludi, ke ĝi estas interesa (kaj ankaŭ facile lernebla kaj instalebla) ilo por analizi kaj optimumigi kostojn por la servoj de nubaj provizantoj uzataj por Kubernetes-grupoj. La kalkuloj rezultas esti tre precizaj: en niaj eksperimentoj ili koincidis kun tio, kion la provizantoj efektive postulis.

Estas ankaŭ kelkaj malavantaĝoj: estas ne-kritikaj cimoj, kaj kelkloke la funkcieco ne kovras la bezonojn specifajn por iuj projektoj. Tamen, se vi bezonas rapide kompreni, kien la mono iras kaj kio povas esti "tranĉita" por konstante redukti la fakturon por nubaj servoj je 5-30% (ĉi tio okazis en nia kazo), ĉi tio estas bonega opcio. .

PS

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Aldoni komenton