Exibir os requisitos de rede do Amazon EKS para VPC e sub-redes
Ao criar um cluster, você especifica uma VPC e pelo menos duas sub-redes em diferentes zonas de disponibilidade. Este tópico fornece uma visão geral dos requisitos e das considerações específicos do Amazon EKS para a VPC e as sub-redes que você utiliza com o cluster. Se você não tiver um VPC para usar com o Amazon EKS, poderá Criar uma Amazon VPC para o cluster do Amazon EKScriar um usando um modelo AWS CloudFormation fornecido pelo Amazon EKS. Se estiver criando um cluster local ou estendido em AWS Outposts, consulte Criar um VPC e sub-redes para clusters do Amazon EKS em AWS Outposts em vez deste tópico.
Requisitos e considerações para VPCs
Quando você cria um cluster, a VPC especificada deve atender aos requisitos e considerações a seguir:
-
A VPC deverá ter uma quantidade suficiente de endereços IP disponíveis para o cluster, todos os nós e outros recursos do Kubernetes que você desejar criar. Se a VPC que você deseja utilizar não tiver uma quantidade suficiente de endereços IP, tente aumentar a quantidade de endereços IP disponíveis.
Você pode fazer isso atualizando a configuração do cluster para alterar as sub-redes e grupos de segurança que o cluster utiliza. Você pode atualizar a partir do AWS Management Console, da versão mais recente da AWS CLI, do AWS CloudFormation e do
eksctl
versãov0.164.0-rc.0
ou posterior. Talvez seja necessário fazer isso para fornecer às sub-redes mais endereços IP disponíveis para atualizar com sucesso uma versão de cluster.Importante
Todas as sub-redes adicionadas devem estar no mesmo conjunto de AZs fornecido na ocasião da criação do cluster. As novas sub-redes devem atender a todos os outros requisitos, por exemplo, devem ter endereços IP suficientes.
Por exemplo, suponha que você tenha feito um cluster e especificado quatro sub-redes. Na ordem em que você as especificou, a primeira sub-rede está na Zona de disponibilidade
us-west-2a
, a segunda e a terceira sub-redes estão na Zona de disponibilidadeus-west-2b
e a quarta sub-rede está na Zona de disponibilidadeus-west-2c
. Se quiser alterar as sub-redes, você deverá fornecer pelo menos uma sub-rede em cada uma das três zonas de disponibilidade, e as sub-redes deverão estar na mesma VPC que as sub-redes originais.Se você precisar de mais endereços IP do que os blocos CIDR na VPC, você pode adicionar mais blocos CIDR associando blocos adicionais de Encaminhamento Entre Domínios Sem Classificação (CIDR) à sua VPC. É possível associar blocos CIDR privados (RFC 1918) e públicos (não RFC 1918) à sua VPC antes ou depois de criar o cluster. Um cluster pode precisar de até cinco horas para que um bloco CIDR associado a uma VPC seja reconhecido.
Você pode conservar a utilização do endereço IP usando um gateway de trânsito com uma VPC de serviços compartilhados. Para obter mais informações, consulte Isolated VPCs with shared services (VPCs isoladas com serviços compartilhados) e Amazon EKS VPC routable IP address conservation patterns in a hybrid network
(Padrões de conservação de endereço IP roteáveis da VPC no Amazon EKS em uma rede híbrida). -
Se quiser que o Kubernetes atribua endereços
IPv6
a Pods e serviços, associe um bloco CIDRIPv6
à VPC. Para obter mais informações, consulte Associar um bloco CIDR IPv6 à sua VPC no Guia do usuário da Amazon VPC. -
A VPC deve ter suporte de nomes de host de
DNS
e resolução deDNS
. Caso contrário, os nós não poderão se registrar no seu cluster. Para mais informações, consulte Atributos de DNS para sua VPC, no Guia do usuário da Amazon VPC. -
A VPC pode exigir endpoints da VPC usando AWS PrivateLink. Para ter mais informações, consulte Requisitos e considerações para sub-redes.
Se você criou um cluster com o Kubernetes 1.14
ou anterior, o Amazon EKS adicionou a seguinte tag à VPC:
Chave | Valor |
---|---|
|
|
Essa etiqueta foi utilizada apenas pelo Amazon EKS. É possível remover a etiqueta sem afetar os serviços. Ela não é utilizada com clusters que são da versão 1.15
ou posterior.
Requisitos e considerações para sub-redes
Quando você cria um cluster, o Amazon EKS cria de 2 a 4 interfaces de rede elástica nas sub-redes especificadas. Essas interfaces permitem a comunicação entre seu cluster e sua VPC. Essa interfaces de redes também habilitam recursos do Kubernetes, como kubectl exec
e kubectl logs
. Cada interface de rede criada pelo Amazon EKS tem o texto Amazon EKS
cluster-name
in its description.
O Amazon EKS é capaz de criar suas interfaces de rede em qualquer sub-rede especificada ao criar um cluster. É possível alterar em quais sub-redes o Amazon EKS cria suas interfaces de rede depois que o cluster é criado. Quando você atualiza a versão do Kubernetes de um cluster, o Amazon EKS exclui as interfaces de rede originais ele criou e cria novas interfaces de rede. Essas interfaces podem ser criadas nas mesmas sub-redes que a das interfaces de rede originais ou em sub-redes diferentes das originais. Para controlar quais interfaces de rede de sub-redes são criadas, você poderá limitar o número de sub-redes especificadas a apenas duas ao criar um cluster ou atualizar as sub-redes depois de criar o cluster.
Requisitos de sub-redes para clusters
As sub-redes que você especifica ao criar ou atualizar um cluster devem atender aos requisitos a seguir:
-
As sub-redes devem ter no mínimo seis endereços IP para uso pelo Amazon EKS. Porém, recomendamos no mínimo 16 endereços IP.
-
As sub-redes devem estar em ao menos duas diferentes zonas de disponibilidade.
-
As sub-redes não podem residir no AWS Outposts ou no AWS Wavelength. Porém, se você as tiver na VPC, poderá implantar Fazer a manutenção dos nós por conta própria com nós autogerenciadosnós autogerenciados e recursos do Kubernetes nesses tipos de sub-redes.
-
As sub-redes podem ser do tipo público ou privado. Convém, se possível, especificar sub-redes privadas. Uma sub-rede pública tem uma tabela de rotas que inclui uma rota para um gateway da Internet, enquanto uma sub-rede privada tem uma tabela de rotas que não inclui uma rota para um gateway da Internet.
-
As sub-redes não podem residir nas seguintes zonas de disponibilidade:
Região da AWS Nome da região IDs de zona de disponibilidade não permitidas us-east-1
Leste dos EUA (N. da Virgínia)
use1-az3
us-west-1
Oeste dos EUA (N. da Califórnia)
usw1-az2
ca-central-1
Canadá (Central)
cac1-az3
Uso da família de endereços IP por componente
A tabela a seguir contém a família de endereços IP usada por cada componente do Amazon EKS. É possível usar uma conversão de endereços de rede (NAT) ou outros sistemas de compatibilidade para efetuar uma conexão com esses componentes usando endereços IP de origem em famílias com o valor "No" para uma entrada de tabela.
A funcionalidade pode diferir dependendo da configuração IP family (ipFamily
) do cluster. Essa configuração altera o tipo de endereço IP usado para o bloco de CIDR que o Kubernetes atribui para Services. Um cluster com o valor de configuração IPv4 é referido como um cluster de IPv4, e um cluster com o valor de configuração IPv6 é referido como um cluster de IPv6.
Componente | Endereços IPv4 | Endereços IPv6 | Endereços de pilha dupla |
---|---|---|---|
Endpoint público da API EKS |
Sim 1,3 |
Sim 1,3 |
Sim 1,3 |
Endpoint da VPC da API EKS |
Sim |
Não |
Não |
Endpoint público da API do EKS Auth (EKS Pod Identity) |
Sim1 |
Sim1 |
Sim1 |
Endpoint da VPC da API do EKS Auth (EKS Pod Identity) |
Sim1 |
Sim1 |
Sim1 |
Endpoint público do cluster Kubernetes |
Sim |
Não |
Não |
Endpoint privado do cluster Kubernetes |
Sim |
Não |
Não |
Endpoint público do cluster Kubernetes |
Sim1,4 |
Sim1,4 |
Sim4 |
Endpoint privado do cluster Kubernetes |
Sim1,4 |
Sim1,4 |
Sim4 |
Sub-redes do cluster do Kubernetes |
Sim2 |
Não |
Sim2 |
Endereços IP primários do nó |
Sim2 |
Não |
Sim2 |
Intervalo de CIDR do cluster para endereços IP do Service |
Sim2 |
Sim2 |
Não |
Endereços IP do Pod do plug-in CNI da VPC |
Sim2 |
Sim2 |
Não |
URLs do emissor OIDC IRSA |
Sim 1,3 |
Sim 1,3 |
Sim 1,3 |
nota
1 O endpoint é uma pilha dupla com endereços IPv4
e IPv6
. As aplicações externas à AWS, os nós do cluster e os pods dentro do cluster podem obter acesso a esse endpoint usando IPv4
ou IPv6
.
2 Você escolhe entre um cluster IPv4
e um cluster IPv6
na configuração IP family (ipFamily
) do cluster ao criar um cluster, e isso não pode ser alterado. Em vez disso, você deve escolher uma configuração diferente ao criar outro cluster e migrar as workloads.
3 O endpoint de pilha dupla foi introduzido em agosto de 2024. Para usar os endpoints de pilha dupla com a AWS CLI, consulte a configuração de endpoints de pilha dupla e FIPS no Guia de referência de SDKs e ferramentas do AWS. A seguinte lista contém os novos endpoints:
- Endpoint público da API EKS
-
eks.
region
.api.aws - URLs do emissor OIDC IRSA
-
oidc-eks.
region
.api.aws
4 O endpoint de cluster de pilha dupla foi introduzido em outubro de 2024. O EKS cria o endpoint a seguir para novos clusters criados após essa data e que selecionam IPv6
na configuração da família de IPs (ipFamily) do cluster:
- Endpoint público/privado do cluster EKS
-
eks-cluster.
region
.api.aws
Requisitos de sub-redes para nós
É possível implantar nós e recursos do Kubernetes nas mesmas sub-redes que você especifica ao criar o cluster. Porém, isso não é necessário. Isso porque também é possível implantar nós e recursos do Kubernetes em sub-redes que você não especificou quando criou o cluster. Se você implantar nós em sub-redes diferentes, o Amazon EKS não criará interfaces de rede de cluster nelas. Qualquer sub-rede na qual você implante nós e recursos do Kubernetes deve atender aos seguintes requisitos:
-
As sub-redes devem ter endereços IP disponíveis suficientes para implantar todos os nós e recursos do Kubernetes.
-
Se quiser que o Kubernetes atribua endereços
IPv6
a Pods e serviços, você deverá ter um bloco CIDRIPv6
e um bloco CIDRIPv4
associados à sub-rede. Para obter mais informações, consulte Associar um bloco CIDR IPv6 à sua sub-rede no Guia do usuário do Amazon VPC. As tabelas de rotas associadas às sub-redes devem incluir rotas para endereçosIPv4
eIPv6
. Para obter mais informações, consulte Rotas, no Guia do usuário da Amazon VPC. Pods recebem apenas um endereçoIPv6
. Porém, as interfaces de rede que criadas pelo Amazon EKS para o seu cluster e os seus nós recebem um endereçoIPv4
e um endereçoIPv6
. -
Se precisar de acesso de entrada pela Internet aos Pods, certifique-se de ter pelo menos uma sub-rede pública com endereços IP disponíveis suficientes para implantar balanceadores de carga e ingressos. Você pode implantar balanceadores de carga em sub-redes públicas. Balanceadores de carga podem balancear carga para Pods em sub-redes privadas ou públicas. Convém implantar nós em sub-redes privadas, se possível.
-
Se você planeja implantar nós em uma sub-rede pública, esta deverá atribuir automaticamente endereços públicos
IPv4
ou endereçosIPv6
. Se você implantar nós em uma sub-rede privada que tenha um bloco CIDRIPv6
associado, esta também deverá atribuir endereçosIPv6
automaticamente. Se você usou um modelo Criar uma Amazon VPC para o cluster do Amazon EKSAmazon EKS AWS CloudFormation para implantar sua VPC após 26 de março de 2020, essa configuração está ativada. Se você utilizou os modelos para implantar sua VPC antes dessa data ou se utilizar sua própria VPC, deverá habilitar essa configuração manualmente. Para obter mais informações, consulte Modificar o atributo de endereçamento IPv4 público para sua sub-rede e Modificar o atributo de endereçamento IPv6 para sua sub-rede no Guia do usuário do Amazon VPC. -
Se a sub-rede na qual você implanta um nó for privada e sua tabela de rotas não incluir uma rota para um dispositivo de conversão de endereços de rede (NAT) (
IPv4
) ou um gateway somente de saída (IPv6
), adicione endpoints de VPC usando o AWS PrivateLink à sua VPC. Os endpoints de VPC são necessários para todos os serviços AWS com os quais seus nós e Pods precisam se comunicar. Os exemplos incluem o Amazon ECR, o Elastic Load Balancing, o Amazon CloudWatch, o AWS Security Token Service e o Amazon Simple Storage Service (Amazon S3). O endpoint deve incluir a sub-rede na qual os nós se encontram. Nem todos os serviços do AWS oferecem suporte a endpoints de VPC. Para obter mais informações, consulte O que é o AWS PrivateLink? e AWS serviços que se integram ao AWS PrivateLink. Para obter uma lista de mais requisitos para o Amazon EKS, consulte Implementar clusters privados com acesso limitado à internet. -
Se quiser implantar balanceadores de carga em uma sub-rede, esta deve ter a seguinte etiqueta:
-
Sub-redes privadas
Chave Valor kubernetes.io/role/internal-elb
1
-
Sub-redes públicas
Chave Valor kubernetes.io/role/elb
1
-
Quando um cluster do Kubernetes da versão 1.18
e anteriores foi criado, o Amazon EKS adicionou a tag a seguir a todas as sub-redes que foram especificadas.
Chave | Valor |
---|---|
|
|
Quando você cria um cluster do Kubernetes agora, o Amazon EKS não adiciona a tag às sub-redes. Se a tag estava em sub-redes usadas por um cluster que era previamente uma versão anterior à 1.19
, a tag não foi removida automaticamente das sub-redes quando o cluster foi atualizado para uma versão mais recente. A versão 2.1.1
ou anterior do Direcionar o tráfego da Internet com o AWS Load Balancer Controller AWS Load Balancer Controller exige essa etiqueta. Se você estiver usando uma versão mais recente do controlador do balanceador de carga, poderá remover a tag sem interromper seus serviços.
Se você implantou uma VPC usando eksctl
ou qualquer um dos modelos de VPC do Amazon EKS AWS CloudFormation, aplica-se o seguinte:
-
Em ou após 26 de março de 2020: os endereços
IPv4
públicos serão atribuídos automaticamente por sub-redes públicas aos novos nós implantados em sub-redes públicas. -
Em ou antes de 26 de março de 2020: os endereços
IPv4
públicos não serão atribuídos automaticamente por sub-redes públicas aos novos nós implantados em sub-redes públicas.
Essa alteração afeta os novos grupos de nós implantados em sub-redes públicas das seguintes maneiras:
-
Grupos de nós gerenciados: se o grupo de nós for implantado em uma sub-rede pública em ou após 22 de abril de 2020, a atribuição automática de endereços IP públicos deverá ser habilitada para a sub-rede pública. Para obter mais informações, consulte Modificar o atributo de endereçamento IPv4 público para a sub-rede.
-
Grupos de nós autogerenciados de Linux, Windows ou Arm: se o grupo de nós for implantado em uma sub-rede pública em ou após 26 de março de 2020, a atribuição automática de endereços IP públicos deverá ser ativada para a sub-rede pública. Caso contrário, os nós deverão ser iniciados com um endereço IP público. Para obter mais informações, consulte Modificar o atributo de endereçamento IPv4 público para a sub-rede ou Atribuir um endereço IPv4 público durante a execução da instância.
Requisitos e considerações de sub-redes
Você pode usar o compartilhamento de VPC para compartilhar sub-redes com outras contas AWS dentro das mesmas organizações AWS. Você pode criar clusters do Amazon EKS em sub-redes compartilhadas com as seguintes considerações:
-
O proprietário da sub-rede VPC deve compartilhar uma sub-rede com uma conta de participante antes que essa conta possa criar nela um cluster Amazon EKS.
-
Você não pode iniciar recursos usando o grupo de segurança padrão da VPC, pois ele pertence ao proprietário. Além disso, os participantes não podem iniciar recursos usando grupos de segurança de propriedade de outros participantes ou do proprietário.
-
Em uma sub-rede compartilhada, o participante e o proprietário controlam separadamente os grupos de segurança na respectiva conta. O proprietário da sub-rede pode visualizar esses grupos de segurança criados pelos participantes, mas não pode realizar neles nenhuma ação. Se o proprietário da sub-rede quiser remover ou modificar esses grupos de segurança, o participante que criou o grupo de segurança deve realizar a ação.
-
Se um cluster for criado por um participante, as seguintes considerações se aplicam:
-
A perfil do IAM do cluster e perfis do IAM do nó devem ser criados na conta. Para ter mais informações, consulte Função do IAM do cluster do Amazon EKS e Perfil do IAM em nós do Amazon EKS.
-
Todos os nós devem ser criados pelo mesmo participante, incluindo grupos de nós gerenciados.
-
-
O proprietário da VPC compartilhada não pode visualizar, atualizar ou excluir um cluster criado por um participante na sub-rede compartilhada. Isso é além dos recursos da VPC aos quais cada conta tem acesso diferente. Para obter mais informações, consulte Responsabilidades e permissões para proprietários e participantes no Manual do usuário do Amazon VPC.
-
Se usar o atributo de rede personalizada do Amazon VPC CNI plugin for Kubernetes, você precisará usar os mapeamentos de ID da zona de disponibilidade listados na conta do proprietário para criar cada
ENIConfig
. Para ter mais informações, consulte Implementar pods em sub-redes alternadas com rede personalizada.
Para obter informações sobre o compartilhamento de sub-rede da VPC, consulte Compartilhar sua VPC com outras contas no Manual do usuário do Amazon VPC.