Monitoramento de cargas de trabalho do EKS para problemas de desempenho de rede

Monitorando o tráfego do CoreDNS para problemas de limitação de DNS

Às vezes, a execução de cargas de trabalho intensivas de DNS pode apresentar falhas intermitentes do CoreDNS devido à limitação do DNS, e isso pode afetar os aplicativos nos quais você pode encontrar erros ocasionais. UnknownHostException

O Deployment for CoreDNS tem uma política de antiafinidade que instrui o programador do Kubernetes a executar instâncias do CoreDNS em nós de trabalho separados no cluster, ou seja, ele deve evitar a colocação de réplicas no mesmo nó de trabalho. Isso reduz efetivamente o número de consultas de DNS por interface de rede porque o tráfego de cada réplica é roteado por meio de uma ENI diferente. Se você perceber que as consultas de DNS estão sendo limitadas devido ao limite de 1024 pacotes por segundo, você pode 1) tentar aumentar o número de réplicas de CoreDNS ou 2) implementar. NodeLocal DNSCache Consulte Monitorar métricas do CoreDNS para obter mais informações.

Desafio

• A queda de pacotes ocorre em segundos e pode ser difícil monitorar adequadamente esses padrões para determinar se a limitação do DNS está realmente acontecendo.

• As consultas de DNS são limitadas no nível da interface elastic network. Portanto, as consultas limitadas não aparecem no registro de consultas.

• Os logs de fluxo não capturam todo o tráfego de IP. Por exemplo: O tráfego gerado por instâncias quando elas entram em contato com o servidor de DNS da Amazon. Se você usa seu próprio servidor DNS, todo o tráfego para esse servidor DNS é registrado

Solução

Uma maneira fácil de identificar os problemas de limitação do DNS nos nós de trabalho é capturando métricas. linklocal_allowance_exceeded O linklocal_allowance_exceeded é o número de pacotes descartados porque o PPS do tráfego para os serviços de proxy locais excedeu o máximo da interface de rede. Isso afeta o tráfego para o serviço de DNS, o Instance Metadata Service e o Amazon Time Sync Service. Em vez de rastrear esse evento em tempo real, também podemos transmitir essa métrica para o Amazon Managed Service for Prometheus e visualizá-la no Amazon Managed Grafana

Monitorando atrasos nas consultas de DNS usando métricas do Conntrack

Outra métrica que pode ajudar a monitorar o atraso de limitação/consulta do CoreDNS é e. conntrack_allowance_available conntrack_allowance_exceeded Falhas de conectividade causadas pelo excesso das permissões de conexões rastreadas podem ter um impacto maior do que aquelas resultantes da superação de outras permissões. Ao confiar no TCP para transferir dados, os pacotes que são enfileirados ou descartados devido ao excesso das permissões de rede da EC2 instância, como largura de banda, PPS etc., geralmente são tratados normalmente graças aos recursos de controle de congestionamento do TCP. Os fluxos afetados serão reduzidos e os pacotes perdidos serão retransmitidos. No entanto, quando uma instância excede sua permissão de conexões rastreadas, nenhuma nova conexão pode ser estabelecida até que algumas das existentes sejam fechadas para abrir espaço para novas conexões.

conntrack_allowance_availablee conntrack_allowance_exceeded ajuda os clientes a monitorar a franquia de conexões rastreadas, que varia em cada instância. Essas métricas de desempenho de rede dão aos clientes visibilidade sobre o número de pacotes enfileirados ou descartados quando as permissões de rede de uma instância, como largura de banda de rede Packets-Per-Second (PPS), conexões rastreadas e acesso ao serviço Link-local (Amazon DNS, Instance Meta Data Service, Amazon Time Sync) são excedidas

conntrack_allowance_availableé o número de conexões rastreadas que podem ser estabelecidas pela instância antes de atingir a permissão de conexões rastreadas desse tipo de instância (compatível somente com instâncias baseadas em nitro). conntrack_allowance_exceededé o número de pacotes descartados porque o rastreamento de conexão excedeu o máximo da instância e não foi possível estabelecer novas conexões.

Outras métricas importantes de desempenho da rede

Outras métricas importantes de desempenho da rede incluem:

bw_in_allowance_exceeded(o valor ideal da métrica deve ser zero) é o número de pacotes enfileirados e/ou descartados porque a largura de banda agregada de entrada excedeu o máximo da instância

bw_out_allowance_exceeded(o valor ideal da métrica deve ser zero) é o número de pacotes enfileirados e/ou descartados porque a largura de banda agregada de saída excedeu o máximo da instância

pps_allowance_exceeded(o valor ideal da métrica deve ser zero) é o número de pacotes enfileirados e/ou descartados porque o PPS bidirecional excedeu o máximo da instância

Capturando as métricas para monitorar cargas de trabalho em busca de problemas de desempenho de rede

O driver do Elastic Network Adapter (ENA) publica as métricas de desempenho da rede discutidas acima a partir das instâncias em que elas estão habilitadas. Todas as métricas de desempenho da rede podem ser publicadas CloudWatch usando o CloudWatch agente. Consulte o blog para obter mais informações.

Agora, vamos capturar as métricas discutidas acima, armazená-las no Amazon Managed Service for Prometheus e visualizá-las usando o Amazon Managed Grafana

Pré-requisitos

• ethtool - Certifique-se de que os nós de trabalho tenham o ethtool instalado

• Um espaço de trabalho AMP configurado em sua conta da AWS. Para obter instruções, consulte Criar um espaço de trabalho no Guia do usuário do AMP.

• Espaço de trabalho gerenciado pela Amazon em Grafana

Implantando o exportador Prometheus ethtool

A implantação contém um script python que extrai informações do ethtool e as publica no formato prometheus.

kubectl apply -f https://raw.githubusercontent.com/Showmax/prometheus-ethtool-exporter/master/deploy/k8s-daemonset.yaml

Implante o coletor ADOT para extrair as métricas do ethtool e armazenar no espaço de trabalho do Amazon Managed Service for Prometheus

Cada cluster no qual você instala o AWS Distro OpenTelemetry (ADOT) deve ter essa função para conceder à sua conta de serviço da AWS permissões para armazenar métricas no Amazon Managed Service for Prometheus. Siga estas etapas para criar e associar seu perfil do IAM à sua conta de serviço do Amazon EKS utilizando o IRSA:

eksctl create iamserviceaccount --name adot-collector --namespace default --cluster <CLUSTER_NAME> --attach-policy-arn arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess --attach-policy-arn arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy --region <REGION> --approve  --override-existing-serviceaccounts

Vamos implantar o coletor ADOT para extrair as métricas do exportador prometheus ethtool e armazená-las no Amazon Managed Service for Prometheus

O procedimento a seguir usa um exemplo de arquivo YAML com a implantação como o valor do modo. Este é o modo padrão e implanta o Coletor ADOT de forma semelhante a uma aplicação autônoma. Essa configuração recebe métricas de OTLP do aplicativo de amostra e métricas do Amazon Managed Service for Prometheus extraídas de pods no cluster.

curl -o collector-config-amp.yaml https://raw.githubusercontent.com/aws-observability/aws-otel-community/master/sample-configs/operator/collector-config-amp.yaml

Em collector-config-amp .yaml, substitua o seguinte pelos seus próprios valores:

• modo: implantação

• Conta de serviço: coletor de pontos

• ponto final: <YOUR_REMOTE_WRITE_ENDPOINT>

• região: <YOUR_ >AWS_REGION

• nome: adot-collector

kubectl apply -f collector-config-amp.yaml

Depois que o coletor de adot for implantado, as métricas serão armazenadas com sucesso no Amazon Prometheus

Configure o gerenciador de alertas no Amazon Managed Service para que o Prometheus envie notificações

Você pode usar o gerenciador de alertas no Amazon Managed Service for Prometheus para configurar regras de alerta para alertas críticos e, em seguida, enviar notificações para um tópico do Amazon SNS. Vamos configurar regras de gravação e regras de alerta para verificar as métricas discutidas até agora.

Usaremos o ACK Controller for Amazon Managed Service for Prometheus para provisionar as regras de alerta e gravação.

Vamos implantar o controlador ACL para o serviço Amazon Managed Service for Prometheus:

export SERVICE=prometheusservice
export RELEASE_VERSION=`curl -sL https://api.github.com/repos/aws-controllers-k8s/$SERVICE-controller/releases/latest | grep '"tag_name":' | cut -d'"' -f4`
export ACK_SYSTEM_NAMESPACE=ack-system
export AWS_REGION=us-east-1
aws ecr-public get-login-password --region us-east-1 | helm registry login --username AWS --password-stdin public.ecr.aws
helm install --create-namespace -n $ACK_SYSTEM_NAMESPACE ack-$SERVICE-controller \
oci://public.ecr.aws/aws-controllers-k8s/$SERVICE-chart --version=$RELEASE_VERSION --set=aws.region=$AWS_REGION

Execute o comando e depois de alguns instantes você verá a seguinte mensagem:

You are now able to create Amazon Managed Service for Prometheus (AMP) resources!

The controller is running in "cluster" mode.

The controller is configured to manage AWS resources in region: "us-east-1"

The ACK controller has been successfully installed and ACK can now be used to provision an Amazon Managed Service for Prometheus workspace.

Agora, vamos criar um arquivo yaml para provisionar a definição do gerenciador de alertas e os grupos de regras. Salve o arquivo abaixo como rulegroup.yaml

apiVersion: prometheusservice.services.k8s.aws/v1alpha1
kind: RuleGroupsNamespace
metadata:
   name: default-rule
spec:
   workspaceID: <Your WORKSPACE-ID>
   name: default-rule
   configuration: |
     groups:
     - name: ppsallowance
       rules:
       - record: metric:pps_allowance_exceeded
         expr: rate(node_net_ethtool{device="eth0",type="pps_allowance_exceeded"}[30s])
       - alert: PPSAllowanceExceeded
         expr: rate(node_net_ethtool{device="eth0",type="pps_allowance_exceeded"} [30s]) > 0
         labels:
           severity: critical

         annotations:
           summary: Connections dropped due to total allowance exceeding for the  (instance {{ $labels.instance }})
           description: "PPSAllowanceExceeded is greater than 0"
     - name: bw_in
       rules:
       - record: metric:bw_in_allowance_exceeded
         expr: rate(node_net_ethtool{device="eth0",type="bw_in_allowance_exceeded"}[30s])
       - alert: BWINAllowanceExceeded
         expr: rate(node_net_ethtool{device="eth0",type="bw_in_allowance_exceeded"} [30s]) > 0
         labels:
           severity: critical

         annotations:
           summary: Connections dropped due to total allowance exceeding for the  (instance {{ $labels.instance }})
           description: "BWInAllowanceExceeded is greater than 0"
     - name: bw_out
       rules:
       - record: metric:bw_out_allowance_exceeded
         expr: rate(node_net_ethtool{device="eth0",type="bw_out_allowance_exceeded"}[30s])
       - alert: BWOutAllowanceExceeded
         expr: rate(node_net_ethtool{device="eth0",type="bw_out_allowance_exceeded"} [30s]) > 0
         labels:
           severity: critical

         annotations:
           summary: Connections dropped due to total allowance exceeding for the  (instance {{ $labels.instance }})
           description: "BWoutAllowanceExceeded is greater than 0"
     - name: conntrack
       rules:
       - record: metric:conntrack_allowance_exceeded
         expr: rate(node_net_ethtool{device="eth0",type="conntrack_allowance_exceeded"}[30s])
       - alert: ConntrackAllowanceExceeded
         expr: rate(node_net_ethtool{device="eth0",type="conntrack_allowance_exceeded"} [30s]) > 0
         labels:
           severity: critical

         annotations:
           summary: Connections dropped due to total allowance exceeding for the  (instance {{ $labels.instance }})
           description: "ConnTrackAllowanceExceeded is greater than 0"
     - name: linklocal
       rules:
       - record: metric:linklocal_allowance_exceeded
         expr: rate(node_net_ethtool{device="eth0",type="linklocal_allowance_exceeded"}[30s])
       - alert: LinkLocalAllowanceExceeded
         expr: rate(node_net_ethtool{device="eth0",type="linklocal_allowance_exceeded"} [30s]) > 0
         labels:
           severity: critical

         annotations:
           summary: Packets dropped due to PPS rate allowance exceeded for local services  (instance {{ $labels.instance }})
           description: "LinkLocalAllowanceExceeded is greater than 0"

Substitua seu ID DO ESPAÇO DE TRABALHO pelo ID do espaço de trabalho que você está usando.

Agora vamos configurar a definição do gerenciador de alertas. Salve o arquivo abaixo como alertmanager.yaml

apiVersion: prometheusservice.services.k8s.aws/v1alpha1
kind: AlertManagerDefinition
metadata:
  name: alert-manager
spec:
  workspaceID: <Your WORKSPACE-ID >
  configuration: |
    alertmanager_config: |
      route:
         receiver: default_receiver
       receivers:
       - name: default_receiver
          sns_configs:
          - topic_arn: TOPIC-ARN
            sigv4:
              region: REGION
            message: |
              alert_type: {{ .CommonLabels.alertname }}
              event_type: {{ .CommonLabels.event_type }}

Substitua You WORKSPACE-ID pelo Workspace ID do novo espaço de trabalho, TOPIC-ARN pelo ARN de um tópico do Amazon Simple Notification Service para o qual você deseja enviar os alertas e REGION pela região atual da carga de trabalho. Certifique-se de que seu espaço de trabalho tenha permissões para enviar mensagens para o Amazon SNS.

Visualize as métricas do ethtool no Amazon Managed Grafana

Vamos visualizar as métricas na Amazon Managed Grafana e criar um painel. Configure o Amazon Managed Service para Prometheus como uma fonte de dados dentro do console Amazon Managed Grafana. Para obter instruções, consulte Adicionar o Amazon Prometheus como fonte de dados

Vamos explorar as métricas no Amazon Managed Grafana agora: clique no botão explorar e pesquise por ethtool:

Vamos criar um painel para a métrica linklocal_allowance_exceeded usando a consulta. rate(node_net_ethtool{device="eth0",type="linklocal_allowance_exceeded"}[30s]) Isso resultará no painel abaixo.

Podemos ver claramente que nenhum pacote foi descartado, pois o valor é zero.

Vamos criar um painel para a métrica conntrack_allowance_exceeded usando a consulta. rate(node_net_ethtool{device="eth0",type="conntrack_allowance_exceeded"}[30s]) Isso resultará no painel abaixo.

A métrica conntrack_allowance_exceeded pode ser visualizada em CloudWatch, desde que você execute um agente do cloudwatch conforme descrito aqui. O painel resultante CloudWatch terá a seguinte aparência:

Podemos ver claramente que nenhum pacote foi descartado, pois o valor é zero. Se você estiver usando instâncias baseadas em Nitro, poderá criar um painel semelhante conntrack_allowance_available e monitorar proativamente as conexões em sua EC2 instância. Você pode estender ainda mais isso configurando alertas no Amazon Managed Grafana para enviar notificações para Slack, SNS, Pagerduty etc.