He creado Kube Eagle, un exportador de Prometheus. Resultó ser una herramienta genial que ayuda a comprender mejor los recursos de clústeres pequeños y medianos. Al final, ahorré más de cien dólares, porque seleccioné los tipos correctos de máquinas y ajusté los límites de recursos de las aplicaciones según las cargas de trabajo.
Les hablaré de las ventajas , pero primero explicaré por qué surgió el problema y para qué se necesitaba un monitoreo de calidad.
He administrado varios clústeres con entre 4 y 50 nodos. En cada clúster hay hasta 200 microservicios y aplicaciones. Para utilizar mejor el hardware disponible, la mayoría de los despliegues estaban configurados con memoria RAM y recursos de CPU tipo burstable. Así, los pods pueden aprovechar los recursos disponibles si es necesario, sin perjudicar a otras aplicaciones en el mismo nodo. ¿No es genial?
Y aunque el clúster consumía relativamente poca CPU (8%) y memoria (40%), constantemente teníamos problemas con la expulsión de pods cuando intentaban asignar más memoria de la que estaba disponible en el nodo. Entonces, solo teníamos un panel para monitorear los recursos de Kubernetes. Este:
Panel de Grafana solo con métricas de cAdvisor
Con ese panel, no es un problema ver los nodos que consumen mucha memoria y CPU. El problema es entender cuál es la causa. Para que los pods se mantengan en su lugar, se podrían haber configurado recursos garantizados en todos los pods (los recursos solicitados son iguales al límite). Pero no es la forma más inteligente de usar el hardware. En el clúster había varios cientos de gigas de memoria, mientras que algunos nodos estaban hambrientos, y otros tenían entre 4 y 10 GB de sobra.
Resulta que el planificador de Kubernetes distribuía las cargas de trabajo de manera desigual según los recursos disponibles. El planificador de Kubernetes considera diferentes configuraciones: reglas de afinidad, taints y tolerations, selectores de nodos, que pueden limitar los nodos disponibles. Pero en mi caso no había nada de eso, y los pods se planificaban según los recursos solicitados en cada nodo.
Para un pod se elegía el nodo con más recursos libres que cumpliera con las condiciones de la solicitud. Así, nos dimos cuenta de 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 vinieron al rescate.
Casi todos mis clústeres de Kubernetes eran monitoreados solo con y . Node Exporter proporciona estadísticas sobre la entrada-salida y el uso del disco, CPU y memoria, mientras que Kube State Metrics muestra métricas de objetos de Kubernetes, como las solicitudes y límites de recursos de CPU y memoria.
Necesitamos combinar las métricas de uso con las métricas de solicitudes y límites en Grafana, y así obtendremos toda la información sobre el problema. Suena simple, pero en la práctica, estos dos instrumentos utilizan nombres diferentes para las etiquetas, y algunas métricas ni siquiera tienen etiquetas de metadatos. Kube Eagle lo hace todo automáticamente y el panel se ve así:
Hemos logrado resolver muchos problemas de recursos y ahorrar en hardware:
- Algunos desarrolladores no sabían cuántos recursos necesitaban los microservicios (o simplemente no se preocupaban). No teníamos forma de identificar las solicitudes de recursos incorrectas, ya que necesitábamos conocer el consumo además de las solicitudes y límites. Ahora ven las métricas de Prometheus, monitorean el uso real y ajustan sus solicitudes y límites.
- Las aplicaciones JVM toman tanto memoria RAM como pueden. El recolector de basura libera memoria solo si se utiliza más del 75%. Y dado que la mayoría de los servicios tienen memoria burstable, el JVM siempre estaba ocupando esa memoria. Por lo tanto, todos estos servicios Java consumían mucha más memoria de la esperada.
- Algunas aplicaciones solicitaban demasiada memoria, y el programador de Kubernetes no le asignaba esos nodos a otras aplicaciones, aunque en realidad estaban más libres que otros nodos. Un desarrollador accidentalmente agregó un dígito adicional a su solicitud y ocupó una gran cantidad de memoria: 20 GB en lugar de 2. Nadie se percató. La aplicación tenía 3 réplicas, así que afectó a 3 nodos.
- Hemos establecido límites de recursos, replanificado los pods con las solicitudes correctas y logrado un balance ideal en el uso del hardware en todos los nodos. Algunos nodos podrían cerrarse por completo. Luego vimos que teníamos máquinas incorrectas (enfocadas en CPU y no en memoria). Cambiamos el tipo y eliminamos otros nodos.
Resultados
Con recursos burstable en el clúster, utilizas de manera más eficiente el hardware disponible, pero el programador de Kubernetes planifica los pods según las solicitudes de recursos, lo cual puede ser problemático. Para matar dos pájaros de un tiro: evitar problemas y usar los recursos al máximo, se necesita un buen monitoreo. Para esto es útil. (exportador de Prometheus y panel de control de Grafana).
Fuente: habr.com
