Configurar a seleção de sub-redes para endereços IP de pods

Aplica-se a: nós do Linux com instâncias do Amazon EC2

O plug-in CNI da Amazon VPC para Kubernetes cria interfaces de rede elásticas (ENIs) secundárias em seus nós e atribui endereços IP dessas ENIs a pods. Por padrão, a CNI da VPC cria ENIs secundárias na mesma sub-rede que a interface de rede primária do nó. Você pode controlar quais sub-redes a CNI da VPC usa para endereços IP de pods por meio dos seguintes métodos:

• Descoberta aprimorada de sub-redes: a CNI da VPC descobre e usa automaticamente sub-redes marcadas com kubernetes.io/role/cni na mesma VPC e zona de disponibilidade. Requer a versão 1.18.0 ou posterior da CNI da VPC. Recomendamos esse método para a maioria dos casos de uso.

• Rede personalizada: especifique manualmente sub-redes e grupos de segurança por zona de disponibilidade usando recursos personalizados de ENIConfig. Para obter mais informações, consulte Implementar pods em sub-redes alternativas com rede personalizada.

nota

A rede personalizada tem precedência quando os dois recursos estão habilitados.

Descoberta aprimorada de sub-redes

A versão 1.18.0 e posterior da CNI da VPC habilita a descoberta aprimorada de sub-redes por padrão (ENABLE_SUBNET_DISCOVERY=true). A CNI da VPC descobre automaticamente sub-redes na mesma VPC e zona de disponibilidade do nó e as usa para criar ENIs secundárias e alocar endereços IP de pods. Isso expande o espaço de endereços IP disponíveis sem a configuração manual de ENIConfig.

Para verificar se o recurso está habilitado:

kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY

Para desabilitar esse recurso, defina ENABLE_SUBNET_DISCOVERY=false no DaemonSet aws-node.

Comportamento das tags de sub-redes (kubernetes.io/role/cni)

A tag kubernetes.io/role/cni controla como a CNI da VPC trata as sub-redes para operações de ENI e alocação de IPs de pods. A tag tem efeitos diferentes, dependendo se a CNI da VPC está criando uma nova ENI ou reconciliando uma existente.

Importante

Os mecanismos de marcação de escopo de cluster e de exclusão só estão disponíveis a partir da versão v1.22.2 da CNI da VPC. Antes dessa versão, somente o comportamento padrão de opt-in estava disponível por meio da tag kubernetes.io/role/cni=1.

Valores de tags

A seguinte tabela resume como cada valor de tag afeta o comportamento da sub-rede:

Valor da tag	Criação de nova ENI	Reconciliação de ENI existente
1	Opt-in: a CNI da VPC cria novas ENIs nessa sub-rede.	A ENI permanece disponível para alocação de IPs de pods.
0	Excluído: a CNI da VPC não cria novas ENIs nessa sub-rede.	Excluído: a CNI da VPC exclui as ENIs existentes nessa sub-rede da alocação de IPs de pods. Nenhum novo IP de pod é atribuído dessa ENI.
Ausente (nenhuma tag)	Não usado para novas ENIs: a CNI da VPC não seleciona sub-redes secundárias sem a tag para a criação de uma nova ENI. A sub-rede primária (a sub-rede em que o nó foi inicializado) ainda é usada para a criação de novas ENIs, mesmo sem a tag, para compatibilidade com versões anteriores.	Nenhuma interrupção: as ENIs existentes em sub-redes não marcadas permanecem disponíveis para alocação de IPs de pods. A CNI da VPC não remove nem exclui essas ENIs.

Comportamento de criação versus de reconciliação

A CNI da VPC aplica intencionalmente políticas diferentes ao criar novas ENIs e ao reconciliar as ENIs existentes:

• Criação (fail-closed para sub-redes secundárias): quando a CNI da VPC precisa criar uma nova ENI secundária, ele usa apenas sub-redes secundárias explicitamente marcadas com kubernetes.io/role/cni=1. As sub-redes secundárias não marcadas nunca são selecionadas para a criação de uma nova ENI. Isso garante que as novas interfaces de rede sejam colocadas somente em sub-redes que os administradores tenham aprovado explicitamente.

• Reconciliação (fail-open para sub-redes sem tag): quando a CNI da VPC é inicializada ou reconcilia ENIs existentes já anexadas ao nó, ela não exclui ENIs porque sua sub-rede não tem a tag kubernetes.io/role/cni. Isso evita a interrupção da execução de pods que já usam endereços IP dessas ENIs.

A CNI da VPC usa esse design de forma intencional. A exclusão forçada de uma ENI já anexada de uma sub-rede não marcada quebraria os pods que atualmente usam endereços IP dessa ENI.

Importante

Para evitar que uma sub-rede forneça novos IPs de pods, inclusive de ENIs existentes, marque a sub-rede com kubernetes.io/role/cni=0. Uma tag ausente somente impede a criação de uma nova ENI nessa sub-rede. Ela não exclui as ENIs existentes da alocação.

Manipulação de sub-rede primária

A CNI da VPC sempre inclui a sub-rede primária do nó (a sub-rede em que o nó foi inicializado) para a criação da ENI, mesmo sem a tag kubernetes.io/role/cni. Isso mantém a compatibilidade com versões anteriores dos clusters existentes. O comportamento principal da sub-rede:

• Incluído para criação de ENI, independentemente da presença de tags (a menos que esteja marcada como 0).

• Se marcada com kubernetes.io/role/cni=0, a CNI da VPC exclui a sub-rede primária da criação da nova ENI e da alocação de uma ENI existente.

Filtragem de sub-redes no escopo do cluster

Quando uma sub-rede é marcada com kubernetes.io/role/cni=1, a CNI da VPC também verifica as tags específicas do cluster usando o formato de chave cni.networking.k8s.aws/cluster/<cluster-name>. Se uma sub-rede tiver alguma tag de cluster nesse formato, somente o cluster cujo nome corresponde usará essa sub-rede. Sub-redes com kubernetes.io/role/cni=1 e sem tags específicas de cluster estão disponíveis para todos os clusters na VPC.

Por exemplo, para restringir uma sub-rede a um cluster específico:

aws ec2 create-tags --resources subnet-example \
  --tags Key=kubernetes.io/role/cni,Value=1 Key=cni.networking.k8s.aws/cluster/my-cluster,Value=shared

Isso é útil quando vários clusters do EKS compartilham uma VPC e você quer que cada cluster use sub-redes diferentes para endereços IP de pods.

Fluxo de trabalho recomendado

Para adicionar novas sub-redes para endereços IP de pods:

1. Crie novas sub-redes na mesma VPC e zona de disponibilidade que seus nós.

2. Marque as sub-redes com kubernetes.io/role/cni=1.

3. Certifique-se de que as sub-redes tenham tabelas de rotas e ACLs de rede apropriadas.

4. Verifique se a CNI da VPC descobre e começa a usar as novas sub-redes.

Para remover uma sub-rede da alocação de IPs de pods:

1. Marque a sub-rede com kubernetes.io/role/cni=0.

2. Espere até que os pods usando IPs dessa sub-rede sejam encerrados ou reprogramados naturalmente.

3. Verifique se a CNI da VPC interrompe a alocação de novos IPs de pods de ENIs nessa sub-rede.

Importante

Não remova a tag kubernetes.io/role/cni para parar de usar uma sub-rede. A remoção da tag impede a criação de novas ENIs, mas não exclui as ENIs existentes da alocação. Para excluir ativamente uma sub-rede, marque-a com kubernetes.io/role/cni=0.

Considerações

• A descoberta aprimorada de sub-redes requer a versão 1.18.0 ou posterior da CNI da Amazon VPC.

• O recurso requer a permissão ec2:DescribeSubnets no perfil do IAM da CNI da VPC. A política gerenciada AmazonEKS_CNI_Policy inclui essa permissão. A política do IAM autogerenciada de IPv6 não a inclui. Se você usa uma política do IAM autogerenciada (por exemplo, para clusters IPv6), adicione ec2:DescribeSubnets manualmente para habilitar a descoberta de sub-rede.

• O recurso funciona com o modo de endereço IP secundário e o modo de delegação de prefixo.

• Todas as sub-redes descobertas devem estar na mesma VPC que o nó.

• A CNI da VPC cria ENIs somente em sub-redes que estão na mesma zona de disponibilidade que o nó.

• A CNI da VPC não desaloca ENIs que ainda têm endereços IP atribuídos aos pods, independentemente das alterações de tags.

• Ao usar VPCs compartilhadas (sub-redes entre contas), marque as sub-redes na conta do participante em que o cluster é inicializado.

• Você pode usar a descoberta aprimorada de sub-rede junto com grupos de segurança para pods, políticas de rede, delegação de prefixos e SNAT.