**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: + Informações de instalação, CRD e permissões de RBAC [Novo CRD `policyendpoints` e permissões](#network-policies-troubleshooting-permissions) + Logs a serem examinados ao diagnosticar problemas de políticas de rede [Logs da política de rede](#network-policies-troubleshooting-flowlogs) + Execução da coleção de ferramentas do SDK do eBPF para solucionar problemas + Problemas e soluções conhecidos [Problemas e soluções conhecidos](#network-policies-troubleshooting-known-issues) **nota** Observe que as políticas de rede são aplicadas somente aos pods criados pelas *Implementações* do Kubernetes. Para obter mais limitações das políticas de rede na CNI da VPC, consulte [Considerações](cni-network-policy.md#cni-network-policy-considerations). Você pode solucionar problemas e investigar conexões de rede que usam políticas de rede lendo os [logs de política de rede](#network-policies-troubleshooting-flowlogs) e executando ferramentas do [SDK do eBPF](#network-policies-ebpf-sdk). ## Novo CRD `policyendpoints` e permissões + CRD: `policyendpoints.networking.k8s.aws` + API do Kubernetes: `apiservice` chamou `v1.networking.k8s.io` + Recurso do Kubernetes: `Kind: NetworkPolicy` + RBAC: `ClusterRole` chamou `aws-node` (CNI da VPC), `ClusterRole` chamou `eks:network-policy-controller` (controlador de políticas de rede no ambiente de gerenciamento de clusters do EKS) 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`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.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: **nota** Os logs de políticas de rede exigem uma vCPU adicional para o contêiner `aws-network-policy-agent` no manifesto `DaemonSet` `aws-node` da CNI da VPC. ### Complemento do Amazon EKS ** Console de gerenciamento da AWS ** 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. No painel de navegação à esquerda, selecione **Clusters** e o nome do cluster para o qual você deseja configurar o complemento Amazon VPC CNI. 1. Escolha a guia **Add-ons** (Complementos). 1. Selecione a caixa no canto superior direito da caixa do complemento e depois escolha **Edit** (Editar). 1. Na página **Configurar *CNI da Amazon VPC***: 1. Selecione a versão `v1.14.0-eksbuild.3` ou posterior na lista suspensa **Versão**. 1. Expanda **Definições de configuração opcionais**. 1. Insira a chave JSON de mais alto nível `"nodeAgent":` e o valor é um objeto com uma chave `"enablePolicyEventLogs":` e valor de `"true"` em **Valores da configuração**. O texto resultante deve ser um objeto JSON válido. O exemplo apresentado a seguir mostra que a política de rede e os logs de política de rede estão habilitados e que os logs de política de rede são enviados para o CloudWatch Logs: ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true" } } ``` A captura de tela a seguir mostra um exemplo desse cenário. ![\[ mostrando o complemento VPC CNI com a política de rede e os logs do CloudWatch na configuração opcional.\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/console-cni-config-network-policy-logs.png) AWS CLI 1. Execute o seguinte comando da AWS CLI. Substitua `my-cluster` pelo nome do cluster e o ARN do perfil do IAM pelo perfil que você está usando. ``` aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}' ``` ### Complemento autogerenciado Helm Caso tenha instalado o plug-in CNI da Amazon VPC para Kubernetes por meio do `helm`, você pode atualizar a configuração para gravar os logs da política de rede. 1. Execute o comando a seguir para habilitar a política de rede. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` kubectl Caso tenha instalado o plug-in CNI da Amazon VPC para Kubernetes por meio do `kubectl`, você pode atualizar a configuração para gravar os logs da política de rede. 1. Abra o `aws-node` `DaemonSet` no editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Substitua `false` por `true` no argumento de comando `--enable-policy-event-logs=false` em `args:`, no contêiner `aws-network-policy-agent` no manifesto `DaemonSet` `aws-node` da CNI da VPC. ``` - args: - --enable-policy-event-logs=true ``` ### 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. **nota** Somente os logs da política de rede são enviados pelo agente do nó. Outros logs feitos pelo VPC CNI não são incluídos. ##### Pré-requisitos + Adicione as permissões a seguir como uma seção ou uma política separada ao perfil do IAM que você está usando para o VPC CNI. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } ``` ##### Complemento do Amazon EKS ** Console de gerenciamento da AWS ** 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. No painel de navegação à esquerda, selecione **Clusters** e o nome do cluster para o qual você deseja configurar o complemento Amazon VPC CNI. 1. Escolha a guia **Add-ons** (Complementos). 1. Selecione a caixa no canto superior direito da caixa do complemento e depois escolha **Edit** (Editar). 1. Na página **Configurar *CNI da Amazon VPC***: 1. Selecione a versão `v1.14.0-eksbuild.3` ou posterior na lista suspensa **Versão**. 1. Expanda **Definições de configuração opcionais**. 1. Insira a chave JSON de mais alto nível `"nodeAgent":` e o valor é um objeto com uma chave `"enableCloudWatchLogs":` e valor de `"true"` em **Valores da configuração**. O texto resultante deve ser um objeto JSON válido. O exemplo apresentado a seguir mostra que a política de rede e os logs de política de rede estão habilitados e que os logs são enviados para o CloudWatch Logs: ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true", } } ``` A captura de tela a seguir mostra um exemplo desse cenário. ![\[ mostrando o complemento VPC CNI com a política de rede e os logs do CloudWatch na configuração opcional.\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png) ** AWS CLI** 1. Execute o seguinte comando da AWS CLI. Substitua `my-cluster` pelo nome do cluster e o ARN do perfil do IAM pelo perfil que você está usando. ``` aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}' ``` ##### Complemento autogerenciado **Helm** Caso tenha instalado o plug-in CNI da Amazon VPC para Kubernetes por meio do `helm`, você pode atualizar a configuração para enviar os logs da política de rede para o CloudWatch Logs. 1. Execute o comando apresentado a seguir para habilitar logs de política de rede e enviá-los ao CloudWatch Logs. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` **kubectl** 1. Abra o `aws-node` `DaemonSet` no editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Substitua `false` por `true` nos dois argumentos de comando `--enable-policy-event-logs=false` e `--enable-cloudwatch-logs=false` em `args:`, no contêiner `aws-network-policy-agent` no manifesto `DaemonSet` `aws-node` da CNI da VPC. ``` - args: - --enable-policy-event-logs=true - --enable-cloudwatch-logs=true ``` #### 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](https://github.com/aws/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](#network-policies-troubleshooting-permissions). ### 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: + `Checking for IPAM connectivity …​` + `Throttling request took 1.047064274s` + `Retrying waiting for IPAM-D` + `panic: runtime error: invalid memory address or nil pointer dereference` **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\$1thick 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](cni-network-policy.md#cni-network-policy-considerations), e em [aws-network-policy-agent GitHub issue \$1327](https://github.com/aws/aws-network-policy-agent/issues/327) no GitHub. Implante pods como parte de uma implantação ou replicaset para um comportamento consistente da política de rede.