Criei o Kube Eagle – um exportador do Prometheus. Descobri que é uma ferramenta incrível que ajuda a entender melhor os recursos de pequenos e médios clusters. No final, economizei centenas de dólares, pois consegui selecionar os tipos corretos de máquinas e ajustar as limitações de recursos dos aplicativos para as cargas de trabalho.
Vou falar sobre as vantagens , mas primeiro, vou explicar por que surgiu a confusão e para que precisamos de monitoramento de qualidade.
Eu gerenciei vários clusters com 4 a 50 nós. Em cada cluster, havia até 200 microsserviços e aplicativos. Para utilizar melhor o hardware disponível, a maioria dos deployments foi configurada com memória e recursos de CPU do tipo burstable. Assim, os pods podem acessar os recursos disponíveis, se necessário, sem interferir em outros aplicativos naquele nó. Não é incrível?
E embora o cluster consumisse relativamente pouca CPU (8%) e memória (40%), enfrentávamos constantemente problemas de expulsão de pods quando eles tentavam alocar mais memória do que disponível no nó. Naquela época, tínhamos apenas um painel para monitorar os recursos do Kubernetes. Aqui está:
Painel do Grafana apenas com métricas do cAdvisor
Com esse painel, não é um problema identificar nós que consomem muita memória e CPU. O problema é entender a causa. Para que os pods permanecessem no lugar, seria possível configurar recursos garantidos para todos os pods (recursos solicitados iguais ao limite). Mas isso não é a maneira mais inteligente de usar o hardware. O cluster tinha vários centenas de gigabytes de memória, enquanto alguns nós estavam famintos e outros tinham de 4 a 10 GB de sobra.
Consequentemente, o agendador do Kubernetes distribuía as cargas de trabalho de forma desigual pelos recursos disponíveis. O agendador do Kubernetes considera diferentes configurações: regras de affinity, taints e tolerations, seletores de nós que podem limitar os nós disponíveis. Mas no meu caso, nada disso estava presente, e os pods eram agendados com base nos recursos solicitados em cada nó.
Para um pod, selecionava-se o nó com mais recursos livres que atendesse às condições do pedido. Isso resultava em uma discrepância entre os recursos solicitados nos nós e o uso real, e foi aqui que o Kube Eagle entrou com suas capacidades de monitoramento de recursos.
Quase todos os meus clusters Kubernetes eram monitorados apenas com e . O Node Exporter fornece estatísticas sobre I/O e uso de disco, CPU e memória RAM, enquanto o Kube State Metrics mostra métricas de objetos Kubernetes, como solicitações e limites de recursos de CPU e memória.
Precisamos combinar métricas de uso com métricas de solicitações e limites no Grafana, e assim teremos todas as informações sobre o problema. Parece simples, mas na prática, nesses dois instrumentos, os rótulos são diferentes, e algumas métricas não têm rótulos de metadados. O Kube Eagle faz tudo isso automaticamente e o painel fica assim:
Conseguimos resolver muitos problemas de recursos e economizar hardware:
- Alguns desenvolvedores não sabiam quanta memória era necessária para os microserviços (ou simplesmente não se preocupavam). Não tínhamos como identificar solicitações de recursos incorretas — para isso, precisamos conhecer o consumo, além das solicitações e limites. Agora, eles podem ver métricas do Prometheus, monitorar o uso real e ajustar solicitações e limites.
- As aplicações JVM consomem tanto memória RAM quanto conseguem. O coletor de lixo libera memória somente se mais de 75% estiver ocupado. E como a maioria dos serviços tem memória burstable, sempre ocupava mais memória do que o esperado pela JVM. Portanto, todos esses serviços Java consumiam muito mais memória RAM do que prevíamos.
- Alguns aplicativos solicitavam mais memória do que o necessário, e o escalonador do Kubernetes não disponibilizava esses nós para os outros aplicativos, embora na prática estivessem mais livres do que os outros nós. Um desenvolvedor acidentalmente adicionou um dígito extra na solicitação e acabou usando uma grande quantidade de memória RAM: 20 GB em vez de 2. Ninguém percebeu. O aplicativo tinha 3 réplicas, então 3 nós foram afetados.
- Implementamos limites de recursos, replanejamos os pods com as solicitações corretas e alcançamos um equilíbrio ideal de uso de hardware em todos os nós. Alguns nós poderiam, na verdade, ser desligados. Depois, percebemos que tínhamos máquinas inadequadas (otimizadas para CPU, e não para memória). Mudamos o tipo e removemos mais alguns nós.
Resultados
Com recursos burstable no cluster, você utiliza o hardware disponível de forma mais eficiente, mas o escalonador do Kubernetes aloca os pods com base nas solicitações de recursos, o que pode ser problemático. Para resolver isso e evitar problemas enquanto utiliza os recursos ao máximo, é necessário um bom monitoramento. É para isso que ele servirá. (exportador Prometheus e painel de monitoramento Grafana).
Fonte: habr.com
