Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Solucionar problemas de políticas de rede do Kubernetes para o Amazon EKS

Este é o guia de solução de problemas do recurso de políticas de rede da CNI da Amazon VPC.

Este guia aborda:

Você pode solucionar problemas e investigar conexões de rede que usam políticas de rede lendo os logs de política de rede e executando ferramentas do SDK do eBPF.

Novo CRD policyendpoints e permissões

Para a política de rede, a CNI da VPC cria um novo CustomResourceDefinition (CRD) denominado policyendpoints.networking.k8s.aws. A CNI da VPC deve ter permissões para criar o CRD e o CustomResources (CR) dele e do outro CRD instalado pela CNI da VPC (eniconfigs.crd.k8s.amazonaws.com). Ambos os CRDs estão disponíveis no arquivo crds.yaml no GitHub. Especificamente, a CNI da VPC deve ter as permissões das ações “get”, “list” e “watch” para policyendpoints.

A Política de Rede do Kubernetes faz parte da apiservice denominada v1.networking.k8s.io, e isso é apiversion: networking.k8s.io/v1 nos seus arquivos YAML da política. A CNI da VPC DaemonSet precisa ter permissões para usar essa parte da API do Kubernetes.

As permissões da CNI da VPC estão em um ClusterRole denominado aws-node. Observe que os objetos ClusterRole não estão agrupados em namespaces. O seguinte mostra o aws-node de um cluster:

kubectl get clusterrole aws-node -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/instance: aws-vpc-cni
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: aws-node
    app.kubernetes.io/version: v1.19.4
    helm.sh/chart: aws-vpc-cni-1.19.4
    k8s-app: aws-node
  name: aws-node
rules:
- apiGroups:
  - crd.k8s.amazonaws.com
  resources:
  - eniconfigs
  verbs:
  - list
  - watch
  - get
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - list
  - watch
  - get
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list
  - watch
  - get
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - list
  - watch
  - get
- apiGroups:
  - ""
  - events.k8s.io
  resources:
  - events
  verbs:
  - create
  - patch
  - list
- apiGroups:
  - networking.k8s.aws
  resources:
  - policyendpoints
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.aws
  resources:
  - policyendpoints/status
  verbs:
  - get
- apiGroups:
  - vpcresources.k8s.aws
  resources:
  - cninodes
  verbs:
  - get
  - list
  - watch
  - patch

Além disso, um novo controlador é executado no ambiente de gerenciamento de cada cluster do EKS. O controlador usa as permissões do ClusterRole denominado eks:network-policy-controller. O seguinte mostra o eks:network-policy-controller de um cluster:

kubectl get clusterrole eks:network-policy-controller -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: amazon-network-policy-controller-k8s
  name: eks:network-policy-controller
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.aws
  resources:
  - policyendpoints
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - networking.k8s.aws
  resources:
  - policyendpoints/finalizers
  verbs:
  - update
- apiGroups:
  - networking.k8s.aws
  resources:
  - policyendpoints/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - networking.k8s.io
  resources:
  - networkpolicies
  verbs:
  - get
  - list
  - patch
  - update
  - watch

Logs da política de rede

Cada decisão tomada pela CNI da VPC com relação a se as conexões são permitidas ou negadas pelas políticas de uma rede está registrada nos logs de fluxo. Os logs da política de rede de cada nó incluem os logs de fluxo para todo pod que tem uma política de rede. Os logs da política de rede são armazenados em /var/log/aws-routed-eni/network-policy-agent.log. O seguinte exemplo é de um arquivo de network-policy-agent.log:

{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}

Os logs de política de rede estão desabilitados por padrão. Para habilitar os logs de política de rede, siga estas etapas:

Complemento do Amazon EKS

A captura de tela a seguir mostra um exemplo desse cenário.

Complemento autogerenciado

Enviar logs de política de rede para o Amazon CloudWatch Logs

Você pode monitorar os logs da política de rede usando serviços como o Amazon CloudWatch Logs. Você pode usar os métodos a seguir para enviar os logs da política de rede para o CloudWatch Logs.

Nos clusters do EKS, os logs da política podem ser encontrados em /aws/eks/cluster-name/cluster/, enquanto, para clusters autogerenciados do K8S, os logs estarão em /aws/k8s-cluster/cluster/.

Enviar logs da política de rede com o plug-in CNI da Amazon VPC para Kubernetes

Se você habilitar uma política de rede, um segundo contêiner será adicionado aos pods do aws-node para um agente do nó. Esse agente do nó pode enviar os logs da política de rede para o CloudWatch Logs.

Pré-requisitos

Complemento do Amazon EKS

Complemento autogerenciado

Enviar logs de políticas de rede com um DaemonSet do Fluent Bit

Caso esteja usando o Fluent Bit em um DaemonSet para enviar os logs dos nós, você poderá adicionar configurações para incluir os logs das políticas de rede de políticas de rede. Você pode usar o seguinte exemplo de configuração:

    [INPUT]
        Name              tail
        Tag               eksnp.*
        Path              /var/log/aws-routed-eni/network-policy-agent*.log
        Parser            json
        DB                /var/log/aws-routed-eni/flb_npagent.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10

SDK do eBPF incluído

O plug-in CNI da Amazon VPC para Kubernetes instala uma coleção de ferramentas do SDK do eBPF nos nós. Você pode usar as ferramentas do SDK do eBPF para identificar problemas com as políticas de rede. Por exemplo, o comando a seguir lista os programas que estão sendo executados no nó.

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Para executar esse comando, você pode usar qualquer método de conexão com o nó.

Problemas e soluções conhecidos

As seções a seguir descrevem problemas conhecidos com o recurso de políticas de rede da CNI da Amazon VPC e suas soluções.

Logs de políticas de rede gerados apesar de enable-policy-event-logs estar definido como false

Problema: a CNI da VPC do EKS está gerando logs de políticas de rede mesmo quando a configuração de enable-policy-event-logs está definida como false.

Solução: a configuração de enable-policy-event-logs desabilita apenas os logs de “decisão” da política, mas não desabilita todos os logs do agente da Política de Rede. Esse comportamento está documentado no README do aws-network-policy-agent no GitHub. Para desabilitar completamente o registro em log, você poderá precisar ajustar outras configurações de registro em log.

Problemas de limpeza do mapa de políticas de rede

Problema: problemas com a rede policyendpoint ainda existindo e não sendo limpa após a exclusão dos pods.

Solução: esse problema foi causado por um problema com a versão 1.19.3-eksbuild.1 do complemento da CNI da VPC. Atualize para uma versão mais recente do complemento da CNI da VPC para resolver esse problema.

As políticas de rede não são aplicadas

Problema: o recurso de política de rede está habilitado no plug-in da CNI da Amazon VPC, mas as políticas de rede não estão sendo aplicadas corretamente.

Se você criar uma política de rede kind: NetworkPolicy e ela não afetar o pod, verifique se o objeto policyendpoint foi criado no mesmo namespace do pod. Se não houver objetos policyendpoint nos namespaces, o controlador de políticas de rede (parte do cluster do EKS) não conseguiu criar regras de política de rede para o agente de política de rede (parte da CNI da VPC) a serem aplicadas.

Solução: a solução é corrigir as permissões da CNI da VPC (ClusterRole : aws-node) e do controlador de políticas de rede (ClusterRole : eks:network-policy-controller) e permitir essas ações em qualquer ferramenta de aplicação de políticas, como o Kyverno. Certifique-se de que as políticas do Kyverno não estejam bloqueando a criação de objetos policyendpoint. Consulte a seção anterior para obter as permissões necessárias em Novo CRD policyendpoints e permissões.

Os pods não retornam ao estado de negação padrão após a exclusão da política no modo estrito

Problema: quando as políticas de rede são habilitadas no modo estrito, os pods começam com uma política de negação padrão. Depois que as políticas são aplicadas, o tráfego é permitido para os endpoints especificados. No entanto, quando as políticas são excluídas, o pod não retorna ao estado de negação padrão e, em vez disso, vai para um estado de permissão padrão.

Solução: esse problema foi corrigido na versão 1.19.3 da CNI da VPC, que incluía a versão 1.2.0 do agente de política de rede. Após a correção, com o modo estrito habilitado, depois que as políticas forem removidas, o pod voltará ao estado de negação padrão conforme o esperado.

Grupos de segurança para latência de inicialização de pods

Problema: ao usar o recurso de grupos de segurança para pods no EKS, há um aumento na latência de inicialização de pods.

Solução: a latência se deve à limitação de taxa no controlador de recursos do controle de utilização de APIs na API CreateNetworkInterface, que o controlador de recursos da VPC usa para criar ENIs de ramificação para os pods. Verifique os limites de APIs da sua conta para essa operação e considere solicitar um aumento de limite, se necessário.

FailedScheduling devido à insuficiência de vpc.amazonaws.com/pod-eni

Problema: os pods não são programados com o erro: FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.

Solução: assim como no problema anterior, atribuir grupos de segurança a pods aumenta a latência de programação de pods e pode ultrapassar o limite de tempo da CNI para adicionar cada ENI, causando falhas na inicialização dos pods. Esse é o comportamento esperado ao usar grupos de segurança para pods. Considere as implicações de programação ao projetar sua arquitetura de workloads.

Problemas de conectividade do IPAM e falhas de segmentação

Problema: ocorrem vários erros, incluindo problemas de conectividade do IPAM, solicitações de controle de utilização e falhas de segmentação:

Solução: esse problema ocorrerá se você instalar systemd-udev no AL2023, pois o arquivo será reescrito com uma política de violação. Isso pode acontecer ao atualizar para outro releasever que tenha um pacote atualizado ou ao atualizar manualmente o próprio pacote. Evite instalar ou atualizar systemd-udev nos nós do AL2023.

Erro ao buscar dispositivo pelo nome

Problema: mensagem de erro: {"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}

Solução: esse problema foi identificado e corrigido nas versões mais recentes do agente de política de rede da CNI da Amazon VPC (v1.2.0). Atualize para a versão mais recente da CNI da VPC para resolver esse problema.

Vulnerabilidades CVE na imagem Multus da CNI

Problema: o relatório CVE do EKS ImageScan aprimorado identifica vulnerabilidades na versão v4.1.4-eksbuild.2_thick da imagem Multus da CNI.

Solução: atualize para a nova versão da imagem Multus da CNI e da nova imagem do controlador de políticas de rede, que não têm vulnerabilidades. O scanner pode ser atualizado para solucionar as vulnerabilidades encontradas na versão anterior.

Veredictos de Flow Info DENY em logs

Problema: os logs das políticas de rede mostram os veredictos de DENY: {"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}

Solução: esse problema foi resolvido na nova versão do controlador de políticas de rede. Atualize para a versão mais recente da plataforma do EKS para resolver problemas de registro em log.

Problemas de comunicação entre pods após a migração do Calico

Problema: depois de atualizar um cluster do EKS para a versão 1.30 e mudar do Calico para a CNI da Amazon VPC para fins de política de rede, a comunicação entre pods falha quando as políticas de rede são aplicadas. A comunicação é restaurada quando as políticas de rede são excluídas.

Solução: o agente de política de rede na CNI da VPC não pode ter tantas portas especificadas quanto o Calico. Em vez disso, use intervalos de portas nas políticas de rede. O número máximo de combinações exclusivas de portas para cada protocolo em cada seletor ingress: ou egress: em uma política de rede é 24. Use intervalos de portas para reduzir o número de portas exclusivas e evitar essa limitação.

Agente da política de rede não compatível com pods autônomos

Problema: as políticas de rede aplicadas a pods autônomos podem ter um comportamento inconsistente.

Solução: atualmente, o agente da política de rede oferece suporte apenas a pods implantados como parte de uma implantação/replicaset. Se as políticas de rede forem aplicadas a pods autônomos, poderá haver algumas inconsistências no comportamento. Isso está documentado na parte superior desta página, em Considerações, e em aws-network-policy-agent GitHub issue #327 no GitHub. Implante pods como parte de uma implantação ou replicaset para um comportamento consistente da política de rede.