Como faço para usar vários intervalos CIDR com o Amazon EKS?
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:
- Adicione mais intervalos CIDR para expandir sua rede de nuvem privada virtual (VPC).
- Crie sub-redes com um novo intervalo CIDR.
- Associe sua nova sub-rede a uma tabela de rotas.
- 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:
- Um cluster do Amazon EKS em execução
- Permissões do AWS Identity and Access Management (AWS IAM) para gerenciar uma Amazon VPC
- Um kubectl com permissões para criar recursos personalizados e editar o DaemonSet
- Uma versão instalada do jq em seu sistema
Observação: para baixar e instalar o jq, consulte Baixar jq no site do jq. - Um sistema baseado em Unix com um shell Bash
- Uma VPC configurada
Adicione mais intervalos CIDR para expandir sua rede VPC
Conclua as etapas a seguir:
- 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:
Observação: substitua CLUSTER_NAME pelo nome do seu cluster e REGION_CODE pela região da AWS em que você implantou o cluster.VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text) - 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:
- Para listar todas as Zonas de disponibilidade em sua Região, execute o seguinte comando describe-availability-zones:
Observação: substitua REGION_CODE pela região em que você implantou seus recursos.aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName' - 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.
Observação: substitua AZ1, AZ2 e AZ3 por suas zonas de disponibilidade de sub-rede.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) - (Opcional) Para definir um par de valor-chave para adicionar uma tag de nome às suas sub-redes, execute o seguinte comando create-tags:
Observação: substitua KEY pela chave da tag e VALUE pelo valor da tag.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
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:
-
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 2Se você não tiver a versão correta do plug-in, atualize a CNI da Amazon VPC.
-
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 -
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 -
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 EOFObservaçã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.
-
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. -
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-nodegroupObservação: substitua CLUSTER_NAME pelo nome do cluster e my-nodegroup pelo nome do grupo de nós.
-
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-testObservaçã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"
- Tópicos
- Containers
- Idioma
- Português

Conteúdo relevante
- feita há 15 dias
- feita há 2 meses
- feita há 8 meses
AWS OFICIALAtualizada há 4 meses