Kitabı oku: «Guía práctica de Kubernetes», sayfa 6

kube-state-metrics

kube-state-metrics es un accesorio de Kubernetes que monitoriza el objeto almacenado en Kubernetes. Donde cAdvisor y el servidor de métricas se utilizan para proporcionar métricas detalladas sobre el uso de recursos, kube-state-metrics se centra en la identificación de las condiciones de los objetos de Kubernetes desplegados en el clúster.

A continuación, se presentan algunas preguntas que kube-state-metrics puede responder por nosotros:

• Cápsulas

- ¿Cuántas cápsulas están desplegadas en el clúster?

- ¿Cuántas cápsulas están en estado de pendiente?

- ¿Existen suficientes recursos para atender la solicitud de una cápsula?

• Deployments (implementaciones)

- ¿Cuántas cápsulas están en estado de funcionamiento en comparación con las que están en estado deseado?

- ¿Cuántas réplicas hay disponibles?

- ¿Qué despliegues se han actualizado?

• Nodos

- ¿Cuál es el estado de los nodos worker (esclavo)?

- ¿Cuáles son los núcleos de CPU asignables en el clúster?

- ¿Hay algún nodo que no se pueda programar?

• Trabajos

- ¿Cuándo ha comenzado un trabajo?

- ¿Cuándo se ha completado un trabajo?

- ¿Cuántos trabajos han fracasado?

En el momento de escribir esto, kube-state-metrics rastrea 22 tipos de objetos. Su número siempre va en aumento. Podemos encontrar la documentación en el repositorio de Github.

¿Qué métricas debemos monitorizar?

La respuesta fácil es «Todo», pero si tratamos de controlar en exceso podemos crear demasiado ruido que filtra las auténticas señales de las señales cuya situación necesitamos conocer. Cuando pensamos en la monitorización en Kubernetes, adoptamos un enfoque por capas que tiene en cuenta lo siguiente:

• Nodos físicos o virtuales

• Componentes del clúster

• Accesorios del clúster

• Aplicaciones de usuario final

El uso de este enfoque de la monitorización por capas nos permite identificar con mayor facilidad las señales correctas en nuestro sistema de monitorización. Nos permite abordar los problemas con un planteamiento selectivo. Por ejemplo, si tenemos cápsulas que entran en un estado de pendiente, podemos empezar con la utilización de recursos de los nodos y, si todo está bien, podemos centrarnos en los componentes a nivel de clúster. A continuación, se presentan las métricas que podríamos utilizar como objetivo en nuestro sistema:

• Nodos

- Utilización de la CPU

- Utilización de la memoria

- Utilización de la red

- Utilización del disco

• Componentes del clúster

- Latencia etcd

• Accesorios del clúster

- Autoescalador de clúster

- Controlador Ingress

• Aplicación

- Utilización y saturación de la memoria del contenedor

- Utilización de la CPU del contenedor

- Utilización de la red de contenedores y tasa de errores

- - Métricas del marco específico de la aplicación

Herramientas de monitorización

Hay muchas herramientas de monitorización que pueden integrarse en Kubernetes. Su número aumenta cada día y, para mejorar su integración, se diseñan teniendo en cuenta el conjunto de características de Kubernetes. A continuación, se presentan algunas herramientas populares que se integran con Kubernetes:

Prometheus

Prometheus es un conjunto de herramientas de monitorización y alerta de sistemas, de código abierto, que originalmente creó SoundCloud. Desde su aparición en 2012, muchas empresas y organizaciones han adoptado Prometheus. El proyecto tiene un desarrollador muy activo y una comunidad de usuarios. Ahora es un proyecto autónomo de código abierto y se mantiene independiente de cualquier empresa. Para destacar lo anterior, y para clarificar la estructura de gobierno del proyecto Prometheus, podemos decir que se unió a la Cloud Native Computing Foundation (CNCF) en 2016 como segundo proyecto acogido, después de Kubernetes.

InfluxDB

InfluxDB es una base de datos de series temporales diseñada para manejar altas cargas de escritura y consulta. Es un componente integral de la pila TICK (Telegraf, InfluxDB, Chronograf, y Kapacitor). InfluxDB está destinado a utilizarse como almacén de reserva para cualquier caso práctico que involucre grandes cantidades de datos con fecha y hora, incluyendo monitorización de DevOps, métricas de aplicación, datos de sensores de IoT y análisis en tiempo real.

Datadog

Datadog proporciona un servicio de monitorización para aplicaciones a escala de la nube. Ofrece monitorización de servidores, bases de datos, herramientas y servicios a través de una plataforma de análisis de datos basada en SaaS.

Sysdig

Sysdig Monitor es una herramienta comercial que proporciona monitorización de Docker y Kubernetes de aplicaciones nativas de contenedores. Sysdig también nos permite recoger, correlacionar y consultar las métricas de Prometheus con integración directa en Kubernetes.

Herramientas para proveedores de la nube

GCP Stackdriver

Stackdriver Kubernetes Engine Monitoring está diseñado para monitorizar clústeres de Google Kubernetes Engine (GKE). Gestiona conjuntamente los servicios de monitorización y recopilación de registros y cuenta con una interfaz que proporciona un panel personalizado para los clústeres GKE. Stackdriver Monitoring proporciona visibilidad sobre el rendimiento, el tiempo de actividad y el estado general de aplicaciones en la nube. Recopila métricas, eventos y metadatos de Google Cloud Platform (GCP), Amazon Web Services (AWS), sondas de tiempo de actividad alojadas e instrumentación de aplicaciones.

Microsoft Azure Monitor para contenedores

Azure Monitor para contenedores es una función diseñada para monitorizar el rendimiento de tareas de contenedores implementadas en cualquiera de las Azure Container Instances o en clústeres administrados de Kubernetes y alojados en Azure Kubernetes Service. La monitorización de contenedores es crítica, especialmente cuando ejecutamos un clúster de producción, a escala, con varias aplicaciones. Azure Monitor para contenedores nos ofrece visibilidad sobre el rendimiento a través de la recopilación de métricas de memoria y procesador en relación con controladores, nodos y contenedores que están disponibles en Kubernetes a través de la API de Metrics. También se recopilan los registros de los contenedores. Después de habilitar la monitorización de los clústeres de Kubernetes, las métricas y los registros se recopilan automáticamente a través de una versión en contenedor del agente Log Analytics de Linux.

Información sobre contenedores AWS

Si utilizamos Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service u otras plataformas de Kubernetes en Amazon EC2, podemos usar CloudWatch Container Insights para recopilar, agregar y hacer resúmenes de métricas y registros de nuestras aplicaciones en contenedores y microservicios. Las métricas incluyen la utilización de recursos como la CPU, la memoria, el disco y la red. Container Insights también proporciona información de diagnóstico, como los fallos de reinicio de contenedor, para ayudarnos a aislar los problemas y resolverlos rápidamente.

Un aspecto importante a la hora de considerar la aplicación de una herramienta para monitorizar métricas es observar cómo las almacena. Las herramientas que proporcionan bases de datos de series temporales con pares clave/valor nos proporcionarán un mayor grado de atributos para las métricas.

Siempre evaluaremos las herramientas de monitorización que ya tenemos, porque si utilizamos una nueva herramienta de monitorización, esta tiene una curva de aprendizaje y un coste debido a su aplicación operativa. Muchas de las herramientas de monitorización están integradas en Kubernetes, así que evaluaremos las que tenemos actualmente y si cumplen nuestros requisitos.

Monitorización en Kubernetes con Prometheus

En esta sección nos centramos en el seguimiento de métricas con Prometheus, que ofrece integraciones aceptables con el etiquetado, el descubrimiento de servicios y los metadatos de Kubernetes. Los conceptos de alto nivel que implementamos a lo largo del capítulo también se podrán aplicar a otros sistemas de monitorización.

Prometheus es un proyecto de código abierto que está alojado en la CNCF. Originalmente lo desarrolló SoundCloud, y muchos de sus conceptos tienen su fundamento en BorgMon, el sistema de monitorización interna de Google. Implementa un modelo de datos multidimensional con pares de claves que funcionan de forma muy parecida a como lo hace el sistema de etiquetado de Kubernetes. Prometheus presenta las métricas en un formato que pueden leer los usuarios, como se aprecia en el siguiente ejemplo:

# HELP node_cpu_seconds_total Seconds the CPU is spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total{cpu="0",mode="idle"} 5144.64 node_cpu_seconds_total{cpu="0",mode="iowait"} 117.98

Para recopilar métricas, Prometheus utiliza un modelo de extracción en el que se raspa el punto final de métricas para recoger las métricas que ingiere el servidor de Prometheus. Sistemas como Kubernetes ya presentan sus métricas en formato Prometheus, facilitando así la recopilación de métricas. Muchos otros proyectos del ecosistema de Kubernetes (NGINX, Traefik, Istio, LinkerD, etc.) también presentan sus métricas en formato Prometheus. Prometheus también puede utilizar exportadores, que nos permiten tomar las métricas que emite nuestro servicio y traducirlas a métricas con formato Prometheus.

Prometheus tiene una arquitectura muy simplificada, como se muestra en la Figura 3-1.

Figura 3-1 Arquitectura de Prometheus.

Podemos instalar Prometheus dentro o fuera del clúster. Una buena práctica es monitorizar nuestro clúster desde un «clúster utilitario», para evitar que un problema de producción afecte también a nuestro sistema de monitorización. Hay herramientas, como Thanos, que proporcionan una alta disponibilidad de Prometheus y nos permiten exportar métricas a un almacenamiento externo al sistema.

Una inmersión a fondo en la arquitectura de Prometheus iría más allá del alcance de este libro. Un buen libro para empezar que trata el tema en profundidad es Prometheus: Up & Running (O’Reilly).

Ahora vamos a poner la configuración de Prometheus en nuestro clúster de Kubernetes. Hay muchas maneras diferentes de hacerlo, y el despliegue dependerá de la aplicación específica. En este capítulo se instala Prometheus Operator:

Servidor Prometheus

Extrae y almacena las métricas que se recogen de los sistemas.

Operador Prometheus

Hace que la configuración de Prometheus sea nativa de Kubernetes, y administra y opera los clústeres de Prometheus y Alertmanager. Nos permite crear, destruir y configurar los recursos de Prometheus mediante las definiciones de recursos nativos de Kubernetes.

Exportador de nodos

Exporta las métricas de hosts desde los nodos de Kubernetes en el clúster.

kube-state-metrics

Recopila métricas específicas de Kubernetes.

Alertmanager

Permite configurar y enviar alertas a sistemas externos.

Grafana

Proporciona la visualización en el dashboard (panel) de las capacidades.

helm install --name prom stable/prometheus-operator

Después de instalar Operator (operador), deberíamos poder ver las siguientes cápsulas implementadas en el clúster:

$ kubectl get pods -n monitoring NAME READY STATUS RESTARTS AGE alertmanager-main-0 2/2 Running 0 5h39m alertmanager-main-1 2/2 Running 0 5h39m alertmanager-main-2 2/2 Running 0 5h38m grafana-5d8f767-ct2ws 1/1 Running 0 5h39m kube-state-metrics- 7fb8b47448-k6j6g 4/4 Running 0 5h39m node-exporter-5zk6k 2/2 Running 0 5h39m node-exporter-874ss 2/2 Running 0 5h39m node-exporter-9mtgd 2/2 Running 0 5h39m node-exporter-w6xwt 2/2 Running 0 5h39m prometheus-adapter- 66fc7797fd-ddgk5 1/1 Running 0 5h39m prometheus-k8s-0 3/3 Running 1 5h39m prometheus-k8s-1 3/3 Running 1 5h39m prometheus-operator- 7cb68545c6-gm84j 1/1 Running 0 5h39m

Echemos un vistazo al servidor de Prometheus para ver cómo podemos ejecutar algunas consultas para extraer las métricas de Kubernetes:

kubectl port-forward svc/prom-prometheus-operator-prometheus 9090

Esta consulta crea un túnel a nuestro localhost en el puerto 9090. Ahora, podemos abrir un navegador web y conectarnos al servidor Prometheus en http://127.0.0.1:9090.

La Figura 3-2 muestra la pantalla que veremos si hemos implementado con éxito Prometheus en el clúster.

Ahora que hemos implementado Prometheus, exploremos algunas métricas de Kubernetes utilizando el lenguaje de consulta Prometheus PromQL. Hay una guía de PromQL Basics disponible en la página oficial de Prometheus (https://prometheus.io/docs/prometheus/latest/querying/basics/).

Anteriormente, hablamos sobre el empleo del método USE, así que vamos a recopilar algunas métricas de nodos sobre la utilización y saturación de la CPU.

Figura 3-2 Panel de Prometheus.

En la entrada Expression, introducimos la siguiente consulta:

avg(rate(node_cpu_seconds_total[5m]))

Esta consulta devolverá el valor promedio de utilización de la CPU para todo el clúster.

Si queremos obtener la utilización de la CPU por nodo, podemos escribir una consulta como la siguiente:

avg(rate(rate(node_cpu_seconds_total[5m]))) by (node_name)

Esta consulta devuelve el valor promedio de utilización de la CPU para cada nodo del clúster.

Así que, ahora que tenemos algo de experiencia en la ejecución de consultas en Prometheus, vamos a ver cómo Grafana puede ayudar a crear la visualización en el panel de estas métricas habituales del método USE que queremos rastrear. Lo mejor de Prometheus Operator es que viene con algunos paneles prediseñados de Grafana que podemos usar.

Ahora tendremos que crear un túnel de redireccionamiento de puertos a la cápsula de Grafana para que podamos acceder desde nuestra máquina local:

kubectl port-forward svc/prom-grafana 3000:3000

Ahora, apuntamos nuestro navegador web a http://localhost:3000 e iniciamos sesión usando las siguientes credenciales:

• Username (nombre de usuario): admin

• Password (contraseña): admin

Situado bajo el panel de Grafana, encontraremos un panel llamado Kubernetes / USE /Method / Cluster. Este panel nos ofrece una visión general de la utilización y saturación del clúster de Kubernetes, que es el corazón del método USE.

La Figura 3-3 presenta un ejemplo del panel.

Figura 3-3 Panel de Grafana.

Seguimos adelante; vamos a dedicar tiempo a explorar los diferentes paneles y métricas que se pueden visualizar en Grafana.

Evitaremos crear demasiados paneles (hecho conocido como «El muro de los gráficos») porque puede resultar difícil razonar en situaciones en las que hay que resolver muchos problemas. Puede que pienses que tener más información en un panel supone una mejor monitorización, pero la mayoría de las veces lo que hace es causar más confusión al usuario que consulta el panel. Orientaremos el diseño de nuestro panel a los resultados y al tiempo de resolución.

Descripción general de la recopilación de registros

Hasta este momento hemos tratado ampliamente sobre métricas y Kubernetes, pero para obtener una imagen completa de nuestro entorno también necesitamos recopilar y centralizar los registros del clúster de Kubernetes y los de las aplicaciones desplegadas en el clúster.

Con los registros, puede resultar fácil decir «Vamos a registrarlo todo», pero esta decisión puede ocasionar dos problemas:

• Que haya demasiado ruido para detectar problemas de forma inmediata.

• Que los registros consuman muchos recursos, lo cual supone un alto coste.

No hay una respuesta clara sobre lo que deberíamos registrar exactamente, puesto que la depuración de registros se convierte en un mal necesario. Con el tiempo empezaremos a entender mejor nuestro entorno y reconoceremos el ruido del sistema de registros al que podemos dejar de prestar atención. Además, para abordar la cantidad cada vez mayor de registros almacenados, necesitaremos implementar una política de retención y de archivado. Desde el punto de vista del usuario final, tener un histórico de registros de entre 30 y 45 días es una buena opción. Esto permite la investigación de problemas que se manifiestan en un período de tiempo más largo, pero también reduce la cantidad de recursos necesarios para almacenar los registros. Si necesitáramos un almacenamiento a más largo plazo por razones de cumplimiento, podríamos pensar en archivar los registros en recursos más baratos.

En un clúster de Kubernetes, hay varios componentes que se deben registrar. A continuación, vemos una lista de los comoponentes cuyas métricas deberíamos recopilar:

• Registros de nodos

• Registros del plano de control de Kubernetes

- Servidor API

- Administrador de controladores

- Scheduler (Planificador)

• Registros de auditoría de Kubernetes

• Registros de contenedores de la aplicación

Con los registros de nodos podemos recopilar eventos que se producen en los servicios esenciales de los nodos. Por ejemplo, podemos tener interés en recopilar registros del daemon (demonio) Docker que se ejecuta en los nodos worker (esclavos). Un daemon Docker que funcione correctamente será esencial para ejecutar los contenedores en los nodos worker. La recopilación de estos registros nos ayudará a diagnosticar cualquier problema que podamos tener con el daemon Docker, y nos proporcionará información sobre cualquier problema subyacente del mismo. También hay otros servicios esenciales del nodo subyacente que nos interesará registrar.

El plano de control de Kubernetes consta de varios componentes, de los que necesitaremos recopilar registros para conseguir más información sobre problemas subyacentes. El plano de control es fundamental para que el clúster funcione correctamente, y a nosotros nos interesará agregar los registros que este almacena en el host en /var/log/kube-APIserver.log, /var/log/kube-scheduler.log y /var/log/kube-controller-manager.log. El controller manager (administrador de controladores) es responsable de la creación de objetos definidos por el usuario final. Como ejemplo, nosotros —como usuarios— podemos crear un servicio Kubernetes con type (tipo) LoadBalancer que se encuentre en un estado pendiente. Es posible que los eventos de Kubernetes no proporcionen todos los detalles para diagnosticar el problema. Si los registros se agrupan en un sistema centralizado, nos proporcionarán más detalles sobre el problema subyacente y una forma más rápida de investigar el problema.

Podemos pensar que los registros de auditoría de Kubernetes son como una monitorización de seguridad porque nos proporcionan una visión de quién hizo qué dentro del sistema. Estos registros pueden ser muy ruidosos, por lo que nos interesa adaptarlos a nuestro entorno. En muchos casos, estos registros pueden causar un gran pico en el sistema de registros cuando se inicializa por primera vez, así que debemos asegurarnos de seguir la guía de la documentación de Kubernetes sobre la monitorización de registros de auditoría.

Los registros de los contenedores de la aplicación nos proporcionan información de los registros reales que emite la aplicación. Podemos enviar estos registros a un repositorio central de varias formas. La primera forma, y la que se recomienda, es enviar todos los registros de la aplicación a STDOUT, porque STDOUT proporciona un modo uniforme de recopilación de dichos registros, y un conjunto de daemons de monitorización pueden recopilar los registros directamente del daemon Docker. La otra forma es usar un patrón sidecar y ejecutar un contenedor de envío de registros junto al contenedor de la aplicación en una cápsula de Kubernetes. Es posible que debamos utilizar este patrón si nuestra aplicación se conecta al sistema de archivos.

Hay muchas opciones y configuraciones para la administración de los registros de auditoría de Kubernetes. Estos registros de auditoría pueden ser muy ruidosos y puede resultar caro registrar todas las acciones. Es una buena idea considerar estudiar la documentación de registro de auditoría, para que podamos ajustar estos registros a nuestro entorno.