Criei Kube Eagle - um exportador Prometheus. Acabou sendo uma coisa bacana que ajuda a entender melhor os recursos dos clusters de pequeno e médio porte. No final, economizei centenas de dólares porque selecionei os tipos de máquinas corretos e configurei limites de recursos de aplicativos para cargas de trabalho.
Vou te contar sobre os benefícios , mas primeiro explicarei o que causou tanto rebuliço e por que era necessário um monitoramento de alta qualidade.
Gerenciei vários clusters de 4 a 50 nós. Cada cluster contém até 200 microsserviços e aplicativos. Para fazer melhor uso do hardware existente, a maioria das implantações foi configurada com RAM expansível e recursos de CPU. Dessa forma, os pods podem aproveitar os recursos disponíveis se necessário e, ao mesmo tempo, não interferir em outras aplicações neste nó. Bem, não é ótimo?
E embora o cluster consumisse relativamente pouca CPU (8%) e RAM (40%), constantemente tínhamos problemas com a preempção dos pods quando tentavam alocar mais memória do que a disponível no nó. Naquela época, tínhamos apenas um painel para monitorar os recursos do Kubernetes. Assim:
Painel Grafana apenas com métricas cAdvisor
Com esse painel, não é um problema ver nós que consomem muita memória e CPU. O problema é descobrir qual é o motivo. Para manter os pods no lugar, é claro que é possível configurar recursos garantidos em todos os pods (recursos solicitados iguais ao limite). Mas este não é o uso mais inteligente de hardware. O cluster tinha várias centenas de gigabytes de memória, enquanto alguns nós estavam morrendo de fome, enquanto outros tinham de 4 a 10 GB restantes de reserva.
Acontece que o agendador do Kubernetes distribuiu as cargas de trabalho de maneira desigual entre os recursos disponíveis. O agendador Kubernetes leva em consideração diferentes configurações: regras de afinidade, taints e tolerâncias, seletores de nós que podem limitar os nós disponíveis. Mas no meu caso não houve nada disso, e os pods foram planejados dependendo dos recursos solicitados em cada nó.
O nó que possui mais recursos livres e que atende às condições de solicitação foi selecionado para o pod. Descobrimos que os recursos solicitados nos nós não correspondiam ao uso real, e foi aí que o Kube Eagle e seus recursos de monitoramento de recursos vieram em socorro.
Tenho quase todos os clusters Kubernetes monitorados apenas com и . O Node Exporter fornece estatísticas sobre E/S e uso de disco, CPU e RAM, enquanto o Kube State Metrics mostra métricas de objetos do Kubernetes, como solicitações e limites de recursos de CPU e memória.
Precisamos combinar as métricas de uso com as métricas de solicitações e limites no Grafana, e então obteremos todas as informações sobre o problema. Isso parece simples, mas na verdade as duas ferramentas nomeiam os rótulos de maneira diferente, e algumas métricas não possuem nenhum rótulo de metadados. Kube Eagle faz tudo sozinho e o painel fica assim:
Conseguimos resolver muitos problemas com recursos e economizar equipamentos:
- Alguns desenvolvedores não sabiam quantos recursos os microsserviços precisavam (ou simplesmente não se preocuparam). Não tivemos como encontrar solicitações incorretas de recursos - para isso precisamos saber o consumo mais solicitações e limites. Agora eles veem as métricas do Prometheus, monitoram o uso real e ajustam solicitações e limites.
- Os aplicativos JVM ocupam tanta RAM quanto podem suportar. O coletor de lixo só libera memória quando mais de 75% é usado. E como a maioria dos serviços possui memória expansível, ela sempre foi ocupada pela JVM. Portanto, todos esses serviços Java consumiam muito mais RAM do que o esperado.
- Alguns aplicativos solicitaram muita memória e o agendador do Kubernetes não forneceu esses nós para outros aplicativos, embora na verdade eles fossem mais livres do que outros nós. Um desenvolvedor acidentalmente adicionou um dígito extra na solicitação e pegou uma grande quantidade de RAM: 20 GB em vez de 2. Ninguém percebeu. O aplicativo tinha três réplicas, portanto, até três nós foram afetados.
- Introduzimos limites de recursos, reprogramamos pods com as solicitações corretas e obtivemos um equilíbrio ideal de uso de hardware em todos os nós. Alguns nós poderiam ter sido completamente fechados. E então vimos que tínhamos as máquinas erradas (orientadas para CPU, não orientadas para memória). Alteramos o tipo e excluímos vários outros nós.
Resultados de
Com recursos expansíveis no cluster, você usa o hardware disponível com mais eficiência, mas o agendador do Kubernetes agenda pods com base em solicitações de recursos, e isso é complicado. Para matar dois coelhos com uma cajadada só: para evitar problemas e aproveitar ao máximo os recursos, é preciso um bom monitoramento. É por isso que será útil (Exportador Prometheus e painel Grafana).
Fonte: habr.com