**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 mais sobre os modos e a configuração de CNI da VPC
O plug-in CNI da Amazon VPC para Kubernetes fornece redes para pods. Use a tabela a seguir para saber mais sobre os recursos de rede disponíveis.
| Recursos de redes | Saiba mais |
| --- | --- |
| Configurar o cluster para atribuir endereços IPv6 a clusters, pods e serviços | [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md) |
| Usar a conversão do endereço de rede de origem IPv4 para pods | [Habilitar o acesso de saída à internet para pods](external-snat.md) |
| Restringir o tráfego de rede de e para os pods | [Restringir o tráfego de rede de pods com políticas de rede do Kubernetes](cni-network-policy-configure.md) |
| Personalizar a interface de rede secundária em nós | [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md) |
| Aumentar os endereços IP do nó | [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md) |
| Usar grupos de segurança para o tráfego de rede de pods | [Atribuir grupos de segurança a pods individuais](security-groups-for-pods.md) |
| Usar várias interfaces de rede para pods | [Anexação de várias interfaces de rede aos pods](pod-multiple-network-interfaces.md) |
# Saiba mais sobre endereços IPv6 para clusters, pods e serviços
**Aplica-se a**: pods com instâncias do Amazon EC2 e pods do Fargate
Por padrão, o Kubernetes atribui endereços `IPv4` aos seus pods e serviços. Em vez de atribuir endereços `IPv4` aos seus pods e serviços, você pode configurar o cluster para atribuir endereços `IPv6` a eles. O Amazon EKS não é compatível com serviços ou pods de pilha dupla, embora o Kubernetes seja. Consequentemente, você não pode atribuir endereços `IPv4` e `IPv6` aos seus pods e serviços.
Você seleciona qual família de IPs deseja usar para o seu cluster ao criá-lo. Não será possível alterar a família depois de criar o cluster.
Para obter um tutorial sobre como implantar um cluster `IPv6` do Amazon EKS, consulte [Implantar um cluster `IPv6` do Amazon EKS e nós gerenciados do Amazon Linux](deploy-ipv6-cluster.md).
Confira as seguintes considerações sobre o uso do recurso:
## Suporte a recursos `IPv6`
+ **Sem compatibilidade com o Windows**: pods e serviços do Windows não são compatíveis.
+ **São necessários nós do EC2 baseados no Nitro**: você só pode usar `IPv6` com nós Amazon EC2 ou Fargate baseados no AWS Nitro.
+ **Suporte a nós do EC2 e Fargate**: você pode usar `IPv6` com [Atribuir grupos de segurança a pods individuais](security-groups-for-pods.md) com nós do Amazon EC2 e nós Fargate.
+ **Não há suporte para Outposts **: não é possível usar `IPv6` com o [Implantar o Amazon EKS on-premises com o AWS Outposts](eks-outposts.md).
+ **Não há suporte para o FSx para Lustre**: o [Usar armazenamento de aplicações de alta performance com o Amazon FSx para Lustre](fsx-csi.md) não é compatível.
+ **Não há suporte para redes personalizadas**: Se você usou anteriormente [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md) para ajudar a aliviar a exaustão de endereços IP, poderá usar `IPv6` em vez disso. Não é possível usar redes personalizadas com `IPv6`. Se você usar redes personalizadas para isolar redes, talvez seja necessário continuar usando redes personalizadas e a família `IPv4` para os seus clusters.
## Atribuições de endereços IP
+ **Serviços Kubernetes**: serviços do Kubernetes recebem apenas um endereço `IPv6`. Eles não recebem endereços IPv4.
+ **Pods**: Os pods recebem um endereço IPv6 e um endereço IPv4 local do host. O endereço IPv4 local do host é atribuído usando um plug-in CNI local do host encadeado com o VPC CNI, e o endereço não é informado ao ambiente de gerenciamento do Kubernetes. Ele só é usado quando um pod precisa se comunicar com recursos IPv4 externos em outra Amazon VPC ou na internet. O endereço IPv4 local do host é SNATed (pelo VPC CNI) para o endereço IPv4 primário da ENI primária do nó de processamento.
+ **Pods e serviços**: pods e serviços recebem somente endereços `IPv6`, não endereços `IPv4`. Quando os pods precisam se comunicar com endpoints `IPv4` externos, eles usam NAT no próprio nó. Esse recurso NAT integrado elimina a necessidade de [DNS64 e NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64). Para tráfego que requer acesso público à internet, o tráfego do pod é um endereço de rede de origem convertido em um endereço IP público.
+ **Endereços de roteamento**: quando um pod se comunica fora da VPC, seu endereço `IPv6` original é preservado (não convertido para o endereço `IPv6` do nó). Esse tráfego é roteado diretamente por meio de um gateway da internet ou de um gateway da internet somente de saída.
+ **Nós**: Todos os nós recebem um endereço `IPv4` e `IPv6`.
+ **Pods do Fargate**: cada pod do Fargate recebe um endereço `IPv6` do CIDR especificado para a sub-rede em que está implantado. A unidade de hardware subjacente que executa pods do Fargate obtém um endereço `IPv4` e `IPv6` exclusivo dos CIDRs atribuídos à sub-rede em que a unidade de hardware está implantada.
## Como usar o `IPv6` com o EKS
+ **Criar novo cluster**: Você deve criar um novo cluster e especificar que deseja usar a família `IPv6` para esse cluster. Você não pode habilitar a família do `IPv6` para um cluster atualizado de uma versão anterior. Para obter instruções sobre como criar um novo cluster, consulte Considerações .
+ **Use o VPC CNI recente**: implante a versão do Amazon VPC CNI `1.10.1` ou posterior. Essa versão ou uma posterior é implantada por padrão. Depois de implantar o complemento, você não poderá fazer downgrade do seu complemento CNI da Amazon VPC para uma versão inferior a `1.10.1` sem remover primeiro todos os nós em todos os grupos de nós do seu cluster.
+ **Configure o VPC CNI para `IPv6` **: Se você usar nós do Amazon EC2, deverá configurar o complemento Amazon VPC CNI com delegação de prefixo IP e `IPv6`. Se você escolher a família `IPv6` ao criar o seu cluster, a versão `1.10.1` do complemento elegerá tal configuração como padrão. Esse é o caso de complementos autogerenciados ou do Amazon EKS. Para obter mais informações sobre a delegação de prefixos IP, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md).
+ **Configure os endereços `IPv4` e `IPv6`:** Quando você cria um cluster, a VPC e as sub-redes que você especificar devem ter um bloco CIDR `IPv6` atribuído à VPC e às sub-redes que você especificar. Elas também precisam ter um bloco CIDR `IPv4` atribuído a elas. Isso ocorre porque, ainda que você só queira usar o `IPv6`, uma VPC ainda precisa de um bloco CIDR `IPv4` para funcionar. Para obter mais informações, consulte [Associar um bloco CIDR IPv6 à sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) no Guia do usuário da Amazon VPC.
+ **Atribuição automática de endereços IPv6 aos nós:** Ao criar seus nós, você deve especificar sub-redes que estejam configuradas para atribuir automaticamente endereços `IPv6`. Caso contrário, você não poderá implantar seus nós. Por padrão, essa configuração fica desativada. Para obter mais informações, consulte [Modificar o atributo de endereçamento IPv6 para a sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) no Guia do usuário da Amazon VPC.
+ **Defina tabelas de rotas para usar `IPv6` **: As tabelas de rotas atribuídas às suas sub-redes devem ter rotas para endereços `IPv6`. Para obter mais informações, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no Guia do usuário da Amazon VPC.
+ **Defina grupos de segurança para o `IPv6` **: seus grupos de segurança devem permitir endereços `IPv6`. Para obter mais informações, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no Guia do usuário da Amazon VPC.
+ **Configurar o balanceador de carga**: use a versão `2.3.1` ou mais recente do AWS Load Balancer Controller para balancear a carga de aplicações HTTP usando [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md) ou o tráfego de rede usando [Roteamento de tráfego TCP e UDP com Network Load Balancers](network-load-balancing.md) para pods `IPv6` com qualquer um dos balanceadores de carga no modo IP, mas não no modo de instância. Para obter mais informações, consulte [Direcionar o tráfego da Internet com o AWS Load Balancer Controller](aws-load-balancer-controller.md).
+ **Adicione a política do IAM `IPv6`:** Você deve anexar uma política do IAM do `IPv6` à perfil do IAM do nó ou de IAM da CNI. Entre os dois, recomendamos que você a anexe a uma função do IAM do CNI. Para obter mais informações, consulte [Criar uma política do IAM para clusters que usam a família `IPv6`](cni-iam-role.md#cni-iam-role-create-ipv6-policy) e [Etapa 1: criar o perfil do IAM do plug-in CNI da Amazon VPC para Kubernetes](cni-iam-role.md#cni-iam-role-create-role).
+ **Avalie todos os componentes**: Faça uma avaliação completa de suas aplicações, dos complementos do Amazon EKS e dos serviços AWS com os quais você se integra antes de implantar os clusters `IPv6`. Isso ocorre para garantir que tudo funcione conforme o esperado com o `IPv6`.
# Implantar um cluster `IPv6` do Amazon EKS e nós gerenciados do Amazon Linux
Neste tutorial, você implanta uma Amazon VPC `IPv6`, um cluster do Amazon EKS com a família `IPv6` e um grupo de nós gerenciados com nós do Amazon Linux do Amazon EC2. Não é possível implantar nós do Windows para Amazon EC2 em um cluster do `IPv6`. Você também pode implantar nós do Fargate em seu cluster. Para simplificar, tais instruções não são fornecidas neste tópico.
## Pré-requisitos
Antes de começar o tutorial, conclua as seguintes etapas:
Instale e configure as ferramentas e recursos a seguir, necessários para criar e gerenciar um cluster do Amazon EKS.
+ Recomendamos que você se familiarize com todas as configurações e implante um cluster com aquelas que atendam aos seus requisitos. Para obter mais informações, consulte [Criar um cluster do Amazon EKS](create-cluster.md), [Simplificar o ciclo de vida dos nós com grupos de nós gerenciados](managed-node-groups.md) e as [Considerações](cni-ipv6.md) sobre este tópico. Só é possível habilitar algumas configurações durante a criação do seu cluster.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ A entidade principal de segurança do IAM que você está usando deve ter permissões para trabalhar com perfis do IAM do Amazon EKS, perfis vinculadas a serviços, AWS CloudFormation, um VPC e recursos relacionados. Para obter mais informações, consulte [Ações](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) e [uso de perfis vinculadas a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) no Guia do Usuário do IAM.
+ Caso use o eksctl, instale a versão `0.215.0` ou mais recente no seu computador. Para instalá-la ou atualizá-la, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*. Se você usar o AWS CloudShell, talvez seja necessário [instalar a versão 2.12.3 ou superior ou a versão 1.27.160 ou superior da AWS CLI](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), pois a versão padrão da CLI do AWS instalada no AWS CloudShell pode ser uma versão anterior.
Você pode usar o eksctl ou a CLI para implantar um cluster do `IPv6`.
## Implantar um cluster do IPv6 com o eksctl
1. Crie o arquivo `ipv6-cluster.yaml`. Copie o conteúdo a seguir no seu dispositivo. Faça as seguintes modificações no comando, conforme necessário, e execute o comando modificado:
+ Substitua *my-cluster* por um nome para seu cluster. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster.
+ Substitua *region-code* por qualquer região AWS com suporte ao Amazon EKS. Para obter uma lista das regiões da AWS, consulte [Endpoints e cotas de serviço do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) no guia Referência geral da AWS.
+ O valor para `version` com a versão do seu cluster. Para obter mais informações, consulte [versões compatíveis do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Substitua *my-nodegroup* por um nome para o seu grupo de nós. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres.
+ Substitua *t3.medium* por qualquer [tipo de instância do AWS Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
cat >ipv6-cluster.yaml <
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Confirme se os serviços padrão são atribuídos a endereços `IPv6`.
```
kubectl get services -n kube-system -o wide
```
Veja abaixo um exemplo de saída.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Opcional) [Implante uma aplicação de amostra](sample-deployment.md) ou implante [AWS Load Balancer Controller](aws-load-balancer-controller.md) e uma aplicação de amostra para realizar o balanceamento de carga de aplicações HTTP com [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md) ou de tráfego de rede com [Roteamento de tráfego TCP e UDP com Network Load Balancers](network-load-balancing.md) para pods `IPv6`.
1. Após a conclusão de criação do cluster e nós para este tutorial, você deverá limpar os recursos que criou com o comando a seguir.
```
eksctl delete cluster my-cluster
```
## Implante um cluster IPv6 com AWS CLI
**Importante**
Você deve concluir todas as etapas deste procedimento como o mesmo usuário. Execute o seguinte comando para verificar o usuário atual:
```
aws sts get-caller-identity
```
Você deve concluir todas as etapas deste procedimento no mesmo shell. Várias etapas usam variáveis definidas em etapas anteriores. As etapas que usam variáveis não funcionarão corretamente se os valores das variáveis forem definidos em um shell diferente. Se você usar o [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) para concluir o procedimento a seguir, lembre-se de que, se não interagir com ele usando o teclado ou o ponteiro por aproximadamente 20 a 30 minutos, a sessão do shell será encerrada. Os processos em execução não contam como interações.
As instruções são redigidas para o shell bash e podem precisar de ajustes em outros shells.
Substitua todos os valores de exemplo nas etapas deste procedimento pelos seus próprios valores.
1. Execute os comandos a seguir para definir algumas variáveis usadas em etapas posteriores. Substitua *region-code* pela região da AWS na qual você deseja implementar seus recursos. O valor pode ser qualquer região da AWS compatível com o Amazon EKS. Para obter uma lista das regiões da AWS, consulte [Endpoints e cotas de serviço do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) no guia Referência geral da AWS. Substitua *my-cluster* por um nome para seu cluster. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster. Substitua *my-nodegroup* por um nome para o seu grupo de nós. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres. Substitua *111122223333* pelo ID da sua conta.
```
export region_code=region-code
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
```
1. Crie uma Amazon VPC com sub-redes públicas e privadas que atenda aos requisitos do Amazon EKS e `IPv6`.
1. Execute o seguinte comando para definir uma variável para o nome da pilha do AWS CloudFormation. É possível substituir *my-eks-ipv6-vpc* por qualquer nome de sua preferência.
```
export vpc_stack_name=my-eks-ipv6-vpc
```
1. Crie um VPC `IPv6` usando um modelo AWS CloudFormation.
```
aws cloudformation create-stack --region $region_code --stack-name $vpc_stack_name \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
A pilha leva alguns minutos para ser criada. Execute o comando a seguir. Não prossiga para a próxima etapa até que a saída do comando seja `CREATE_COMPLETE`.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name --query Stacks[].StackStatus --output text
```
1. Recupere os IDs das sub-redes públicas que foram criadas.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text
```
Veja um exemplo de saída abaixo.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE
```
1. Habilite a opção de atribuição automática de endereços `IPv6` para as sub-redes públicas que foram criadas.
```
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-0a1a56c486EXAMPLE --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-099e6ca77aEXAMPLE --assign-ipv6-address-on-creation
```
1. Recupere os nomes das sub-redes e grupos de segurança criados pelo modelo na pilha implantada do AWS CloudFormation e armazene-os em variáveis para usar em uma etapa posterior.
```
security_groups=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SecurityGroups`].OutputValue' --output text)
public_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text)
private_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPrivate`].OutputValue' --output text)
subnets=${public_subnets},${private_subnets}
```
1. Crie um perfil do IAM de cluster e associe a política gerenciada do Amazon EKS IAM a ele. Os clusters do Kubernetes gerenciados pelo Amazon EKS fazem chamadas a outros serviços da AWS em seu nome para gerenciar os recursos que você usa com o serviço.
1. Execute o seguinte comando para criar o arquivo `eks-cluster-role-trust-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Execute o seguinte comando para definir uma variável para o nome da sua função. É possível substituir *myAmazonEKSClusterRole* por qualquer nome de sua preferência.
```
export cluster_role_name=myAmazonEKSClusterRole
```
1. Crie a função.
```
aws iam create-role --role-name $cluster_role_name --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Recupere o ARN da função do IAM e o armazene em uma variável para uma etapa posterior.
```
CLUSTER_IAM_ROLE=$(aws iam get-role --role-name $cluster_role_name --query="Role.Arn" --output text)
```
1. Anexe a política do IAM gerenciada pelo Amazon EKS ao perfil.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name $cluster_role_name
```
1. Crie o seu cluster.
```
aws eks create-cluster --region $region_code --name $cluster_name --kubernetes-version 1.XX \
--role-arn $CLUSTER_IAM_ROLE --resources-vpc-config subnetIds=$subnets,securityGroupIds=$security_groups \
--kubernetes-network-config ipFamily=ipv6
```
1. OBSERVAÇÃO: talvez você receba um erro porque uma das zonas de disponibilidade em sua solicitação não tem capacidade suficiente para criar um cluster do Amazon EKS. Se isso acontecer, o resultado do erro conterá as zonas de disponibilidade que são compatíveis com o novo cluster. Tente criar o cluster com pelo menos duas sub-redes que estejam localizadas nas zonas de disponibilidade compatíveis de sua conta. Para obter mais informações, consulte [Capacidade insuficiente](troubleshooting.md#ice).
A criação do cluster domora alguns minutos. Execute o comando a seguir. Não prossiga para a próxima etapa até que a saída do comando esteja `ACTIVE`.
```
aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status
```
1. Crie ou atualize um arquivo `kubeconfig` para o seu cluster para que você possa se comunicar com ele.
```
aws eks update-kubeconfig --region $region_code --name $cluster_name
```
Por padrão, um arquivo `~/.kube` é criado em `config` ou o novo cluster é adicionado a um arquivo `config` existente no `~/.kube`.
1. Crie um perfil do IAM para o nó.
1. Execute o seguinte comando para criar o arquivo `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Crie a política do IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Execute o seguinte comando para criar o arquivo `node-role-trust-relationship.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Execute o seguinte comando para definir uma variável para o nome da sua função. É possível substituir *AmazonEKSNodeRole* por qualquer nome de sua preferência.
```
export node_role_name=AmazonEKSNodeRole
```
1. Crie o perfil do IAM.
```
aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Anexe a política do IAM à função do IAM.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name $node_role_name
```
**Importante**
Para simplificar este tutorial, a política é anexada a esta função do IAM. No entanto, em um cluster do produção, recomendamos que você anexe a política a uma função do IAM separada. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md).
1. Anexe duas políticas do IAM gerenciadas necessárias à função do IAM.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name $node_role_name
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name $node_role_name
```
1. Recupere o ARN da função do IAM e o armazene em uma variável para uma etapa posterior.
```
node_iam_role=$(aws iam get-role --role-name $node_role_name --query="Role.Arn" --output text)
```
1. Crie um grupo de nós gerenciado.
1. Exiba os IDs das sub-redes que você criou em uma etapa anterior.
```
echo $subnets
```
Veja um exemplo de saída abaixo.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE,subnet-0377963d69EXAMPLE,subnet-0c05f819d5EXAMPLE
```
1. Crie o grupo de nós. Substitua *0a1a56c486EXAMPLE*, *099e6ca77aEXAMPLE*, *0377963d69EXAMPLE* e *0c05f819d5EXAMPLE* pelos valores retornados na saída da etapa anterior. Certifique-se de remover as vírgulas entre IDs de sub-redes da saída anterior no comando a seguir. Você pode substituir *t3.medium* por qualquer [tipo de instância do AWS Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--subnets subnet-0a1a56c486EXAMPLE subnet-099e6ca77aEXAMPLE subnet-0377963d69EXAMPLE subnet-0c05f819d5EXAMPLE \
--instance-types t3.medium --node-role $node_iam_role
```
A criação do grupo de nós demora alguns minutos. Execute o comando a seguir. Não prossiga para a próxima etapa até que a saída recebida esteja `ACTIVE`.
```
aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--query nodegroup.status --output text
```
1. Verifique se os pods padrão estão atribuídos a endereços `IPv6` na coluna `IP`.
```
kubectl get pods -n kube-system -o wide
```
Veja abaixo um exemplo de saída.
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-rslts 1/1 Running 1 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Confirme se os serviços padrão são atribuídos a endereços `IPv6` na coluna `IP`.
```
kubectl get services -n kube-system -o wide
```
Veja abaixo um exemplo de saída.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Opcional) [Implante uma aplicação de amostra](sample-deployment.md) ou implante [AWS Load Balancer Controller](aws-load-balancer-controller.md) e uma aplicação de amostra para realizar o balanceamento de carga de aplicações HTTP com [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md) ou de tráfego de rede com [Roteamento de tráfego TCP e UDP com Network Load Balancers](network-load-balancing.md) para pods `IPv6`.
1. Após a conclusão de criação do cluster e nós para este tutorial, você deverá limpar os recursos que criou com os comandos a seguir. Certifique-se de que você não esteja usando nenhum dos recursos fora deste tutorial antes de excluí-los.
1. Se você estiver concluindo esta etapa em um shell diferente daquele em que concluiu as etapas anteriores, defina os valores de todas as variáveis usadas nas etapas anteriores, substituindo os valores de exemplo pelos valores especificados ao concluir as etapas anteriores. Se você estiver concluindo esta etapa no mesmo shell em que concluiu as etapas anteriores, pule para a próxima etapa.
```
export region_code=region-code
export vpc_stack_name=my-eks-ipv6-vpc
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
export node_role_name=AmazonEKSNodeRole
export cluster_role_name=myAmazonEKSClusterRole
```
1. Exclua o seu grupo de nós.
```
aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name
```
A exclusão demora alguns minutos. Execute o comando a seguir. Não prossiga para a próxima etapa se receber alguma saída.
```
aws eks list-nodegroups --region $region_code --cluster-name $cluster_name --query nodegroups --output text
```
1. Excluir o cluster.
```
aws eks delete-cluster --region $region_code --name $cluster_name
```
Demora alguns minutos até que o cluster seja excluído. Antes de continuar, verifique se o cluster foi excluído com o seguinte comando.
```
aws eks describe-cluster --region $region_code --name $cluster_name
```
Não prossiga para a próxima etapa até que a saída seja semelhante à seguinte saída.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
```
1. Exclua os recursos do IAM que você criou. Substitua *AmazonEKS\$1CNI\$1IPv6\$1Policy* pelo nome que você escolheu, se o mesmo for diferente do que foi usado nas etapas anteriores.
```
aws iam detach-role-policy --role-name $cluster_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-policy --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-role --role-name $cluster_role_name
aws iam delete-role --role-name $node_role_name
```
1. Exclua a pilha do AWS CloudFormation que criou a VPC.
```
aws cloudformation delete-stack --region $region_code --stack-name $vpc_stack_name
```
# Habilitar o acesso de saída à internet para pods
**Aplica-se a**: nós Linux `IPv4` do Fargate, nós Linux com instâncias do Amazon EC2
Se você implantou seu cluster utilizando a família `IPv6`, as informações neste tópico não serão aplicáveis a ele, pois endereços `IPv6` não são convertidos na rede. Para obter mais informações sobre como usar o `IPv6` com o seu cluster, consulte [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md).
Por padrão, cada pod no cluster recebe um endereço `IPv4` [privado](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) de um bloco de Encaminhamento Entre Domínios Sem Classificação (CIDR) associado à VPC em que o pod está implantado. Os pods na mesma VPC se comunicam entre si usando esses endereços IP privados como endpoints. Quando um pod se comunica com qualquer endereço `IPv4` que não esteja em um bloco CIDR associado à VPC, o plug-in CNI da Amazon VPC (para [Linux](https://github.com/aws/amazon-vpc-cni-k8s#amazon-vpc-cni-k8s) ou [Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge)) converte o endereço `IPv4` do pod para o endereço privado primário `IPv4` da [interface de rede elástica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics) primária do nó em que o pod está sendo executado, por padrão, [\$1](#snat-exception).
**nota**
Para nós do Windows, existem detalhes adicionais a serem considerados. Por padrão, o [plug-in VPC CNI para Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge) é definido com uma configuração de rede na qual o tráfego para um destino dentro da mesma VPC é excluído para SNAT. Isso significa que a comunicação interna da VPC tem a SNAT desabilitada e que o endereço IP alocado a um pod é roteável dentro da VPC. Porém, o tráfego para um destino fora da VPC tem a SNAT do IP de origem do pod conectado ao endereço IP primário da ENI da instância. Essa configuração padrão para o Windows garante que o pod possa acessar redes fora da sua VPC da mesma forma que a instância do host.
Devido a este comportamento:
+ Os pods poderão se comunicar com os recursos da internet somente se o nó em que estão sendo executados tiver um endereço IP [público](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) ou [elástico](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) atribuído a ele e se estiver em uma [sub-rede pública](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics). A [tabela de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) associada a uma sub-rede pública tem uma rota para um gateway da Internet. Convém implantar nós em sub-redes privadas, sempre que possível.
+ Para versões do plug-in anteriores a `1.8.0`, os recursos que estão em redes ou VPCs conectados à VPC do cluster usando o [emparelhamento da VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), uma [VPC de trânsito](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) ou o [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) não podem iniciar a comunicação com os pods por meio de interfaces de rede elásticas secundárias. No entanto, os pods poderão iniciar a comunicação com esses recursos e receber respostas deles.
Se qualquer uma das declarações a seguir for verdadeira em seu ambiente, altere a configuração padrão com o comando a seguir.
+ Você tem recursos em redes ou VPCs que estão conectados à VPC do seu cluster usando [emparelhamento da VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), uma [VPC de trânsito](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) ou o [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) que precisam iniciar a comunicação com os pods usando um endereço `IPv4` e sua versão de plug-in anterior à `1.8.0`.
+ Os pods estão em uma [sub-rede privada](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics) e precisam se comunicar com a saída da internet. A sub-rede tem uma rota para um [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
```
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
```
**nota**
As variáveis de configuração `AWS_VPC_K8S_CNI_EXTERNALSNAT` e `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` da CNI não são aplicáveis a nós do Windows. A desabilitação da SNAT não tem suporte no Windows. Quanto à exclusão de uma lista de CIDRs `IPv4` da SNAT, você pode definir isso especificando o parâmetro `ExcludedSnatCIDRs` no script de bootstrap do Windows. Para obter mais informações sobre o uso desse parâmetro, consulte [Parâmetros de configuração do script de bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Redes do host
\$1 Se uma especificação de pod contiver `hostNetwork=true` (o padrão é `false`), seu endereço IP não será convertido para um endereço diferente. Este é o caso para o `kube-proxy` e o plug-in CNI da Amazon VPC dos pods do Kubernetes que são executados no cluster por padrão. Para esses pods, o endereço IP é o mesmo que o endereço IP primário do nó e, portanto, o endereço IP do pod não é convertido. Para saber mais sobre a configuração `hostNetwork` de um pod, consulte [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) na referência de APIs do Kubernetes.
# Limitar o tráfego do pod com políticas de rede do Kubernetes
## Visão geral
Por padrão, não há restrições no Kubernetes para endereços IP, portas ou conexões entre os pods do cluster ou entre os pods e os recursos de qualquer outra rede. Você pode usar uma *política de rede* do Kubernetes para restringir o tráfego de rede que entra e sai dos pods. Para obter mais informações, consulte [Políticas de rede](https://kubernetes.io/docs/concepts/services-networking/network-policies/) na documentação do Kubernetes.
## Política de rede padrão
Você pode usar a política `NetworkPolicy` padrão para segmentar o tráfego entre pods no cluster. Essas políticas de rede operam nas camadas 3 e 4 do modelo de rede OSI, permitindo controlar o fluxo de tráfego no nível de endereço IP ou de porta dentro do cluster do Amazon EKS. As políticas de rede padrão têm escopo definido no nível do namespace.
### Casos de uso
+ Realize a segmentação do tráfego de rede entre as workloads para assegurar que a comunicação ocorra apenas entre aplicações relacionadas.
+ Realize o isolamento dos locatários por namespace, usando políticas para garantir a separação de rede.
### Exemplo
Na política abaixo, o tráfego de saída proveniente dos pods *webapp* no namespace *sun* é restrito.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-egress-policy
namespace: sun
spec:
podSelector:
matchLabels:
role: webapp
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: moon
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
name: stars
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
```
A política é aplicada aos pods com o rótulo `role: webapp` no namespace `sun`.
+ Tráfego permitido: pods com o rótulo `role: frontend` no namespace `moon` na porta TCP `8080`
+ Tráfego permitido: pods com o rótulo “role: frontend” no namespace `stars` na porta TCP `8080`
+ Tráfego bloqueado: todo o restante do tráfego de saída proveniente dos pods `webapp` é negado implicitamente
## Política de rede do administrador (ou do cluster)
![\[Ilustração da ordem de avaliação das políticas de rede no EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/evaluation-order.png)
É possível usar a política `ClusterNetworkPolicy` para impor um padrão de segurança de rede válido para todo o cluster. Em vez de criar e gerenciar uma política diferente para cada namespace de forma repetitiva, é possível usar uma política única para o controle centralizado do acesso à rede de diversas workloads no cluster, independentemente do namespace em que estejam.
### Casos de uso
+ Gerencie de forma centralizada o acesso à rede de todas as workloads (ou de um grupo específico delas) no seu cluster do EKS.
+ Defina uma postura de segurança de rede padrão em todo o cluster.
+ Amplie os padrões de segurança organizacionais ao escopo do cluster com maior eficiência operacional.
### Exemplo
Na política abaixo, é possível bloquear explicitamente o tráfego do cluster proveniente de outros namespaces para impedir o acesso de rede a um namespace da workload sensível.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Observações importantes
As políticas de rede no plug-in CNI da Amazon VPC para Kubernetes são compatíveis com as configurações listadas abaixo.
+ Versão 1.21.0 (ou versões posteriores) do plug-in CNI da Amazon VPC para políticas de rede padrão e de administração.
+ Cluster configurado para endereços `IPv4` ou `IPv6`.
+ Você pode usar políticas de rede com [grupos de segurança para Pods](security-groups-for-pods.md). Com as políticas de rede, você pode controlar toda a comunicação dentro do cluster. Com os grupos de segurança para pods, você pode controlar o acesso aos serviços da AWS de aplicações em um pod.
+ Você pode usar políticas de rede com *rede personalizada* e *delegação de prefixo*.
## Considerações
**Arquitetura do**
+ Ao aplicar as políticas de rede do plug-in CNI da Amazon VPC para Kubernetes ao cluster com o plug-in CNI da Amazon VPC para Kubernetes, você só poderá aplicar as políticas aos nós do Linux do Amazon EC2. Você não pode aplicar as políticas aos nós do Fargate ou do Windows.
+ As políticas de rede se aplicam somente a endereços `IPv4` ou `IPv6`, mas não a ambos. Em um cluster `IPv4`, a VPC CNI atribui endereços `IPv4` aos pods e aplica políticas de `IPv4`. Em um cluster `IPv6`, a VPC CNI atribui endereços `IPv6` aos pods e aplica políticas de `IPv6`. Todas as regras de política de rede `IPv4` aplicadas a um cluster `IPv6` são ignoradas. Todas as regras de política de rede `IPv6` aplicadas a um cluster `IPv4` são ignoradas.
**Políticas de rede**
+ As políticas de rede são aplicadas somente a pods que fazem parte de uma implantação. Os pods autônomos que não têm um conjunto `metadata.ownerReferences` não podem ter políticas de rede aplicadas a eles.
+ Você pode aplicar várias políticas de rede ao mesmo pod. Quando duas ou mais políticas que selecionam o mesmo pod estão configuradas, todas as políticas são aplicadas ao pod.
+ O número máximo de combinações de portas e protocolos para um único intervalo de endereços IP (CIDR) é 24 em todas as suas políticas de rede. Seletores como `namespaceSelector` resolvem para um ou mais CIDRs. Se vários seletores forem resolvidos para um único CIDR ou você especificar o mesmo CIDR direto várias vezes na mesma política de rede ou em políticas de rede diferentes, todos eles contarão para esse limite.
+ Para qualquer serviço do Kubernetes, a porta de serviço deve ser a mesma que porta de contêiner. Se você estiver usando portas nomeadas, use o mesmo nome na especificação do serviço.
**Políticas de rede de administração**
1. **Políticas do nível de Administrador (avaliadas primeiro)**: todas as ClusterNetworkPolicies do nível de Administrador são avaliadas antes de quaisquer outras políticas. No nível de Administrador, o processamento das políticas segue a ordem de prioridade (o menor número de prioridade tem precedência). O tipo de ação determina o que acontece em seguida no processamento.
+ **Ação de negação (maior precedência)**: quando uma política de Administrador com uma ação de negação corresponde ao tráfego, esse tráfego é bloqueado imediatamente, independentemente de quaisquer outras políticas. O processamento de quaisquer outras regras de ClusterNetworkPolicy ou NetworkPolicy é interrompido. Isso garante que os controles de segurança de nível organizacional não possam ser substituídos por políticas de nível de namespace.
+ **Ação de permissão**: uma vez avaliadas as regras de negação, as políticas de Administrador com a ação de permissão entram em processamento seguindo a ordem de prioridade (o menor número de prioridade tem precedência). Se o tráfego coincidir com uma regra de permissão, ele é liberado imediatamente e o processo de avaliação de políticas é encerrado. Essas políticas podem conceder acesso entre diversos namespaces com base em seletores de rótulos, oferecendo controle centralizado sobre quais workloads podem acessar recursos específicos.
+ **Ação de aprovação**: as ações de aprovação nas políticas do nível de Administrador delegam a tomada de decisão para os níveis inferiores. Quando o tráfego corresponde a uma regra de aprovação, a avaliação ignora todas as regras restantes do nível de Administrador para esse tráfego e prossegue diretamente para o nível de NetworkPolicy. Dessa forma, os administradores conseguem transferir formalmente o controle de padrões específicos de tráfego para as equipes responsáveis pelas aplicações. Por exemplo, é possível usar regras de aprovação para delegar o gerenciamento do tráfego interno do namespace aos administradores do namespace, enquanto mantém controles rígidos sobre o acesso externo.
1. **Nível de política de rede**: se nenhuma política do nível de Administrador corresponder às ações de negação ou de aprovação, ou se uma ação de aprovação for acionada, os recursos de NetworkPolicy com escopo de namespace são avaliados em seguida. Essas políticas oferecem controle granular nos namespaces individuais e são gerenciadas pelas equipes responsáveis pela aplicação. As políticas com escopo de namespace conseguem apenas aumentar a restrição imposta pelas políticas de Administrador. Eles não podem substituir a decisão de negação de uma política de Administrador, mas podem restringir ainda mais o tráfego que foi permitido ou aprovado pelas políticas de Administrador.
1. **Políticas de Administrador do nível de Linha de Base**: se nenhuma política do nível de Administrador ou de escopo de namespace corresponder ao tráfego, as ClusterNetworkPolicies do nível de Linha de Base são avaliadas. Estas políticas fornecem posturas de segurança padrão que podem ser substituídas por políticas com escopo de namespace, permitindo que os administradores definam padrões para toda a organização, enquanto oferecem flexibilidade às equipes para realizar personalizações conforme necessário. A avaliação das políticas de Linha de Base respeita a ordem de prioridade, na qual o menor número de prioridade tem precedência.
1. **Negação padrão (se nenhuma política corresponder)**: este comportamento de negação por padrão garante que apenas conexões explicitamente permitidas sejam autorizadas, mantendo uma postura de segurança robusta.
**Migração**
+ Se o cluster estiver usando atualmente uma solução de terceiros para gerenciar as políticas de rede do Kubernetes, você poderá usar essas mesmas políticas com o plug-in CNI da Amazon VPC para Kubernetes. Porém, você deve remover a solução existente para que ela não gerencie as mesmas políticas.
**Atenção**
Recomendamos que, depois de remover uma solução de política de rede, você substitua todos os nós que tiveram a solução de política de rede aplicada a eles. Isso ocorre porque as regras de tráfego podem ser deixadas para trás por um pod da solução se ele sair repentinamente.
**Instalação**
+ O atributo de política de rede cria e exige uma definição de atributos personalizados (CRD) de `PolicyEndpoint` denominada `policyendpoints.networking.k8s.aws`. Os objetos de `PolicyEndpoint` do atributo personalizado são gerenciados pelo Amazon EKS. Você não deve modificar nem excluir esses recursos.
+ Se você executar pods que usem as credenciais do IAM do perfil da instância ou se conectar ao IMDS do EC2, tenha o cuidado de verificar as políticas de rede que bloqueariam o acesso ao IMDS do EC2. Pode ser necessário adicionar uma política de rede para permitir o acesso ao IMDS do EC2. Para obter mais informações, consulte [Metadados da instância e dados do usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) no Manual do usuário do Amazon EC2.
Pods que usam *perfis do IAM para contas de serviço* ou *identidade de Pods do EKS* não acessam o IDMS do EC2.
+ O plug-in CNI da Amazon VPC para Kubernetes não aplica políticas de rede a interfaces de rede adicionais para cada pod, somente à interface primária para cada pod (`eth0`). Isso afeta as seguintes arquiteturas:
+ Pods `IPv6` com a variável `ENABLE_V4_EGRESS` definida como `true`. Essa variável permite que o recurso de saída `IPv4` conecte os pods IPv6 a endpoints `IPv4`, como aqueles fora do cluster. O funcionamento do recurso de saída `IPv4` se dá com a criação de uma interface de rede adicional com um endereço IPv4 de loopback local.
+ Ao usar plug-ins de rede encadeados, como o Multus. Como esses plug-ins adicionam interfaces de rede a cada pod, as políticas de rede não são aplicadas aos plug-ins de rede encadeados.
# Restringir o tráfego de rede de pods com políticas de rede do Kubernetes
Você pode usar uma política de rede do Kubernetes para restringir o tráfego de rede que entra e sai dos pods. Para obter mais informações, consulte [Políticas de rede](https://kubernetes.io/docs/concepts/services-networking/network-policies/) na documentação do Kubernetes.
É necessário fazer as seguintes configurações para usar esse atributo:
1. Configure aplicação de políticas na inicialização do pod. Você faz isso no contêiner `aws-node` do `DaemonSet` CNI da VPC.
1. Habilitar o parâmetro da política de redes para o complemento.
1. Configurar o cluster para usar as políticas de rede do Kubernetes
Antes de começar, reveja as considerações. Para obter mais informações, consulte [Considerações](cni-network-policy.md#cni-network-policy-considerations).
## Pré-requisitos
A seguir estão os pré-requisitos do recurso:
### Versão mínima do cluster
Um cluster existente do Amazon EKS. Para implantar, consulte [Começar a usar o Amazon EKS](getting-started.md). O cluster dove estar executando uma das versões do Kubernetes e versões da plataforma listadas na tabela a seguir. Observe que qualquer versão da plataforma e do Kubernetes posterior às versões listadas também é compatível. Para verificar a versão atual do Kubernetes, substitua *my-cluster* no comando a seguir pelo nome do seu cluster e execute o comando modificado:
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Versão do Kubernetes | Versão da plataforma |
| --- | --- |
| `1.27.4` | `eks.5` |
| `1.26.7` | `eks.6` |
### Versão mínima do VPC CNI
Para criar tanto políticas de rede padrão do Kubernetes quanto políticas de rede de administrador, é necessário executar a versão `1.21` do plug-in CNI da VPC. É possível verificar qual é a sua versão atual com o comando a seguir.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Se a versão for anterior à `1.21`, consulte [Atualização do plug-in da CNI da Amazon VPC (complemento do Amazon EKS)](vpc-add-on-update.md) para atualizar para a versão `1.21` ou superior.
### Versão mínima do kernel do Linux
Os nós devem ter a versão `5.10` ou superior do kernel do Linux. Você pode verificar qual é a sua versão atual com `uname -r`. Se você usa as versões mais recentes do Amazon Linux otimizado para Amazon EKS, das AMIs do Amazon Linux otimizadas para Amazon EKS e as AMIs do Bottlerocket, elas já têm a versão do kernel exigida.
A AMI do Amazon Linux acelerada otimizada para Amazon EKS versão `v20231116` ou superior possui o kernel versão `5.10`.
## Etapa 1: configurar a aplicação de políticas na inicialização dos pods
O plug-in CNI da Amazon VPC para Kubernetes configura as políticas de rede para os pods em paralelo ao provisionamento de pods. Até que todas as políticas estejam configuradas para o novo pod, os contêineres no novo pod serão iniciados com uma *política de permissão padrão*. Isso é denominado *modo padrão*. Uma política de permissão padrão significa que todo o tráfego de entrada e de saída é permitido de e para os novos pods. Por exemplo, os pods não terão nenhuma regra de firewall aplicada (todo o tráfego é permitido) até que o novo pod seja atualizado com as políticas ativas.
Com a variável `NETWORK_POLICY_ENFORCING_MODE` definida como `strict`, os pods que usam o plug-in CNI da VPC são iniciados com uma *política de negação padrão* e, em seguida, as políticas são configuradas. Isso é denominado *modo estrito*. No modo estrito, você deve ter uma política de rede para cada endpoint que os pods precisam acessar no cluster. Observe que esse requisito se aplica aos pods do CoreDNS. A política de negação padrão não está configurada para pods com sistemas de redes de host.
É possível alterar a política de rede padrão ao definir a variável de ambiente `NETWORK_POLICY_ENFORCING_MODE` como `strict` no contêiner `aws-node` do `DaemonSet` do plug-in CNI da VPC.
```
env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: "strict"
```
## Etapa 2: habilitar o parâmetro da política de redes do complemento
O recurso de política de rede usa a porta `8162` no nó para métricas por padrão. Além disso, o recurso usa a porta `8163` para a realização de sondagens de integridade. Se você executar outro aplicativo nos nós ou dentro dos pods que precisa usar essas portas, o aplicativo não será executado. Na versão `v1.14.1` ou em versões posteriores da CNI da VPC, é possível alterar essas portas.
Use o procedimento a seguir para habilitar o parâmetro da política de redes do complemento.
### 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 `Amazon VPC CNI`**:
1. Selecione a versão `v1.14.0-eksbuild.3` ou superior na lista **Versão**.
1. Expanda **Definições de configuração opcionais**.
1. Insira a chave JSON `"enableNetworkPolicy":` e o valor `"true"` em **Valores da configuração**. O texto resultante deve ser um objeto JSON válido. Se esse par de chave e valor for o único dado na caixa de texto, coloque-o entre colchetes `{ }`.
O seguinte exemplo tem a funcionalidade de política de rede ativada e as métricas e investigações de integridade estão configuradas com os números de porta padrão:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"healthProbeBindAddr": "8163",
"metricsBindAddr": "8162"
}
}
```
### Helm
Se você instalou o plug-in CNI da Amazon VPC para Kubernetes por meio do `helm`, você pode atualizar a configuração para alterar as portas.
1. Execute o seguinte comando para alterar as portas. Defina o número da porta no valor da chave `nodeAgent.metricsBindAddr` ou da chave `nodeAgent.healthProbeBindAddr`, respectivamente.
```
helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 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 os números da porta nos argumentos do comando a seguir no contêiner `args:` no manifesto do daemonset `aws-network-policy-agent` do CNI do `aws-node` VPC.
```
- args:
- --metrics-bind-addr=:8162
- --health-probe-bind-addr=:8163
```
## Etapa 3: configurar o cluster para usar as políticas de rede do Kubernetes
É possível configurar isso para um complemento do Amazon EKS ou autogerenciado.
### Complemento do Amazon EKS
Usando a AWS CLI, você pode configurar o cluster para usar as políticas de rede do Kubernetes ao executar o comando a seguir. 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 '{"enableNetworkPolicy": "true"}'
```
Para definir essa configuração usando o Console de Gerenciamento da AWS, siga as etapas abaixo:
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 `Amazon VPC CNI`**:
1. Selecione a versão `v1.14.0-eksbuild.3` ou superior na lista **Versão**.
1. Expanda **Definições de configuração opcionais**.
1. Insira a chave JSON `"enableNetworkPolicy":` e o valor `"true"` em **Valores da configuração**. O texto resultante deve ser um objeto JSON válido. Se esse par de chave e valor for o único dado na caixa de texto, coloque-o entre colchetes `{ }`. O exemplo apresentado a seguir mostra que a política de rede está habilitada:
```
{ "enableNetworkPolicy": "true" }
```
A captura de tela a seguir mostra um exemplo desse cenário.
![\[ mostrando o complemento VPC CNI com política de rede na configuração opcional.\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/console-cni-config-network-policy.png)
### Complemento autogerenciado
Se você instalou o plug-in CNI da Amazon VPC para Kubernetes por meio do `helm`, você pode atualizar a configuração para habilitar a política de rede.
1. Execute o comando a seguir para habilitar a política de rede.
```
helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
1. Abra o `amazon-vpc-cni` `ConfigMap` no editor.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Adicione a linha a seguir aos `data` no `ConfigMap`.
```
enable-network-policy-controller: "true"
```
Depois de adicionar a linha, o `ConfigMap` deverá ser semelhante ao exemplo a seguir.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Abra o `aws-node` `DaemonSet` no editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Substitua `false` por `true` no argumento do comando `--enable-network-policy=false` em `args:` no contêiner do `aws-network-policy-agent` no manifesto do daemonset do `aws-node` do VPC CNI.
```
- args:
- --enable-network-policy=true
```
## Etapa 4: Próximas etapas
Depois de concluir a configuração, confirme se os pods `aws-node` estão sendo executados no cluster.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Veja abaixo um exemplo de saída.
```
aws-node-gmqp7 2/2 Running 1 (24h ago) 24h
aws-node-prnsh 2/2 Running 1 (24h ago) 24h
```
Existem dois contêineres nos pods `aws-node` na versão `1.14` e posteriores. Nas versões anteriores e quando a política de rede está desabilitada, há apenas um único contêiner nos pods do `aws-node`.
Agora você pode implantar políticas de rede do Kubernetes no cluster.
Para implementar políticas de rede do Kubernetes, você pode criar objetos `NetworkPolicy` ou `ClusterNetworkPolicy` e implantá-los em seu cluster. Os objetos `NetworkPolicy` são restritos a um namespace, enquanto objetos `ClusterNetworkPolicy` podem abranger todo o cluster ou diversos namespaces. Você implementa políticas para permitir ou negar tráfego entre os pods com base em seletores de rótulos, namespaces e intervalos de endereços IP. Para obter mais informações sobre a criação de objetos de `NetworkPolicy`, consulte [Políticas de rede](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) na documentação do Kubernetes.
A aplicação dos objetos de `NetworkPolicy` do Kubernetes é implementada usando o Extended Berkeley Packet Filter (eBPF). Em relação a implementações baseadas em `iptables`, ele oferece menor latência e características de performance, incluindo menor utilização da CPU e prevenção de consultas sequenciais. Além disso, as sondas do eBPF fornecem acesso a dados contextuais ricos que ajudam a depurar problemas complexos no nível do kernel e a melhorar a observabilidade. O Amazon EKS é compatível com um exportador baseado no eBPF que aproveita as sondas para registrar em log os resultados da política em cada nó e exportar os dados para coletores de logs externos para auxiliar na depuração. Para obter mais informações, consulte a [documentação do eBPF](https://ebpf.io/what-is-ebpf/#what-is-ebpf).
# Desabilitar as políticas de rede do Kubernetes para o tráfego de rede de pods do Amazon EKS
Desabilite as políticas de rede do Kubernetes para interromper a restrição do tráfego de rede de pods do Amazon EKS
1. Liste todas as políticas de rede do Kubernetes.
```
kubectl get netpol -A
```
1. Exclua cada política de rede do Kubernetes. Você deve excluir todas as políticas de rede antes de desabilitar as políticas de rede.
```
kubectl delete netpol
```
1. Abra o DaemonSet aws-node em seu editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Substitua `true` por `false` no argumento do comando `--enable-network-policy=true` em `args:` no contêiner do `aws-network-policy-agent` no manifesto do daemonset do `aws-node` do VPC CNI.
```
- args:
- --enable-network-policy=true
```
# 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.
# Demonstração Stars da política de redes do Amazon EKS
A demonstração cria um serviço de front-end, de back-end e de cliente no cluster do Amazon EKS. A demonstração também cria um interface gráfica do usuário de gerenciamento que mostra os caminhos de entrada e saída disponíveis entre cada serviço. Recomendamos que você conclua a demonstração em um cluster no qual você não executa workloads de produção.
Antes de você criar políticas de rede, todos os serviços podem se comunicar bidirecionalmente. Depois de aplicar as políticas de rede, você poderá ver que o cliente só pode se comunicar com o serviço de front-end, e o back-end só aceita tráfego do front-end.
1. Aplique os serviços de front-end, de back-end, de cliente e de interface do usuário de gerenciamento:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
```
1. Veja todos os pods no cluster.
```
kubectl get pods -A
```
Veja um exemplo de saída abaixo.
Na saída, você deve ver pods nos namespaces mostrados na saída a seguir. Os *NOMES* dos pods e o número de pods na coluna `READY` são diferentes dos que aparecem na saída a seguir. Não continue até ver pods com nomes semelhantes e que todos eles tenham `Running` na coluna `STATUS`.
```
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
client client-xlffc 1/1 Running 0 5m19s
[...]
management-ui management-ui-qrb2g 1/1 Running 0 5m24s
stars backend-sz87q 1/1 Running 0 5m23s
stars frontend-cscnf 1/1 Running 0 5m21s
[...]
```
1. Para se conectar à interface de usuário de gerenciamento, conecte-se ao `EXTERNAL-IP` do serviço em execução no cluster:
```
kubectl get service/management-ui -n management-ui
```
1. Abra o navegador no local da etapa anterior. Você deve ver a interface do usuário de gerenciamento a seguir. O nó **C** é o serviço de cliente, o nó **F** é o serviço de front-end e o nó **B** é o serviço de back-end. Cada nó possui acesso total à comunicação com todos os outros nós, conforme indicado pelas linhas coloridas em negrito.
![\[Abrir a política de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/stars-default.png)
1. Aplique a seguintes política de rede a ambos os namespaces `stars` e `client` para isolar os serviços um do outro:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny
spec:
podSelector:
matchLabels: {}
```
Você pode usar os comandos a seguir para aplicar a política a ambos os namespaces:
```
kubectl apply -n stars -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
```
1. Atualize o navegador. Você verá que a interface do usuário de gerenciamento não pode mais acessar nenhum dos nós, portanto, eles não são mostrados na interface do usuário.
1. Aplique as políticas de rede a seguir para permitir que a interface de usuário de gerenciamento acesse os serviços. Aplique essa política para permitir que a interface do usuário:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Aplique essa política para permitir que o cliente:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: client
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Você pode usar os seguintes comandos para aplicar ambas as políticas:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
```
1. Atualize o navegador. Você verá que a interface do usuário de gerenciamento pode acessar os nós novamente, mas os nós não podem se comunicar uns com os outros.
![\[Política de rede de acesso à interface do usuário\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/stars-no-traffic.png)
1. Aplique a seguinte política de rede para permitir o tráfego do serviço de front-end para o serviço de back-end:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: backend-policy
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
```
1. Atualize o navegador. Você vê que o front-end pode se comunicar com o back-end.
![\[Política de front-end para back-end\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/stars-front-end-back-end.png)
1. Aplique a política de rede a seguir para permitir tráfego do cliente para o serviço de front-end:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: frontend-policy
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 80
```
1. Atualize o navegador. Você vê que o cliente pode se comunicar com o serviço de front-end. O serviço de front-end ainda pode se comunicar com o serviço de back-end.
![\[Política de rede final\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/stars-final.png)
1. (Opcional) Ao concluir a demonstração, você poderá excluir os recursos dela.
```
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
```
Mesmo após a exclusão dos recursos, ainda pode haver endpoints de política de rede nos nós que podem interferir de maneiras inesperados nas conexões de rede do cluster. A única maneira garantida de remover essas regras é recarregar os nós ou encerrar todos os nós e reciclá-los. Para encerrar todos os nós, defina a contagem desejada do grupo de Auto Scaling como 0 e faça backup para o número desejado ou simplesmente encerre os nós.
# Implementar pods em sub-redes alternativas com rede personalizada
**Aplica-se a**: nós Linux `IPv4` do Fargate, nós Linux com instâncias do Amazon EC2
![\[Diagrama de nó com várias interfaces de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/cn-image.png)
Por padrão, quando o plug-in CNI da Amazon VPC para Kubernetes cria [interfaces de rede elásticas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) secundárias (interfaces de rede) para o nó do Amazon EC2, ele as cria na mesma sub-rede que a interface de rede primária do nó. Ele também associa os mesmos grupos de segurança à interface de rede secundária que estão associados à interface de rede primária. Por uma ou mais das razões a seguir, você pode querer que o plugin crie interfaces de rede secundárias em uma sub-rede diferente ou associar grupos de segurança diferentes às interfaces de rede secundárias, ou ambos:
+ Existe um número limitado de endereços `IPv4` disponíveis na sub-rede na qual a interface de rede primária se encontra. Isso pode limitar o número de pods que podem ser criados na sub-rede. Usando uma sub-rede diferente para interfaces de rede secundárias, é possível aumentar o número de endereços `IPv4` disponíveis para pods.
+ Por motivos de segurança, os pods talvez precisem usar diferentes grupos de segurança ou sub-redes do que os da interface de rede primária do nó.
+ Os nós são configurados em sub-redes públicas, e você deseja colocar os pods em sub-redes privadas. A tabela de rotas que está associada a uma sub-rede pública inclui uma rota para um gateway da Internet. A tabela de rotas que está associada a uma sub-rede privada não inclui uma rota para um gateway da Internet.
**dica**
Você também pode adicionar uma sub-rede nova ou existente diretamente ao cluster do Amazon EKS, sem usar redes personalizadas. Para obter mais informações, consulte [Adicionar uma sub-rede da VPC existente a um cluster do Amazon EKS no console de gerenciamento](eks-networking.md#add-existing-subnet).
## Considerações
A seguir estão algumas considerações sobre o uso do recurso.
+ Com redes personalizadas habilitadas, nenhum endereço IP atribuído à interface de rede primária é atribuído a pods. Apenas endereços IP de interfaces de rede secundária são atribuídos a pods.
+ Se o seu cluster utilizar a família `IPv6`, não será possível utilizar redes personalizadas.
+ Se você planeja utilizar redes personalizadas somente para aliviar a exaustão de endereços `IPv4`, pode criar um cluster utilizando a família `IPv6`. Para obter mais informações, consulte [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md).
+ Mesmo que os pods implantados em sub-redes especificadas para interfaces de rede secundária possam usar sub-redes e grupos de segurança diferentes da interface de rede primária do nó, as sub-redes e os grupos de segurança devem estar na mesma VPC do nó.
+ No Fargate, as sub-redes são controladas por meio do perfil do Fargate. Para obter mais informações, consulte [Definir quais pods usam o AWS Fargate quando iniciado](fargate-profile.md).
# Personalização da interface de rede secundária nos nós do Amazon EKS
Antes de começar o tutorial, conclua as seguintes etapas:
+ Revisar as considerações
+ Familiaridade com como o plug-in CNI da Amazon VPC para Kubernetes cria interfaces de rede secundárias e atribui endereços IP a pods. Para saber mais, consulte [Alocação de ENIs](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation) no GitHub
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Convém concluir as etapas neste tópico em um shell Bash. Se não estiver utilizando um shell Bash, alguns comandos de script, como caracteres de continuação de linha e a forma como as variáveis são definidas e utilizadas, exigirão o ajuste do seu shell. Além disso, as regras de citação e de escape do seu shell podem ser diferentes. Para obter mais informações, consulte [Uso de aspas com cadeias de caracteres na AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html), no Guia do usuário da AWS Command Line Interface.
Para este tutorial, convém utilizar os valores de exemplo, exceto onde indicado para substituí-los. É possível substituir qualquer valor de exemplo ao concluir as etapas para um cluster do produção. Convém que todas as etapas sejam concluídas no mesmo terminal. Isso porque variáveis são definidas e utilizadas ao longo das etapas e não existirão em terminais diferentes.
Os comandos deste tópico estão formatados de acordo com as convenções listadas em [Exemplos de uso da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html). Se estiver executando comandos da linha de comandos em recursos que estão em uma região da AWS diferente da região da AWS padrão definida no [perfil](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles) da AWS CLI que você está usando, será necessário adicionar `--region us-west-2` aos comandos, substituindo `us-west-2` pela sua região da AWS.
Quando quiser implantar redes personalizadas no seu cluster do produção, pule para [Etapa 2: Configurar sua VPC](#custom-networking-configure-vpc).
## Etapa 1: Criar uma VPC de teste e um cluster
Os procedimentos a seguir ajudam a criar uma VPC de teste e um cluster e a configurar redes personalizadas para esse cluster. Não recomendamos utilizar o cluster do teste para workloads de produção, pois vários recursos não relacionados que você pode utilizar no seu cluster do produção não são abordados neste tópico. Para obter mais informações, consulte [Criar um cluster do Amazon EKS](create-cluster.md).
1. Execute o comando a seguir para definir a variável `account_id`.
```
account_id=$(aws sts get-caller-identity --query Account --output text)
```
1. Crie uma VPC.
1. Se estiver implementando em um sistema de teste, crie um VPC usando um modelo do Amazon EKS AWS CloudFormation.
```
aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
--parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
```
1. A pilha do AWS CloudFormation leva alguns minutos para ser criada. Para verificar o status de implantação da pilha, execute o comando a seguir.
```
aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus --output text
```
Não prossiga para a próxima etapa até que a saída do comando seja `CREATE_COMPLETE`.
1. Defina variáveis com os valores dos IDs das sub-redes privadas criadas pelo modelo.
```
subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
```
1. Defina variáveis com as zonas de disponibilidade das sub-redes que foram recuperadas na etapa anterior.
```
az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
```
1. Crie um perfil do IAM de cluster.
1. Execute o comando a seguir para criar um arquivo JSON de política de confiança do IAM:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Crie o perfil do IAM do cluster do Amazon EKS. Se necessário, prefixe `eks-cluster-role-trust-policy.json` com o caminho no computador no qual você gravou o arquivo na etapa anterior. O comando associa a política de confiança criada na etapa anterior à função. Para criar um perfil do IAM, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que estiver criando o perfil deverá ser atribuída à seguinte ação `iam:CreateRole` (permissão):
```
aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Anexe a política gerenciada do Amazon EKS chamada [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) à perfil. Para anexar uma política do IAM a uma [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) a entidade principal do IAM que está anexando a política deve receber uma das seguintes ações do IAM (permissões): `iam:AttachUserPolicy` ou `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Crie um cluster do Amazon EKS e configure seu dispositivo para se comunicar com ele.
1. Crie um cluster.
```
aws eks create-cluster --name my-custom-networking-cluster \
--role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
--resources-vpc-config subnetIds="$subnet_id_1","$subnet_id_2"
```
**nota**
Talvez você receba um erro porque uma das zonas de disponibilidade em sua solicitação não tem capacidade suficiente para criar um cluster do Amazon EKS. Se isso acontecer, o resultado do erro conterá as zonas de disponibilidade que são compatíveis com o novo cluster. Tente criar o cluster com pelo menos duas sub-redes que estejam localizadas nas zonas de disponibilidade compatíveis de sua conta. Para obter mais informações, consulte [Capacidade insuficiente](troubleshooting.md#ice).
1. A criação do cluster domora alguns minutos. Para verificar o status de implantação do cluster, execute o comando a seguir.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
```
Não prossiga para a próxima etapa até que a saída do comando seja `"ACTIVE"`.
1. Configure `kubectl` para se comunicar com o cluster.
```
aws eks update-kubeconfig --name my-custom-networking-cluster
```
## Etapa 2: Configurar sua VPC
Este tutorial requer a VPC que foi criada em [Etapa 1: Criar uma VPC de teste e um cluster](#custom-networking-create-cluster). Para um cluster do produção, ajuste as etapas de acordo com sua VPC, substituindo todos os valores de exemplo pelos seus próprios.
1. Verifique se o plug-in CNI da Amazon VPC instalado atualmente para Kubernetes é a versão mais recente. Para determinar a versão mais recente do tipo de complemento do Amazon EKS e atualizar sua versão para ela, consulte [Atualizar um complemento do Amazon EKS](updating-an-add-on.md). Para determinar a versão mais recente do tipo de complemento autogerenciado e atualizar sua versão para ela, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md).
1. Recupere o ID da VPC do seu cluster e armazene-o em uma variável para uso em etapas posteriores.
```
vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
```
1. Associe um bloco de Encaminhamento Entre Domínios Sem Classificação (CIDR) adicional à VPC do seu cluster. O bloco CIDR não pode se sobrepor a nenhum bloco CIDR existente associado.
1. Visualize os blocos CIDR atuais que estão associados à sua VPC.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id \
--query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Veja um exemplo de saída abaixo.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
+-----------------+--------------+
```
1. Associe um bloco CIDR adicionais à sua VPC. Substitua o valor do bloco CIDR no comando a seguir. Para obter mais informações, consulte [Associar blocos CIDR IPv4 adicionais ao seu VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr) no Guia do usuário do Amazon VPC.
```
aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
```
1. Confirme se o novo bloco está associado.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Veja abaixo um exemplo de saída.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
| 192.168.1.0/24 | associated |
+-----------------+--------------+
```
Não continue na próxima etapa até que o `State` do novo bloco CIDR seja `associated`.
1. Crie quantas sub-redes quiser utilizar em cada zona de disponibilidade na qual suas sub-redes existentes estejam. Especifique um bloco CIDR que esteja dentro do bloco CIDR que você associou à sua VPC em uma etapa anterior.
1. Crie novas sub-redes. Substitua os valores do bloco CIDR no comando a seguir. As sub-redes devem ser criadas em um bloco CIDR de VPC diferente daquele em que as sub-redes existentes se encontram, mas nas mesmas zonas de disponibilidade dessas sub-redes existentes. Neste exemplo, uma sub-rede é criada no novo bloco CIDR em cada zona de disponibilidade na qual as sub-redes privadas atuais existem. Os IDs das sub-redes criadas são armazenados em variáveis para uso em etapas posteriores. Os valores de `Name` correspondem aos valores atribuídos às sub-redes criadas utilizando o modelo VPC do Amazon EKS em uma etapa anterior. Não são necessários nomes. É possível utilizar nomes diferentes.
```
new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
```
**Importante**
Por padrão, suas novas sub-redes estão implicitamente associadas a [tabela de rotas principal](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables) da sua VPC. Essa tabela de rotas permite a comunicação entre todos os recursos que estão implantados na VPC. Porém, ela não permite comunicação com recursos que têm endereços IP fora dos blocos CIDR associados à sua VPC. É possível associar sua própria tabela de rotas a sub-redes para alterar esse comportamento. Para obter mais informações, consulte [Tabelas de rotas de sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables), no Guia do usuário da Amazon VPC.
1. Visualize as sub-redes atuais na sua VPC.
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
--query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
--output table
```
Veja um exemplo de saída abaixo.
```
----------------------------------------------------------------------
| DescribeSubnets |
+------------------+--------------------+----------------------------+
| AvailabilityZone | CidrBlock | SubnetId |
+------------------+--------------------+----------------------------+
| us-west-2d | 192.168.0.0/27 | subnet-example1 |
| us-west-2a | 192.168.0.32/27 | subnet-example2 |
| us-west-2a | 192.168.0.64/27 | subnet-example3 |
| us-west-2d | 192.168.0.96/27 | subnet-example4 |
| us-west-2a | 192.168.1.0/27 | subnet-example5 |
| us-west-2d | 192.168.1.32/27 | subnet-example6 |
+------------------+--------------------+----------------------------+
```
É possível ver que as sub-redes no bloco CIDR `192.168.1.0` que você criou estão nas mesmas zonas de disponibilidade que as sub-redes do bloco CIDR `192.168.0.0`.
## Etapa 3: Configurar recursos do Kubernetes
1. Defina a variável de ambiente `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` como `true` no DaemonSet `aws-node`.
```
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
```
1. Recupere o ID do [grupo de segurança do cluster](sec-group-reqs.md) e armazene-o em uma variável para usar na próxima etapa. O Amazon EKS criará automaticamente esse grupo de segurança quando você criar seu cluster.
```
cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
```
1. Crie um recurso `ENIConfig` personalizado para cada sub-rede na qual você deseja implantar pods.
1. Crie um arquivo exclusivo para cada configuração de interface de rede elástica.
Os comandos a seguir criam arquivos `ENIConfig` separados para as duas sub-redes criadas em uma etapa anterior. O valor de `name` deve ser exclusivo. O nome é o mesmo da zona de disponibilidade na qual a sub-rede está localizada. O grupo de segurança do cluster é atribuído a `ENIConfig`.
```
cat >$az_1.yaml <$az_2.yaml <
1. Crie um perfil do IAM para o nó.
1. Execute o comando a seguir para criar um arquivo JSON de política de confiança do IAM:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Crie o perfil do IAM e armazene o nome do recurso da Amazon (ARN) retornado em uma variável para uso em uma etapa posterior.
```
node_role_arn=$(aws iam create-role --role-name myCustomNetworkingNodeRole --assume-role-policy-document file://"node-role-trust-relationship.json" \
--query Role.Arn --output text)
```
1. Anexe três políticas do IAM gerenciadas necessárias ao perfil do IAM.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name myCustomNetworkingNodeRole
```
**Importante**
Para simplificar este tutorial, a política [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) é anexada à perfil IAM do nó. No entanto, em um cluster do produção, recomendamos que você anexe a política a um perfil do IAM separado que seja usado apenas com o plug-in CNI da Amazon VPC para Kubernetes. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md).
1. Crie um dos seguintes tipos de grupos de nós. Para determinar o tipo de instância a ser implantado, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md). Neste tutorial, conclua a opção **Gerenciado**, **Sem um modelo de inicialização ou com um modelo de inicialização sem um ID de AMI especificado**. Se for usar o grupo de nós para workloads de produção, recomendamos que você se familiarize com todas as opções de [grupo de nós gerenciados](create-managed-node-group.md) e [grupo de nós autogerenciados](worker.md) antes de implantar o grupo de nós.
+ **Managed (Gerenciado)** – Implante seu grupo de nós usando uma das seguintes opções:
+ **Sem um modelo de inicialização ou com um modelo de inicialização sem um ID de AMI especificado**: execute o comando a seguir. Neste tutorial, use os valores de exemplo. Para um grupo de nós de produção, substitua todos os valores de exemplo pelos seus próprios. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres.
```
aws eks create-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup \
--subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
```
+ **Com um modelo de inicialização com um ID de AMI especificado**
1. Determine o número máximo de pods recomendado do Amazon EKS para os nós. Siga as instruções em , adicionando `--cni-custom-networking-enabled` à etapa 3 desse tópico. Anote a saída para uso na próxima etapa.
1. No seu modelo de inicialização, especifique um ID de AMI otimizado do Amazon EKS ou uma AMI personalizada criada a partir da AMI otimizada do Amazon EKS e, em seguida [implante o grupo de nós usando um modelo de inicialização](launch-templates.md) e forneça os seguintes dados do usuário no modelo de lançamento: Estes dados do usuário fornecem argumentos para a especificação do `NodeConfig`. Para obter mais informações sobre o NodeConfig, consulte a [Referência de API do NodeConfig](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig). Você pode substituir `20` pelo valor da etapa anterior (recomendado) ou por seu próprio valor.
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
...
kubelet:
config:
maxPods: 20
```
Se você criou uma AMI personalizada que não foi criada a partir da AMI otimizada do Amazon EKS, precisa criar a configuração você mesmo.
+ **Autogerenciado**
1. Determine o número máximo de pods recomendado do Amazon EKS para os nós. Siga as instruções em , adicionando `--cni-custom-networking-enabled` à etapa 3 nesse tópico. Anote a saída para uso na próxima etapa.
1. Implante o grupo de nós usando as instruções em [Criar nós autogerenciados do Amazon Linux](launch-workers.md).
**nota**
Se quiser que os nós em um cluster do produção sejam compatíveis com um número significativamente maior de pods, execute o script em novamente. Adicione também a opção `--cni-prefix-delegation-enabled` ao comando. Por exemplo, `110` é retornado para um tipo de instância `m5.large`. Para obter instruções sobre como habilitar esse recurso, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md). É possível usar esse recurso com redes personalizadas.
1. A criação do grupo de nós demora vários minutos. Você pode verificar o status da criação de um grupo de nós gerenciados com o seguinte comando:
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Não continue na próxima etapa até que a saída recebida esteja `ACTIVE`.
1. No tutorial, é possível ignorar essa etapa.
Para um cluster do produção, se você definir para as suas `ENIConfigs` os mesmos nomes que os da zona de disponibilidade para a qual você as estiver utilizando, deverá anotar seus nós com o nome de `ENIConfig` que deve ser utilizado com o nó. Essa etapa não será necessária se você tiver apenas uma sub-rede em cada zona de disponibilidade e tiver definido suas `ENIConfigs` com os mesmos nomes das zonas de disponibilidade. Isso ocorre porque o plug-in CNI da Amazon VPC para Kubernetes associa automaticamente o `ENIConfig` correto ao nó quando você o habilitou a fazer isso em uma [etapa anterior](#custom-networking-automatically-apply-eniconfig).
1. Obtenha a lista de nós no seu cluster.
```
kubectl get nodes
```
Veja um exemplo de saída abaixo.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-0-126.us-west-2.compute.internal Ready 8m49s v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal Ready 8m34s v1.22.9-eks-810597c
```
1. Especifique em qual zona de disponibilidade cada nó se encontra. Execute o comando a seguir para cada nó retornado na etapa anterior, substituindo os endereços IP com base na saída anterior.
```
aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
--query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
```
Veja abaixo um exemplo de saída.
```
[
{
"AvailabilityZone": "us-west-2d",
"SubnetId": "subnet-Example5"
}
]
```
1. Anote cada nó com a `ENIConfig` que você criou para o ID da sub-rede e a zona de disponibilidade. Apenas é possível anotar um nó com uma `ENIConfig`, embora vários nós possam ser anotados com a mesma `ENIConfig`. Substitua os valores de exemplo pelos seus próprios.
```
kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
```
1. Se você tinha nós em um cluster do produção com pods em execução antes de mudar para usar o recurso de redes personalizadas, conclua as seguintes tarefas:
1. Certifique-se de ter nós disponíveis que estão utilizando o recurso de rede personalizado.
1. Isole e drene os nós para desligar os pods adequadamente. Para obter mais informações, consulte [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) (Drenar um nó com segurança) na documentação do Kubernetes.
1. Encerre os nós. Se os nós estiverem em um grupo de nós gerenciados existente, será possível excluir o grupo de nós. Execute o comando a seguir.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
Somente os novos nós que são registrados com o rótulo `k8s.amazonaws.com/eniConfig` usam o novo recurso de redes personalizadas.
1. Verifique se os pods receberam um endereço IP de um bloco CIDR associado a uma das sub-redes criadas em uma etapa anterior.
```
kubectl get pods -A -o wide
```
Veja abaixo um exemplo de saída.
```
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal
kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
```
Você pode ver que os pods do CoreDNS receberam endereços IP do bloco CIDR `192.168.1.0` que você adicionou à VPC. Sem redes personalizadas, eles teriam recebido endereços do bloco CIDR `192.168.0.0`, porque este era o único bloco CIDR originalmente associado à VPC.
Se um `spec` do pod contiver `hostNetwork=true`, será atribuído o endereço IP primário do nó. Ele não receberá um endereço das sub-redes que foram adicionadas. Por padrão, esse valor é definido como `false`. Esse valor é definido como `true` para os pods do `kube-proxy` e do plug-in CNI da Amazon VPC para Kubernetes (`aws-node`) que são executados no cluster. É por esse motivo que os pods do `kube-proxy` e do `aws-node` do plug-in não receberam os endereços 192.168.1.x na saída anterior. Para saber mais sobre a configuração `hostNetwork` de um pod, consulte [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) na referência de APIs do Kubernetes.
## Etapa 5: Excluir os recursos do tutorial
Depois de concluir o tutorial, convém excluir os recursos criados. Em seguida, ajuste as etapas para habilitar as redes personalizadas para um cluster do produção.
1. Se o grupo de nós criado foi apenas para testes, exclua-o.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
1. Mesmo após a saída da AWS CLI informar que o cluster foi excluído, o processo de exclusão pode não ter sido concluído. O processo de exclusão demora alguns minutos. Confirme se a exclusão foi feita, executando o seguinte comando:
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Não continue até que a saída retornada seja semelhante à seguinte:
```
An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
```
1. Se o grupo de nós criado foi apenas para testes, exclua a perfil do IAM do nó.
1. Desanexe as políticas da função.
```
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
```
1. Exclua o perfil.
```
aws iam delete-role --role-name myCustomNetworkingNodeRole
```
1. Excluir o cluster.
```
aws eks delete-cluster --name my-custom-networking-cluster
```
Confirme se a exclusão do cluster foi concluída, com o comando a seguir.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
```
Quando uma saída semelhante à seguinte for retornada, significa que o cluster foi excluído com êxito:
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
```
1. Exclua o perfil do IAM do cluster.
1. Desanexe as políticas da função.
```
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
1. Exclua o perfil.
```
aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Exclua as sub-redes que você criou em uma etapa anterior.
```
aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2
```
1. Exclua a pilha da VPC criada.
```
aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
```
# Atribuir mais endereços IP aos nós do Amazon EKS com prefixos
**Aplica-se a**: nós do Linux e Windows com instâncias do Amazon EC2
**Aplica-se a**: sub-redes públicas e privadas
Cada tipo de instância do Amazon EC2 oferece suporte a um número máximo de interfaces de rede elásticas e a um número máximo de endereços IP que podem ser atribuídos a cada interface de rede. Cada nó requer um endereço IP para cada interface de rede. Todos os outros endereços IP disponíveis podem ser atribuídos a `Pods`. Cada `Pod` exige seu próprio endereço IP. Como resultado, é possível ter nós com recursos de computação e memória disponíveis, mas que não são capazes de acomodar `Pods` adicionais porque o nó ficou sem endereços IP para atribuir aos `Pods`.
É possível aumentar o número de endereços IP que os nós podem atribuir a `Pods` atribuindo prefixos IP em vez de atribuir endereços IP secundários individuais aos nós. Cada prefixo inclui vários endereços IP. Se você não configurar o cluster para atribuição de prefixos IP, ele deverá fazer mais chamadas da interface de programação de aplicações (API) do Amazon EC2 para configurar as interfaces de rede e os endereços IP necessários para a conectividade de pods. À medida que os clusters aumentam de tamanho, a frequência dessas chamadas de API podem levar a tempos de execução de instâncias e pods maiores. Isso resulta em atrasos na escalabilidade para atender à demanda de workloads grandes e com alto pico, além de adicionar custos e despesas gerais de gerenciamento, pois você precisará provisionar clusters e VPCs adicionais para atender aos requisitos de escalabilidade. Para obter mais informações, consulte [Limites de escalabilidade do Kubernetes](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) no GitHub.
## Compatibilidade com recursos do plug-in CNI da Amazon VPC para Kubernetes
É possível usar prefixos IP com os seguintes atributos:
+ Tradução do endereço de rede de origem IPv4: para obter mais informações, consulte [Habilitar o acesso de saída à internet para pods](external-snat.md).
+ Endereços IPv6 para clusters, pods e serviços: para obter mais informações, consulte [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md).
+ Restrição do tráfego usando políticas de rede do Kubernetes: para obter mais informações, consulte [Limitar o tráfego do pod com políticas de rede do Kubernetes](cni-network-policy.md).
A lista a seguir fornece informações sobre as configurações do plug-in CNI da Amazon VPC aplicáveis. Para obter mais informações sobre cada configuração, consulte [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) no GitHub.
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## Considerações
Considere o seguinte ao usar esse atributo:
+ Cada tipo de instância do Amazon EC2 é compatível com um número máximo de pods. Se o grupo de nós gerenciados consistir em vários tipos de instância, o menor número de pods máximos para uma instância no cluster será aplicado a todos os nós do cluster.
+ Por padrão, o número máximo de `Pods` que podem ser executados em um nó é 110, mas esse número pode ser alterado. Se você alterar o número e tiver um grupo de nós gerenciados existente, a próxima atualização da AMI ou do modelo de execução do seu grupo de nós resultará no surgimento de novos nós com o valor alterado.
+ Ao fazer a transição da atribuição de endereços IP para a atribuição de prefixos IP, recomendamos criar novos grupos de nós para aumentar o número de endereços IP disponíveis, em vez de fazer uma substituição contínua dos nós existentes. A execução de pods em um nó com endereços IP e prefixos atribuídos pode causar inconsistência na capacidade anunciada do endereço IP, afetando as futuras workloads no nó. Para ver a forma recomendada de realizar a transição, consulte [Modo de delegação de prefixo para Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html) no *Guia de práticas recomendadas do Amazon EKS*.
+ O escopo do grupo de segurança está no nível do nó: para obter mais informações, consulte [Grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
+ Os prefixos de IP atribuídos a uma interface de rede são compatíveis com alta densidade de pods por nó e têm o melhor tempo de execução.
+ Prefixos IP e endereços IP estão associados a interfaces de rede elásticas padrão do Amazon EC2. Os pods que exigem grupos de segurança específicos recebem o endereço IP principal de uma interface de rede de filial. Você pode misturar pods recebendo endereços IP ou endereços IP de prefixos de IP com pods obtendo interfaces de rede de ramificação no mesmo nó.
+ Para clusters somente com nós Linux.
+ Depois de configurar o complemento para atribuir prefixos a interfaces de rede, você não poderá fazer downgrade do complemento do plug-in CNI da Amazon VPC para Kubernetes para uma versão inferior à `1.9.0` (ou `1.10.1`) sem remover todos os nós em todos os grupos de nós do cluster.
+ Se você também estiver usando grupos de segurança para pods, com `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` e `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false`, quando seus pods se comunicarem com endpoints fora da VPC, os grupos de segurança do nó serão usados, em vez de quaisquer grupos de segurança que você possa ter atribuído a seus pods.
Se você também estiver usando [grupos de segurança para pods](security-groups-for-pods.md), com `POD_SECURITY_GROUP_ENFORCING_MODE` = `strict`, quando seu `Pods` se comunicar com endpoints fora de sua VPC, os grupos de segurança `Pod’s` serão usados.
# Aumente a quantidade de endereços IP disponíveis para o nó do Amazon EKS
É possível aumentar o número de endereços IP que os nós podem atribuir a pods atribuindo prefixos de IP em vez de endereços IP secundários individuais aos nós.
## Pré-requisitos
+ É necessário um cluster existente. Para implantar, consulte [Criar um cluster do Amazon EKS](create-cluster.md).
+ As sub-redes nas quais seus nós do Amazon EKS estão devem ter blocos de Encaminhamento Entre Domínios Sem Classificação (CIDR) `/28` (para clusters `IPv4`) ou `/80` (para clusters `IPv6`) suficientemente contíguos. Somente nós Linux podem existir em um cluster `IPv6`. O uso de prefixos IP poderá falhar se os endereços IP estiverem espalhados pelo CIDR da sub-rede. Recomendamos o seguinte:
+ Usar uma reserva CIDR de sub-rede para que, mesmo que algum endereço IP dentro do intervalo reservado ainda esteja em uso, após sua liberação, os endereços IP não sejam reatribuídos. Isso garante que os prefixos estejam disponíveis para alocação sem segmentação.
+ Usar novas sub-redes que sejam utilizadas especificamente para executar workloads às quais os prefixos IP estão atribuídos. As workloads do Linux e do Windows podem ser executadas na mesma sub-rede ao atribuir prefixos de IP.
+ Para atribuir prefixos IP aos seus nós, eles devem ser baseados no AWS Nitro. As instâncias que não são baseadas em Nitro continuam alocando endereços IP secundários individuais, mas têm um número significativamente menor de endereços IP para atribuir aos pods do que as instâncias baseadas em Nitro.
+ **Somente para clusters com nós do Linux**: se o cluster estiver configurado para a família `IPv4`, você deverá ter a versão `1.9.0` ou mais recente do complemento do plug-in CNI da Amazon VPC para Kubernetes instalada. É possível verificar a versão atual com o comando a seguir.
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
Se o cluster estiver configurado para a família `IPv6`, a versão `1.10.1` ou posterior do complemento deverá estar instalada. Se a versão do plug-in for anterior às versões exigidas, será necessário atualizá-lo. Para obter mais informações, consulte as seções de atualização de [Atribuir IPs a pods com o Amazon VPC CNI](managing-vpc-cni.md).
+ **Somente para clusters com nós do Windows**
+ Você deve ter o suporte do Windows habilitado para o cluster. Para obter mais informações, consulte [Implantar nós Windows em clusters EKS](windows-support.md).
## Atribuir prefixos de endereço IP aos nós
Configure seu cluster para atribuir prefixos de endereço IP aos nós. Conclua o procedimento que corresponda ao sistema operacional do seu nó.
### Linux
1. Habilite o parâmetro para atribuir prefixos a interfaces de rede para o DaemonSet CNI da Amazon VPC. Ao implantar um cluster, a versão `1.10.1` ou mais recente do complemento do plug-in CNI da Amazon VPC para Kubernetes é implantada com ele. Se você criou o cluster com a família `IPv6`, essa configuração foi definida como `true` por padrão. Se você criou o cluster com a família `IPv4`, essa configuração foi definida como `false` por padrão.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**Importante**
Mesmo que sua sub-rede tenha endereços IP disponíveis, se ela não tiver blocos `/28` contíguos disponíveis, você verá o erro a seguir nos logs do plug-in CNI da Amazon VPC para Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Isso pode acontecer devido à fragmentação dos endereços IP secundários existentes espalhados por uma sub-rede. Para resolver esse erro, crie uma sub-rede e inicie pods lá ou use uma reserva CIDR de sub-rede do Amazon EC2 para reservar espaço em uma sub-rede para uso com atribuição de prefixo. Para obter mais informações, consulte [Comportamento do endereçamento IP para sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) no Guia do usuário da Amazon VPC.
1. Caso planeje implantar um grupo de nós gerenciados sem um modelo de inicialização, ou com um modelo de inicialização no qual não especificou um ID da AMI, e esteja usando uma versão do plug-in CNI da Amazon VPC para Kubernetes igual ou posterior às versões listadas nos pré-requisitos, pule para a próxima etapa. Os grupos de nós gerenciados calculam automaticamente o número máximo de pods para você.
Se você estiver implantando um grupo de nós autogerenciados ou um grupo de nós gerenciados com um modelo de execução em que você especificou um ID de AMI, será necessário determinar o número recomendado do Amazon EKS de pods máximos para seus nós. Siga as instruções em , adicionando `--cni-prefix-delegation-enabled` à etapa 3. Anote a saída para uso em uma etapa superior.
**Importante**
Grupos de nós gerenciados impõem um número máximo para o valor de `maxPods`. Para instâncias com menos de 30 vCPUs, o número máximo é 110 e, para todas as outras instâncias, o número máximo é 250. Esse número máximo é aplicado quer a delegação de prefixo esteja habilitada ou não.
1. Se você estiver usando um cluster configurado para `IPv6`, pule para a próxima etapa.
Especifique os parâmetros em uma das opções a seguir. Para determinar qual opção é a certa para você e qual valor fornecer para ela, consulte [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET, and MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md) no GitHub.
Você pode substituir os valores de exemplo por um valor maior que zero.
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` ou `MINIMUM_IP_TARGET` – Se qualquer um dos dois valores for definido, substitui qualquer valor definido para `WARM_PREFIX_TARGET`.
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. Crie um dos tipos de grupos de nós listados a seguir, utilizando, pelo menos, uma instância do Amazon EC2 do tipo Nitro com Amazon Linux 2023. Para obter uma lista dos tipos de instância do Nitro, consulte [Instâncias criadas no Sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) no Guia do usuário do Amazon EC2. Este recurso não é compatível no Windows. Para as opções que incluem *110*, substitua pelo valor da etapa 3 (recomendado) ou por seu próprio valor.
+ **Autogerenciado**: implante o grupo de nós usando as instruções em [Criar nós autogerenciados do Amazon Linux](launch-workers.md). Antes de criar a pilha do CloudFormation, abra o arquivo de modelo e ajuste `UserData` no `NodeLaunchTemplate`, conforme mostrado abaixo.
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
Se estiver usando `eksctl` para criar o grupo de nós, poderá usar o comando a seguir.
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **Managed (Gerenciado)** – Implante seu grupo de nós usando uma das seguintes opções:
+ **Sem um modelo de inicialização ou com um modelo de inicialização sem uma ID de AMI especificada**: conclua o procedimento em [Criar um grupo de nós gerenciados para o seu cluster](create-managed-node-group.md). Grupos de nós gerenciados agora calculam automaticamente o valor recomendado de `max-pods` do Amazon EKS para você.
+ **Com um modelo de lançamento com um ID de AMI especificado** – Em seu modelo de lançamento, especifique um ID de AMI otimizado do Amazon EKS ou uma AMI personalizada criada a partir da AMI otimizada do Amazon EKS e, em seguida [implante o grupo de nós usando um modelo de lançamento](launch-templates.md) e forneça os seguintes dados do usuário no modelo de lançamento. Estes dados do usuário são transferidos de um objeto `NodeConfig` para serem lidos pela ferramenta `nodeadm` no nó. Para obter mais informações sobre `nodeadm`, consulte a [documentação do nodeadm](https://awslabs.github.io/amazon-eks-ami/nodeadm).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
Se estiver usando `eksctl` para criar o grupo de nós, poderá usar o comando a seguir.
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Se você criou uma AMI personalizada que não foi criada a partir da AMI otimizada do Amazon EKS, precisa criar a configuração você mesmo.
**nota**
Se você também quiser atribuir endereços IP aos pods de uma sub-rede diferente da sub-rede da instância, será necessário habilitar o recurso nesta etapa. Para obter mais informações, consulte [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md).
### Windows
1. Habilite a atribuição de prefixos IP.
1. Abra o `ConfigMap` de `amazon-vpc-cni` para edição.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Adicione as linhas a seguir à seção `data`:
```
enable-windows-prefix-delegation: "true"
```
1. Salve o arquivo e feche o editor.
1. Confirme se a anotação foi adicionada ao `ConfigMap`.
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
Se a saída retornada não for `true`, é possível que um erro tenha ocorrido. Tente concluir a etapa novamente.
**Importante**
Mesmo que sua sub-rede tenha endereços IP disponíveis, se ela não tiver blocos `/28` contíguos disponíveis, você verá o erro a seguir nos logs do plug-in CNI da Amazon VPC para Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Isso pode acontecer devido à fragmentação dos endereços IP secundários existentes espalhados por uma sub-rede. Para resolver esse erro, crie uma sub-rede e inicie pods lá ou use uma reserva CIDR de sub-rede do Amazon EC2 para reservar espaço em uma sub-rede para uso com atribuição de prefixo. Para obter mais informações, consulte [Comportamento do endereçamento IP para sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) no Guia do usuário da Amazon VPC.
1. (Opcional) Especifique uma configuração adicional para controlar o comportamento de pré-escalabilidade e escalabilidade dinâmica do seu cluster. Para obter mais informações, consulte [Opções de configuração com o modo de delegação de prefixo no Windows](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md) no GitHub.
1. Abra o `ConfigMap` de `amazon-vpc-cni` para edição.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Substitua os valores de exemplo por um valor maior que zero e adicione as entradas necessárias à seção `data` do `ConfigMap`. Se você definir um valor para um `warm-ip-target` ou `minimum-ip-target`, o valor substituirá qualquer valor definido para `warm-prefix-target`.
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. Salve o arquivo e feche o editor.
1. Crie grupos de nós do Windows com pelo menos um tipo de instância do Nitro para Amazon EC2. Para obter uma lista dos tipos de instância do Nitro, consulte [Instâncias criadas no Sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) no Guia do usuário do Amazon EC2. Por padrão, o número máximo de pods que podem ser implantados em um nó é 110. Se você quiser aumentar ou diminuir esse número, especifique as informações a seguir nos dados do usuário para a configuração do bootstrap. Substitua *max-pods-quantity* pelo seu valor máximo de pods.
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
Se você estiver implantando grupos de nós gerenciados, essa configuração precisará ser adicionada ao modelo de inicialização. Para obter mais informações, consulte [Personalizar nós gerenciados com modelos de execução](launch-templates.md). Para obter mais informações sobre os parâmetros de configuração do script de bootstrap do Windows, consulte [Parâmetros de configuração do script de bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Determinar o máximo de pods e endereços IP disponíveis
1. Depois que seus nós forem implantados, visualize-os no cluster.
```
kubectl get nodes
```
Veja um exemplo de saída abaixo.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. Descreva um dos nós para determinar o valor de `max-pods` para o nó e o número de endereços IP disponíveis. Substitua *192.168.30.193* pelo endereço `IPv4` no nome de um do seus nós retornado na saída anterior.
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
Veja abaixo um exemplo de saída.
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
Na saída anterior, `110` é o número máximo de pods que o Kubernetes implantará no nó, mesmo que endereços IP *144* estejam disponíveis.
# Atribuir grupos de segurança a pods individuais
**Aplica-se a**: nós do Linux com instâncias do Amazon EC2
**Aplica-se a**: sub-redes privadas
Os grupos de segurança para pods integram grupos de segurança do Amazon EC2 aos pods do Kubernetes. Você pode usar grupos de segurança do Amazon EC2 para definir regras que permitem tráfego de rede de entrada e saída de e para pods implantados em nós executados em muitos tipos de instância do Amazon EC2 e Fargate. Para obter uma explicação detalhada sobre esse recurso, consulte o post do blog [Apresentação de grupos de segurança para pods](https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods).
## Compatibilidade com recursos do plug-in CNI da Amazon VPC para Kubernetes
Você pode usar os grupos de segurança dos pods com os seguintes recursos:
+ Tradução do endereço de rede de origem IPv4: para obter mais informações, consulte [Habilitar o acesso de saída à internet para pods](external-snat.md).
+ Endereços IPv6 para clusters, pods e serviços: para obter mais informações, consulte [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md).
+ Restrição do tráfego usando políticas de rede do Kubernetes: para obter mais informações, consulte [Limitar o tráfego do pod com políticas de rede do Kubernetes](cni-network-policy.md).
## Considerações
Antes de implantar grupos de segurança para pods, considere as seguintes limitações e condições:
+ Os grupos de segurança para pods não podem ser usados com os nós do Windows ou com o modo automático do EKS.
+ Os grupos de segurança para pods podem ser usados com clusters configurados para a família `IPv6` que contém nós do Amazon EC2 usando a versão 1.16.0 ou mais recente do plug-in CNI da Amazon VPC. Você pode usar grupos de segurança para pods com clusters configurados para a família `IPv6` que contêm apenas nós do Fargate usando a versão 1.7.7 ou mais recente do plug-in CNI da Amazon VPC. Para obter mais informações, consulte . [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md)
+ Os grupos de segurança para pods são compatíveis com a maioria das famílias de instâncias do Amazon EC2 [baseadas no Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances), mas não com todas as gerações de uma família. Por exemplo, eles são compatíveis com a família e as gerações de instâncias `m5`, `c5`, `r5`, `m6g`, `c6g` e `r6g`. Mas não são compatíveis com nenhum tipo de instância da família `t`. Para obter uma lista completa de tipos de instância compatíveis, consulte o arquivo [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/v1.5.0/pkg/aws/vpc/limits.go) no GitHub. Seus nós devem ser um dos tipos de instâncias listados que têm `IsTrunkingCompatible: true` nesse arquivo.
+ Se você estiver usando a rede personalizada e grupos de segurança para pods juntos, o grupo de segurança especificado por grupos de segurança para pods é usado em vez do grupo de segurança especificado na `ENIConfig`.
+ Se você estiver usando a versão `1.10.2` ou anterior do plug-in CNI da Amazon VPC e incluir a configuração `terminationGracePeriodSeconds` na especificação do pod, o valor dessa configuração não poderá ser zero.
+ Se você estiver usando a versão `1.10` ou anterior do plug-in CNI da Amazon VPC, ou a versão `1.11` com `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, que é a configuração padrão, então os serviços do Kubernetes do tipo `NodePort` e `LoadBalancer` que usam destinos de instância com a `externalTrafficPolicy` definida como `Local` não serão compatíveis com os pods aos quais você atribuir grupos de segurança. Para obter mais informações sobre como usar um balanceador de carga com destinos de instância, consulte . [Roteamento de tráfego TCP e UDP com Network Load Balancers](network-load-balancing.md).
+ Se você estiver usando a versão `1.10` ou anterior do plug-in CNI da Amazon VPC ou a versão `1.11` com `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, que é a configuração padrão, o NAT de origem estará desabilitado para tráfego de saída de pods com grupos de segurança atribuídos para que as regras de grupo de segurança de saída sejam aplicadas. Para acessar a internet, os pods com grupos de segurança atribuídos devem ser iniciados em nós implantados em uma sub-rede privada configurada com uma instância ou gateway NAT. Pods com grupos de segurança atribuídos implantados em sub-redes públicas não conseguem acessar a Internet.
Se estiver usando a versão `1.11` ou mais recente do plug-in com `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, o tráfego do pod destinado para fora da VPC será convertido no endereço IP da interface de rede primária da instância. Para esse tráfego, as regras nos grupos de segurança da interface de rede primária são usadas, e não as regras nos grupos de segurança do pod.
+ Para usar a política de rede do Calico com pods que têm grupos de segurança associados, é necessário usar a versão `1.11.0` ou mais recente do plug-in CNI da Amazon VPC e definir `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`. Do contrário, o fluxo de tráfego de e para pods com grupos de segurança associados não estará sujeito à política de rede do Calico e estará limitado apenas à imposição do grupo de segurança do Amazon EC2. Para atualizar sua versão do Amazon VPC CNI, consulte . [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md)
+ Pods em execução nos nós do Amazon EC2 que usam grupos de segurança em clusters que usam [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) são compatíveis apenas com a versão `1.11.0` ou mais recente do plug-in CNI da Amazon VPC e com `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`. Para atualizar sua versão do plugin Amazon VPC CNI, consulte . [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md)
+ Grupos de segurança nos pods podem levar a uma latência de inicialização mais alta no pod para pods com alta rotatividade. Isso se deve à limitação de taxa no controlador de recursos.
+ O escopo do grupo de segurança do EC2 está no nível do pod. Para obter mais informações, consulte [Grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
Se você tiver definido `POD_SECURITY_GROUP_ENFORCING_MODE=standard` e `AWS_VPC_K8S_CNI_EXTERNALSNAT=false`, o tráfego destinado a endpoints fora da VPC usará os grupos de segurança do nó e não os grupos de segurança do pod.
# Configurar o plug-in CNI da Amazon VPC para Kubernetes de grupos de segurança para pods do Amazon EKS
Caso use pods com instâncias do Amazon EC2, é necessário configurar o plug-in CNI da Amazon VPC para grupos de segurança do Kubernetes.
Caso use apenas pods do Fargate e não tenha nenhum nó do Amazon EC2 no cluster, consulte [Usar uma política para grupos de segurança para um pod do Amazon EKS](sg-pods-example-deployment.md).
1. Verifique a versão atual do plug-in CNI da Amazon VPC para Kubernetes com o seguinte comando:
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Veja um exemplo de saída abaixo.
```
v1.7.6
```
Se a versão do plug-in CNI da Amazon VPC para Kubernetes for anterior à `1.7.7`, atualize o plug-in para a versão `1.7.7` ou mais recente. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md).
1. Adicione a política do IAM gerenciada pelo [AmazonEKSVPCResourceController](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSVPCResourceController) ao [perfil de cluster](cluster-iam-role.md#create-service-role) que está associado ao seu cluster do Amazon EKS. A política permite que a função gerencie interfaces de rede, seus endereços IP privados e seu anexo e desprendimento de e para instâncias de rede.
1. Recupere o nome do perfil do IAM do cluster e armazene-o em uma variável. Substitua *my-cluster* pelo nome do cluster.
```
cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
```
1. Anexe a política ao perfil.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
```
1. Habilite o complemento CNI da Amazon VPC para gerenciar interfaces de rede para pods, definindo a variável `ENABLE_POD_ENI` como `true` no DaemonSet `aws-node`. Depois que essa configuração estiver definida como `true`, para cada nó no cluster, o complemento cria um recurso personalizado `cninode`. O controlador de recursos da VPC cria e anexa uma interface de rede especial chamada *Interface de rede* com a descrição `aws-k8s-trunk-eni`.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
```
**nota**
A interface de rede de tronco está incluída no número máximo de interfaces de rede suportadas pelo tipo de instância. Para obter uma lista do número máximo de interfaces de rede com suporte por cada tipo de instância, consulte [IP addresses per network interface per instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) (Endereços IP por interface de rede por tipo de instância) no *Guia do usuário do Amazon EC2*. Se o nó já tiver o número máximo de interfaces de rede padrão anexadas a ele, o controlador de recursos da VPC reservará um espaço. Você terá que reduzir a escala verticalmente dos pods em execução o suficiente para que o controlador desconecte e exclua uma interface de rede padrão, crie a interface de rede tronco e anexe-a à instância.
1. Você pode ver quais de seus nós possuem um recurso personalizado do `CNINode` com o comando a seguir. Se `No resources found` for retornado, aguarde alguns segundos e tente de novo. A etapa anterior requer a reinicialização do plug-in CNI da Amazon VPC para pods do Kubernetes, o que leva alguns segundos.
```
kubectl get cninode -A
NAME FEATURES
ip-192-168-64-141.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
ip-192-168-7-203.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
```
Se você estiver usando versões do VPC CNI anteriores a `1.15`, rótulos de nós foram usados em vez do recurso `CNINode` personalizado. Você pode ver quais do seus nós têm o rótulo de nó `aws-k8s-trunk-eni` definido como `true` com o comando a seguir. Se `No resources found` for retornado, aguarde alguns segundos e tente de novo. A etapa anterior requer a reinicialização do plug-in CNI da Amazon VPC para pods do Kubernetes, o que leva alguns segundos.
```
kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
```
Depois que a interface de rede tronco for criada, os pods receberão endereços IP secundários das interfaces de rede tronco ou padrão. A interface de tronco é excluída automaticamente se o nó for excluído.
Quando você implanta um grupo de segurança para um pod em uma etapa posterior, o controlador de recursos da VPC cria uma interface de rede especial denominada *interface de rede de ramificação*, com uma descrição de `aws-k8s-branch-eni`, e associa os grupos de segurança a ela. As interfaces de rede da ramificação são criadas como um adicional para as interfaces de rede padrão e de tronco conectadas ao nó.
Se você estiver usando uma investigação de atividade ou de preparação, também precisará desabilitar o *TCP early demux*, de modo que o `kubelet` possa se conectar aos pods em interfaces de rede de ramificação usando o TCP. Para desativar o *TCP early demux*, execute o seguinte comando:
```
kubectl patch daemonset aws-node -n kube-system \
-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
```
**nota**
Se você estiver usando o plug-in CNI `1.11.0` ou mais recente da Amazon VPC para o complemento do Kubernetes e definir `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, conforme descrito na próxima etapa, não será necessário executar o comando anterior.
1. Se o cluster usar `NodeLocal DNSCache`, ou caso deseje usar a política de rede do Calico com os pods que têm seus próprios grupos de segurança, ou caso tenha serviços do Kubernetes do tipo `NodePort` e `LoadBalancer` que usam destinos de instâncias com uma `externalTrafficPolicy` definida como `Local` para os pods aos quais deseja atribuir grupos de segurança, você deverá estar usando a versão `1.11.0` ou mais recente do complemento do plug-in CNI da Amazon VPC para Kubernetes e habilitar a seguinte configuração:
```
kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
```
IMPORTANTE: **as regras do grupo de segurança dos pods não são aplicadas ao tráfego entre os pods ou entre os pods e serviços, como `kubelet` ou `nodeLocalDNS`, que estão no mesmo nó. Os pods que usam grupos de segurança diferentes no mesmo nó não podem se comunicar porque estão configurados em sub-redes diferentes, e o roteamento está desativado entre essas sub-redes. ** O tráfego de saída dos pods para endereços fora da VPC é o endereço de rede convertido no endereço IP da interface de rede primária da instância (a menos que você também tenha definido `AWS_VPC_K8S_CNI_EXTERNALSNAT=true`). Para esse tráfego, as regras nos grupos de segurança da interface de rede primária são usadas, e não as regras nos grupos de segurança do pod. \$1\$1 Para que essa configuração seja aplicada a pods existentes, é necessário reiniciar os pods ou os nós em que esses pods estejam sendo executados.
1. Para saber como usar uma política de grupos de segurança no pod, consulte [Usar uma política para grupos de segurança para um pod do Amazon EKS](sg-pods-example-deployment.md).
# Usar uma política para grupos de segurança para um pod do Amazon EKS
Para usar grupos de segurança em pods, é necessário ter um grupo de segurança existente. As etapas a seguir mostram como usar a política de grupo de segurança para um pod. A menos que indicado de outra forma, conclua todas as etapas no mesmo terminal, pois são utilizadas nas etapas a seguir variáveis que não persistem entre terminais.
Caso tenha um pod com instâncias do Amazon EC2, você deverá configurar o plug-in antes de usar esse procedimento. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para Kubernetes de grupos de segurança para pods do Amazon EKS](security-groups-pods-deployment.md).
1. Crie um namespace do Kubernetes no qual implantar recursos do . Você pode substituir *my-namespace* pelo nome de um namespace que deseje usar.
```
kubectl create namespace my-namespace
```
1. Implante uma `SecurityGroupPolicy` do Amazon EKS no cluster.
1. Copie o conteúdo a seguir para o seu dispositivo. Você pode substituir *podSelector* por `serviceAccountSelector` se preferir selecionar pods com base em rótulos de conta de serviço. É preciso especificar um seletor ou outro. Um `podSelector` vazio (exemplo: `podSelector: {}`) seleciona todos os pods no namespace. Você pode alterar *my-role* para o nome do seu perfil. Uma `serviceAccountSelector` vazia seleciona todas as contas de serviço no namespace. Você pode substituir *my-security-group-policy* por um nome para a `SecurityGroupPolicy` e *my-namespace* pelo namespace no qual você deseja criar a `SecurityGroupPolicy`.
Você deve substituir *my\$1pod\$1security\$1group\$1id* pelo ID de um grupo de segurança existente. Se você ainda não tiver um grupo de segurança, deverá criar um. Para obter mais informações, consulte [Grupos de segurança do Amazon EC2 para instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) no [Guia do usuário do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). Você deve especificar de 1 a 5 IDs de grupo de segurança. Se você especificar mais de um ID, a combinação de todas as regras em todos os grupos de segurança será efetiva para os pods selecionados.
```
cat >my-security-group-policy.yaml <sample-application.yaml <
my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal
```
**nota**
Tente essas dicas se houver pods presos.
Se houver pods presos no estado `Waiting`, execute `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace `. Se você observar `Insufficient permissions: Unable to create Elastic Network Interface.`, confirme se adicionou a política do IAM à função de cluster do IAM em uma etapa anterior.
Se houver pods presos no estado `Pending`, verifique se o tipo de instância do nó está listado em [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go) e se o resultado da multiplicação do número máximo de interfaces de rede de ramificação compatíveis com o tipo de instância pelo número de nós do grupo de nós ainda não foi atingido. Por exemplo, um `m5.large` suporta nove interfaces de rede de ramificação. Se o grupo de nós tiver cinco nós, um máximo de 45 interfaces de rede de ramificação poderá ser criado para o grupo de nós. O 46.º pod que você tentar implantar ficará no estado `Pending` até que outro pod que tenha grupos de segurança associados seja excluído.
Se você executar `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` e ver uma mensagem semelhante à seguinte, ela pode ser ignorada com segurança. Esta mensagem poderá aparecer quando o plug-in CNI da Amazon VPC para Kubernetes tentar configurar a rede de host e falhar enquanto a interface de rede estiver sendo criada. O plugin CNI registra esse evento até que a interface de rede seja criada.
```
Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for Pod "my-deployment-5df6f7687b-4fbjm": networkPlugin
cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container
```
Você não pode exceder o número máximo de pods que podem ser executados no tipo de instância. Para obter uma lista do número máximo de pods que você pode executar em cada tipo de instância, consulte [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) no GitHub. Quando você exclui um pod que tenha grupos de segurança associados ou exclui o nó em que o pod está sendo executado, o controlador de recursos da VPC exclui a interface de rede de ramificação. Se você excluir um cluster com pods usando pods para grupos de segurança, o controlador não excluirá as interfaces de rede de ramificação, portanto, será necessário excluí-las você mesmo. Para obter mais informações sobre como excluir interfaces de rede, consulte [Interfaces de rede elásticas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#delete_eni) no Guia do usuário do Amazon EC2.
1. Em um terminal à parte, faça shell em um dos pods. Para o restante do tópico, esse terminal é indicado como `TerminalB`. Substitua *5df6f7687b-4fbjm* pelo ID de um dos pods exibidos no resultado da etapa anterior.
```
kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
```
1. No shell em `TerminalB`, confirme se a aplicação de amostra funciona.
```
curl my-app
```
Veja abaixo um exemplo de saída.
```
Welcome to nginx!
[...]
```
Você recebeu a saída porque todos os pods que executam a aplicação estão associados ao grupo de segurança que você criou. Esse grupo contém uma regra que permite todo o tráfego entre todos os pods aos quais o grupo de segurança está associado. O tráfego DNS pode sair desse grupo de segurança para o grupo de segurança do cluster, que está associado aos seus nós. Os nós estão executando os pods do CoreDNS, para os quais seus pods fizeram uma pesquisa de nome.
1. No `TerminalA`, remova as regras de grupo de segurança que permitem a comunicação DNS com o grupo de segurança de cluster do grupo de segurança. Se você não tiver adicionado as regras de DNS ao grupo de segurança de cluster em uma etapa anterior, substitua *\$1my\$1cluster\$1security\$1group\$1id* pelo ID do grupo de segurança no qual as regras foram criadas.
```
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
```
1. No `TerminalB`, tente acessar a aplicação novamente.
```
curl my-app
```
Veja abaixo um exemplo de saída.
```
curl: (6) Could not resolve host: my-app
```
A tentativa falha porque o pod não é mais capaz de acessar os pods do CoreDNS, que têm o grupo de segurança do cluster associado. O grupo de segurança do cluster não tem mais as regras de grupo de segurança que permitem a comunicação DNS do grupo de segurança associado ao pod.
Caso tente acessar a aplicação usando os endereços IP retornados para um dos pods em uma etapa anterior, você ainda receberá uma resposta, pois todas as portas são permitidas entre os pods que têm o grupo de segurança associado a eles, e uma pesquisa de nome não é necessária.
1. Quando você terminar os testes, poderá remover o exemplo de política de grupo de segurança, a aplicação e o grupo de segurança criados. Execute os comandos a seguir no `TerminalA`.
```
kubectl delete namespace my-namespace
aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id
wait
sleep 45s
aws ec2 delete-security-group --group-id $my_pod_security_group_id
```
# Anexação de várias interfaces de rede aos pods
Por padrão, o plug-in CNI da Amazon VPC atribui um endereço IP a cada pod. Esse endereço IP é anexado a uma *interface de rede elástica* que gerencia todo o tráfego de entrada e saída do pod. Para aumentar a largura de banda e a performance de taxa de pacotes por segundo, é possível usar o *recurso Multi-NIC* da CNI da VPC para configurar um pod com várias interfaces de rede. Um pod com várias interfaces de rede é um único pod do Kubernetes que usa múltiplas interfaces de rede (e múltiplos endereços IP). Ao executar um pod com várias interfaces de rede, é possível distribuir o tráfego da aplicação em várias interfaces de rede usando conexões simultâneas. Isso é especialmente útil em casos de uso de Inteligência Artificial (IA), Machine Learning (ML) e Computação de Alta Performance (HPC).
O diagrama a seguir mostra um pod com várias hospedagens em execução em um nó de processamento com várias placas de interface de rede (NICs) em uso.
![\[Um pod com hospedagem múltipla com duas interfaces de rede conectadas, uma interface de rede com ENA e uma interface de rede com ENA e EFA\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/multi-homed-pod.png)
## Contexto
No Amazon EC2, uma *interface de rede elástica* é um componente lógico de redes em uma VPC que representa uma placa de rede virtual. Para muitos tipos de instância do EC2, as interfaces de rede compartilham uma única placa de interface de rede (NIC) no hardware. Essa única NIC tem uma largura de banda máxima e uma taxa de pacotes por segundo.
Se o recurso Multi-NIC estiver habilitado, a CNI da VPC não atribuirá endereços IP em massa, o que acontece por padrão. Em vez disso, a CNI da VPC atribuirá um endereço IP a uma interface de rede em cada placa de rede sob demanda quando um novo pod for iniciado. Esse comportamento reduz a taxa de esgotamento de endereço IP, que é aumentada com o uso de pods com várias hospedagens. Como a CNI da VPC está atribuindo endereços IP sob demanda, os pods podem levar mais tempo para serem iniciados em instâncias com o recurso multi-NIC habilitado.
## Considerações
+ Certifique-se de que seu cluster do Kubernetes esteja executando a versão `1.20.0` ou posterior da CNI da VPC. O recurso Multi-NIC só está disponível na versão `1.20.0` ou posterior da CNI da VPC.
+ Ative a variável de ambiente `ENABLE_MULTI_NIC` no plug-in CNI da VPC. É possível executar o comando a seguir para definir a variável e iniciar uma implantação do DaemonSet.
+ `kubectl set env daemonset aws-node -n kube-system ENABLE_MULTI_NIC=true`
+ Certifique-se de criar nós de processamento que tenham várias placas de interface de rede (NICs). Para obter uma lista de instâncias do EC2 que tenham várias placas de interface de rede, consulte [Placas de rede](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) no **Guia do usuário do Amazon EC2**.
+ Se o recurso Multi-NIC estiver habilitado, a CNI da VPC não atribuirá endereços IP em massa, o que acontece por padrão. Como a CNI da VPC está atribuindo endereços IP sob demanda, os pods podem levar mais tempo para serem iniciados em instâncias com o recurso multi-NIC habilitado. Para obter mais informações, consulte a seção anterior [Contexto](#pod-multi-nic-background).
+ Com o recurso Multi-NIC habilitado, os pods não têm várias interfaces de rede por padrão. Você deverá configurar cada workload para usar várias NICs. Adicione a anotação `k8s.amazonaws.com/nicConfig: multi-nic-attachment` às workloads que devam ter várias interfaces de rede.
### `IPv6`Considerações do
+ **Política do IAM personalizada**: para clusters `IPv6`, crie e use a seguinte política personalizada do IAM para a CNI da VPC. Essa política é específica para multi-NIC. Para obter mais informações gerais sobre o uso da CNI da VPC com clusters `IPv6`, consulte [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSCNIPolicyIPv6MultiNIC",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeInstances",
"ec2:AssignIpv6Addresses",
"ec2:DetachNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstanceTypes",
"ec2:UnassignIpv6Addresses",
"ec2:AttachNetworkInterface",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSCNIPolicyENITagIPv6MultiNIC",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:network-interface/*"
}
]
}
```
+ **Mecanismo de transição de `IPv6` não disponível**: se você usar o recurso de várias NICs, a CNI da VPC não atribuirá um endereço `IPv4` aos pods em um cluster `IPv6`. Caso contrário, a CNI da VPC atribuirá um endereço `IPv4` local de host a cada pod para que um pod possa se comunicar com recursos externos `IPv4` em outra Amazon VPC ou na Internet.
## Usage
Depois que o recurso Multi-NIC for habilitado na CNI da VPC e os pods do `aws-node` forem reiniciados, será possível configurar cada workload para ser de vários hospedeiros. A seguir há um exemplo de uma configuração de YAML com a anotação necessária:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-deployment
namespace: ecommerce
labels:
app: orders
spec:
replicas: 3
selector:
matchLabels:
app: orders
template:
metadata:
annotations:
k8s.amazonaws.com/nicConfig: multi-nic-attachment
labels:
app: orders
spec:
...
```
## Perguntas frequentes
### **1. O que é uma placa de interface de rede (NIC)?**
Uma placa de interface de rede (NIC), também chamada simplesmente de placa de rede, é um dispositivo físico que permite a conectividade de rede para o hardware de computação em nuvem subjacente. Nos servidores EC2 modernos, isso se refere à placa de rede Nitro. Uma Interface de Rede Elástica (ENI) é uma representação virtual dessa placa de rede subjacente.
Alguns tipos de instâncias do EC2 têm várias NICs para maior largura de banda e performance de taxa de pacotes. Para tais instâncias, é possível atribuir ENIs secundárias às placas de rede adicionais. Por exemplo, a ENI \$11 pode funcionar como a interface para a NIC conectada ao índice 0 da placa de rede, enquanto a ENI \$12 pode funcionar como a interface para a NIC conectada a um índice de placa de rede separado.
### **2. O que é um pod com vários hospedeiros?**
Um pod com vários hospedeiros é um único pod do Kubernetes com várias interfaces de rede (e, por implicação, vários endereços IP). Cada interface de rede do pod está associada a uma [Interface de Rede Elástica (ENI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html), e essas ENIs são representações lógicas de NICs separadas no nó de processamento subjacente. Com várias interfaces de rede, um pod com vários hospedeiros tem capacidade adicional de transferência de dados, o que também aumenta sua taxa de transferência de dados.
**Importante**
A CNI da VPC só pode configurar pods com vários hospedeiros em tipos de instâncias que tenham várias NICs.
### **3. Por que devo usar esse recurso?**
Se você precisar escalar a performance da rede em suas workloads baseadas em Kubernetes, é possível usar o recurso de várias NICs para executar pods com várias interfaces que interajam com todas as NICs subjacentes que tenham um dispositivo ENA conectado a elas. A utilização de placas de rede adicionais aumenta a capacidade de largura de banda e a performance da taxa de pacotes em suas aplicações, distribuindo o tráfego de aplicações em várias conexões simultâneas. Isso é especialmente útil em casos de uso de Inteligência Artificial (IA), Machine Learning (ML) e Computação de Alta Performance (HPC).
### **4. Como faço para usar esse recurso?**
1. Primeiro, você deve garantir que seu cluster do Kubernetes esteja usando a CNI da VPC versão 1.20 ou posterior. Para obter as etapas para atualizar a CNI da VPC como um complemento do EKS, consulte [Atualização do plug-in da CNI da Amazon VPC (complemento do Amazon EKS)](vpc-add-on-update.md).
1. Em seguida, você precisará habilitar o suporte a várias NICs na CNI do VPC usando a variável de ambiente `ENABLE_MULTI_NIC`.
1. Em seguida, você deverá se certificar de criar e unir nós que tenham várias placas de rede. Para obter uma lista de tipos de instâncias do EC2 que tenham várias placas de rede, consulte [Placas de rede](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) no *Guia do usuário do Amazon EC2*.
1. Por fim, você configura cada workload para usar várias interfaces de rede (pods de vários hospedeiros) ou usar uma única interface de rede.
### **5. Como configuro minhas workloads para usar várias NICs em um nó de processamento com suporte?**
Para usar pods com vários hospedeiros, você precisa adicionar a seguinte anotação: `k8s.amazonaws.com/nicConfig: multi-nic-attachment`. Isso anexará uma ENI de cada NIC na instância subjacente ao pod (mapeamento de um para muitos entre um pod e as NICs).
Se essa anotação estiver ausente, a CNI da VPC presumirá que o seu pod requer apenas uma interface de rede e atribuirá a ele um IP de uma ENI em qualquer NIC disponível.
### **6. Quais adaptadores de interface de rede são compatíveis com esse recurso?**
É possível usar qualquer adaptador de interface de rede se tiver pelo menos um ENA conectado à placa de rede subjacente para tráfego IP. Para obter mais informações sobre ENAs, consulte [Adaptador de Rede Elástica (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) no *Guia do usuário do Amazon EC2*.
Configurações de dispositivos de rede com suporte:
+ As interfaces **ENA** fornecem todos os atributos tradicionais de rede IP e roteamento necessários para oferecer suporte à rede IP para uma VPC. Para obter mais informações, consulte [Habilitação de redes aperfeiçoadas com ENA em instâncias do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html).
+ As interfaces **EFA** **(EFA** **com ENA)** fornecem o dispositivo ENA para redes IP e o dispositivo EFA para comunicação de baixa latência e alto throughput.
**Importante**
Se uma placa de rede tiver apenas um adaptador **somente EFA** conectado a ela, a CNI da VPC a ignorará ao provisionar a conectividade de rede para um pod com vários hospedeiros. No entanto, se você combinar um adaptador **somente EFA** com um adaptador **ENA** em uma placa de rede, a CNI da VPC também gerenciará as ENIs nesse dispositivo. Para usar interfaces somente EFA com clusters do EKS, consulte [Execute o treinamento de machine learning no Amazon EKS com o Elastic Fabric Adapter](node-efa.md).
### **7. Posso ver se um nó no meu cluster tem suporte para ENA?**
Sim, é possível usar a AWS CLI ou a API do EC2 para recuperar informações de rede sobre uma instância do EC2 no seu cluster. Isso fornece detalhes sobre se a instância tem ou não suporte para ENA. No exemplo a seguir, substitua `` pelo ID de um nó da instância do EC2.
AWSExemplo da CLI de :
```
aws ec2 describe-instances --instance-ids --query "Reservations[].Instances[].EnaSupport"
```
Resultado do exemplo:
```
[ true ]
```
### **8. Posso ver os diferentes endereços IP associados a um pod?**
Não, não de forma simples. No entanto, é possível usar o `nsenter` a partir do nó para executar ferramentas de rede comuns, como `ip route show`, e ver os endereços IP e as interfaces adicionais.
### **9. Posso controlar o número de interfaces de rede para meus pods?**
Não. Quando sua workload é configurada para usar várias NICs em uma instância com suporte, um único pod tem automaticamente um endereço IP de cada placa de rede na instância. Como alternativa, os pods de único hospedeiros terão uma interface de rede conectada a uma NIC na instância.
**Importante**
As placas de rede que tenham *apenas* um dispositivo **somente EFA** conectado a elas serão ignoradas pela CNI da VPC.
### **10. Posso configurar meus pods para usar uma NIC específica?**
Não, não há suporte para isso. Se um pod tiver a anotação relevante, a CNI da VPC o configurará automaticamente para usar cada NIC com um adaptador ENA no nó de processamento.
### **11. Esse recurso funciona com os outros recursos de rede da CNI da VPC?**
Sim, o recurso de várias NICs na CNI da VPC funciona tanto com *redes personalizadas* quanto com a *descoberta aprimorada de sub-redes*. No entanto, os pods com vários hospedeiros não usam sub-redes ou grupos de segurança personalizados. Em vez disso, a CNI da VPC atribui endereços IP e interfaces de rede aos pods com vários hospedeiros com a mesma configuração de sub-rede e grupo de segurança do nó. Para obter mais informações sobre redes personalizadas, consulte [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md).
O recurso de várias NICs na CNI da VPC não funciona e não pode ser combinado com *grupos de segurança para pods*.
### **12. Posso usar políticas de rede com esse recurso?**
Sim, é possível usar as políticas de rede do Kubernetes com várias NICs. As políticas de rede do Kubernetes restringem o tráfego de rede que entra e sai dos seus pods. Para obter mais informações sobre a aplicação de políticas de rede com a CNI da VPC, consulte [Limitar o tráfego do pod com políticas de rede do Kubernetes](cni-network-policy.md).
### **13. O suporte a várias NICs está ativado no Modo Automático do EKS?**
Não há suporte para várias NICs em clusters do Modo Automático do EKS.