# 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
2. 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.
3. 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:
4. 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
5. 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.**
6. 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:
6. 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.
