Penseu en el concepte de monitorització de Kubernetes, familiaritzeu-vos amb l'eina Prometheus i parleu d'alerta.
El tema del seguiment és voluminós, no es pot desmuntar en un article. L'objectiu d'aquest text és oferir una visió general de les eines, conceptes i enfocaments.
El material de l'article és un espremut . Si vols fer un curs complet, inscriu-te a un curs .
Què es controla en un clúster de Kubernetes
servidors físics. Si el clúster de Kubernetes s'ha desplegat als seus servidors, cal que en superviseu l'estat. Zabbix s'encarrega d'aquesta tasca; si treballeu amb ell, no cal que us negueu, no hi haurà conflictes. És Zabbix qui supervisa l'estat dels nostres servidors.
Passem al seguiment a nivell de clúster.
Components del pla de control: API, Scheduler i altres. Com a mínim, heu d'assegurar-vos que l'API dels servidors o etcd sigui superior a 0. Etcd pot retornar moltes mètriques: pels discos en què gira, per la salut del seu clúster etcd i altres.
estibador va aparèixer fa molt de temps i tothom és ben conscient dels seus problemes: molts contenidors generen congelacions i altres problemes. Per tant, el mateix Docker, com a sistema, també s'hauria de controlar, almenys per disponibilitat.
DNS Si el DNS cau al clúster, tot el servei Discovery caurà després d'ell, les trucades de pods a pods deixaran de funcionar. A la meva pràctica, no hi havia aquests problemes, però això no vol dir que l'estat del DNS no s'hagi de supervisar. La latència de sol·licitud i algunes altres mètriques es poden fer un seguiment a CoreDNS.
Entrada. Cal controlar la disponibilitat d'entrades (inclòs el controlador d'entrada) com a punts d'entrada al projecte.
Els components principals del clúster s'han desmantellat; ara baixem al nivell d'abstraccions.
Sembla que les aplicacions s'executen en pods, la qual cosa significa que s'han de controlar, però en realitat no ho són. Els pods són efímers: avui funcionen en un servidor, demà en un altre; avui n'hi ha 10, demà 2. Per tant, ningú vigila les beines. Dins d'una arquitectura de microservei, és més important controlar la disponibilitat de l'aplicació en el seu conjunt. En particular, comproveu la disponibilitat dels punts finals del servei: funciona alguna cosa? Si l'aplicació està disponible, què passa darrere, quantes rèpliques hi ha ara: aquestes són preguntes de segon ordre. No cal controlar instàncies individuals.
En l'últim nivell, cal controlar el funcionament de la pròpia aplicació, prendre mètriques empresarials: el nombre de comandes, el comportament dels usuaris, etc.
Prometeu
El millor sistema per controlar un clúster és . No conec cap eina que pugui igualar a Prometheus en termes de qualitat i facilitat d'ús. És ideal per a infraestructures flexibles, de manera que quan diuen "vigilància de Kubernetes", normalment es refereixen a Prometeu.
Hi ha un parell d'opcions per començar amb Prometheus: amb Helm, podeu instal·lar un Prometheus o un Operador Prometheus normal.
- Prometeu regular. Tot està bé amb ell, però cal configurar ConfigMap; de fet, escriviu fitxers de configuració basats en text, com vam fer abans, abans de l'arquitectura del microservei.
- Prometheus Operator és una mica més estès, una mica més complicat pel que fa a la lògica interna, però és més fàcil treballar-hi: hi ha objectes separats, s'afegeixen abstraccions al clúster, de manera que són molt més còmodes de controlar i configurar.
Per entendre el producte, recomano instal·lar primer el Prometheus normal. Haureu de configurar-ho tot a través de la configuració, però això serà beneficiós: descobrireu què pertany a què i com es configura. A Prometheus Operator, s'eleva immediatament a una abstracció més alta, tot i que també podeu endinsar-vos en les profunditats si voleu.
Prometheus està ben integrat amb Kubernetes: pot accedir i interactuar amb el servidor API.
Prometheus és popular, és per això que un gran nombre d'aplicacions i llenguatges de programació ho admeten. Cal suport, ja que Prometheus té el seu propi format de mètriques, i per transferir-lo, necessiteu una biblioteca dins de l'aplicació o un exportador ja preparat. I hi ha força exportadors d'aquest tipus. Per exemple, hi ha PostgreSQL Exporter: agafa dades de PostgreSQL i les converteix al format Prometheus perquè Prometheus pugui treballar-hi.
Arquitectura de Prometeu
Servidor Prometheus és la part posterior, el cervell de Prometeu. Les mètriques s'emmagatzemen i es processen aquí.
Les mètriques s'emmagatzemen a la base de dades de sèries temporals (TSDB). TSDB no és una base de dades separada, sinó un paquet en l'idioma Go que està incrustat a Prometheus. A grans trets, tot està en un únic binari.
No deseu dades a TSDB durant molt de temps
La infraestructura de Prometheus no és adequada per a l'emmagatzematge a llarg termini de mètriques. El període de retenció predeterminat és de 15 dies. Podeu superar aquest límit, però tingueu en compte: com més dades emmagatzemeu a TSDB i com més temps ho feu, més recursos consumirà. Emmagatzemar dades històriques a Prometeu es considera una mala pràctica.
Si teniu un trànsit enorme, el nombre de mètriques és de centenars de milers per segon, llavors és millor limitar-ne l'emmagatzematge per espai de disc o per període. Normalment, les "dades calentes" s'emmagatzemen a TSDB, mètriques en poques hores. Per a un emmagatzematge més llarg, l'emmagatzematge extern s'utilitza en aquelles bases de dades que són realment adequades per a això, per exemple, InfluxDB, ClickHouse, etc. Vaig veure més bones crítiques sobre ClickHouse.
Prometheus Server treballa amb el model tirar: va per mètriques a aquells punts finals que li vam donar. Van dir: "aneu al servidor de l'API", i ell hi va cada n-èsimo nombre de segons i pren les mètriques.
Per als objectes amb una vida útil curta (job o cron job) que poden aparèixer entre períodes de raspat, hi ha un component Pushgateway. S'hi introdueixen mètriques d'objectes a curt termini: el treball ha augmentat, ha realitzat una acció, ha enviat mètriques a Pushgateway i s'ha completat. Al cap d'un temps, Prometheus baixarà al seu ritme i recollirà aquestes mètriques de Pushgateway.
Per configurar les notificacions a Prometheus hi ha un component independent: Gestor d'alertes. I les normes d'alerta. Per exemple, heu de crear una alerta si l'API del servidor és 0. Quan l'esdeveniment s'activa, l'alerta es passa al gestor d'alertes per a un posterior enviament. El gestor d'alertes té una configuració d'encaminament força flexible: un grup d'alertes es pot enviar al xat de telegrama dels administradors, un altre al xat dels desenvolupadors i un tercer al xat dels treballadors de la infraestructura. Les notificacions es poden enviar a Slack, Telegram, correu electrònic i altres canals.
I, finalment, us parlaré de la funció assassí de Prometheus: Descobrir. Quan treballeu amb Prometheus, no cal que especifiqueu adreces específiques d'objectes per al seguiment, n'hi ha prou amb establir-ne el tipus. És a dir, no cal que escriviu "aquí hi ha l'adreça IP, aquí hi ha el port - monitor", en canvi, cal determinar segons quins principis trobareu aquests objectes (objectius - metes). El mateix Prometeu, depenent dels objectes que estiguin actius actualment, treu els necessaris i els afegeix al monitoratge.
Aquest enfocament encaixa bé amb l'estructura de Kubernetes, on tot també flota: avui hi ha 10 servidors, demà 3. Per no especificar l'adreça IP del servidor cada vegada, van escriure una vegada com trobar-la, i Discovering ho farà. .
Es diu la llengua de Prometeu PromQL. Amb aquest llenguatge, podeu obtenir els valors de mètriques específiques i després convertir-los, crear càlculs analítics basats en ells.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Interfície web de Prometheus
Prometheus té la seva pròpia interfície web força minimalista. Només apte per a depuració o demostració.
A la línia Expressió, podeu escriure una consulta en el llenguatge PromQL.
La pestanya Alertes conté regles d'alertes i tenen tres estats:
- inactiu: si l'alerta no està activa en aquest moment, és a dir, tot està bé i no va funcionar;
- pendent: això és si l'alerta ha funcionat, però l'enviament encara no ha passat. El retard està configurat per compensar el parpelleig de la xarxa: si el servei especificat ha augmentat en un minut, l'alarma encara no hauria de sonar;
- disparar és el tercer estat quan l'alerta s'il·lumina i envia missatges.
Al menú Estat trobareu accés a informació sobre què és Prometeu. També hi ha una transició als objectius (objectius), dels quals hem parlat més amunt.
Per obtenir una visió general més detallada de la interfície de Prometheus, vegeu .
Integració amb Grafana
A la interfície web de Prometheus, no trobareu gràfics bonics i entenedors dels quals pugueu treure una conclusió sobre l'estat del clúster. Per construir-los, Prometheus s'integra amb Grafana. Tenim aquests quadres de comandament.
Configurar la integració de Prometheus i Grafana no és gens difícil, podeu trobar instruccions a la documentació: Bé, acabaré amb això.
En els articles següents, continuarem el tema del monitoratge: parlarem de la recollida i anàlisi de registres mitjançant Grafana Loki i eines alternatives.
Autor: Marcel Ibraev, administrador certificat Kubernetes, enginyer en exercici a l'empresa , ponent i desenvolupador de cursos Slurm.
Font: www.habr.com