Ir para o conteúdo

Como faço para usar vários intervalos CIDR com o Amazon EKS?

7 minuto de leitura
0

Quero usar vários intervalos CIDR com o Amazon Elastic Kubernetes Service (Amazon EKS) para resolver problemas com meus pods.

Breve descrição

Para usar vários intervalos CIDR no Amazon EKS, conclua as seguintes etapas:

  1. Adicione mais intervalos CIDR para expandir sua rede de nuvem privada virtual (VPC).
  2. Crie sub-redes com um novo intervalo CIDR.
  3. Associe sua nova sub-rede a uma tabela de rotas.
  4. Configure o plug-in de Interface de rede de contêiner (CNI) da Amazon Virtual Private Cloud (Amazon VPC) para usar um novo intervalo CIDR.

Observação: é uma prática recomendada usar CIDRs (/16) do espaço NAT de nível de operadora (CGN), como 100.64.0.0/10 ou 198.19.0.0/16. É possível usar um intervalo de VPC válido como um intervalo CIDR secundário em redes personalizadas. No entanto, é menos provável que esses intervalos sejam usados em um ambiente corporativo. Para mais informações sobre os requisitos de rede personalizados, consulte Considerações.

Resolução

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solução de problemas da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

Pré-requisitos: Você deve ter as seguintes configurações:

Adicione mais intervalos CIDR para expandir sua rede VPC

Conclua as etapas a seguir:

  1. Para recuperar o ID da VPC do seu cluster e armazená-lo em uma variável, execute o seguinte comando describe-cluster da AWS CLI:
    VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text)
    Observação: substitua CLUSTER_NAME pelo nome do seu cluster e REGION_CODE pela região da AWS em que você implantou o cluster.
  2. Para associar outro bloco CIDR ao intervalo 100.64.0.0/16 para a VPC, execute o seguinte comando associate-vpc-cidr-block:
    aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16

Crie sub-redes com um novo intervalo CIDR

Conclua as etapas a seguir:

  1. Para listar todas as Zonas de disponibilidade em sua Região, execute o seguinte comando describe-availability-zones:
    aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName'
    Observação: substitua REGION_CODE pela região em que você implantou seus recursos.
  2. Crie as sub-redes que você deseja usar em cada zona de disponibilidade em que suas sub-redes estão. Para criar novas sub-redes sob a VPC com o novo intervalo CIDR, execute os seguintes comandos create-subnet.
    CUST_SNET1=$(aws ec2 create-subnet --cidr-block 100.64.0.0/19 --vpc-id $VPC_ID --availability-zone AZ1 | jq -r .Subnet.SubnetId)
    CUST_SNET2=$(aws ec2 create-subnet --cidr-block 100.64.32.0/19 --vpc-id $VPC_ID --availability-zone AZ2 | jq -r .Subnet.SubnetId)
    CUST_SNET3=$(aws ec2 create-subnet --cidr-block 100.64.64.0/19 --vpc-id $VPC_ID --availability-zone AZ3 | jq -r .Subnet.SubnetId)
    Observação: substitua AZ1, AZ2 e AZ3 por suas zonas de disponibilidade de sub-rede.
  3. (Opcional) Para definir um par de valor-chave para adicionar uma tag de nome às suas sub-redes, execute o seguinte comando create-tags:
    aws ec2 create-tags --resources $CUST_SNET1 --tags Key=KEY,Value=VALUE
    aws ec2 create-tags --resources $CUST_SNET2 --tags Key=KEY,Value=VALUE
    aws ec2 create-tags --resources $CUST_SNET3 --tags Key=KEY,Value=VALUE
    Observação: substitua KEY pela chave da tag e VALUE pelo valor da tag.

Associe sua nova sub-rede a uma tabela de rotas

Por padrão, a Amazon VPC associa suas novas sub-redes à tabela de rotas principal da sua VPC. Essa tabela de rotas permite a comunicação somente entre os recursos implantados na VPC. Para permitir a comunicação com endereços IP que estão fora dos blocos CIDR da VPC, você deve criar sua própria tabela de rotas para suas sub-redes.

Configurar o plug-in CNI da Amazon VPC para usar o novo intervalo CIDR

Conclua as etapas a seguir:

  1. Certifique-se de executar a versão correta do plug-in para sua versão do Kubernetes. Para verificar a versão, execute o seguinte comando:

    kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

    Se você não tiver a versão correta do plug-in, atualize a CNI da Amazon VPC.

  2. Para ativar a configuração de rede personalizada para o plug-in de CNI da Amazon VPC, execute o seguinte comando:

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  3. Para adicionar o rótulo ENIConfig para identificar seus nós de processamento, execute o seguinte comando:

    kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone
  4. Para criar recursos personalizados ENIConfig para todas as sub-redes e zonas de disponibilidade, execute os seguintes comandos:

    cat <<EOF  | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1
    kind: ENIConfig
    metadata:
     name: $AZ1
    spec:
      securityGroups:
        - cluster_security_group_id
      subnet: $CUST_SNET1
    EOF
    
    cat <<EOF | kubectl apply -f -
    apiVersion: crd.k8s.amazonaws.com/v1alpha1
    kind: ENIConfig
    metadata:
     name: $AZ2
    spec:
      securityGroups:
        - cluster_security_group_id
      subnet: $CUST_SNET2
    EOF
    
    cat <<EOF | kubectl apply -f -
    apiVersion: crd.k8s.amazonaws.com/v1alpha1
    kind: ENIConfig
    metadata:
     name: $AZ3
    spec:
      securityGroups:
        - cluster_security_group_id
      subnet: $CUST_SNET3
    EOF

    Observação: substitua cluster_security_group_id pelo ID do grupo de segurança que você deseja usar para cada recurso ENIConfig. Os nomes do recurso ENIConfig são os mesmos da zona de disponibilidade em que você criou as novas sub-redes.

  5. Se você usa um grupo de nós autogerenciados, inicie os nós de processamento autogerenciados para permitir que o plug-in aloque endereços IP para eles. Em Sub-redes, use as sub-redes originais que você escolheu ao criar o cluster em vez das novas sub-redes usadas nos recursos ENIConfig. também é possível usar um grupo de nós gerenciados com um modelo de inicialização para iniciar nós. Em ambos os casos, você deve identificar o valor correto de max-pods para seu tipo de instância. Isso ocorre porque a rede personalizada no Amazon EKS não usa a interface de rede principal para o posicionamento do pod. Certifique-se de adicionar o parâmetro --cni-custom-networking-enabled ao executar o script max-pods-calculator.sh.
    Em seguida, execute o comando a seguir para especificar o valor max-pods para seus nós autogerenciados:

    --use-max-pods false --kubelet-extra-args '--max-pods=20'

    Observação: substitua 20 pelo valor max-pods que você calculou.
    Em um grupo de nós gerenciados, adicione o seguinte script aos dados do usuário:

    #!/bin/bash
    /etc/eks/bootstrap.sh my-cluster-name --use-max-pods false --kubelet-extra-args '--max-pods=20'

    Observação: substitua my-cluster-name pelo nome do cluster e 20 pelo valor max-pods que você calculou. Em seu modelo de inicialização, especifique um ID de imagem de máquina da Amazon (AMI) otimizado para Amazon EKS ou uma AMI personalizada criada com base na AMI otimizada para Amazon EKS. As AMIs do Amazon Linux 2023 (AL2023) usam o processo nodeadm. Para obter mais informações sobre como isso altera a configuração de dados do usuário, consulte Atualização do Amazon Linux 2 para o Amazon Linux 2023.
    Se você usar um grupo de nós gerenciados sem um modelo de inicialização ou um ID de AMI especificado, o grupo de nós gerenciados calculará automaticamente o valor max-pods.

  6. Depois que os novos nós estiverem prontos, drene os nós anteriores para desativar os pods normalmente. Para mais informações, consulte Drenar um nó com segurança no site do Kubernetes. Se os nós estiverem em um grupo de nós gerenciados, execute o seguinte comando para excluir o grupo de nós:

    aws eks delete-nodegroup --cluster-name CLUSTER_NAME --nodegroup-name my-nodegroup

    Observação: substitua CLUSTER_NAME pelo nome do cluster e my-nodegroup pelo nome do grupo de nós.

  7. Para iniciar uma nova implantação para testar a configuração, execute o seguinte comando:

    kubectl create deployment nginx-test --image=nginx --replicas=10   
    kubectl get pods -o wide --selector=app=nginx-test

    Observação: o comando anterior adiciona 10 novos pods e os programa no novo intervalo CIDR em novos nós de processamento.

Importante: um cluster pode levar até 5 horas para reconhecer e colocar na lista de permissões um novo bloco CIDR que você associa a uma VPC. Durante esse período, o ambiente de gerenciamento do Amazon EKS não consegue se comunicar com os pods que você inicia nas novas sub-redes. Se api-server entrar em contato com os pods com um webhook, o comando kubectl logs ou o comando kubectl exec, você poderá receber a seguinte mensagem de erro:

"failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=10s": Address is not allowed"

AWS OFICIALAtualizada há 4 meses