As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Considerações sobre VPC e sub-rede
dica
Explore as
Operar um cluster EKS exige conhecimento da rede VPC da AWS, além da rede Kubernetes.
Recomendamos que você entenda os mecanismos de comunicação do plano de controle do EKS antes de começar a projetar sua VPC ou implantar clusters em VPCs existentes.
Consulte as considerações sobre o Cluster VPC e sobre o grupo de segurança do Amazon EKS ao arquitetar uma VPC e sub-redes para serem usadas com o EKS.
Visão geral do
Arquitetura de cluster EKS
Um cluster EKS consiste em duas VPCs:
-
Uma AWS-managed VPC que hospeda o plano de controle do Kubernetes. Essa VPC não aparece na conta do cliente.
-
Uma VPC gerenciada pelo cliente que hospeda os nós do Kubernetes. É aqui que os contêineres são executados, bem como outras infraestruturas da AWS gerenciadas pelo cliente, como balanceadores de carga usados pelo cluster. Essa VPC aparece na conta do cliente. Você precisa criar uma VPC gerenciada pelo cliente antes de criar um cluster. O eksctl cria uma VPC se você não fornecer uma.
Os nós na VPC do cliente precisam da capacidade de se conectar ao endpoint do servidor de API gerenciado na AWS VPC. Isso permite que os nós se registrem no plano de controle do Kubernetes e recebam solicitações para executar pods de aplicativos.
Os nós se conectam ao plano de controle do EKS por meio de (a) um endpoint público do EKS ou (b) de uma interface de rede Cross-Account elástica (X-ENI) gerenciada pelo EKS. Quando um cluster é criado, você precisa especificar pelo menos duas sub-redes VPC. O EKS coloca um X-ENI em cada sub-rede especificada durante a criação do cluster (também chamada de sub-redes de cluster). O servidor da API Kubernetes usa esses Cross-Account ENIs para se comunicar com os nós implantados nas sub-redes VPC do cluster gerenciado pelo cliente.
Quando o nó é iniciado, o script de bootstrap do EKS é executado e os arquivos de configuração do nó Kubernetes são instalados. Como parte do processo de inicialização em cada instância, os agentes de tempo de execução do contêiner, kubelet e agentes de node do Kubernetes são iniciados.
Para registrar um nó, o Kubelet entra em contato com o endpoint do cluster Kubernetes. Ele estabelece uma conexão com o endpoint público fora da VPC ou com o endpoint privado dentro da VPC. O Kubelet recebe instruções da API e fornece atualizações de status e pulsações para o endpoint regularmente.
Comunicação do plano de controle EKS
O EKS tem duas maneiras de controlar o acesso ao endpoint do cluster. O controle de acesso ao endpoint permite que você escolha se o endpoint pode ser acessado pela Internet pública ou somente por meio de sua VPC. Você pode ativar o endpoint público (que é o padrão), o endpoint privado ou os dois ao mesmo tempo.
A configuração do endpoint da API do cluster determina o caminho que os nós percorrem para se comunicar com o plano de controle. Observe que essas configurações de endpoint podem ser alteradas a qualquer momento por meio do console EKS ou da API.
Endpoint público
Esse é o comportamento padrão para novos clusters do Amazon EKS. Quando somente o endpoint público do cluster está habilitado, as solicitações da API Kubernetes que se originam da VPC do seu cluster (como o node de trabalho para controlar a comunicação do plano) saem da VPC, mas não da rede da Amazon. Para que os nós se conectem ao plano de controle, eles devem ter um endereço IP público e uma rota para um gateway da Internet ou uma rota para um gateway NAT, onde possam usar o endereço IP público do gateway NAT.
Endpoint público e privado
Quando os endpoints públicos e privados estão habilitados, as solicitações da API Kubernetes de dentro da VPC se comunicam com o plano de controle por meio da sua VPC. X-ENIs O servidor de API do cluster é acessível pela internet.
Endpoint privado
Não há acesso público ao seu servidor de API pela Internet quando somente o endpoint privado está ativado. Todo o tráfego para o servidor de API do cluster deve vir da VPC do cluster ou de uma rede conectada. Os nós se comunicam com o servidor da API por meio X-ENIs de sua VPC. Observe que as ferramentas de gerenciamento de clusters devem ter acesso ao endpoint privado. Saiba mais sobre como se conectar a um endpoint de cluster privado do Amazon EKS de fora da Amazon VPC.
Observe que o endpoint do servidor de API do cluster é resolvido por servidores DNS públicos para um endereço IP privado da VPC. No passado, o endpoint só podia ser resolvido a partir da VPC.
Configurações de VPC
O Amazon VPC é compatível com endereçamento IPv4 e IPv6. O Amazon EKS oferece suporte a IPv4 por padrão. Uma VPC deve ter um bloco CIDR IPv4 associado a ela. Opcionalmente, você pode associar vários blocos de Inter-Domain roteamento sem classe /16 prefixo (65.536 endereços IP) e um /28 prefixo (16 endereços IP).
Ao criar uma nova VPC, você pode anexar um único bloco CIDR IPv6 e até cinco ao alterar uma VPC existente. O comprimento do prefixo do tamanho do bloco CIDR IPv6 pode estar entre /44 e /60 e, para as sub-redes IPv6, pode estar entre /44/ e /64. Você pode solicitar um bloco CIDR IPv6 do pool de endereços IPv6 mantido pela Amazon. Consulte a seção de blocos CIDR da VPC do Guia do usuário da VPC para obter mais informações.
Os clusters do Amazon EKS oferecem suporte a IPv4 e IPv6. Por padrão, os clusters EKS usam IP IPv4. Especificar IPv6 no momento da criação do cluster permitirá o uso de clusters IPv6. Os clusters IPv6 exigem VPCs e sub-redes de pilha dupla.
O Amazon EKS exige que você especifique pelo menos duas sub-redes em duas zonas de disponibilidade diferentes ao criar um cluster. As sub-redes que você especifica são conhecidas como sub-redes de cluster. O Amazon EKS provisiona dois ENIs entre contas (X-ENIS) em diferentes zonas de disponibilidade para permitir a comunicação com seus nós de trabalho. Quando você cria um cluster, o Amazon EKS cria de 2 a 4 X-ENIs em suas sub-redes especificadas. O Amazon EKS sempre implanta os X-enis e os usa para tráfego de administração de clusters, como entrega de log, exec e proxy. Para obter mais informações sobre os requisitos de VPC e sub-rede, consulte os requisitos de VPC e sub-rede no Guia do usuário do Amazon EKS.
Os nós de trabalho do Kubernetes podem ser executados nas sub-redes do cluster, mas isso não é recomendado. Durante as atualizações do cluster, o Amazon EKS provisiona ENIs adicionais nas sub-redes do cluster. Quando seu cluster se expande, os nós de trabalho e os pods podem consumir os IPs disponíveis na sub-rede do cluster. Portanto, para garantir que haja IPs disponíveis suficientes, você pode considerar o uso de sub-redes de cluster dedicadas com máscara de rede /28.
Os nós de trabalho do Kubernetes podem ser executados em uma sub-rede pública ou privada. O fato de uma sub-rede ser pública ou privada se refere ao fato de o tráfego dentro da sub-rede ser roteado por meio de um gateway da Internet. As sub-redes públicas têm uma entrada na tabela de rotas para a Internet por meio do gateway da Internet, mas as sub-redes privadas não.
O tráfego que se origina em outro lugar e chega aos seus nós é chamado de entrada. O tráfego que se origina dos nós e sai da rede é chamado de saída. Os nós com endereços IP públicos ou elásticos (EIPs) em uma sub-rede configurada com um gateway de internet permitem a entrada de fora da VPC. As sub-redes privadas geralmente têm um roteamento para um gateway NAT, que não permite o tráfego de entrada para os nós nas sub-redes de fora da VPC e, ao mesmo tempo, permite que o tráfego dos nós saia da VPC (saída).
No mundo IPv6, cada endereço é roteável pela Internet. Os endereços IPv6 associados aos nós e pods são públicos. As sub-redes privadas são suportadas pela implementação de gateways de internet somente de saída (EIGW) em uma VPC, permitindo tráfego de saída e bloqueando todo o tráfego de entrada. As melhores práticas para implementar sub-redes IPv6 podem ser encontradas no guia do usuário da VPC.
Você pode configurar a VPC e as sub-redes de três maneiras diferentes:
Usando somente sub-redes públicas
Nas mesmas sub-redes públicas, os nós e os recursos de entrada (como balanceadores de carga) são criados. Marque a sub-rede pública com kubernetes.io/role/elb para criar balanceadores de carga voltados para a Internet. Nessa configuração, o endpoint do cluster pode ser configurado para ser público, privado ou ambos (público e privado).
Usando sub-redes públicas e privadas
Os nós são criados em sub-redes privadas, enquanto os recursos do Ingress são instanciados em sub-redes públicas. Você pode habilitar o acesso público, privado ou ambos (público e privado) ao endpoint do cluster. Dependendo da configuração do endpoint do cluster, o tráfego do nó entrará pelo gateway NAT ou pela ENI.
Usando somente sub-redes privadas
Tanto os nós quanto a entrada são criados em sub-redes privadas. Usando a tag de kubernetes.io/role/internal-elb sub-rede para criar balanceadores de carga internos. O acesso ao endpoint do seu cluster exigirá uma conexão VPN. Você deve ativar a AWS PrivateLink para EC2 e todos os repositórios Amazon ECR e S3. Somente o endpoint privado do cluster deve ser ativado. Sugerimos que você analise os requisitos de cluster privado do EKS antes de provisionar clusters privados.
Comunicação entre VPCs
Há muitos cenários em que você precisa de várias VPCs e clusters EKS separados implantados nessas VPCs.
Você pode usar o Amazon VPC Lattice
O Amazon VPC Lattice opera no espaço de endereço link-local em IPv4 e IPv6, fornecendo conectividade entre serviços que podem ter endereços IPv4 sobrepostos. Para eficiência operacional, é altamente recomendável implantar clusters e nós do EKS em faixas de IP que não se sobreponham. Caso sua infraestrutura inclua VPCs com intervalos de IP sobrepostos, você precisa arquitetar sua rede adequadamente. Sugerimos o gateway NAT privado, ou VPC CNI, no modo de rede personalizado em conjunto com o gateway de trânsito para integrar cargas de trabalho no EKS e solucionar desafios de CIDR sobrepostos e, ao mesmo tempo, preservar os endereços IP RFC1918 roteáveis.
Considere utilizar a AWS PrivateLink, também conhecida como serviço de endpoint, se você for o provedor de serviços e quiser compartilhar seu serviço e entrada do Kubernetes (ALB ou NLB) com a VPC do seu cliente em contas separadas.
Compartilhamento de VPC em várias contas
Muitas empresas adotaram Amazon VPCs compartilhadas como um meio de simplificar a administração da rede, reduzir custos e melhorar a segurança em várias contas da AWS em uma organização da AWS. Eles utilizam o AWS Resource Access Manager (RAM) para compartilhar com segurança os recursos suportados da AWS com contas individuais da AWS, unidades organizacionais (OUs) ou toda a organização da AWS.
Você pode implantar clusters do Amazon EKS, grupos de nós gerenciados e outros recursos de suporte da AWS (como grupos de segurança LoadBalancers, endpoints etc.) em sub-redes VPC compartilhadas de outra conta da AWS usando a RAM da AWS. A figura abaixo mostra um exemplo de arquitetura de alto nível. Isso permite que as equipes de rede central controlem as construções de rede, como VPCs, sub-redes etc., ao mesmo tempo em que permite que as equipes de aplicativos ou plataformas implantem clusters do Amazon EKS em suas respectivas contas da AWS. Uma explicação completa desse cenário está disponível neste repositório do github.
Considerações ao usar sub-redes compartilhadas
-
Clusters e nós de trabalho do Amazon EKS podem ser criados em sub-redes compartilhadas que fazem parte da mesma VPC. O Amazon EKS não oferece suporte à criação de clusters em várias VPCs.
-
O Amazon EKS usa grupos de segurança (SGs) do AWS VPC para controlar o tráfego entre o plano de controle do Kubernetes e os nós de trabalho do cluster. Os grupos de segurança também são usados para controlar o tráfego entre os nós de trabalho, outros recursos da VPC e endereços IP externos. Você deve criar esses grupos de segurança na application/participant conta. Certifique-se de que os grupos de segurança que você pretende usar para seus pods também estejam localizados na conta do participante. Você pode configurar as regras de entrada e saída em seus grupos de segurança para permitir o tráfego necessário de e para grupos de segurança localizados na conta da VPC Central.
-
Crie funções do IAM e políticas associadas na conta do participante em que seu cluster Amazon EKS reside. Essas funções e políticas do IAM são essenciais para conceder as permissões necessárias aos clusters Kubernetes gerenciados pelo Amazon EKS, bem como aos nós e pods em execução no Fargate. As permissões permitem que o Amazon EKS faça chamadas para outros serviços da AWS em seu nome.
-
Você pode seguir as seguintes abordagens para permitir o acesso entre contas a recursos da AWS, como buckets do Amazon S3, tabelas do Dynamodb, etc., a partir de pods k8s:
-
Abordagem de política baseada em recursos: se o serviço da AWS oferecer suporte a políticas de recursos, você poderá adicionar uma política apropriada baseada em recursos para permitir o acesso entre contas às funções do IAM atribuídas aos pods do kubernetes. Nesse cenário, o provedor do OIDC, as funções do IAM e as políticas de permissão existem na conta do aplicativo. Para encontrar serviços da AWS que oferecem suporte a políticas baseadas em recursos, consulte os serviços da AWS que funcionam com o IAM e procure os serviços que têm Sim na coluna Baseado em recursos.
-
Abordagem do provedor de OIDC: recursos do IAM, como provedor de OIDC, funções do IAM, permissões e políticas de confiança, serão criados em outra conta participante da AWS onde os recursos existam. Essas funções serão atribuídas aos pods do Kubernetes na conta do aplicativo, para que eles possam acessar recursos de várias contas. Consulte o blog
Cross account IAM roles for Kubernetes service accounts para obter uma explicação completa dessa abordagem.
-
-
Você pode implantar os recursos do Amazon Elastic Loadbalancer (ELB) (ALB ou NLB) para rotear o tráfego para pods k8s em contas de aplicativos ou de rede central. Consulte o passo a passo do
Expose Amazon EKS Pods Through Cross-Account Load Balancer para obter instruções detalhadas sobre a implantação dos recursos do ELB em uma conta de rede central. Essa opção oferece maior flexibilidade, pois concede à conta de rede central controle total sobre a configuração de segurança dos recursos do balanceador de carga. -
Ao usar o
custom networking featureAmazon VPC CNI, você precisa usar os mapeamentos de ID da zona de disponibilidade (AZ) listados na conta de rede central para criar cada um.ENIConfigIsso ocorre devido ao mapeamento aleatório de AZs físicas para os nomes de AZ em cada conta da AWS.
Grupos de segurança
Um grupo de segurança controla o tráfego que tem permissão para acessar e sair dos recursos aos quais está associado. O Amazon EKS usa grupos de segurança para gerenciar a comunicação entre o plano de controle e os nós. Ao criar um cluster, o Amazon EKS cria um grupo de segurança com o nome eks-cluster-sg-my-cluster-uniqueID. O EKS associa esses grupos de segurança aos ENIs gerenciados e aos nós. As regras padrão permitem que todo o tráfego flua livremente entre o cluster e os nós e aceitam todo o tráfego de saída para qualquer destino.
Ao criar um cluster, você pode especificar seus próprios grupos de segurança. Consulte a recomendação para grupos de segurança ao especificar grupos de segurança próprios.
Recomendações
Considere a Multi-AZ implantação
As regiões da AWS oferecem várias zonas de disponibilidade (AZ) fisicamente separadas e isoladas, conectadas com redes de baixa latência, alta taxa de transferência e altamente redundantes. Com as zonas de disponibilidade, você pode projetar e operar aplicativos que falham automaticamente entre as zonas de disponibilidade sem interrupção. O Amazon EKS recomenda fortemente a implantação de clusters EKS em várias zonas de disponibilidade. Considere especificar sub-redes em pelo menos duas zonas de disponibilidade ao criar o cluster.
O Kubelet em execução nos nós adiciona automaticamente rótulos ao objeto do nó, como. topology.kubernetes.io/region=us-west-2
Você pode definir as sub-redes ou as zonas de disponibilidade ao criar nós. Os nós são colocados em sub-redes de cluster se nenhuma sub-rede estiver configurada. O suporte do EKS para grupos de nós gerenciados distribui automaticamente os nós em várias zonas de disponibilidade de acordo com a capacidade disponível. A Karpenter
Os AWS Elastic Load Balancers são gerenciados pelo AWS Load Balancer Controller para um cluster Kubernetes. Ele provisiona um Application Load Balancer (ALB) para recursos de entrada do Kubernetes e um Network Load Balancer (NLB) para serviços Kubernetes do tipo Loadbalancer. O controlador do Elastic Load Balancer usa tags
Implemente nós em sub-redes privadas
Uma VPC incluindo sub-redes privadas e públicas é o método ideal para implantar cargas de trabalho do Kubernetes no EKS. Considere definir no mínimo duas sub-redes públicas e duas sub-redes privadas em duas zonas de disponibilidade distintas. A tabela de rotas relacionada de uma sub-rede pública contém uma rota para um gateway da Internet. Os pods podem interagir com a Internet por meio de um gateway NAT. As sub-redes privadas são suportadas por gateways de Internet somente de saída no ambiente IPv6 (EIGW).
A instanciação de nós em sub-redes privadas oferece controle máximo sobre o tráfego para os nós e é eficaz para a grande maioria dos aplicativos Kubernetes. Os recursos de entrada (como balanceadores de carga) são instanciados em sub-redes públicas e direcionam o tráfego para pods que operam em sub-redes privadas.
Considere o modo somente privado se você exigir segurança estrita e isolamento de rede. Nessa configuração, três sub-redes privadas são implantadas em zonas de disponibilidade distintas dentro da VPC da região da AWS. Os recursos implantados nas sub-redes não podem acessar a Internet, nem a Internet pode acessar os recursos nas sub-redes. Para que seu aplicativo Kubernetes acesse outros serviços da AWS, você deve configurar PrivateLink interfaces and/or , gateway, endpoints. Você pode configurar balanceadores de carga internos para redirecionar o tráfego para pods usando o AWS Load Balancer Controller. As sub-redes privadas devem ser marcadas (kubernetes.io/role/internal-elb: 1) para que o controlador provisione balanceadores de carga. Para que os nós se registrem no cluster, o endpoint do cluster deve estar configurado para o modo privado. Visite o guia de clusters privados para ver os requisitos e considerações completos.
Considere o modo público e privado para o endpoint de cluster
O Amazon EKS oferece modos de endpoint de cluster somente públicos, públicos e privados e somente privados. O modo padrão é somente público, mas recomendamos configurar o endpoint do cluster nos modos público e privado. Essa opção permite que as chamadas da API Kubernetes dentro da VPC do seu cluster (como a comunicação entre o nó e o plano de controle) utilizem o endpoint privado da VPC e o tráfego para permanecer na VPC do cluster. Seu servidor de API de cluster, por outro lado, pode ser acessado pela Internet. No entanto, é altamente recomendável limitar os blocos CIDR que podem usar o endpoint público. Saiba como configurar o acesso público e privado a endpoints, incluindo a limitação de blocos CIDR.
Sugerimos um endpoint somente privado quando você precisar de segurança e isolamento de rede. Recomendamos usar qualquer uma das opções listadas no guia do usuário do EKS para se conectar a um servidor de API de forma privada.
Configure grupos de segurança com cuidado
O Amazon EKS oferece suporte ao uso de grupos de segurança personalizados. Qualquer grupo de segurança personalizado deve permitir a comunicação entre os nós e o plano de controle do Kubernetes. Verifique os requisitos de porta e configure as regras manualmente quando sua organização não permitir a comunicação aberta.
O EKS aplica os grupos de segurança personalizados que você fornece durante a criação do cluster às interfaces gerenciadas (X-ENIs). No entanto, ele não os associa imediatamente aos nós. Ao criar grupos de nós, é altamente recomendável associar grupos de segurança personalizados
É altamente recomendável criar um grupo de segurança para permitir todo o tráfego de comunicação entre nós. Durante o processo de bootstrap, os nós precisam de conectividade de saída com a Internet para acessar o endpoint do cluster. Avalie os requisitos de acesso externo, como conexão local e acesso ao registro de contêineres, e defina as regras adequadamente. Antes de colocar as alterações em produção, sugerimos que você verifique cuidadosamente as conexões em seu ambiente de desenvolvimento.
Implemente gateways NAT em cada zona de disponibilidade
Se você implantar nós em sub-redes privadas (IPv4 e IPv6), considere criar um gateway NAT em cada zona de disponibilidade (AZ) para garantir uma arquitetura independente de zona e reduzir os gastos entre AZ. Cada gateway NAT em uma AZ é implementado com redundância.
