Regras

As Regras de Kubernetes são um conjunto de recomendações baseadas nas aplicações sendo executadas nos Clusters e buscando dar visibilidade da sub-utilização dos Nós em execução dentro dos Clusters. Essas regras são divididas em duas categorias: Economia e Boas Práticas.

Como chegar em Regras:

1. Em Kubernetes, selecione a opção Regras.

Regras

1. Cada regra terá uma visão com algumas informações conforme abaixo:

• Nodes Encontrados: Lista a quantidade de Nodes encontrados que se aplicam a recomendação.

• Custo estimado de economia: Custo de economia mensal estimada com a realização da recomendação.

• Categoria: Informa se a recomendação possui algum saving relacionado ou apenas se aplica a uma boa prática de utilização do recurso.

1. Ao clicar no nome da regra em azul, o sistema irá exibir uma visão gráfica da recomendação ao longo do tempo e uma economia estimada, caso seja uma regra de economia:

1. Mais abaixo, é possível visualização uma lista mais detalhada com informações de todos os nodes ou workloads encontrados, que se aplicam a regra:

• Para recomendações de Economia, serão exibidas informações como:

  • Node

  • Tipo de Node

  • Região

  • Account ID

  • Nome do Cluster

  • Custo do Node (CPU e Memória)

• Para recomendações de Boas Práticas, serão exibidas informações como:

  • Aplicação

  • Nome do Cluster

  • Container

  • Namespace

  • Tipo de Aplicação

  • Limite de CPU

1. Clicando no nome em azul, o sistema irá direcionar para a informação mais detalhada por aplicação na página de Overview. Em caso de Nodes, ele irá direcionar para a informação mais detalhada do Node na página de Nodes.

2. Clicando no ícone de Filtros, conforme indicado abaixo:

O sistema irá exibir todas as opções de labels coletados da plataforma de observabilidade, permitindo aplicar o campo de filtro desejado para o K8s:

Ao selecionar o campo desejado, será possível fornecer mais informações sobre o campo de filtro, como:

• Habilitar a opção de expressões negativas, caso queira trabalhar com um resultado diferente do informado.

• É igual a: Nesse caso, deve ser selecionado o valor desejado no retorno.

• É vazio: Quando for desejado um resultado vazio para o meu retorno.

• Contém: Quando for desejado que o resultado contenha um valor específico a ser informado.

• Começa com: Quando for desejado que o resultado começe com um valor específico a ser informado.

• Termina com: Quando for desejado que o resultado termine com um valor específico a ser informado.

E clicando no botão Salvar, o sistema irá exibir o filtro adicionado:

1. Além de permitir aplicar um campo de filtro, o sistema também permite aplicar um período de competência:

Clicando na opção de período, conforme destado acima, o sistema irá abrir o mês informado, permitindo selecionar um dia especifico:

Ao selecionar o dia desejado, clicando no botão Recarregar, o sistema irá atualizar os dados da página para o novo dia informado:

Por fim, clicando no ícone "" o sistema permite extrair um relatório em formato CSV.

Regras de Economia

• Nodes com baixa utilização: Nós com baixa utilização de CPU e memória indicam recursos ociosos. Para otimizar custos, esses nós podem ser removidos ou redimensionados.

Regras de Boas Práticas

• Workloads com CPU Limit: Exceder o limite de CPU leva a throttling do vCPU, impactando o desempenho de todos os pods no node devido ao enfileiramento de instruções.

• Workloads sem Request de CPU: Pods sem request de CPU podem levar a um provisionamento ilimitado, causando throttling de vCPU e impactando a performance. A reserva de CPU tende a melhorar significativamente o desempenho da aplicação.

• Workloads sem Request de Memória: A ausência de request de memória pode levar à exaustão da memória do nó e, consequentemente, a falhas. Alocar memória garante melhor desempenho.

• Workloads sem limite de Memória: A ausência de limite de memória em pods pode consumir toda a memória do nó, causando travamento e custos desnecessários, sem intervenção do ASG.

• Workloads com request e limite de memória diferentes: A configuração de limit de memória superior ao request expõe o nó ao risco de travamento por exaustão de memória, comportamento semelhante ao de pods sem limite.