Kubernetes klastrite jälgimine: üldine ülevaade ja tutvustus Prometheus'ega

Vaatame üle Kubernetes'i jälgimise kontseptsiooni, tutvume Prometheuse tööriistaga ja arutame häirete haldamist.

Jälgimise teema on mahukas, ühes artiklis seda ei käsitle. Selle teksti eesmärk on anda ülevaade tööriistadest, kontseptsioonidest ja lähenemisviisidest.

Artikli sisu — väljaanne avatud loengust koolis "Slerm". Kui soovite saada täielikku koolitust, registreeruge kursusele Kuberneteses infrastruktuuri jälgimise ja logimise kohta.

Mida jälgitakse Kubernetes'i klastris

Füüsilised serverid. Kui Kubernetes'i klaster on paigaldatud teie serveritesse, tuleb jälgida nende tervist. Sellega tegeleb Zabbix; kui te töötate Zabbixiga, siis ei pea te loobuma, konflikte ei tekki. Meie serverite seisukorda jälgib just Zabbix.

Liigume edasi klastri tasemel jälgimise juurde.

Control Plane'i komponendid: API, Scheduler ja teised. Vähemalt tuleks jälgida, et API servereid või etcd oleks rohkem kui 0. Etcd suudab anda palju mõõdikuid: diskide kohta, millel see töötab, oma klastritehingu tervise kohta ja palju muud.

Docker on ilmunud juba ammu ja selle probleemidest on kõik hästi teadlikud: palju konteinerid põhjustavad hangumisi ja muid probleeme. Seetõttu tasub ka Dockerit jälgida, vähemalt selle kättesaadavust.

DNS. Kui klastris lakkab DNS töötamast, lakkab töötamast ka kogu teenuse avastamine, peatub side podide vahel. Minu praktikas pole selliseid probleeme olnud, kuid see ei tähenda, et DNS-i seisukorda ei peaks jälgima. Küsimuste viivitusi ja mõned muud mõõdikud saab jälgida CoreDNS-i peal.

Ingress. Jälgida tuleb ingresside (sealhulgas Ingress Controller) kättesaadavust, kuna need on projektis sissepääsu punktid.

Peamised klastrikomponendid on läbi vaadatud - nüüd laskume madalamale, abstraktsioonide tasemele.

Tundub, et rakendused töövad podides, seega tuleb neid jälgida, kuid tegelikult ei ole see nii. Podid on efemeersed: täna töötavad ühel serveril, homme teisel; täna on neid 10, homme 2. Seega, lihtsalt podid ei ole kellegi jälgimise all. Mikroteenuste arhitektuuri raames on olulisem jälgida rakenduse kättesaadavust tervikuna. Eriti tuleks kontrollida teenuse lõpp-punktide kättesaadavust: kas midagi üldse töötab? Kui rakendus on kättesaadav, siis mis selle taga toimub, kui palju on praegu replikaid — need on teisejärgulised küsimused. Erinevate instantside jälgimine ei ole vajalik.

Viimasel tasemel tuleb jälgida rakenduse tööd, koguda ärimõõdikud: tellimuste arv, kasutajate käitumine jne.

Prometheus

Parim süsteem klastri jälgimiseks on Prometheus. Ma ei tea ühtegi tööriista, mis suudaks Prometheusega võrreldes kvaliteedi ja mugavuse poolest konkureerida. See on suurepärane paindlikule infrastruktuurile, seega kui räägitakse "Kubernetes'i jälgimisest", mõeldakse tavaliselt just Prometheusele.

On paar võimalust, kuidas Prometheusega alustada: Helm'i abil saab installida tavapärast Prometheust või Prometheus Operaatort.

1. Tavaline Prometheus. Sellega on kõik korras, kuid ConfigMap'i ikkagi tuleb seadistada — põhimõtteliselt tuleb kirjutada tekstifailid, nagu me tegime varem, enne mikroteenuste arhitektuuri.
2. Prometheus Operator on veidi keerukam, sisemise loogika poolest keerulisem, kuid selle kasutamine on lihtsam: seal on eraldi objektid, abstraktsioonid lisatakse klastri, seega on neid palju mugavam kontrollida ja seadistada.

Toote mõistmiseks soovitan esmalt paigaldada tavalise Prometheuse. Peate kõik seadistama config'i kaudu, kuid see tuleb kasuks: saate aru, mis millele viitab ja kuidas seadistada. Prometheus Operaators tõstate te kohe abstraktsioonile, kuigi soovi korral on ka sügavamale kaevamine võimalik.

Prometheus on hästi integreeritud Kubernetesega: see saab ühendust API serveriga ja suhtleb sellega.

Prometheus on populaarne, seetõttu toetab seda suur hulk rakendusi ja programmeerimiskeeli. Toetust on vaja, kuna Prometheusel on oma mõõdikute formaat, ja selle edastamiseks on vajalik kas rakenduse sees olev teek või valmis eksportija. Ja selliseid eksportijaid on tõeliselt palju. Näiteks on olemas PostgreSQL Exporter: see võtab andmed PostgreSQL-st ja konverteerib need Prometheuse formaati, et Prometheus saaks nendega töötada.

Prometheuse arhitektuur

Prometheus Server — see on serveripool, Prometheuse aju. Siin hoitakse ja töödeldakse mõõdikud.

Mõõdikud salvestatakse ajaseeria andmebaasi (TSDB). TSDB ei ole eraldi andmebaas, vaid Go keeles kirjutatud pakett, mis on sisseehitatud Prometheusesse. Ükskõik, kõik asub ühes binaarses failis.

Ärge hoidke andmeid TSDB-s pikka aega.

Prometheuse infrastruktuur ei sobi pikaks ajaks meetmete salvestamiseks. Vaikimisi on säilitusaeg 15 päeva. Seda piirangut on võimalik ületada, kuid tuleb silmas pidada: mida rohkem andmeid te TSDB-s säilitate ja mida kauem te seda teete, seda rohkem ressursse ta tarvitab. Ajalooliste andmete hoidmist Prometheuses peetakse halbadeks praktikaks.

Kui teil on tohutu liiklus ja mõõtmeid on sadu tuhandeid sekundis, siis on parem piirata nende säilitamist kas kettaruumi mahuga või ajaliselt. Üldiselt hoitakse TSDB-s „kuumi andmeid“, mõõtmisi, mis on salvestatud vaid mõne tunni jooksul. Pikema säilitamise jaoks kasutatakse välist hoidlat nendes andmebaasides, mis on selleks sobivad, näiteks InfluxDB, ClickHouse ja nii edasi. Olen näinud rohkem positiivseid arvustusi ClickHouse'i kohta.

Prometheus Server töötab mudelis pull: ta käib ise mõõtmiste järele nendes lõpp-punktides, mille me talle edastasime. Ütlesime: „käi API Serveris“ ja ta käib seal iga n-nda sekundi järel ning tõmbab mõõtmised.

Lühiajalise elueaga objektide (job või cron job) jaoks, mis võivad ilmuda skaneerimise perioodide vahel, on olemas komponent Pushgateway. Sellesse saadetakse mõõtmed lühiajalistelt objektidelt: job tõusis, täitis tegevuse, saatis mõõtmed Pushgateway-sse ja lõpetas. Mõne aja pärast läheb Prometheus enda rütmis ja tõmbab need mõõtmised Pushgateway-st.

Teavituste seadistamiseks Prometheuses on eraldi komponent — Alertmanager. Ja häirete seadistused — alerting rules. Näiteks tuleb luua häire olukorras, kui API serverid on 0. Kui sündmus aktiveeritakse, edastatakse häire alert managerisse edasiseks saatmiseks. Alert manageris on piisavalt paindlikud marsruudistamise seadistused: ühe rühma häireid saab saata administraatorite Telegrami-chat'i, teise arendajate chat'i, kolmanda infrastruktuuri töötajate chat'i. Teavitused võivad tulla Slacki, Telegrami, e-posti ja teiste kanalite kaudu.

Ja lõpuks räägiks Prometheuse Killer-featuurist — Discovering. Prometheuse kasutamisel ei ole vaja näidata konkreetseid objekte, mida jälgida, piisab, kui määrata nende tüüp. See tähendab, et ei pea kirjutama: „siin on IP-aadress, siin on port — jälgi“, vaid tuleb määrata, milliste põhimõtete alusel neid objekte leida (targets — sihtmärk). Prometheus ise, olenevalt sellest, millised objektid on aktiivsed, toob vajalikud endaga kaasa ja lisab need jälgimisele.

See approach fits well with the structure of Kubernetes, where everything is also fluid: today 10 servers, tomorrow 3. Instead of specifying the server IP address each time, we write down how to find it once — and Discovering will take care of this.

The language of Prometheus is called PromQL. With this language, you can extract specific metric values and then transform them, creating analytical reports based on them.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Simple query

    container_memory_usage_bytes

Mathematical operations

    container_memory_usage_bytes / 1024 / 1024

Built-in functions

    sum(container_memory_usage_bytes) / 1024 / 1024

Query refinement

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

The Prometheus web interface

Prometheus has its own, quite minimalist web interface. It's only suitable for debugging or demonstrations.

In the Expression field, you can write queries in the PromQL language.

In the Alerts tab, there are alert rules - alerting rules, and they have three statuses:

1. inactive — if the alert is currently inactive, meaning everything is fine, and it hasn’t triggered;
2. pending — this is in the case that the alert has triggered, but the notification has not yet been sent. The delay is set to compensate for network flickers: if the specified service was restored within a minute, there’s no need to raise an alarm yet;
3. firing — this is the third status, when the alert goes off and sends messages.

In the Status menu, you will find access to information about what Prometheus consists of. There is also a link to the targets we mentioned earlier.

For a more detailed overview of the Prometheus interface, see the Slurm lecture on Kubernetes cluster monitoring.

Integration with Grafana

In the Prometheus web interface, you won't find beautiful and clear graphs from which you can draw conclusions about the state of the cluster. To create them, Prometheus is integrated with Grafana. This results in dashboards like these.

Setting up the Prometheus and Grafana integration is quite simple; you will find instructions in the documentation: GRAFANA SUPPORT FOR PROMETHEUS, and I will conclude here.

In the following articles, we will continue the topic of monitoring: we will talk about collecting and analyzing logs using Grafana Loki and alternative tools.

Autor: Marsel Ibraev, sertifitseeritud Kubernetes administraator, praktiseeriv insener ettevõttes Southbridge, speaker and course developer at Slurm.

Allikas: habr.com