O uso de CPU e memória está correlacionado ao número de bytes de cada amostra e o número de amostras extraídas. Esses parâmetros de comparação baseiam-se nos destinos padrão extraídos, no volume de métricas personalizadas extraídas e no número de nós, pods e contêineres. Esses números são uma referência, pois o uso ainda pode variar significativamente dependendo do número de séries temporais e bytes por métrica.
Atualmente, o limite de volume superior por pod é de cerca de 3 a 3,5 milhões de amostras por minuto, dependendo do número de bytes por amostra. Essa limitação é resolvida quando a fragmentação é adicionada no futuro.
O agente consiste em uma implantação com uma réplica e um DaemonSet para métricas de extração. O DaemonSet extrai todos os destinos no nível do nó, como cAdvisor, kubelet e exportador de nós. Você também pode configurá-lo para extrair quaisquer destinos personalizados no nível do nó com configurações estáticas. O conjunto de réplicas extrai todo o resto, como kube-state-metrics ou trabalhos de extração personalizados que utilizam a descoberta de serviço.
Comparação entre cluster pequeno e grande para réplica
Destinos de extração
Amostras Enviadas / Minuto
Contagem de nós
Contagem de Pods
Uso da CPU Prometheus-Coletor (núcleos)
Uso de memória Prometheus-Coletor (bytes)
destinos padrão
11.344
3
40
12,9 mc
148 Mi
destinos padrão
260.000
340
13000
1,10c
1,70 GB
destinos padrão + destinos personalizados
3,56 milhões
340
13000
5,13c
9,52 GB
Comparação entre cluster pequeno e grande para DaemonSets
Destinos de extração
Amostras Enviadas / Total de minutos
Amostras Enviadas / Minuto / Pod
Contagem de nós
Contagem de Pods
Total de Uso da CPU Prometheus-Coletor (núcleos)
Total de Uso de Memória Prometheus-Coletor (bytes)
Uso da CPU / Pod (núcleos) Prometheus-Coletor
Uso de Memória / Pod (bytes) Prometheus-Coletor
destinos padrão
9.858
3.327
3
40
41,9 mc
581 Mi
14,7 mc
189 Mi
destinos padrão
2,3 milhões
14.400
340
13000
805 mc
305,34 GB
2,36 mc
898 Mi
Para mais métricas personalizadas, o pod único se comporta da mesma forma que o pod réplica, dependendo do volume de métricas personalizadas.
Agendar o pod réplica ama-metrics em um pool de nós com mais recursos
Um grande volume de métricas por pod exige que o nó tenha capacidade suficiente de CPU e memória. Caso o pod de réplica ama-metrics não seja agendado em um nó ou em um pool de nós com recursos suficientes, ele poderá ser finalizado por falta de memória (OOMKilled) e entrar no estado de CrashLoopBackoff. Para corrigir isso, você pode adicionar o rótulo azuremonitor/metrics.replica.preferred=true a um nó ou pool de nós no seu cluster que tenha recursos mais elevados (no pool de nós do sistema). Isso garante que o pod de réplica seja agendado nesse nó. Outra opção é criar pools de sistema extras com nós maiores e aplicar o mesmo rótulo. É melhor rotular pools de nós em vez de nós individuais, para que novos nós adicionados ao pool também possam ser usados para o agendamento.