Implementar clusters privados com acesso limitado à internet

Este tópico descreve como implantar um cluster do Amazon EKS que está implantado na nuvem AWS, mas não tem acesso à Internet de saída. Se você tiver um cluster local em AWS Outposts, consulte Criar nós Amazon Linux no AWS Outposts, em vez deste tópico.

Se você não estiver familiarizado com a rede do Amazon EKS, consulte De-mystifying cluster networking for Amazon EKS worker nodes. Se o cluster não tiver acesso de saída à Internet, ele deverá atender aos seguintes requisitos:

• O cluster deve extrair imagens de um registro de contêiner que esteja na VPC. Você pode criar um Amazon Elastic Container Registry na VPC e copiar para ele as imagens de contêiner para que os nós as extrai dali. Para ter mais informações, consulte Copiar uma imagem de contêiner de um repositório para outro.

• O cluster deve ter acesso privado ao endpoint habilitado. Isso é necessário para que os nós sejam registrados no endpoint do cluster. O acesso público ao endpoint é opcional. Para ter mais informações, consulte Controlar o acesso à rede ao endpoint do servidor de API do cluster.

• Os nós autogerenciados do Linux e do Windows devem incluir os seguintes argumentos de bootstrap antes de serem iniciados. Esses argumentos ignoram a introspecção do Amazon EKS e não exigem acesso à API do Amazon EKS de dento da VPC.

  1. Determine o valor do endpoint do cluster com o comando a seguir. Substitua my-cluster pelo nome do cluster.

     aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text

     Veja um exemplo de saída abaixo.

     https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com

  2. Determine o valor da autoridade de certificação do cluster com o comando a seguir. Substitua my-cluster pelo nome do cluster.

     aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text

     A saída retornada é uma string longa.

  3. Substitua cluster-endpoint e certificate-authority nos comandos a seguir pelos valores retornados na saída dos comandos anteriores. Para obter mais informações sobre a especificação de argumentos de bootstrap ao iniciar nós autogerenciados, consulte Criar nós autogerenciados do Amazon Linux e Criar nós Microsoft Windows autogerenciados.

     • Para nós do Linux:

       --apiserver-endpoint cluster-endpoint --b64-cluster-ca certificate-authority

       Para obter argumentos adicionais, consulte bootstrap script (script de bootstrap) no GitHub.

     • Para nós do Windows:

       nota

       Se você estiver usando um CIDR de serviço personalizado, será necessário especificá-lo usando o parâmetro -ServiceCIDR. Caso contrário, a resolução de DNS Pods no cluster falhará.

       -APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority

       Para obter argumentos adicionais, consulte Parâmetros de configuração do script de bootstrap.

• O ConfigMap da aws-auth do cluster deve ser criado de dentro da VPC. Para obter mais informações sobre como criar e adicionar entradas ao ConfigMap aws-auth, insira eksctl create iamidentitymapping --help em seu terminal. Se o ConfigMap não existir no seu servidor, eksctl será criado quando você usar o comando para adicionar um mapeamento de identidade.

• Pods configurados com perfis de IAM para contas de serviço adquirem credenciais de uma chamada de API do AWS Security Token Service (AWS STS). Se não houver acesso de saída à Internet, você deverá criar e usar um endpoint AWS STS VPC em sua VPC. A maioria dos SDKs do AWS v1 usa o endpoint global AWS STS por padrão (sts.amazonaws.com), que não usa o endpoint AWS STS VPC. Para usar o endpoint AWS STS VPC, talvez seja necessário configurar o SDK para usar o endpoint regional AWS STS (sts.region-code.amazonaws.com). Para ter mais informações, consulte Configure o endpoint do AWS Security Token Service para uma conta de serviço.

• As sub-redes VPC do seu cluster devem ter um endpoint de interface VPC para todos os serviços AWS aos quais seu Pods precisa acessar. Para obter mais informações, consulte Acessar um serviço da AWS usando um endpoint da VPC de interface. Alguns serviços e endpoints comumente usados estão listados na tabela a seguir. Para obter uma lista completa de endpoints, consulte AWS services that integrate with AWS PrivateLink no AWS PrivateLink Guide.

  Recomendamos que você habilite nomes de DNS privados para seus endpoints da VPC, para que as workloads possam continuar usando endpoints de serviço da AWS públicos sem problemas.

  Serviço	Endpoint
  Amazon EC2	com.amazonaws.region-code.ec2
  Amazon Elastic Container Registry (para extração de imagens de contêineres)	com.amazonaws.region-code.ecr.api, com.amazonaws.region-code.ecr.dkr e com.amazonaws.region-code.s3
  Application Load Balancers e Network Load Balancers	com.amazonaws.region-code.elasticloadbalancing
  AWS X-Ray	com.amazonaws.cregion-code.xray
  Amazon CloudWatch Logs	com.amazonaws.region-code.logs
  AWS Serviço de token de segurança (necessário ao usar perfis de IAM para contas de serviço)	com.amazonaws.region-code.sts

• Todos os nós autogerenciados devem ser implantados em sub-redes que tenham os endpoints de interface da VPC necessários. Se você criar um grupo de nós gerenciados, o grupo de segurança de endpoint de interface da VPC deverá aceitar o CIDR para as sub-redes ou será necessário adicionar o grupo de segurança do nó criado ao grupo de segurança do endpoint de interface da VPC.

• Se o seu Pods usar volumes do Amazon EFS, antes de implantar o Store an elastic file system com o Amazon EFS, o arquivo kustomization.yaml do driver deverá ser alterado para definir as imagens do contêiner para usar a mesma AWS Region que o cluster do Amazon EKS.

• Você pode usar o AWS Load Balancer Control ler para implantar AWS Application Load Balancers (ALB) e Network Load Balancers em seu cluster privado. Ao implantá-lo, você deve usar sinalizadores de linha de comando para definir enable-shield, enable-waf e enable-wafv2 como falsos. Detecção de certificados com nomes de host de objetos de ingresso não é compatível. Isso ocorre porque o controlador precisa acessar o AWS Certificate Manager, que não tem um endpoint de interface VPC.

  O controlador é compatível com balanceadores de carga de rede com destinos IP, que são necessários para uso com Fargate. Para ter mais informações, consulte Aplicação de roteamento e tráfego HTTP com Application Load Balancers e Criar um balanceador de carga da rede.

• Há suporte para o Cluster Autoscaler. Ao implantar Pods do Cluster Autoscaler, certifique-se de que a linha de comando inclua --aws-use-static-instance-list=true. Para obter mais informações, consulte Use Static Instance List (Usar lista de instâncias estáticas) no GitHub. A VPC do nó de processamento também deve incluir o endpoint da VPC AWS STS e o endpoint VPC de escalabilidade automática.

• Alguns produtos de software de contêiner utilizam chamadas de API que acessam o serviço AWS Marketplace para monitorar a utilização. Como os clusters privados não permitem essas chamadas, esses tipos de contêiner não podem ser usados nesses clusters.