Creé Kube Eagle, un exportador de Prometheus. Resultó ser algo interesante que ayuda a comprender mejor los recursos de los clústeres pequeños y medianos. Al final, ahorré cientos de dólares porque seleccioné los tipos de máquinas correctos y configuré límites de recursos de aplicaciones para las cargas de trabajo.
Te cuento los beneficios , pero primero explicaré qué causó tanto revuelo y por qué se necesitaba un seguimiento de alta calidad.
Gestioné varios grupos de 4 a 50 nodos. Cada clúster contiene hasta 200 microservicios y aplicaciones. Para hacer un mejor uso del hardware existente, la mayoría de las implementaciones se configuraron con recursos de CPU y RAM ampliables. De esta manera, los pods pueden aprovechar los recursos disponibles si es necesario y, al mismo tiempo, no interferir con otras aplicaciones en este nodo. Bueno, ¿no es genial?
Y aunque el clúster consumía relativamente poca CPU (8%) y RAM (40%), constantemente teníamos problemas con la preferencia de los pods cuando intentaban asignar más memoria de la que estaba disponible en el nodo. En aquel entonces, solo teníamos un panel para monitorear los recursos de Kubernetes. Como esto:
Panel de control de Grafana solo con métricas de cAdvisor
Con un panel de este tipo, no es un problema ver nodos que consumen mucha memoria y CPU. El problema es descubrir cuál es el motivo. Para mantener los pods en su lugar, por supuesto, se podrían configurar recursos garantizados en todos los pods (recursos solicitados iguales al límite). Pero éste no es el uso más inteligente del hardware. El clúster tenía varios cientos de gigabytes de memoria, mientras que algunos nodos estaban muriendo de hambre, mientras que a otros les quedaban entre 4 y 10 GB en reserva.
Resulta que el programador de Kubernetes distribuyó las cargas de trabajo de manera desigual entre los recursos disponibles. El planificador de Kubernetes tiene en cuenta diferentes configuraciones: afinidad, reglas de tolerancia y contaminación, selectores de nodos que pueden limitar los nodos disponibles. Pero en mi caso no hubo nada de eso y los pods se planificaron en función de los recursos solicitados en cada nodo.
Para el pod se seleccionó el nodo que tiene la mayor cantidad de recursos libres y que satisface las condiciones de la solicitud. Descubrimos que los recursos solicitados en los nodos no coincidían con el uso real, y aquí es donde Kube Eagle y sus capacidades de monitoreo de recursos acudieron al rescate.
Tengo casi todos los clusters de Kubernetes monitoreados solo con и . Node Exporter proporciona estadísticas sobre E/S y uso de disco, CPU y RAM, mientras que Kube State Metrics muestra métricas de objetos de Kubernetes, como solicitudes y límites de recursos de memoria y CPU.
Necesitamos combinar las métricas de uso con las métricas de solicitudes y límites en Grafana, y luego obtendremos toda la información sobre el problema. Esto suena simple, pero las dos herramientas en realidad nombran las etiquetas de manera diferente y algunas métricas no tienen ninguna etiqueta de metadatos. Kube Eagle hace todo por sí solo y el panel se ve así:
Logramos resolver muchos problemas con recursos y ahorrar equipos:
- Algunos desarrolladores no sabían cuántos recursos necesitaban los microservicios (o simplemente no se molestaron). No teníamos forma de encontrar solicitudes incorrectas de recursos; para ello necesitamos conocer el consumo más las solicitudes y los límites. Ahora ven las métricas de Prometheus, monitorean el uso real y ajustan las solicitudes y los límites.
- Las aplicaciones JVM consumen tanta RAM como pueden manejar. El recolector de basura solo libera memoria cuando se utiliza más del 75%. Y como la mayoría de los servicios tienen memoria ampliable, siempre estuvo ocupada por la JVM. Por lo tanto, todos estos servicios Java consumían mucha más RAM de lo esperado.
- Algunas aplicaciones solicitaron demasiada memoria y el programador de Kubernetes no proporcionó estos nodos a otras aplicaciones, aunque en realidad eran más libres que otros nodos. Un desarrollador añadió accidentalmente un dígito adicional en la solicitud y tomó una gran cantidad de RAM: 20 GB en lugar de 2. Nadie se dio cuenta. La aplicación tenía 3 réplicas, por lo que hasta 3 nodos se vieron afectados.
- Introdujimos límites de recursos, reprogramamos pods con las solicitudes correctas y obtuvimos un equilibrio ideal de uso de hardware en todos los nodos. Un par de nodos podrían haberse cerrado por completo. Y luego vimos que teníamos las máquinas equivocadas (orientadas a CPU, no a memoria). Cambiamos el tipo y eliminamos varios nodos más.
resultados
Con recursos ampliables en el clúster, se utiliza el hardware disponible de manera más eficiente, pero el programador de Kubernetes programa pods en función de las solicitudes de recursos, y esto es complicado. Para matar dos pájaros de un tiro: para evitar problemas y aprovechar al máximo los recursos, es necesario un buen seguimiento. Por eso será útil. (Exportador de Prometheus y panel de control de Grafana).
Fuente: habr.com