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á.
# Fully-Private Cluster EKS
O eksctl suporta a criação de clusters totalmente privados que não têm acesso de saída à Internet e têm apenas sub-redes privadas. Os VPC endpoints são usados para permitir o acesso privado aos serviços da AWS.
Este guia descreve como criar um cluster privado sem acesso de saída à Internet.
## Criação de um cluster totalmente privado
O único campo obrigatório para criar um cluster totalmente privado é: `privateCluster.enabled`
```
privateCluster:
enabled: true
```
Após a criação do cluster, os comandos eksctl que precisam acessar o servidor da API Kubernetes precisarão ser executados de dentro da VPC do cluster, de uma VPC emparelhada ou usando algum outro meio, como o AWS Direct Connect. Os comandos eksctl que precisam de acesso às APIs do EKS não funcionarão se estiverem sendo executados de dentro da VPC do cluster. Para corrigir isso, [crie um endpoint de interface para o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/vpc-interface-endpoints.html) acessar de forma privada as APIs de gerenciamento do Amazon Elastic Kubernetes Service (Amazon EKS) a partir da sua Amazon Virtual Private Cloud (VPC). Em uma versão futura, o eksctl adicionará suporte para criar esse endpoint para que ele não precise ser criado manualmente. Os comandos que precisam acessar a URL do provedor do OpenID Connect precisarão ser executados de fora da VPC do seu cluster depois que você habilitar o AWS para PrivateLink o Amazon EKS.
A criação de grupos de nós gerenciados continuará funcionando, e a criação de grupos de nós autogerenciados funcionará, pois é necessário acessar o servidor de API por meio do [endpoint da interface](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-supports-aws-privatelink/) EKS se o comando for executado de dentro da VPC do cluster, de uma VPC emparelhada ou usando algum outro meio, como o AWS Direct Connect.
**nota**
Os VPC endpoints são cobrados por hora e com base no uso. Mais detalhes sobre preços podem ser encontrados em [ PrivateLink Preços da AWS](https://aws.amazon.com/privatelink/pricing/)
**Atenção**
Fully-private clusters não são suportados no`eu-south-1`.
## Configurando o acesso privado a serviços adicionais da AWS
Para permitir que os nós de trabalho acessem os serviços da AWS de forma privada, o eksctl cria endpoints VPC para os seguintes serviços:
+ Endpoints de interface para ECR (ambos `ecr.api` e`ecr.dkr`) para extrair imagens de contêineres (plug-in AWS CNI etc.)
+ Um endpoint de gateway para o S3 extrair as camadas reais da imagem
+ Um endpoint de interface para EC2 exigido pela integração `aws-cloud-provider`
+ Um endpoint de interface para STS para dar suporte às funções de Fargate e IAM para contas de serviços (IRSA)
+ Um endpoint de interface para CloudWatch logging (`logs`) se o CloudWatch registro estiver ativado
Esses endpoints VPC são essenciais para um cluster privado funcional e, como tal, o eksctl não oferece suporte para configurá-los ou desativá-los. No entanto, um cluster pode precisar de acesso privado a outros serviços da AWS (por exemplo, escalonamento automático exigido pelo autoescalador de cluster). Esses serviços podem ser especificados em`privateCluster.additionalEndpointServices`, o que instrui o eksctl a criar um VPC endpoint para cada um deles.
Por exemplo, para permitir acesso privado ao escalonamento automático e CloudWatch ao registro:
```
privateCluster:
enabled: true
additionalEndpointServices:
# For Cluster Autoscaler
- "autoscaling"
# CloudWatch logging
- "logs"
```
Os endpoints suportados em `additionalEndpointServices` são`autoscaling`, `cloudformation` e. `logs`
### Ignorando criações de endpoints
Se uma VPC já tiver sido criada com os endpoints da AWS necessários configurados e vinculados às sub-redes descritas na documentação do EKS, `eksctl` pode pular a criação deles fornecendo a seguinte opção: `skipEndpointCreation`
```
privateCluster:
enabled: true
skipEndpointCreation: true
```
Essa configuração não pode ser usada junto com `additionalEndpointServices` o. Isso ignorará toda a criação de endpoints. Além disso, essa configuração só é recomendada se a topologia da `<→` sub-rede do endpoint estiver configurada corretamente. Se os IDs de sub-rede estiverem corretos, o `vpce` roteamento será configurado com endereços de prefixo, todos os endpoints EKS necessários serão criados e vinculados à VPC fornecida. `eksctl`não alterará nenhum desses recursos.
## Grupos de nós
Somente grupos de nós privados (gerenciados e autogerenciados) são suportados em um cluster totalmente privado porque a VPC do cluster é criada sem nenhuma sub-rede pública. O `privateNetworking` campo (`nodeGroup[].privateNetworking `e`managedNodeGroup[`) deve ser definido explicitamente. É um erro deixar `privateNetworking` sem definição em um cluster totalmente privado.
```
nodeGroups:
- name: ng1
instanceType: m5.large
desiredCapacity: 2
# privateNetworking must be explicitly set for a fully-private cluster
# Rather than defaulting this field to `true`,
# we require users to explicitly set it to make the behaviour
# explicit and avoid confusion.
privateNetworking: true
managedNodeGroups:
- name: m1
instanceType: m5.large
desiredCapacity: 2
privateNetworking: true
```
## Acesso ao endpoint do cluster
Um cluster totalmente privado não oferece suporte à modificação `clusterEndpointAccess` durante a criação do cluster. É um erro definir um `clusterEndpoints.publicAccess` ou`clusterEndpoints.privateAccess`, pois um cluster totalmente privado só pode ter acesso privado, e permitir a modificação desses campos pode interromper o cluster.
## User-supplied VPC e sub-redes
O eksctl suporta a criação de clusters totalmente privados usando uma VPC e sub-redes preexistentes. Somente sub-redes privadas podem ser especificadas e é um erro especificar sub-redes em. `vpc.subnets.public`
eksctl cria endpoints de VPC na VPC fornecida e modifica as tabelas de rotas para as sub-redes fornecidas. Cada sub-rede deve ter uma tabela de rotas explícita associada a ela porque o eksctl não modifica a tabela de rotas principal.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: private-cluster
region: us-west-2
privateCluster:
enabled: true
additionalEndpointServices:
- "autoscaling"
vpc:
subnets:
private:
us-west-2b:
id: subnet-0818beec303f8419b
us-west-2c:
id: subnet-0d42ef09490805e2a
us-west-2d:
id: subnet-0da7418077077c5f9
nodeGroups:
- name: ng1
instanceType: m5.large
desiredCapacity: 2
# privateNetworking must be explicitly set for a fully-private cluster
# Rather than defaulting this field to true for a fully-private cluster, we require users to explicitly set it
# to make the behaviour explicit and avoid confusion.
privateNetworking: true
managedNodeGroups:
- name: m1
instanceType: m5.large
desiredCapacity: 2
privateNetworking: true
```
## Gerenciando um cluster totalmente privado
Para que todos os comandos funcionem após a criação do cluster, o eksctl precisará de acesso privado ao endpoint do servidor da API EKS e acesso de saída à Internet (para). `EKS:DescribeCluster` Os comandos que não precisam de acesso ao servidor da API serão suportados se o eksctl tiver acesso de saída à Internet.
## Force-delete um cluster totalmente privado
É provável que ocorram erros ao excluir um cluster totalmente privado por meio do eksctl, pois o eksctl não tem acesso automático a todos os recursos do cluster. `--force`existe para resolver isso: ele forçará a exclusão do cluster e continuará quando ocorrerem erros.
## Limitações
Uma limitação da implementação atual é que o eksctl inicialmente cria o cluster com o acesso ao endpoint público e privado habilitado e desativa o acesso ao endpoint público após a conclusão de todas as operações. Isso é necessário porque o eksctl precisa acessar o servidor da API Kubernetes para permitir que nós autogerenciados se juntem ao cluster e ofereçam suporte ao Fargate. GitOps Depois que essas operações forem concluídas, o eksctl alterna o acesso ao endpoint do cluster para somente privado. Essa atualização adicional significa que a criação de um cluster totalmente privado levará mais tempo do que a de um cluster padrão. No futuro, o eksctl poderá mudar para uma função VPC-enabled Lambda para realizar essas operações de API.
## Acesso de saída via servidores proxy HTTP
O eksctl é capaz de se comunicar com as APIs da AWS por meio de um servidor proxy HTTP (S) configurado, no entanto, você precisará garantir a configuração correta da lista de exclusão de proxy.
Geralmente, você precisará garantir que as solicitações do VPC endpoint do seu cluster não sejam roteadas por meio de seus proxies definindo uma variável de ambiente apropriada`no_proxy`, incluindo o valor. `.eks.amazonaws.com`
Se seu servidor proxy realizar a “interceptação de SSL” e você estiver usando funções do IAM para contas de serviço (IRSA), você precisará garantir que você ignore explicitamente o SSL para o domínio. Man-in-the-Middle `oidc..amazonaws.com` Se não fizer isso, o eksctl obterá a impressão digital incorreta do certificado raiz do provedor OIDC, e o plug-in CNI do AWS VPC falhará na inicialização devido à impossibilidade de obter as credenciais do IAM, tornando seu cluster inoperante.
## Mais informações
+ [Clusters privados EKS](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html)