Creei Kube Eagle, un exportador de Prometheus. Resultou unha cousa chula que axuda a comprender mellor os recursos dos clústeres pequenos e medianos. Ao final, aforrei centos de dólares porque seleccionei os tipos de máquina correctos e configurei os límites de recursos das aplicacións para as cargas de traballo.
Vouvos falar dos beneficios , pero primeiro explicarei o que causou o alboroto e por que era necesario un seguimento de alta calidade.
Xestionei varios grupos de 4-50 nodos. Cada clúster contén ata 200 microservizos e aplicacións. Para facer un mellor uso do hardware existente, a maioría das implementacións configuráronse con recursos de CPU e memoria RAM que se poden romper. Deste xeito, os pods poden tomar recursos dispoñibles se é necesario e, ao mesmo tempo, non interferir con outras aplicacións deste nodo. Ben, non é xenial?
E aínda que o clúster consumía relativamente pouca CPU (8 %) e RAM (40 %), constantemente tivemos problemas con que os pods fosen anticipados cando tentaban asignar máis memoria da que estaba dispoñible no nodo. Daquela só tiñamos un panel para supervisar os recursos de Kubernetes. Como isto:
Panel de control de Grafana só con métricas de cAdvisor
Con tal panel, non é un problema ver nós que consumen moita memoria e CPU. O problema é descubrir cal é o motivo. Para manter as vainas no seu lugar, pódese configurar recursos garantidos en todas as vainas (recursos solicitados iguais ao límite). Pero este non é o uso máis intelixente do hardware. O clúster tiña varios centos de gigabytes de memoria, mentres que algúns nodos morrían de fame, mentres que outros tiñan entre 4 e 10 GB en reserva.
Resulta que o programador de Kubernetes distribuíu as cargas de traballo de forma desigual entre os recursos dispoñibles. O planificador de Kubernetes ten en conta diferentes configuracións: regras de afinidade, contaminacións e tolerancias, selectores de nodos que poden limitar os nodos dispoñibles. Pero no meu caso non houbo nada parecido, e as vainas planificáronse en función dos recursos solicitados en cada nodo.
Seleccionouse para o pod o nodo que ten máis recursos libres e que cumpre as condicións da solicitude. Descubrimos que os recursos solicitados nos nodos non coincidían co uso real, e aquí foi onde Kube Eagle e as súas capacidades de seguimento de recursos acudiron ao rescate.
Teño case todos os clústeres de Kubernetes supervisados só con и . Node Exporter ofrece estatísticas sobre o uso de E/S e disco, CPU e RAM, mentres que Kube State Metrics mostra métricas de obxectos de Kubernetes, como solicitudes e límites de recursos de memoria e CPU.
Necesitamos combinar as métricas de uso coas métricas de solicitudes e límites en Grafana e despois obteremos toda a información sobre o problema. Parece sinxelo, pero as dúas ferramentas realmente nomean as etiquetas de forma diferente e algunhas métricas non teñen ningunha etiqueta de metadatos. Kube Eagle fai todo por si mesmo e o panel ten este aspecto:
Conseguimos resolver moitos problemas cos recursos e aforrar equipos:
- Algúns desenvolvedores non sabían cantos recursos necesitaban os microservizos (ou simplemente non se preocuparon). Non había forma de atopar solicitudes incorrectas de recursos; para iso necesitamos coñecer o consumo máis as solicitudes e os límites. Agora ven as métricas de Prometheus, supervisan o uso real e axustan as solicitudes e os límites.
- As aplicacións JVM levan tanta memoria RAM como poden manexar. O colector de lixo só libera memoria cando se usa máis do 75 %. E como a maioría dos servizos teñen memoria explosiva, sempre estivo ocupada pola JVM. Polo tanto, todos estes servizos Java estaban consumindo moita máis memoria RAM do esperado.
- Algunhas aplicacións solicitaban demasiada memoria, e o planificador de Kubernetes non deu estes nodos a outras aplicacións, aínda que en realidade eran máis libres que outros nodos. Un desenvolvedor engadiu accidentalmente un díxito adicional na solicitude e colleu unha gran parte de RAM: 20 GB en lugar de 2. Ninguén se decatou. A aplicación tiña 3 réplicas, polo que ata 3 nodos víronse afectados.
- Introducimos límites de recursos, reprogramamos pods coas solicitudes correctas e obtivemos un equilibrio ideal de uso de hardware en todos os nodos. Un par de nodos poderían estar pechados por completo. E entón vimos que tiñamos as máquinas equivocadas (orientadas á CPU, non á memoria). Cambiamos o tipo e eliminamos varios nodos máis.
Resultados de
Con recursos explosivos no clúster, utilizas o hardware dispoñible de forma máis eficiente, pero o programador de Kubernetes programa pods en función das solicitudes de recursos, e isto é abondo. Para matar dous paxaros dun tiro: para evitar problemas e aproveitar ao máximo os recursos, cómpre un bo seguimento. Por iso será útil (Exportador de Prometheus e panel de control Grafana).
Fonte: www.habr.com