**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. # Saiba como o Modo Automático do EKS funciona Use este capítulo para saber mais sobre como os componentes dos clusters do Modo Automático do Amazon EKS funcionam. **Topics** + [Saiba mais sobre as instâncias gerenciadas do modo automático do Amazon EKS](automode-learn-instances.md) + [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md) + [Saiba mais sobre as redes de VPC e sobre o balanceamento de carga no modo automático do EKS](auto-networking.md) # Saiba mais sobre as instâncias gerenciadas do modo automático do Amazon EKS Este tópico explica como o Modo automático do Amazon EKS gerencia as instâncias do Amazon EC2 no cluster de EKS. Quando você habilita o Modo automático do EKS, os recursos computacionais do cluster são automaticamente provisionados e gerenciados pelo EKS, mudando a forma como você interage com as instâncias do EC2 que servem como nós no cluster. Entender como o Modo automático do Amazon EKS gerencia as instâncias é essencial para planejar a estratégia de implantação de workloads e procedimentos operacionais. Diferentemente das instâncias do EC2 tradicionais ou dos grupos de nós gerenciados, essas instâncias seguem um modelo de ciclo de vida diferente, em que o EKS assume a responsabilidade por muitos aspectos operacionais, ao mesmo tempo em que restringe certos tipos de acesso e personalização. O Modo automático do Amazon EKS automatiza tarefas de rotina para criar novas instâncias do EC2 e as anexa como nós ao cluster de EKS. O Modo automático do EKS detecta quando uma workload não cabe nos nós existentes e cria uma instância do EC2. O Modo automático do Amazon EKS é responsável por criar, excluir e aplicar patches em instâncias do EC2. Você é responsável pelos contêineres e pods implantados na instância. As instâncias do EC2 criadas pelo Modo automático do EKS são diferentes das outras instâncias do EC2. Elas são instâncias gerenciadas. Essas instâncias gerenciadas são de propriedade do EKS e são mais restritas. Você não pode acessar diretamente ou instalar software em instâncias gerenciadas pelo Modo automático do EKS. A AWS sugere executar o Modo automático do EKS ou o Karpenter autogerenciado. É possível instalar ambos durante uma migração ou em uma configuração avançada. Se você tiver ambos instalados, configure os grupos de nós para que as workloads sejam associadas ao Karpenter ou ao Modo automático do EKS. Para obter mais informações, consulte [Amazon EC2 managed instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) no Guia do usuário do Amazon EC2. ## Tabela de comparação | Instância padrão do EC2 | Instância gerenciada do Modo automático do EKS | | --- | --- | | Você é responsável por aplicar patches e atualizar a instância. | A AWS aplica patches e atualiza automaticamente a instância. | | O EKS não é responsável pelo software na instância. | O EKS é responsável por determinados softwares na instância, como `kubelet`, o runtime do contêiner e o sistema operacional. | | É possível excluir a instância do EC2 usando a API do EC2. | O EKS determina o número de instâncias implantadas na conta. Se você excluir uma workload, o EKS reduzirá o número de instâncias na conta. | | É possível usar o SSH para acessar a instância do EC2. | É possível implantar pods e contêineres na instância gerenciada. | | Você determina o sistema operacional e a imagem (AMI). | A AWS determina o sistema operacional e a imagem. | | É possível implantar workloads que dependam da funcionalidade do Windows ou do Ubuntu. | É possível implantar contêineres baseados em Linux, mas sem dependências específicas do sistema operacional. | | Você determina qual família e tipo de instância executar. | A AWS determina qual família e tipo de instância executar. É possível usar um grupo de nós para limitar os tipos de instância selecionados pelo Modo automático do EKS. | A seguinte funcionalidade funciona tanto para instâncias gerenciadas quanto para instâncias padrão do EC2: + É possível visualizar a instância no console da AWS. + É possível usar o armazenamento de instâncias como armazenamento efêmero para workloads. ### Compatibilidade com a AMI Com o Modo automático do EKS, a AWS determina a imagem (AMI) usada para seus nós de computação. A AWS monitora o lançamento das novas versões de AMIs do Modo automático do EKS. Se você tiver problemas com as workloads relacionados a uma versão de AMI, crie um caso de suporte. Para obter mais informações, consulte [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) no Guia do usuário do AWS Support. Geralmente, o EKS lança uma nova AMI toda semana contendo um CVE e correções de segurança. ## Referência de instâncias compatíveis com o Modo automático do EKS O Modo automático do EKS cria apenas instâncias de tipos compatíveis e que atendem a um requisito de tamanho mínimo. O modo automático do EKS é compatível com os seguintes tipos de instância: | Família | Tipos de instância | | --- | --- | | Otimizada para computação (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 | | Uso geral (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 | | Otimizada para memória (R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 | | Com capacidade de intermitência (T) | t4g, t3, t3a, t2 | | Alta memória (Z/X) | z1d, x8g, x2gd | | Otimizada para armazenamento (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn | | Computação acelerada (P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n | | Computação de alta performance (X2) | x2iezn, x2iedn, x2idn | Além disso, o Modo automático do EKS só criará instâncias do EC2 que atendam aos seguintes requisitos: + Mais de uma CPU + O tamanho da instância não é nano, micro ou pequeno Para obter mais informações, consulte [Convenções de nomenclatura de tipos de instância do Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html). ## Serviço de metadados da instância + O Modo automático do EKS impõe o IMDSv2 com um limite de salto de um por padrão, aderindo às práticas recomendadas de segurança da AWS. + Essa configuração padrão não pode ser modificada no Modo automático. + Para complementos que normalmente exigem acesso ao IMDS, forneça parâmetros (como região da AWS) durante a instalação para evitar consultas ao IMDS. Para obter mais informações, consulte [Determinar os campos que podem ser personalizados para os complementos do Amazon EKS](kubernetes-field-management.md). + Se for absolutamente necessário que um pod tenha acesso ao IMDS ao ser executado no Modo automático, ele deverá ser configurado para ser executado com `hostNetwork: true`. Isso permite que o pod acesse diretamente o serviço de metadados da instância. + Considere as implicações de segurança ao conceder aos pods acesso aos metadados da instância. Para obter mais informações sobre o serviço de metadados de instância (IMDS) do Amazon EC2, consulte [Configurar as opções de serviço de metadados de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) no *Guia do usuário do Amazon EC2*. ## Considerações + Se o armazenamento efêmero configurado no NodeClass for menor do que o armazenamento local NVMe da instância, o Modo automático do EKS eliminará a necessidade de configuração manual executando automaticamente as seguintes ações: + Usa um volume de dados menor (20 GiB) do Amazon EBS para reduzir custos. + Formata e configura o armazenamento local NVMe para uso efêmero de dados. Isso inclui a configuração de uma matriz RAID 0 se houver várias unidades NVMe. + Quando `ephemeralStorage.size` for igual ou exceder a capacidade local do NVMe, as seguintes ações ocorrerão: + O modo automático ignora o pequeno volume de EBS. + Drives NVMe são diretamente expostos à sua workload. + O modo automático do Amazon EKS não é compatível com as seguintes ações do Serviço de Injeção de Falhas da AWS: + `ec2:RebootInstances` + `ec2:SendSpotInstanceInterruptions` + `ec2:StartInstances` + `ec2:StopInstances` + `ec2:TerminateInstances` + `ec2:PauseVolumeIO` + O modo automático do Amazon EKS é compatível com as ações de pod do EKS do Serviço de Injeção de Falhas da AWS. Para obter mais informações, consulte [Gerenciamento de experimentos do Serviço de Injeção de Falhas](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) e [Uso das ações aws:eks:pod do AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) no Guia do usuário do Hub de Resiliência da AWS. + Você não precisa instalar o `Neuron Device Plugin` nos nós do Modo automático do EKS. Caso tenha outros tipos de nós no cluster, você precisará configurar o plug-in Neuron Device para não ser executado em nós do Modo automático. Para obter mais informações, consulte [Controlar se uma workload é implantada nos nós do Modo Automático do EKS](associate-workload.md). # Saber mais sobre identidade e acesso no Modo Automático do EKS Este tópico descreve os perfis e as permissões do Identity and Access Management (IAM) necessários para usar o Modo Automático do EKS. O Modo Automático do EKS usa dois perfis principais do IAM: um perfil do IAM do cluster e um perfil do IAM do nó. Esses perfis trabalham em conjunto com a Identidade de Pods do EKS e as entradas de acesso do EKS para fornecer gerenciamento de acesso abrangente para os clusters do EKS. Ao configurar o Modo Automático do EKS, você precisará configurar esses perfis do IAM com permissões específicas que permitam que os serviços da AWS interajam com os recursos do cluster. Isso inclui permissões para gerenciar recursos computacionais, volumes de armazenamento, balanceadores de carga e componentes de rede. Compreender essas configurações de perfil é essencial para a operação e a segurança adequadas do cluster. No Modo Automático do EKS, os perfis do AWS IAM são mapeados automaticamente para as permissões do Kubernetes por meio de entradas de acesso do EKS, eliminando a necessidade de configuração manual de ConfigMaps `aws-auth` ou vinculações personalizadas. Quando você cria um novo cluster no modo automático, o EKS cria automaticamente as permissões correspondentes do Kubernetes usando entradas de acesso, garantindo que os componentes do cluster e serviços da AWS tenham os níveis de acesso apropriados nos sistemas de autorização da AWS e do Kubernetes. Essa integração automatizada reduz a complexidade da configuração e ajuda a evitar problemas relacionados a permissões que geralmente ocorrem ao gerenciar clusters do EKS. ## Função do IAM do cluster O perfil do IAM do cluster é um perfil do AWS Identity and Access Management (IAM) usado pelo Amazon EKS para gerenciar permissões para clusters do Kubernetes. Esse perfil concede ao Amazon EKS as permissões necessárias para interagir com outros serviços da AWS em nome do cluster, e é configurado automaticamente com as permissões do Kubernetes usando entradas de acesso do EKS. + Você também deve anexar políticas do AWS IAM ao perfil. + O Modo Automático do EKS anexa permissões do Kubernetes a esse perfil automaticamente usando entradas de acesso do EKS. + Com o Modo Automático do EKS, a AWS sugere a criação de um único perfil do IAM do cluster por conta da AWS. + A AWS sugere nomear esse perfil `AmazonEKSAutoClusterRole`. + Esse perfil exige permissões para vários serviços da AWS gerenciarem recursos, incluindo volumes do EBS, Elastic Load Balancers e instâncias do EC2. + A configuração sugerida para esse perfil inclui várias políticas do IAM gerenciadas pela AWS, relacionadas aos diferentes recursos do Modo Automático do EKS. + `AmazonEKSComputePolicy` + `AmazonEKSBlockStoragePolicy` + `AmazonEKSLoadBalancingPolicy` + `AmazonEKSNetworkingPolicy` + `AmazonEKSClusterPolicy` Para obter mais informações sobre o perfil do IAM do cluster e políticas do IAM gerenciadas pela AWS, consulte: + [Políticas gerenciadas pela AWS para o Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Função do IAM do cluster do Amazon EKS](cluster-iam-role.md) Para obter mais informações sobre o acesso do Kubernetes, consulte: + [Analisar permissões da política de acesso](access-policy-permissions.md) ## Perfil do IAM do nó O perfil do IAM do nó é um perfil do AWS Identity and Access Management (IAM) usado pelo Amazon EKS para gerenciar permissões para nós de processamento em clusters do Kubernetes. Esse perfil concede às instâncias do EC2 executadas como nós do Kubernetes as permissões necessárias para interagir com os serviços e recursos da AWS, e é configurado automaticamente com permissões de RBAC do Kubernetes usando entradas de acesso do EKS. + Você também deve anexar políticas do AWS IAM ao perfil. + O Modo Automático do EKS anexa permissões de RBAC do Kubernetes a esse perfil automaticamente usando entradas de acesso do EKS. + A AWS sugere nomear esse perfil `AmazonEKSAutoNodeRole`. + Com o Modo Automático do EKS, a AWS sugere a criação de um único perfil do IAM do nó por conta da AWS. + Esse perfil tem permissões limitadas. As principais permissões incluem assumir um perfil de Identidade de Pods e extrair imagens do ECR. + A AWS sugere as seguintes políticas do IAM gerenciadas pela AWS: + `AmazonEKSWorkerNodeMinimalPolicy` + `AmazonEC2ContainerRegistryPullOnly` Para obter mais informações sobre o perfil do IAM do cluster e políticas do IAM gerenciadas pela AWS, consulte: + [Políticas gerenciadas pela AWS para o Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Perfil do IAM em nós do Amazon EKS](create-node-role.md) Para obter mais informações sobre o acesso do Kubernetes, consulte: + [Analisar permissões da política de acesso](access-policy-permissions.md) ## Perfil vinculado a serviço O Amazon EKS usa um perfil vinculado ao serviço (SLR) para determinadas operações. A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome. A AWS cria e configura automaticamente o SLR. Você poderá excluir um SLR somente depois de primeiro excluir seus recursos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos. A política de SLR concede ao Amazon EKS permissões para observar e excluir os principais componentes da infraestrutura: recursos do EC2 (instâncias, interfaces de rede, grupos de segurança), recursos do ELB (balanceadores de carga, grupos de destino), recursos do CloudWatch (registro em log e métricas) e perfis do IAM com o prefixo "eks". Também habilita a rede de endpoints privados por meio da associação da VPC e zona hospedada e inclui permissões para o monitoramento do EventBridge e limpeza dos recursos marcados com o EKS. Para obter mais informações, consulte: + [Política gerenciada pela AWS: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) + [Permissões de função vinculada ao serviço para o Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) ## Tags da AWS personalizadas para recursos do Modo Automático do EKS. Por padrão, as políticas gerenciadas relacionadas ao Modo Automático do EKS não permitem a aplicação de tags definidas pelo usuário aos recursos da AWS provisionados pelo Modo Automático. Caso queira aplicar tags definidas pelo usuário aos recursos da AWS, você deverá anexar permissões adicionais ao perfil do IAM do cluster com permissões suficientes para criar e modificar tags nos recursos da AWS. Segue abaixo um exemplo de uma política que permitirá acesso irrestrito à marcação: ### Visualizar exemplo de política de tags personalizadas ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Compute", "Effect": "Allow", "Action": [ "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateLaunchTemplate" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-node-class-name": "*", "aws:RequestTag/eks:kubernetes-node-pool-name": "*" } } }, { "Sid": "Storage", "Effect": "Allow", "Action": [ "ec2:CreateVolume", "ec2:CreateSnapshot" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:snapshot/*" ], "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "Networking", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-cni-node-name": "*" } } }, { "Sid": "LoadBalancer", "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateRule", "ec2:CreateSecurityGroup" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldProtection", "Effect": "Allow", "Action": [ "shield:CreateProtection" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldTagResource", "Effect": "Allow", "Action": [ "shield:TagResource" ], "Resource": "arn:aws:shield::*:protection/*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } } ] } ``` ## Referência de política de acesso Para obter mais informações sobre as permissões do Kubernetes usadas pelo Modo Automático do EKS, consulte [Analisar permissões da política de acesso](access-policy-permissions.md). # Saiba mais sobre as redes de VPC e sobre o balanceamento de carga no modo automático do EKS Este tópico explica como configurar os recursos de balanceamento de carga e rede da Virtual Private Cloud (VPC) no Modo Automático do EKS. Embora o Modo Automático do EKS gerencie a maioria dos componentes de rede automaticamente, você ainda pode personalizar certos aspectos da configuração de rede do cluster por meio dos recursos do `NodeClass` e das anotações do balanceador de carga. Quando você usa o Modo Automático do EKS, a AWS gerencia a configuração da interface de rede de contêineres (CNI) da VPC e o provisionamento de balanceador de carga para o cluster. Você pode influenciar os comportamentos de rede definindo objetos `NodeClass` e aplicando anotações específicas aos seus recursos de Service e Ingress, mantendo o modelo operacional automatizado fornecido pelo Modo Automático do EKS. ## Funcionalidade de redes O modo automático do EKS oferece uma nova funcionalidade de redes para gerenciar a rede de nós e de pods. É possível configurá-la criando um objeto `NodeClass` no Kubernetes. As opções de configuração para o plug-in CNI da AWS VPC anterior não se aplicarão ao modo automático do EKS. ### Configurar a rede com um `NodeClass` O recurso `NodeClass` no Modo Automático do EKS possibilita a personalização de determinados aspectos dos recursos de redes. Por meio do `NodeClass`, você pode especificar seleções de grupos de segurança, controlar o posicionamento dos nós em sub-redes da VPC, definir políticas de SNAT, configurar políticas de rede e habilitar o registro em log de eventos de rede. Essa abordagem mantém o modelo operacional automatizado do Modo Automático do EKS e, ao mesmo tempo, fornece flexibilidade para a personalização da rede. Você pode usar um `NodeClass` para: + Selecionar um grupo de segurança para nós + Controlar como os nós são posicionados nas sub-redes da VPC + Definir a política de SNAT do nó como `random` ou `disabled` + Habilitar as *políticas de rede* do Kubernetes, incluindo: + Definir a política de rede como Negar por padrão ou Permitir por padrão + Habilite o registro em log de eventos de rede em um arquivo. + Isole o tráfego de pods do tráfego de nós anexando os pods a sub-redes diferentes. Saiba como [Criar um NodeClass do Amazon EKS](create-node-class.md). ### Considerações Modo Automático do EKS é compatível com: + Políticas de rede do EKS. + As opções `HostPort` e `HostNetwork` para pods do Kubernetes. + Pods e nós em sub-redes públicas ou privadas. + Armazenamento em cache de consultas ao DNS no nó. O Modo Automático do EKS **não** é compatível com: + Grupos de segurança por pod (SGPP). Para aplicar grupos de segurança distintos ao tráfego do Pod no Modo Automático, use `podSecurityGroupSelectorTerms` no `NodeClass` em vez disso. Para obter mais informações, consulte [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector). + Rede personalizada no `ENIConfig`. Você pode colocar pods em várias sub-redes ou isolá-los exclusivamente do tráfego de nós com [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector). + Configurações de IP warm, prefixo warm e ENI warm. + Configuração de destinos de IP mínimos. + Outras configurações compatíveis com a CNI de código aberto da AWS VPC. + Configurações de política de rede, como personalização do temporizador conntrack (o padrão é 300 s). + Exportação de logs de eventos de rede para o CloudWatch. ### Gerenciamento de recursos de rede O Modo Automático do EKS lida com o gerenciamento de prefixo, endereçamento IP e interface de rede monitorando os recursos do NodeClass para as configurações de rede. O serviço executa várias operações importantes automaticamente: **Delegação de prefixo** O modo automático do EKS utiliza por padrão a delegação de prefixos (prefixos /28) para a rede dos pods e mantém um grupo de recursos IP definido previamente que é escalado com base no número de pods agendados. Quando é detectada fragmentação da sub-rede do pod, o modo automático provisiona endereços IP secundários (prefixos /32). Devido a esse algoritmo de rede de pods padrão, o modo automático calcula o número máximo de pods por nó com base na quantidade de ENIs e de IPs com suporte por tipo de instância (considerando o pior cenário de fragmentação). Para obter mais informações sobre o número máximo de ENIs e de IPs com suporte por tipo de instância, consulte [Máximo de endereços IP por interface de rede](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) no Guia do usuário do EC2. As famílias de instâncias da geração mais recente (Nitro v6 e versões posteriores) geralmente têm um número maior de ENIs e de IPs com suporte por tipo de instância, e o modo automático ajusta o cálculo do número máximo de pods de acordo. Para clusters IPv6, apenas a delegação de prefixo é utilizada, e o modo automático sempre usa um limite máximo de 110 pods por nó. **Gerenciamento do período de espera** O serviço implementa um grupo de espera para prefixos ou endereços IPv4 secundários que não estão mais em uso. Depois que o período de espera expirar, esses recursos serão liberados de volta para a VPC. No entanto, se os pods reutilizarem esses recursos durante o período de espera, eles serão restaurados do grupo de espera. **Compatibilidade com IPv6** Para clusters IPv6, o Modo Automático do EKS provisiona um prefixo IPv6 `/80` por nó na interface de rede primária. Ao usar `podSubnetSelectorTerms`, o prefixo é alocado em uma interface de rede secundária na sub-rede do pod. O serviço também garante o gerenciamento adequado e a coleta de resíduos de todas as interfaces de rede. ## Balanceamento de carga Você configura os AWS Elastic Load Balancers provisionados pelo Modo Automático do EKS usando anotações nos recursos de Service e Ingress. Para ter mais informações, consulte [Criar uma IngressClass para configurar um Application Load Balancer](auto-configure-alb.md) ou [Usar anotações de serviço para configurar Network Load Balancers](auto-configure-nlb.md). ### Considerações sobre o balanceamento de carga com o Modo Automático do EKS + O modo de direcionamento padrão é o modo de IP, não o modo de instância. + O Modo Automático do EKS é compatível apenas com o modo de grupo de segurança para Network Load Balancers. + A AWS não é compatível com a migração de balanceadores de carga do controlador de balanceador de carga autogerenciado da AWS para o gerenciamento pelo Modo Automático do EKS. + O campo `networking.ingress.ipBlock` na especificação `TargetGroupBinding` não é compatível. + Se os nós de processamento usarem grupos de segurança personalizados (não o padrão de nomenclatura `eks-cluster-sg- `), o perfil do cluster precisará de permissões adicionais do IAM. A política padrão gerenciada pelo EKS só permite que o EKS modifique grupos de segurança denominados `eks-cluster-sg-`. Sem permissão para modificar os grupos de segurança personalizados, o EKS não pode adicionar as regras de entrada necessárias que permitem que o tráfego de ALB e NLB chegue aos pods. #### Considerações sobre o CoreDNS O modo automático do EKS não usa a implantação tradicional do CoreDNS para fornecer resolução de DNS dentro do cluster. Em vez disso, os nós do modo automático empregam o CoreDNS, que é executado como um serviço do sistema diretamente em cada nó. Ao migrar um cluster tradicional para o modo automático, você pode remover a implantação do CoreDNS do cluster assim que as workloads forem movidas para os nós do modo automático. **Importante** Se você planeja manter um cluster com nós no modo automático e nós que não estejam no modo automático, deve manter a implantação do CoreDNS. Os nós que não operam no modo automático dependem dos pods do CoreDNS tradicionais para a resolução de DNS, pois não têm acesso ao serviço de DNS em nível de nó fornecido pelo modo automático.