Cluster totalmente privado 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 ao EKS não APIs funcionarão se estiverem sendo executados de dentro da VPC do cluster. Para corrigir isso, crie um endpoint de interface para o Amazon EKS acessar de forma privada o gerenciamento do Amazon Elastic Kubernetes Service (Amazon APIs 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 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

Atenção

Não há suporte para clusters totalmente privados 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 eecr.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 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 emprivateCluster.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ãoautoscaling, 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. eksctlnã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 emanagedNodeGroup[) 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 ouclusterEndpoints.privateAccess, pois um cluster totalmente privado só pode ter acesso privado, e permitir a modificação desses campos pode interromper o cluster.

VPC e sub-redes fornecidas pelo usuário

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.

Exclusão forçada de 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. --forceexiste 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 Lambda habilitada para VPC para realizar essas operações de API.

Acesso de saída via servidores proxy HTTP

O eksctl é capaz de se comunicar com a AWS APIs por meio de um servidor proxy HTTP (S) configurado, no entanto, você precisará garantir que definiu sua lista de exclusão de proxy corretamente.

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 apropriadano_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.<region>.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