As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
CNI da Amazon VPC
dica
Explore as
O Amazon EKS implementa redes de clusters por meio do plugin
O Amazon VPC CNI tem dois componentes:
-
CNI Binary, que configurará a rede Pod para permitir a Pod-to-Pod comunicação. O binário CNI é executado em um sistema de arquivos raiz de nó e é invocado pelo kubelet quando um novo pod é adicionado ou quando um pod existente é removido do nó.
-
ipamd, um daemon de gerenciamento de endereços IP (IPAM) local de longa duração e é responsável por:
-
gerenciando ENIs em um nó e
-
manter um pool aquecido de endereços IP ou prefixos disponíveis
-
Quando uma instância é criada, o EC2 cria e anexa uma ENI primária associada a uma sub-rede primária. A sub-rede primária pode ser pública ou privada. Os pods que são executados no modo HostNetwork usam o endereço IP primário atribuído à ENI primária do nó e compartilham o mesmo namespace de rede do host.
O plug-in CNI gerencia as interfaces de rede elásticas (ENI) no nó. Quando um nó é provisionado, o plug-in CNI aloca automaticamente um pool de slots (IPs ou prefixos) da sub-rede do nó para a ENI primária. Esse pool é conhecido como pool aquecido e seu tamanho é determinado pelo tipo de instância do nó. Dependendo das configurações da CNI, um slot pode ser um endereço IP ou um prefixo. Quando um slot em um ENI é atribuído, o CNI pode conectar ENIs adicionais com um pool aquecido de slots aos nós. Esses ENIs adicionais são chamados de ENIs secundários. Cada ENI só pode oferecer suporte a um determinado número de slots, com base no tipo de instância. O CNI atribui mais ENIs às instâncias com base no número de slots necessários, o que geralmente corresponde ao número de pods. Esse processo continua até que o nó não possa mais suportar ENI adicional. O CNI também pré-aloca ENIs e slots “quentes” para uma inicialização mais rápida do pod. Observe que cada tipo de instância tem um número máximo de ENIs que podem ser anexados. Essa é uma restrição na densidade de pods (número de pods por nó), além dos recursos computacionais.
O número máximo de interfaces de rede e o número máximo de slots que você pode usar variam de acordo com o tipo de instância do EC2. Como cada pod consome um endereço IP em um slot, o número de pods que você pode executar em uma instância EC2 específica depende de quantos ENIs podem ser conectados a ela e quantos slots cada ENI suporta. Sugerimos definir o máximo de pods por guia do usuário do EKS para evitar o esgotamento dos recursos de CPU e memória da instância. Os pods usados hostNetwork são excluídos desse cálculo. Para obter mais informações, consulte Como os MaxPods são determinados no Guia do usuário do Amazon EKS.
Visão geral do
O modo IP secundário é o modo padrão para VPC CNI. Este guia fornece uma visão geral genérica do comportamento da CNI da VPC quando o modo IP secundário está ativado. A funcionalidade do ipamd (alocação de endereços IP) pode variar dependendo das configurações da VPC CNI, comoModo de prefixo para Linux, e. Grupos de segurança por pod Rede personalizada
O CNI do Amazon VPC é implantado como um Daemonset do Kubernetes chamado aws-node em nós de trabalho. Quando um nó de trabalho é provisionado, ele tem um ENI padrão, chamado ENI primário, anexado a ele. O CNI aloca um pool quente de ENIs e endereços IP secundários da sub-rede conectada à ENI primária do nó. Por padrão, o ipamd tenta alocar um ENI adicional para o nó. O IPAMD aloca ENI adicional quando um único pod é programado e recebe um endereço IP secundário do ENI primário. Esse ENI “quente” permite uma rede de Pod mais rápida. À medida que o pool de endereços IP secundários se esgota, o CNI adiciona outro ENI para atribuir mais.
O número de ENIs e endereços IP em um pool é configurado por meio de variáveis de ambiente chamadas WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET. aws-node Daemonset verificará periodicamente se um número suficiente de ENIs está conectado. Um número suficiente de ENIs é anexado quando todas as WARM_ENI_TARGET MINIMUM_IP_TARGET condições ou WARM_IP_TARGET e são atendidas. Se não houver ENIs anexados insuficientes, o CNI fará uma chamada de API para o EC2 para anexar mais até que o MAX_ENI limite seja atingido.
-
WARM_ENI_TARGET- Número inteiro, valores maiores que 0 indicam o requisito ativado-
O número de ENIs quentes a serem mantidos. Uma ENI fica “quente” quando é conectada como uma ENI secundária a um nó, mas não está sendo usada por nenhum pod. Mais especificamente, nenhum endereço IP da ENI foi associado a um pod.
-
Exemplo: considere uma instância com 2 ENIs, cada ENI suportando 5 endereços IP. WARM_ENI_TARGET está definido como 1. Se exatamente 5 endereços IP estiverem associados à instância, a CNI manterá 2 ENIs anexados à instância. A primeira ENI está em uso e todos os 5 endereços IP possíveis dessa ENI são usados. O segundo ENI é “quente” com todos os 5 endereços IP no pool. Se outro pod for iniciado na instância, será necessário um sexto endereço IP. O CNI atribuirá a esse 6º Pod um endereço IP do segundo ENI e de 5 IPs do pool. O segundo ENI está agora em uso e não está mais em um status “quente”. O CNI alocará um 3º ENI para manter pelo menos 1 ENI quente.
-
nota
Os ENIs quentes ainda consomem endereços IP do CIDR da sua VPC. Os endereços IP são “não usados” ou “quentes” até serem associados a uma carga de trabalho, como um pod.
-
WARM_IP_TARGET, Inteiro, Valores maiores que 0 indicam o requisito Ativado-
O número de endereços IP quentes a serem mantidos. Um IP quente está disponível em um ENI ativamente conectado, mas não foi atribuído a um pod. Em outras palavras, o número de IPs quentes disponíveis é o número de IPs que podem ser atribuídos a um pod sem exigir um ENI adicional.
-
Exemplo: considere uma instância com 1 ENI, cada ENI suportando 20 endereços IP. WARM_IP_TARGET está definido como 5. WARM_ENI_TARGET está definido como 0. Somente 1 ENI será anexada até que um 16º endereço IP seja necessário. Em seguida, o CNI anexará um segundo ENI, consumindo 20 endereços possíveis da sub-rede CIDR.
-
-
MINIMUM_IP_TARGET, Inteiro, Valores maiores que 0 indicam o requisito Ativado-
O número mínimo de endereços IP a serem alocados a qualquer momento. Isso geralmente é usado para antecipar a atribuição de vários ENIs na inicialização da instância.
-
Exemplo: considere uma instância recém-lançada. Ele tem 1 ENI e cada ENI suporta 10 endereços IP. MINIMUM_IP_TARGET está definido como 100. O ENI anexa imediatamente mais 9 ENIs para um total de 100 endereços. Isso acontece independentemente de qualquer valor WARM_IP_TARGET ou WARM_ENI_TARGET.
-
Este projeto inclui um documento Excel da Calculadora de WARM_IP_TARGET WARM_ENI_TARGET
Quando o Kubelet recebe uma solicitação de adição de pod, o binário CNI consulta ipamd para obter um endereço IP disponível, que o ipamd então fornece ao Pod. O binário CNI conecta o host e a rede Pod.
Os pods implantados em um nó são, por padrão, atribuídos aos mesmos grupos de segurança do ENI primário. Como alternativa, os pods podem ser configurados com grupos de segurança diferentes.
À medida que o grupo de endereços IP é esgotado, o plugin anexa automaticamente outra interface de rede elástica à instância e aloca outro conjunto de endereços IP secundários a essa interface. Esse processo continua até que o nó não possa mais oferecer suporte a interfaces de rede elástica adicionais.
Quando um pod é excluído, o VPC CNI coloca o endereço IP do pod em um cache de resfriamento de 30 segundos. Os IPs em um cache de resfriamento não são atribuídos a novos pods. Quando o período de resfriamento termina, o VPC CNI move o IP do pod de volta para a piscina aquecida. O período de resfriamento evita que os endereços IP do pod sejam reciclados prematuramente e permite que o kube-proxy em todos os nós do cluster termine de atualizar as regras do iptables. Quando o número de IPs ou ENIs excede o número de configurações de pool aquecido, o plug-in ipamd retorna IPs e ENIs para a VPC.
Conforme descrito acima no modo IP secundário, cada pod recebe um endereço IP privado secundário de um dos ENIs conectados a uma instância. Como cada pod usa um endereço IP, o número de pods que você pode executar em uma instância específica do EC2 depende de quantos ENIs podem ser anexados a ela e quantos endereços IP ela suporta. O VPC CNI verifica o arquivo de
Você pode usar a fórmula a seguir para determinar o número máximo de pods que podem ser implantados em um nó.
(Number of network interfaces for the instance type * (the number of IP addresses per network interface - 1)) + 2
O +2 indica pods que exigem rede de host, como kube-proxy e VPC CNI. O Amazon EKS exige que o kube-proxy e o VPC CNI estejam operando em cada nó, e esses requisitos são considerados no valor de max-pods. Se você quiser executar pods adicionais de rede de host, considere atualizar o valor de max-pods. Você pode especificar --kubelet-extra-args "—max-pods=110" como dados do usuário no modelo de lançamento.
Por exemplo, em um cluster com 3 nós c5.large (3 ENIs e máximo de 10 IPs por ENI), quando o cluster é inicializado e tem 2 pods CoreDNS, o CNI consumirá 50 endereços IP e manterá 43 IPs no pool aquecido. A piscina aquecida permite lançamentos mais rápidos do pod quando o aplicativo é implantado.
Nó 1 (com pod CoreDNS): 2 ENIs, 20 IPs atribuídos
Node 2 (com pod CoreDNS): 2 ENIs, 20 IPs atribuídos
Node 3 (sem pod): 1 ENI. 10 IPs atribuídos.
Para o Nó 1 e o Nó 2 (configuração idêntica):
-
2 ENIs × 10 IPs por ENI = 20 IPs no total
-
Subtraia 2 IPs primários (1 por ENI) = 18 IPs
-
Subtraia 1 IP para o pod CoreDNS = 17 IPs disponíveis
-
Então, cada um desses nós tem 17 IPs na piscina aquecida
Para o Node 3:
-
1 ENI × 10 IPs = 10 IPs no total
-
Subtraia 1 IP primário = 9 IPs disponíveis na piscina aquecida
Cálculo total da piscina aquecida: - 17 (Nodo 1) + 17 (Nodo 2) + 9 (Nodo 3) = 43 IPs
Lembre-se de que cada pods de infraestrutura, geralmente executados como conjuntos de daemons, contribui para a contagem máxima de pods. Isso pode incluir:
-
CoreDNS
-
Amazon Elastic LoadBalancer
-
Pods operacionais para servidor de métricas
Sugerimos que você planeje sua infraestrutura combinando as capacidades desses Pods. Para ver uma lista do número máximo de pods suportados por cada tipo de instância, consulte eni-max-pods.txt
Recomendações
Implemente o cluster EKS com o modo automático
Quando você usa o EKS Auto Mode para criar um cluster, a AWS gerencia a configuração da VPC Container Network Interface (CNI) para seu cluster. Com o Modo automático do Amazon EKS, você não precisa instalar ou atualizar complementos de rede. No entanto, garanta que suas cargas de trabalho sejam compatíveis com a configuração gerenciada da VPC CNI.
Implemente o VPC CNI Managed Add-On
Quando você provisiona um cluster, o Amazon EKS instala o VPC CNI automaticamente. No entanto, o Amazon EKS oferece suporte a complementos gerenciados que permitem que o cluster interaja com os recursos subjacentes da AWS, como computação, armazenamento e rede. É altamente recomendável que você implante clusters com complementos gerenciados, incluindo VPC CNI.
O complemento gerenciado do Amazon EKS oferece instalação e gerenciamento de VPC CNI para clusters do Amazon EKS. Os complementos do Amazon EKS incluem os patches de segurança e correções de erros mais recentes e são validados pela AWS para funcionar com o Amazon EKS. O complemento VPC CNI permite que você garanta continuamente a segurança e a estabilidade de seus clusters do Amazon EKS e diminua o esforço necessário para instalar, configurar e atualizar complementos. Além disso, um complemento gerenciado pode ser adicionado, atualizado ou excluído por meio da API do Amazon EKS, do AWS Management Console, da AWS CLI e do eksctl.
Você pode encontrar os campos gerenciados do VPC CNI usando --show-managed-fields flag com o kubectl get comando.
kubectl get daemonset aws-node --show-managed-fields -n kube-system -o yaml
Os complementos gerenciados evitam desvios na configuração substituindo automaticamente as configurações a cada 15 minutos. Isso significa que todas as alterações nos complementos gerenciados, feitas por meio da API Kubernetes após a criação do complemento, serão substituídas pelo processo automatizado de prevenção de desvios e também definidas como padrão durante o processo de atualização do complemento.
Os campos gerenciados pelo EKS estão listados em ManagedFields com o gerente como EKS. Os campos gerenciados pelo EKS incluem conta de serviço, imagem, URL da imagem, sonda de vivacidade, sonda de prontidão, rótulos, volumes e montagens de volume.
nota
Os campos usados com mais frequência, como WARM_ENI_TARGET, WARM_IP_TARGET e MINIMUM_IP_TARGET, não são gerenciados e não serão reconciliados. As alterações nesses campos serão preservadas após a atualização do complemento.
Sugerimos testar o comportamento do complemento em seus clusters que não são de produção para uma configuração específica antes de atualizar os clusters de produção. Além disso, siga as etapas no guia do usuário do EKS para configurações complementares.
Migrar para gerenciado Add-On
Você gerenciará a compatibilidade da versão e atualizará os patches de segurança do VPC CNI autogerenciado. Para atualizar um complemento autogerenciado, você deve usar as APIs e as instruções do Kubernetes descritas no guia do usuário do EKS. https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on Recomendamos migrar para um complemento gerenciado para clusters EKS existentes e é altamente recomendável criar um backup de suas configurações CNI atuais antes da migração. Para configurar complementos gerenciados, você pode utilizar a API do Amazon EKS, o AWS Management Console ou a AWS Command Line Interface.
kubectl apply view-last-applied daemonset aws-node -n kube-system aws-k8s-cni-old.yaml
O Amazon EKS substituirá as configurações da CNI se o campo estiver listado como gerenciado com as configurações padrão. Advertimos contra a modificação dos campos gerenciados. O complemento não reconcilia campos de configuração, como as variáveis de ambiente quente e os modos CNI. Os pods e os aplicativos continuarão em execução enquanto você migra para um CNI gerenciado.
Faça backup das configurações CNI antes da atualização
O VPC CNI é executado no plano de dados do cliente (nós) e, portanto, o Amazon EKS não atualiza automaticamente o complemento (gerenciado e autogerenciado) quando novas versões são lançadas ou depois que você atualiza seu cluster para uma nova versão secundária do Kubernetes. Para atualizar o complemento de um cluster existente, você deve acionar uma atualização por meio da API update-addon ou clicando no link atualizar agora no console EKS para complementos. Se você implantou o complemento autogerenciado, siga as etapas mencionadas em Atualização do complemento CNI da VPC autogerenciado.
É altamente recomendável que você atualize uma versão secundária por vez. Por exemplo, se a sua versão atual for a 1.9 e você quiser atualizá-la para a 1.11, deverá primeiro atualizá-la para a versão de patch mais recente da 1.10 primeiro e, em seguida, para a versão de patch mais recente da 1.11.
Faça uma inspeção do daemonset do aws-node antes de atualizar o CNI do Amazon VPC. Faça um backup das configurações existentes. Se estiver usando um complemento gerenciado, confirme que você não atualizou nenhuma configuração que o Amazon EKS possa substituir. Recomendamos um gancho de pós-atualização em seu fluxo de trabalho de automação ou uma etapa de aplicação manual após uma atualização adicional.
kubectl apply view-last-applied daemonset aws-node -n kube-system aws-k8s-cni-old.yaml
Para um complemento autogerenciado, compare o backup com o releases on GitHub para ver as versões disponíveis e familiarize-se com as alterações na versão para a qual você deseja atualizar. Recomendamos usar o Helm para gerenciar complementos autogerenciados e aproveitar os arquivos de valores para aplicar as configurações. Qualquer operação de atualização envolvendo a exclusão do Daemonset resultará em tempo de inatividade do aplicativo e deverá ser evitada.
Entenda o contexto de segurança
É altamente recomendável que você entenda os contextos de segurança configurados para gerenciar o VPC CNI de forma eficiente. O Amazon VPC CNI tem dois componentes: CNI binary e ipamd (aws-node) Daemonset. O CNI é executado como um binário em um nó e tem acesso ao sistema de arquivos raiz do nó, além de ter acesso privilegiado, pois lida com iptables no nível do nó. O binário CNI é invocado pelo kubelet quando os pods são adicionados ou removidos.
O aws-node Daemonset é um processo de longa duração responsável pelo gerenciamento de endereços IP no nível do nó. O aws-node é executado no hostNetwork modo e permite acesso ao dispositivo de loopback e à atividade de rede de outros pods no mesmo nó. O aws-node init-container é executado no modo privilegiado e monta o soquete CRI, permitindo que o Daemonset monitore o uso de IP pelos pods em execução no nó. O Amazon EKS está trabalhando para remover o requisito privilegiado do contêiner aws-node init. Além disso, o aws-node precisa atualizar as entradas NAT e carregar os módulos iptables e, portanto, é executado com privilégios NET_ADMIN.
O Amazon EKS recomenda a implantação das políticas de segurança definidas pelo manifesto aws-node para gerenciamento de IP dos pods e das configurações de rede. Considere atualizar para a versão mais recente do VPC CNI. Além disso, considere abrir um GitHub problema
Use uma função IAM separada para CNI
O AWS VPC CNI exige permissões do AWS Identity and Access Management (IAM). A política da CNI precisa ser configurada antes que a função do IAM possa ser usada. Você pode usar AmazonEKS_CNI_Policy
Por padrão, a VPC CNI herda a função IAM do nó Amazon EKS (grupos de nós gerenciados e autogerenciados).
É altamente recomendável configurar uma função separada do IAM com as políticas relevantes para o Amazon VPC CNI. Caso contrário, os pods do Amazon VPC CNI recebem a permissão atribuída à função IAM do nó e têm acesso ao perfil da instância atribuído ao nó.
O plug-in VPC CNI cria e configura uma conta de serviço chamada aws-node. Por padrão, a conta de serviço se vincula à função IAM do nó Amazon EKS com a política CNI do Amazon EKS anexada. Para usar a função separada do IAM, recomendamos que você crie uma nova conta de serviço com a política CNI do Amazon EKS anexada. Para usar uma nova conta de serviço, você deve reimplantar os pods CNI. Considere especificar um complemento gerenciado --service-account-role-arn para VPC CNI ao criar novos clusters. Certifique-se de remover a política CNI do Amazon EKS para IPv4 e IPv6 da função de nó do Amazon EKS.
É recomendável que você bloqueie os metadados da instância de acesso para minimizar o raio de explosão da violação de segurança.
Lidar com Liveness/Readiness falhas na sonda
Recomendamos aumentar os valores de tempo limite da sonda de vida e prontidão (padrãotimeoutSeconds: 10) para clusters EKS 1.20 e posteriores para evitar que falhas na sondagem façam com que o pod do seu aplicativo fique preso no estado ContainerCreating. Esse problema foi observado em clusters com uso intenso de dados e processamento em lote. O alto uso da CPU causa falhas na integridade da sonda aws-node, levando a solicitações de CPU do pod não atendidas. Além de modificar o tempo limite da sondagem, certifique-se de que as solicitações de recursos de CPU (padrãoCPU: 25m) para aws-node estejam configuradas corretamente. Não sugerimos atualizar as configurações, a menos que seu nó esteja tendo problemas.
É altamente recomendável que você execute o sudo bash /opt/cni/bin/aws-cni-support.sh em um node enquanto contrata o suporte do Amazon EKS. O script ajudará na avaliação dos registros do kubelet e da utilização da memória no nó. Considere instalar o SSM Agent nos nós de trabalho do Amazon EKS para executar o script.
Configurar a política de encaminhamento do IPTables em instâncias de AMI não otimizadas para EKS
Se você estiver usando uma AMI personalizada, certifique-se de definir a política de encaminhamento de iptables como ACCEPT em https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/rootfs/etc/systemd/system/kubelet.service
Atualize rotineiramente a versão CNI
O VPC CNI é compatível com versões anteriores. A versão mais recente funciona com todas as versões do Kubernetes compatíveis com o Amazon EKS. Além disso, o VPC CNI é oferecido como um complemento do EKS (consulte “Implantar VPC CNI Managed” acima). Add-On Embora os complementos do EKS orquestrem atualizações de complementos, eles não atualizarão automaticamente complementos como o CNI porque eles são executados no plano de dados. Você é responsável por atualizar o complemento VPC CNI após as atualizações gerenciadas e autogerenciadas do node de trabalho.
