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

Configuração da VPC

VPC dedicada para cluster

Por padrão, eksctl create cluster criará uma VPC dedicada para o cluster. Isso é feito para evitar interferência nos recursos existentes por vários motivos, incluindo segurança, mas também porque é difícil detectar todas as configurações em uma VPC existente.

Alterar o CIDR da VPC

Se você precisar configurar o peering com outra VPC, ou simplesmente precisar de um intervalo IPs maior ou menor, você pode --vpc-cidr usar o sinalizador para alterá-lo. Consulte os documentos da AWS para obter guias sobre como escolher blocos CIDR que são permitidos para uso em uma VPC da AWS.

Se você estiver criando um IPv6 cluster, poderá configurá-lo VPC.IPv6Cidr no arquivo de configuração do cluster. Essa configuração está somente no arquivo de configuração, não em um sinalizador CLI.

Se você possui um bloco de endereços IPv6 IP, também pode trazer seu próprio IPv6 pool. Consulte Traga seus próprios endereços IP (BYOIP) para a Amazon EC2 sobre como importar seu próprio pool. Em seguida, use o VPC.IPv6Cidr no arquivo de configuração do cluster para configurar o Eksctl.

Use uma VPC existente: compartilhada com kops

Você pode usar a VPC de um cluster Kubernetes existente gerenciado pelo kops. Esse recurso é fornecido para facilitar o emparelhamento de and/or clusters de migração.

Se você já criou um cluster com kops, por exemplo, usando comandos semelhantes a este:

export KOPS_STATE_STORE=s3://kops
kops create cluster cluster-1.k8s.local --zones=us-west-2c,us-west-2b,us-west-2a --networking=weave --yes

Você pode criar um cluster EKS no mesmo AZs usando as mesmas sub-redes VPC (NOTA: são necessárias pelo menos 2 AZs/subnets ):

eksctl create cluster --name=cluster-2 --region=us-west-2 --vpc-from-kops-cluster=cluster-1.k8s.local

Use a VPC existente: outra configuração personalizada

eksctlfornece alguma flexibilidade, mas não completa, para topologias personalizadas de VPC e sub-rede.

Você pode usar uma VPC existente fornecendo sub-redes and/or públicas privadas usando os sinalizadores e. --vpc-private-subnets --vpc-public-subnets Cabe a você garantir que as sub-redes que você usa sejam categorizadas corretamente, pois não há uma maneira simples de verificar se uma sub-rede é realmente privada ou pública, pois as configurações variam.

Dadas essas sinalizações, eksctl create cluster determinará o ID da VPC automaticamente, mas não criará nenhuma tabela de roteamento ou outros recursos, como gateways. internet/NAT No entanto, ele criará grupos de segurança dedicados para o grupo de nós inicial e o plano de controle.

Você deve garantir o fornecimento de pelo menos 2 sub-redes diferentes AZs e essa condição é verificada pelo EKS. Se você usa uma VPC existente, os requisitos a seguir não são aplicados ou verificados pelo EKS ou pelo Eksctl, e o EKS cria o cluster. Algumas funções básicas do cluster funcionam sem esses requisitos. (Por exemplo, a marcação não é estritamente necessária; testes mostraram que é possível criar um cluster funcional sem nenhuma tag definida nas sub-redes, no entanto, não há garantia de que isso sempre será válido e a marcação é recomendada.)

Requisitos padrão:

Pode haver outros requisitos impostos pelo EKS ou pelo Kubernetes, e cabe inteiramente a você cumprir quaisquer requisitos up-to-date. and/or recommendations, and implement those as needed/possible

As configurações padrão do grupo de segurança aplicadas por eksctl podem ou não ser suficientes para compartilhar o acesso com recursos em outros grupos de segurança. Se você quiser modificar as ingress/egress regras dos grupos de segurança, talvez seja necessário usar outra ferramenta para automatizar as alterações ou fazer isso por meio do EC2 console.

Em caso de dúvida, não use uma VPC personalizada. Usar eksctl create cluster sem --vpc-* sinalizadores sempre configurará o cluster com uma VPC dedicada totalmente funcional.

Exemplos

Crie um cluster usando uma VPC personalizada com 2x sub-redes privadas e 2x públicas:

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0426fb4a607393184 \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-009fa0199ec203c37

ou use o seguinte arquivo de configuração equivalente:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    private:
      us-west-2a:
          id: "subnet-0ff156e0c4a6d300c"
      us-west-2c:
          id: "subnet-0426fb4a607393184"
    public:
      us-west-2a:
          id: "subnet-0153e560b3129a696"
      us-west-2c:
          id: "subnet-009fa0199ec203c37"

nodeGroups:
  - name: ng-1

Crie um cluster usando uma VPC personalizada com três sub-redes privadas e faça com que o nodegroup inicial use essas sub-redes:

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0549cdab573695c03,subnet-0426fb4a607393184 \
  --node-private-networking

ou use o seguinte arquivo de configuração equivalente:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    private:
      us-west-2d:
          id: "subnet-0ff156e0c4a6d300c"
      us-west-2c:
          id: "subnet-0549cdab573695c03"
      us-west-2a:
          id: "subnet-0426fb4a607393184"

nodeGroups:
  - name: ng-1
    privateNetworking: true

Crie um cluster usando uma sub-rede pública VPC 4x personalizada:

eksctl create cluster \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-0cc9c5aebe75083fd,subnet-009fa0199ec203c37,subnet-018fa0176ba320e45

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    public:
      us-west-2d:
          id: "subnet-0153e560b3129a696"
      us-west-2c:
          id: "subnet-0cc9c5aebe75083fd"
      us-west-2a:
          id: "subnet-009fa0199ec203c37"
      us-west-2b:
          id: "subnet-018fa0176ba320e45"

nodeGroups:
  - name: ng-1

Mais exemplos podem ser encontrados na examples pasta do repositório:

Grupo de segurança de nós compartilhados personalizados

eksctlcriará e gerenciará um grupo de segurança de nós compartilhados que permite a comunicação entre nós não gerenciados e o plano de controle do cluster e os nós gerenciados.

Se, em vez disso, desejar fornecer seu próprio grupo de segurança personalizado, você pode substituir o sharedNodeSecurityGroup campo no arquivo de configuração:

vpc:
  sharedNodeSecurityGroup: sg-0123456789

Por padrão, ao criar o cluster, eksctl adicionará regras a esse grupo de segurança para permitir a comunicação de e para o grupo de segurança de cluster padrão criado pelo EKS. O grupo de segurança de cluster padrão é usado tanto pelo plano de controle do EKS quanto pelos grupos de nós gerenciados.

Se você quiser gerenciar as regras do grupo de segurança sozinho, você pode eksctl evitar a criação das regras configurando manageSharedNodeSecurityGroupRules como false no arquivo de configuração:

vpc:
  sharedNodeSecurityGroup: sg-0123456789
  manageSharedNodeSecurityGroupRules: false

NAT Gateway

O gateway NAT de um cluster pode ser configurado para serDisable, Single (padrão) ouHighlyAvailable. A HighlyAvailable opção implantará um gateway NAT em cada zona de disponibilidade da região, de forma que, se uma AZ estiver inativa, os nós da outra AZs ainda possam se comunicar com a Internet.

Ele pode ser especificado por meio do sinalizador --vpc-nat-mode CLI ou no arquivo de configuração do cluster, como no exemplo abaixo:

vpc:
  nat:
    gateway: HighlyAvailable # other options: Disable, Single (default)

Veja o exemplo completo aqui.