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á.

VPCe considerações sobre sub-rede

Operar um EKS cluster requer conhecimento de AWS VPC rede, além da rede Kubernetes.

Recomendamos que você entenda os mecanismos de comunicação do plano de EKS controle antes de começar a projetar VPC ou implantar clusters em clusters existentesVPCs.

Consulte as VPCconsiderações de cluster e as considerações do grupo EKS de segurança da Amazon ao arquitetar sub-redes a VPC e para serem usadas com. EKS

Visão geral

EKSArquitetura de cluster

Um EKS cluster consiste em doisVPCs:

Os nós do cliente VPC precisam da capacidade de se conectar ao endpoint do API servidor gerenciado no AWSVPC. 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 EKS controle por meio de (a) um endpoint EKS público ou (b) uma interface de rede elástica entre contas (X-ENI) gerenciada por. EKS Quando um cluster é criado, você precisa especificar pelo menos duas VPC sub-redes. EKScoloca um X- ENI em cada sub-rede especificada durante a criação do cluster (também chamadas de sub-redes de cluster). O API servidor Kubernetes usa essas contas cruzadas ENIs para se comunicar com os nós implantados nas sub-redes de cluster gerenciadas pelo cliente. VPC

Quando o nó é iniciado, o script de EKS bootstrap é executado e os arquivos de configuração do nó do 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, o kubelet e os agentes do nó 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 do VPC ou com o endpoint privado dentro do. VPC O Kubelet recebe API instruções e fornece atualizações de status e pulsações ao endpoint regularmente.

EKSComunicação do plano de controle

EKStem 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 pela sua. VPC Você pode ativar o endpoint público (que é o padrão), o endpoint privado ou ambos ao mesmo tempo.

A configuração do API endpoint 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 EKS console ouAPI.

Endpoint público

Esse é o comportamento padrão para novos EKS clusters da Amazon. Quando somente o endpoint público do cluster está habilitado, as API solicitações do Kubernetes originadas de dentro do seu cluster VPC (como o nó de trabalho para controlar a comunicação do plano) saem da redeVPC, mas não 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 NAT gateway onde possam usar o endereço IP público do NAT gateway.

Endpoint público e privado

Quando os endpoints públicos e privados estão habilitados, as API solicitações do Kubernetes de dentro do plano de VPC comunicação para o plano de controle por meio do X- dentro do seu. ENIs VPC Seu API servidor de cluster pode ser acessado pela Internet.

Endpoint privado

Não há acesso público ao seu API servidor pela Internet quando somente o endpoint privado está habilitado. Todo o tráfego para seu API servidor de cluster deve vir de dentro do seu cluster VPC ou de uma rede conectada. Os nós se comunicam com o API servidor via X- ENIs dentro do seuVPC. Observe que as ferramentas de gerenciamento de cluster devem ter acesso ao endpoint privado. Saiba mais sobre como se conectar a um endpoint de EKS cluster privado da Amazon de fora da Amazon VPC.

Observe que o endpoint do API servidor do cluster é resolvido por DNS servidores públicos em um endereço IP privado doVPC. No passado, o endpoint só podia ser resolvido de dentro doVPC.

VPCconfigurações

VPCSuporte IPv4 e IPv6 endereçamento da Amazon. A Amazon EKS oferece suporte IPv4 por padrão. A VPC deve ter um IPv4 CIDR bloco associado a ele. Opcionalmente, você pode associar vários blocos IPv4 Classless Inter-Domain Routing (CIDR) e vários IPv6 CIDR blocos ao seu. VPC Ao criar umVPC, você deve especificar um IPv4 CIDR bloco para o dos intervalos VPC de IPv4 endereços privados, conforme especificado em RFC1918. O tamanho de bloco permitido está entre um /16 prefixo (65.536 endereços IP) e um /28 prefixo (16 endereços IP).

Ao criar um novoVPC, você pode anexar um único IPv6 CIDR bloco e até cinco ao alterar um existenteVPC. O comprimento do prefixo do tamanho do IPv6 CIDR bloco pode estar entre /44 e /60 e para as IPv6 sub-redes pode estar entre /44/ e /64. Você pode solicitar um IPv6 CIDR bloqueio do pool de IPv6 endereços mantido pela Amazon. Consulte a seção de VPCCIDRblocos do Guia do VPC usuário para obter mais informações.

EKSOs clusters da Amazon oferecem suporte IPv4 a ambos IPv6 e. Por padrão, EKS os clusters usam IPv4 IP. Especificar IPv6 no momento da criação do cluster permitirá o uso de IPv6 clusters. IPv6os clusters exigem pilha dupla VPCs e sub-redes.

EKSA Amazon recomenda que você use pelo menos duas sub-redes que estejam em zonas de disponibilidade diferentes durante a criação do cluster. As sub-redes que você passa durante a criação do cluster são conhecidas como sub-redes de cluster. Quando você cria um cluster, a Amazon EKS cria até 4 contas cruzadas (x-account ou x-ENIs) ENIs nas sub-redes que você especifica. Os x- ENIs são sempre implantados e usados para tráfego de administração de clusters, como entrega de logs, exec e proxy. Consulte o guia do EKS usuário para obter detalhes completos VPCe sobre os requisitos de sub-rede.

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, a Amazon EKS provisiona mais ENIs nas sub-redes do cluster. Quando seu cluster se expande, os nós e pods de trabalho podem consumir o que está disponível IPs na sub-rede do cluster. Portanto, para garantir que haja disponibilidade IPs suficiente, convém 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 do. VPC As sub-redes privadas geralmente têm um roteamento para um NATgateway, que não permite o tráfego de entrada para os nós nas sub-redes de fora, mas VPC ainda permite que o tráfego dos nós saia da (saída). VPC

No IPv6 mundo, todo endereço é roteável pela Internet. Os IPv6 endereços 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 umVPC, permitindo o tráfego de saída e bloqueando todo o tráfego de entrada. As melhores práticas para implementar IPv6 sub-redes podem ser encontradas no guia do VPCusuário.

Você pode configurar VPC sub-redes de três maneiras diferentes:

Usando somente sub-redes públicas

Nas mesmas sub-redes públicas, tanto os nós quanto os recursos de entrada (como balanceadores de carga) são criados. Marque a sub-rede pública com kubernetes.io/role/elbpara 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 NAT gateway ou peloENI.

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-elbsub-rede para criar balanceadores de carga internos. O acesso ao endpoint do seu cluster exigirá uma VPN conexão. Você deve ativar AWS PrivateLinkpara 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 clusters EKS privados antes de provisioná-los.

Comunicação entre VPCs

Há muitos cenários em que você precisa VPCs implantar vários EKS clusters separados neles. VPCs

Você pode usar o Amazon VPC Lattice para conectar serviços de forma consistente e segura em várias VPCs contas (sem exigir que a conectividade adicional seja fornecida por serviços como VPC peering ou Transit AWS PrivateLink GatewayAWS). Saiba mais aqui.

O Amazon VPC Lattice opera no espaço de endereço local do link em IPv4 eIPv6, fornecendo conectividade entre serviços que podem ter endereços sobrepostos. IPv4 Para eficiência operacional, é altamente recomendável implantar EKS clusters e nós em intervalos de IP que não se sobreponham. Caso sua infraestrutura inclua intervalos VPCs de IP sobrepostos, você precisa arquitetar sua rede adequadamente. Sugerimos o Private NAT Gateway ou o modo de rede personalizado VPC CNI em conjunto com o Transit Gateway para integrar cargas de trabalho e resolver CIDR desafios sobrepostos e, EKS ao mesmo tempo, preservar os endereços IP roteáveis. RFC1918

Considere utilizar AWS PrivateLink, também conhecido como serviço de endpoint, se você for o provedor de serviços e quiser compartilhar seu serviço e entrada do Kubernetes (um ALB ou outroNLB) com seu cliente em contas separadas. VPC

Compartilhamento VPC em várias contas

Muitas empresas adotaram a Amazon compartilhada VPCs como um meio de agilizar a administração da rede, reduzir custos e melhorar a segurança em várias AWS contas em uma AWS organização. Eles utilizam o AWS Resource Access Manager (RAM) para compartilhar com segurança AWSos recursos suportados com AWS contas individuais, unidades organizacionais (OUs) ou com toda a AWS organização.

Você pode implantar EKS clusters da Amazon, grupos de nós gerenciados e outros AWS recursos de suporte (como grupos de segurança LoadBalancers, endpoints etc.) em VPC sub-redes compartilhadas de outra AWS conta usando. AWS RAM 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 redeVPCs, como sub-redes, etc., enquanto permite que equipes de aplicativos ou plataformas implantem EKS clusters da Amazon em suas respectivas contas. AWS Uma explicação completa desse cenário está disponível neste repositório github.

Considerações ao usar sub-redes compartilhadas

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. A Amazon EKS usa grupos de segurança para gerenciar a comunicação entre o plano de controle e os nós. Quando você cria um cluster, a Amazon EKS cria um grupo de segurança chamadoeks-cluster-sg-my-cluster-uniqueID. EKSassocia esses grupos de segurança aos nós gerenciados ENIs 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 seus próprios grupos de segurança.

Recomendações

Considere a implantação do Multi-AZ

AWSAs regiões fornecem várias zonas de disponibilidade (AZ) fisicamente separadas e isoladas, conectadas a redes de baixa latência, alto rendimento e altamente redundantes. Com as Zonas de Disponibilidade, você pode projetar e operar aplicativos que realizam o failover automático entre as Zonas de Disponibilidade sem interrupção. A Amazon recomenda EKS fortemente a implantação de EKS clusters em várias zonas de disponibilidade. Considere especificar sub-redes em pelo menos duas zonas de disponibilidade ao criar o cluster.

O Kubelet executado em nós adiciona automaticamente rótulos ao objeto do nó, como. topology.kubernetes.io/region=us-west-2 Recomendamos usar rótulos de nós em conjunto com as restrições de distribuição da topologia de pods para controlar como os pods são distribuídos pelas zonas. Essas dicas permitem que o programador do Kubernetes coloque pods para obter uma melhor disponibilidade esperada, reduzindo o risco de que uma falha correlacionada afete toda a sua carga de trabalho. Consulte Atribuição de nós a pods para ver exemplos de seletor de nós e restrições de propagação de AZ.

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. EKSo suporte para grupos de nós gerenciados distribui automaticamente os nós em várias zonas de disponibilidade de acordo com a capacidade disponível. O Karpenter honrará o posicionamento da distribuição AZ escalando os nós para especificar AZs se as cargas de trabalho definem limites de distribuição de topologia.

AWSOs 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 para descobrir as sub-redes. ELBo controlador requer um mínimo de duas zonas de disponibilidade (AZs) para provisionar o recurso de entrada com sucesso. Considere configurar sub-redes em pelo menos duas AZs para aproveitar a segurança e a confiabilidade da redundância geográfica.

Implante nós em sub-redes privadas

A VPC inclusão de sub-redes privadas e públicas é o método ideal para implantar cargas de trabalho do Kubernetes em. 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 NAT gateway. 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. 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 AWS região. VPC 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 AWS serviços, você deve configurar PrivateLink interfaces e/ou endpoints de gateway. Você pode configurar balanceadores de carga internos para redirecionar o tráfego para pods usando o Load Balancer ControllerAWS. As sub-redes privadas devem ser marcadas com (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 ser definido 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 cluster Endpoint

A Amazon EKS oferece modos de endpoint de public-and-private cluster somente público e privado. O modo padrão é somente público, no entanto, recomendamos configurar o endpoint do cluster nos modos público e privado. Essa opção permite que as API chamadas do Kubernetes dentro do seu cluster VPC (como node-to-control-plane comunicação) utilizem o VPC endpoint privado e o tráfego permaneça dentro do seu cluster. VPC Seu API servidor de cluster, por outro lado, pode ser acessado pela Internet. No entanto, é altamente recomendável limitar os CIDR blocos que podem usar o endpoint público. Saiba como configurar o acesso ao endpoint público e privado, 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 EKS usuário para se conectar a um API servidor de forma privada.

Configure grupos de segurança com cuidado

A 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.

EKSaplica 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 manualmente. Considere ativar securityGroupSelectoros Termos para permitir que o modelo de nó do Karpenter descubra grupos de segurança personalizados durante o escalonamento automático dos nós.

É 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 exigem 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 apropriadamente. Antes de colocar as mudanças em produção, sugerimos que você verifique cuidadosamente as conexões em seu ambiente de desenvolvimento.

Implemente NAT gateways em cada zona de disponibilidade

Se você implantar nós em sub-redes privadas (IPv4eIPv6), considere criar um NAT gateway em cada zona de disponibilidade (AZ) para garantir uma arquitetura independente da zona e reduzir os gastos entre AZ. Cada NAT gateway em uma AZ é implementado com redundância.

Use o Cloud9 para acessar clusters privados

AWSO Cloud9 é IDE baseado na Web e pode ser executado com segurança em sub-redes privadas sem acesso de entrada, usando o Systems Manager. AWS A saída também pode ser desativada na instância do Cloud9. Saiba mais sobre como usar o Cloud9 para acessar clusters e sub-redes privadas.

📝 Edite esta página em GitHub