Kubernetes: Números do nosso cluster
A palavra Kubernetes é extremamente normal nos corredores do Grupo ZAP ━ agora, junto com a OLX Brasil somos a unidade de negócio ZAP+.
Faz mais de um ano que ele faz parte do dia a dia da Engenharia e principalmente do time de Plataforma. E quais são os números que tornam esse cluster o orgulho de nosso time?
Aqui você vai conseguir ver mais de perto como nós funcionamos e quais são esses números.
Como monitoramos nosso cluster?
Para monitorar e armazenar nossas métricas, escolhemos o Prometheus. Então vamos começar por ele:
Prometheus
Atualmente o Prometheus monitora aplicações e serviços essenciais que rodam no cluster de Kubernetes, algumas aplicações que rodam na AWS e também alguns serviços core oferecidos pelo time de Plataforma que não rodam no cluster de Kubernetes como, por exemplo, o Kafka.
Um dos monitoramentos que olhamos com frequência em nosso Prometheus é a de novas métricas criadas. Ele nos ajuda a garantir como nosso serviço irá performar de acordo com os novos dados que ingerimos. No gráfico abaixo, por exemplo, podemos ver a quantidade de samples ingeridas por job. Nos últimos minutos, tivemos uma média de 2k de samples em nossos endpoints de aplicação no Kubernetes, gerando um total de 255k novas métricas.
Caso algum novo projeto seja adicionado, conseguimos ver pelo gráfico novas métricas que podem causar problemas de performance no Prometheus, identificando rapidamente quem está causando impacto.
No gráfico seguinte, podemos ver que a média de samples ingeridas é de 260 mil por minuto, acumulando um total de 67 milhões de samples por hora.
E abaixo, podemos ver como é a utilização de nossos recursos baseados na ingestão atual de samples.
Com esse número de samples, os recursos necessários para manter o Prometheus funcionando são valores entre 20GB e 25GB de RAM e 1.0 e 3.0 CPUs.
Números do nosso cluster
Começando pelo básico e lembrando que o que estamos mostrando é uma média da utilização diária do cluster, nossos números são:
- Nodes: 160, com picos de 300.
- Pods: 2500, com picos de 4000.
- Services: 308
- Configmaps: 191
- Secrets: 405
- Aplicações: 306 (deployments + statefulsets)
Utilização de recursos computacionais
Como nosso objetivo é sempre utilizar do melhor modo nossos recursos, não gostamos de super provisionar recursos e desperdiçar dinheiro. Para evitar isso, monitoramos todos os recursos provisionados vs recursos utilizados em nosso cluster, e também tentamos garantir que sempre 100% das nossas aplicações estão rodando em instâncias do tipo Spot.
No momento atual, estamos rodando com 87% do nosso cluster em instâncias spot.
Na imagem abaixo, mostro um de nossos monitoramentos que indica quanto temos disponível de recursos em nosso cluster para a quantidade de pods atual rodando nele:
No gráfico a seguir, temos a média de recursos provisionados vs recursos utilizados em nosso cluster. São 1800GB de RAM provisionados em nosso cluster e utilizamos uma média de 1200GB.
Quando falamos de CPU no contexto das aplicações do Grupo ZAP, temos que prestar atenção que várias aplicações solicitam muita CPU para "startar", mas não utilizam tanto durante seu funcionamento no cluster, fazendo com que muitos de nossos nós tenha desperdício. O gráfico seguinte mostra que temos reservado cerca de 700 CPUs, mas utilizamos normalmente uma média de 300 CPUs.
É importante lembrar que medimos a utilização de recursos por namespace e por container em nosso cluster, o que permite sugerir modificações para os times de Engenharia relacionados à utilização de recursos dos seus apps. A seguir mostro um de nossos gráficos que faz uma comparação de recursos solicitados vs recursos utilizados (por namespace).
O time de data-analytics, por exemplo, solicita para suas aplicações 496GB de RAM, mas, naquele momento, estava utilizando apenas 295GB de RAM.
Ingress
Em nossa principal porta da internet para as aplicações, temos os seguintes números:
- Endpoints: 300 (245 internos e 55 externos)
- Pods: 13 (7 públicos e 6 privados)
Como podemos ver acima, tivemos picos de 222k RPM e nossa média é de 103k RPM (nos últimos 7 dias).
E abaixo, você consegue ver a utilização de recursos do Ingress:
Mesmo com a grande quantidade de RPM que temos em nosso Ingress, nesses 7 dias nossa utilização média foi de 0.13 cores por pod e 422 MB de RAM.
Por que temos todos esses números?
Quando começamos a utilizar o Kubernetes, essa mudança foi um grande desafio para toda a Engenharia e, principalmente para o time de Plataforma, que teve que lidar com diversos problemas que foram aparecendo conforme a utilização foi aumentando.
No início, nada era monitorado e um problema levava horas para ser resolvido. Hoje em dia, com a maturidade de nosso time, das ferramentas e com o monitoramento avançado que foi criado, podemos descobrir em minutos a origem de um problema e muitas vezes é possível prevê-lo antes que impacte aplicações sensíveis para o negócio.
Métricas e números não são só importantes para a aplicação: são importantes para a saúde do desenvolvedor. Poder acompanhar uma aplicação, prever problemas e aplicar soluções antes de uma falha ajudam a ter um sono mais tranquilo, mesmo para essa grande quantidade de pods rodando.
E esses números não vão ficar assim, queremos crescer ainda mais! Já pensou em fazer parte desse time e trabalhar com essas tecnologias? Junte-se a nós! 😉 https://careers.smartrecruiters.com/OLXBrasil
