**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# 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](eks-outposts-self-managed-nodes.md), 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](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Se o seu cluster não tiver acesso de saída à Internet, ele deverá atender aos seguintes requisitos:
## Requisitos de arquitetura do cluster
+ 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 obter mais informações, consulte [Copiar uma imagem de contêiner de um repositório para outro](copy-image-to-repository.md).
+ 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 obter mais informações, consulte [Endpoint do servidor de API do cluster](cluster-endpoint.md).
## Requisitos do nó
+ Os nós autogerenciados do Windows e do Linux devem incluir os seguintes argumentos de bootstrap antes de serem executados. 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 abaixo um exemplo de saída.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. 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.
1. Substitua os valores de `apiServerEndpoint` e `certificateAuthority` no objeto NodeConfig pelos valores retornados na saída dos comandos anteriores. Para obter mais informações sobre como especificar argumentos de inicialização ao executar nós gerenciados pelo cliente do Amazon Linux 2023, consulte [Criar nós autogerenciados do Amazon Linux](launch-workers.md) e [Criar nós autogerenciados do Microsoft Windows](launch-windows-workers.md).
+ Para nós do Linux:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Para obter argumentos adicionais, consulte o [script de bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) 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`. Do contrário, a resolução de DNS para pods no cluster falhará.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Para obter argumentos adicionais, consulte [Parâmetros de configuração do script de bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ 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.
## Requisitos do Pod
+ **Identidade de Pods**: os pods configurados com a Identidade de Pods do EKS adquirem credenciais da API Auth do EKS. Se não houver acesso de saída à Internet, será necessário criar e usar um endpoint da VPC para a API Auth do EKS: `com.amazonaws.region-code.eks-auth`. Para obter mais informações sobre endpoints da VPC do EKS e o EKS Auth, consulte [Acessar o Amazon EKS usando o AWS PrivateLink](vpc-interface-endpoints.md).
+ **IRSA**: pods configurados com [perfis do IAM para contas de serviço](iam-roles-for-service-accounts.md) 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 obter mais informações, consulte [Configurar o endpoint do AWS Security Token Service para uma conta de serviço](configure-sts-endpoint.md).
+ As sub-redes da VPC do cluster devem ter um endpoint de interface da VPC para todos os serviços da AWS que os pods precisam acessar. Para obter mais informações, consulte [Acessar um serviço da AWS usando um endpoint da VPC de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). 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](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) no [AWS PrivateLink Guide](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Recomendamos que você [habilite nomes de DNS privados](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) para seus endpoints da VPC, para que as workloads possam continuar usando endpoints de serviço da AWS públicos sem problemas.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/private-clusters.html)
+ 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.
+ **Armazenamento do EFS**: se os seus pods usarem volumes do Amazon EFS, antes de implantar a ação indicada em [Armazene um sistema de arquivos elástico com o Amazon EFS](efs-csi.md), o arquivo [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) do driver deverá ser alterado para definir as imagens do contêiner para usar a mesma região da AWS que o cluster do Amazon EKS.
+ O Route 53 não é compatível com o AWS PrivateLink. Você não pode gerenciar registros DNS do Route 53 em um cluster privado do Amazon EKS. Isso afeta o [external-dns](https://github.com/kubernetes-sigs/external-dns) do Kubernetes.
+ Se você usa a AMI otimizada para EKS, deve habilitar o endpoint do `ec2` na tabela acima. Como alternativa, você pode definir manualmente o nome DNS do nó. A AMI otimizada usa APIs do EC2 para definir o nome DNS do nó automaticamente.
+ Você pode usar o [AWS Load Balancer Control](aws-load-balancer-controller.md) 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](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) para definir `enable-shield`, `enable-waf` e `enable-wafv2` como falsos. [Detecção de certificados](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) 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 obter mais informações, consulte [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md) e [Criar um balanceador de carga da rede](network-load-balancing.md#network-load-balancer).
+ Há suporte para o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md). Ao implantar pods do Cluster Autoscaler, certifique-se de que a linha de comandos inclua `--aws-use-static-instance-list=true`. Para obter mais informações, consulte [Usar lista de instâncias estáticas](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) 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.