Requisitos e considerações sobre a VPC e a sub-rede do Amazon EKS - Amazon EKS
Requisitos e considerações para VPCsRequisitos e considerações para sub-redesRequisitos e considerações de sub-redes

Requisitos e considerações sobre a VPC e a sub-rede do Amazon EKS

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 uma VPC para utilizar com o Amazon EKS, poderá criar uma utilizando um modelo AWS CloudFormation fornecido pelo Amazon EKS. Se você estiver criando um cluster local ou estendido no AWS Outposts, consulte Requisitos e considerações sobre a VPC e a sub-rede de clusters locais do Amazon EKS 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 AWS Management Console a partir da versão mais recente da versão AWS CLI, AWS CloudFormation e eksctl v0.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 disponibilidade us-west-2b e a quarta sub-rede está na Zona de disponibilidade us-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 CIDR IPv6 à 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 de DNS. 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 o 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
kubernetes.io/cluster/my-cluster owned

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 em sua descrição.

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 não podem residir no AWS Outposts, no AWS Wavelength ou em uma zona local da AWS. Porém, se você as tiver na VPC, poderá implantar nó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 IPv4 cluster, e um cluster com o valor de configuração IPv6 é referido como um IPv6 cluster.

Componente Somente endereços IPv4 Somente endereços IPv6 Endereços de pilha dupla
Endpoint público da API EKS Sim Não Não
Endpoint da VPC da API EKS Sim Não Não
Endpoint público da API EKS Auth Sim1 Sim1 Sim1
Endpoint da VPC da API EKS Auth Sim1 Sim1 Sim1
Endpoint público do cluster do EKS Sim Não Não
Endpoint privado do cluster do EKS Sim2 Sim2 Não
Sub-redes do cluster do EKS 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
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.

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 CIDR IPv6 e um bloco CIDR IPv4 associados à sub-rede. Para obter mais informações, consulte Associar um bloco CIDR IPv6 à sua sub-rede, no Guia do usuário da Amazon VPC. As tabelas de rotas associadas às sub-redes devem incluir rotas para endereços IPv4 e IPv6. Para obter mais informações, consulte Rotas, no Guia do usuário da Amazon VPC. Pods recebem apenas um endereço IPv6. Porém, as interfaces de rede que criadas pelo Amazon EKS para o seu cluster e os seus nós recebem um endereço IPv4 e um endereço IPv6.

  • 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 deve atribuir automaticamente endereços públicos IPv4 ou endereços IPv6. Se você implantar nós em uma sub-rede privada que tenha um bloco CIDR IPv6 associado, a sub-rede privada também deverá atribuir endereços IPv6 automaticamente. Se você utilizou um modelo de AWS CloudFormation do Amazon EKS para implantar a VPC após 26 de março de 2020, essa configuração estará habilitada. 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 saber mais, 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 da 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. Endpoints de VPC são necessários para todos os Serviços da AWS com os quais seus nós e Pods precisam se comunicar. Exemplos incluem Amazon ECR, Elastic Load Balancing, Amazon CloudWatch, AWS Security Token Service e 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 da AWS oferecem suporte a endpoints de VPC. Para mais informações, consulte O que é o AWS PrivateLink? e Serviços da AWS que se integram ao AWS PrivateLink. Para obter uma lista de mais requisitos para o Amazon EKS, consulte Requisitos de clusters privados.

  • 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
kubernetes.io/cluster/my-cluster shared

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. Versões 2.1.1 ou anteriores do AWS Load Balancer Controller exigem essa tag. 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ê tiver implantado uma VPC usando eksctl ou qualquer um dos modelos de VPC AWS CloudFormation do Amazon EKS, o seguinte será aplicável:

  • 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:

Requisitos e considerações de sub-redes

Você pode usar Compartilhamento de VPC para compartilhar sub-redes com outras contas da AWS dentro da mesma AWS Organizations. 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:

  • 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 Rede personalizada para pods.

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.