Monitorización dun clúster de Kubernetes: unha visión xeral e introdución a Prometheus

Considere o concepto de monitorización de Kubernetes, familiarízase coa ferramenta Prometheus e fala sobre as alertas.

O tema do seguimento é voluminoso, non se pode desmontar nun artigo. O propósito deste texto é ofrecer unha visión xeral das ferramentas, conceptos e enfoques.

O material do artigo é unha aperta charla aberta da escola "Slurm". Se queres facer un curso completo, inscríbete nun curso Infraestrutura de seguimento e rexistro en Kubernetes.

O que se supervisa nun clúster de Kubernetes

servidores físicos. Se o clúster de Kubernetes está implantado nos seus servidores, cómpre supervisar o seu estado. Zabbix encárgase desta tarefa; se traballas con el, non tes que rexeitar, non haberá conflitos. É Zabbix o que supervisa o estado dos nosos servidores.

Pasemos ao seguimento a nivel de cluster.

Compoñentes do plano de control: API, Scheduler e outros. Como mínimo, cómpre asegurarse de que a API dos servidores ou etcd sexa superior a 0. Etcd pode devolver moitas métricas: polos discos nos que está xirando, pola saúde do seu clúster etcd e outras.

Estivador apareceu hai tempo e todo o mundo coñece ben os seus problemas: moitos envases xeran conxelacións e outros problemas. Polo tanto, o propio Docker, como sistema, tamén debería estar controlado, polo menos pola dispoñibilidade.

dns. Se o DNS cae no clúster, todo o servizo Discovery caerá despois, as chamadas de pods a pods deixarán de funcionar. Na miña práctica, non houbo tales problemas, pero isto non significa que o estado do DNS non teña que ser supervisado. A latencia de solicitudes e algunhas outras métricas pódense seguir en CoreDNS.

Ingreso. É necesario controlar a dispoñibilidade de entradas (incluíndo o controlador de entrada) como puntos de entrada ao proxecto.

Os compoñentes principais do clúster foron desmantelados - agora imos baixar ao nivel de abstraccións.

Parece que as aplicacións se executan en pods, o que significa que hai que controlalas, pero en realidade non o son. Os pods son efémeros: hoxe funcionan nun servidor, mañá noutro; hoxe son 10, mañá 2. Polo tanto, ninguén controla as vainas. Dentro dunha arquitectura de microservizos, é máis importante controlar a dispoñibilidade da aplicación no seu conxunto. En particular, comprobe a dispoñibilidade dos puntos finais do servizo: funciona algo? Se a aplicación está dispoñible, entón o que pasa detrás dela, cantas réplicas hai agora - estas son preguntas de segundo orden. Non é necesario supervisar as instancias individuais.

No último nivel, cómpre controlar o funcionamento da propia aplicación, tomar métricas comerciais: o número de pedidos, o comportamento do usuario, etc.

Prometeu

O mellor sistema para supervisar un clúster é Prometeu. Non coñezo ningunha ferramenta que poida igualar a Prometheus en canto a calidade e facilidade de uso. É óptimo para infraestruturas flexibles, polo que cando din "seguimento de Kubernetes", normalmente se refiren a Prometheus.

Hai un par de opcións para comezar con Prometheus: usando Helm, podes instalar un Prometheus ou un Prometheus Operator normal.

1. Prometeo regular. Todo está ben con el, pero cómpre configurar ConfigMap; de feito, escribir ficheiros de configuración baseados en texto, como fixemos antes, antes da arquitectura de microservizos.
2. Prometheus Operator está un pouco máis espallado, un pouco máis complicado en termos de lóxica interna, pero é máis fácil traballar con el: hai obxectos separados, engádense abstraccións ao clúster, polo que son moito máis cómodos de controlar e configurar.

Para entender o produto, recomendo instalar primeiro o Prometheus normal. Terá que configurar todo a través da configuración, pero isto será beneficioso: descubrirá o que pertence a que e como se configura. En Prometheus Operator, ascendes inmediatamente a unha abstracción superior, aínda que tamén podes afondar nas profundidades se o desexas.

Prometheus está ben integrado con Kubernetes: pode acceder e interactuar co servidor API.

Prometheus é popular, polo que un gran número de aplicacións e linguaxes de programación o admiten. Necesítase soporte, xa que Prometheus ten o seu propio formato de métricas e, para transferilo, necesitas unha biblioteca dentro da aplicación ou un exportador preparado. E hai bastantes exportadores deste tipo. Por exemplo, existe PostgreSQL Exporter: toma datos de PostgreSQL e convérteos ao formato Prometheus para que Prometheus poida traballar con el.

Arquitectura Prometeo

Servidor Prometheus é a parte traseira, o cerebro de Prometeo. Aquí gárdanse e procesan as métricas.

As métricas almacénanse na base de datos de series temporales (TSDB). TSDB non é unha base de datos separada, senón un paquete no idioma Go que está integrado en Prometheus. En liñas xerais, todo está nun binario.

Non almacene datos en TSDB durante moito tempo

A infraestrutura de Prometheus non é adecuada para o almacenamento a longo prazo de métricas. O período de retención predeterminado é de 15 días. Podes superar este límite, pero ten en conta: cantos máis datos almacene en TSDB e canto máis tempo o faga, máis recursos consumirá. Almacenar datos históricos en Prometheus considérase unha mala práctica.

Se tes un tráfico enorme, o número de métricas é de centos de miles por segundo, entón é mellor limitar o seu almacenamento por espazo en disco ou por período. Normalmente, os "datos quentes" almacénanse en TSDB, métricas en só unhas horas. Para un almacenamento máis longo, utilízase almacenamento externo naquelas bases de datos que son realmente adecuadas para iso, por exemplo, InfluxDB, ClickHouse, etc. Vin máis boas críticas sobre ClickHouse.

Prometheus Server traballa no modelo tirar: vai por métricas a eses puntos finais que lle demos. Dixeron: "vai ao servidor API", e el vai alí cada n-ésimo número de segundos e toma as métricas.

Para os obxectos cunha vida útil curta (traballo ou traballo cron) que poden aparecer entre períodos de raspado, hai un compoñente Pushgateway. As métricas de obxectos a curto prazo son introducidas nel: o traballo aumentou, realizou unha acción, enviou métricas a Pushgateway e completouse. Despois dun tempo, Prometheus baixará ao seu propio ritmo e recollerá estas métricas de Pushgateway.

Para configurar as notificacións en Prometheus hai un compoñente separado: Administrador de alertas. E as regras de alerta. Por exemplo, cómpre crear unha alerta se a API do servidor é 0. Cando se desencadea o evento, a alerta pásase ao xestor de alertas para o seu posterior envío. O xestor de alertas ten unha configuración de enrutamento bastante flexible: un grupo de alertas pódese enviar ao chat de telegramas dos administradores, outro ao chat dos desenvolvedores e un terceiro ao chat dos traballadores da infraestrutura. As notificacións pódense enviar a Slack, Telegram, correo electrónico e outras canles.

E, finalmente, falareivos da función do asasino de Prometheus: Descubrindo. Ao traballar con Prometheus, non é necesario especificar enderezos específicos de obxectos para o seguimento, é suficiente con establecer o seu tipo. É dicir, non precisa escribir "aquí está o enderezo IP, aquí está o porto - monitor", en vez diso, debe determinar por que principios atopar estes obxectos (obxectivos - metas). O propio Prometheus, dependendo dos obxectos que estean activos actualmente, saca os necesarios e engádeos ao seguimento.

Este enfoque encaixa ben coa estrutura de Kubernetes, onde todo tamén flota: hoxe hai 10 servidores, mañá 3. Para non especificar o enderezo IP do servidor cada vez, escribiron unha vez como atopalo, e Discovering farao. .

Chámase a lingua de Prometeo PromQL. Usando esta linguaxe, pode obter os valores de métricas específicas e despois convertelas, construír cálculos analíticos baseados neles.

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)

Interface web Prometheus

Prometheus ten a súa propia interface web bastante minimalista. Só apto para depuración ou demostración.

Na liña Expresión, pode escribir unha consulta na linguaxe PromQL.

A pestana Alertas contén regras de alerta e teñen tres estados:

1. inactivo: se a alerta non está activa neste momento, é dicir, todo está ben con ela e non funcionou;
2. pendente - isto é se a alerta funcionou, pero o envío aínda non pasou. O atraso está configurado para compensar o parpadeo da rede: se o servizo especificado aumentou nun minuto, a alarma aínda non debería soar;
3. o disparo é o terceiro estado cando a alerta se ilumina e envía mensaxes.

No menú Estado atoparás acceso á información sobre o que é Prometheus. Tamén hai unha transición aos obxectivos (obxectivos), dos que falamos anteriormente.

Para obter unha visión máis detallada da interface de Prometheus, consulte na conferencia de Slurm sobre o seguimento dun clúster de Kubernetes.

Integración con Grafana

Na interface web de Prometheus, non atoparás gráficos fermosos e comprensibles dos que poidas sacar unha conclusión sobre o estado do clúster. Para construílos, Prometheus está integrado con Grafana. Temos tales paneis.

Configurar a integración de Prometheus e Grafana non é nada difícil, podes atopar instrucións na documentación: APOIO GRAFANA PARA PROMETHEUSPois rematarei con isto.

Nos seguintes artigos, continuaremos co tema do seguimento: falaremos da recollida e análise de rexistros mediante Grafana Loki e ferramentas alternativas.

Autor: Marcel Ibraev, administrador certificado de Kubernetes, enxeñeiro en exercicio na empresa Southbridge, locutor e desenvolvedor de cursos Slurm.

Fonte: www.habr.com