Subnet del bilanciatore del carico

Questa pagina descrive come GKE su AWS funziona con AWS per scegliere le subnet per i bilanciatori del carico del servizio e come taggare le subnet da rilevare automaticamente durante la creazione del bilanciatore del carico del servizio.

Perché devi specificare le subnet

Quando crei i bilanciatori del carico, AWS deve sapere in quali subnet inserirli. La subnet determina le zone di disponibilità, gli indirizzi IP e gli endpoint del bilanciatore del carico.

In genere, i bilanciatori del carico vengono allocati in una subnet per ogni zona di disponibilità contenente un pool di nodi. AWS richiede un minimo di una subnet disponibile per creare un bilanciatore del carico di rete (NLB) e un minimo di due subnet per un bilanciatore del carico delle applicazioni (ALB).

Tutte le subnet AWS sono pubbliche (con IP pubblici e una route al gateway internet del VPC) o private (senza queste funzionalità). I bilanciatori del carico per internet devono trovarsi in subnet pubbliche. I bilanciatori del carico interni possono risiedere in subnet pubbliche o private.

Se non sono disponibili subnet con tag

Se GKE su AWS deve creare un bilanciatore del carico e non sono disponibili subnet con tag o non hanno capacità, potrebbe creare il bilanciatore del carico in un'altra subnet. Per evitare questo problema e controllare le subnet in cui vengono inseriti i bilanciatori del carico, devi taggare tutte le subnet.

Rilevamento automatico delle subnet

GKE su AWS rileva automaticamente le subnet da utilizzare per un bilanciatore del carico elencando tutte le subnet nel VPC e selezionando fino a una subnet da ogni zona di disponibilità.

Affinché GKE su AWS rilevi automaticamente una subnet, questa deve:

  • Avere il tag kubernetes.io/role/elb (per un bilanciatore del carico per internet)
  • Avere il tag kubernetes.io/role/internal-elb (per un bilanciatore del carico interno)
  • Non contenere tag con il prefisso kubernetes.io/cluster/ oppure contenere il tag kubernetes.io/cluster/CLUSTER_UID, dove CLUSTER_UID è l'UID del cluster corrente.

Inoltre, una subnet destinata all'uso con un bilanciatore del carico per internet deve avere una route al gateway internet del VPC.

Se in una zona di disponibilità sono presenti diverse subnet che soddisfano i requisiti del bilanciatore del carico, GKE su AWS classifica le subnet in base al relativo ID.

Tagga le subnet per l'uso previsto

Affinché GKE su AWS rilevi automaticamente una subnet per un bilanciatore del carico, devi applicare uno dei due tag alla subnet per segnalarne la disponibilità. Questi sono:

  • kubernetes.io/role/elb: applica questo tag alla subnet per contrassegnarla come disponibile per un bilanciatore del carico per internet. Deve essere una subnet pubblica con una route al gateway internet del VPC. Imposta il tag su 1. Per applicare questo tag, esegui il comando seguente:

    aws ec2 create-tags \
      --resources SUBNET_ID \
      --tags "Key=kubernetes.io/role/elb,Value=1"
    
  • kubernetes.io/role/internal-elb: applica questo tag alla subnet per contrassegnarla come disponibile per un bilanciatore del carico interno. Imposta il valore del tag su 1. Per applicare questo tag, esegui il comando seguente:

    aws ec2 create-tags \
      --resources SUBNET_ID \
      --tags Key=kubernetes.io/role/internal-elb,Value=1
    

Sostituisci quanto segue:

  • SUBNET_ID: l'ID della subnet che stai taggando

Dopo aver assegnato alla subnet un tag kubernetes.io/role, puoi anche taggarla con uno o più tag kubernetes.io/cluster/CLUSTER_UID, dove CLUSTER_UID è l'UID di un cluster GKE su AWS. In questo modo, nessun cluster non elencato in uno di questi tag può rilevare automaticamente la subnet per l'utilizzo da parte dei relativi bilanciatori del carico.

Per ulteriori informazioni sul comando aws ec2 create-tags, consulta la documentazione di Amazon aws ec2 create-tags.

Risoluzione dei problemi

Il problema più comune con la configurazione del bilanciatore del carico è la presenza di subnet con tag errati. Questo può causare la selezione di subnet errate da parte dell'algoritmo di rilevamento automatico. Per diagnosticare e risolvere questo problema:

  • Se stai creando un bilanciatore del carico per internet, assicurati che in ognuna delle zone di disponibilità che contengono un pool di nodi sia presente almeno una subnet pubblica e che le subnet siano taggate con kubernetes.io/role/elb.

  • Se stai creando un bilanciatore del carico interno, assicurati che in ognuna delle zone di disponibilità che contengono un pool di nodi sia presente almeno una subnet e che le subnet siano taggate con kubernetes.io/role/internal-elb.

  • Controlla se le subnet che vuoi rilevare automaticamente hanno tag nel formato kubernetes.io/cluster/CLUSTER_UID. Se una subnet ha tag di questo tipo che nominano un cluster, la subnet può essere rilevata automaticamente solo dai cluster denominati. Per risolvere il problema, elimina tutti i tag dei nomi dei cluster (per consentire il rilevamento automatico della subnet da qualsiasi cluster) o aggiungi un tag del nome del cluster con l'UID del cluster GKE su AWS e il valore shared.

  • Controlla la cronologia degli eventi Kubernetes con il comando seguente:

    kubectl get events -A | grep LoadBalancer
    

    Ad esempio, il messaggio di evento could not find any suitable subnets for creating the ELB indica che non è stato possibile rilevare automaticamente alcuna subnet. Se ricevi questo avviso, assicurati che le subnet e i relativi tag siano corretti e completi.

  • Per elencare le subnet che possono essere rilevate automaticamente per i bilanciatori del carico per internet, esegui il comando seguente:

    aws ec2 describe-subnets \
      --filters "Name=vpc-id,Values=VPC_ID" "Name=tag:kubernetes.io/role/elb,Values=*"
    

    Sostituisci VPC_ID con l'ID del tuo VPC.

  • Per elencare le subnet che possono essere rilevate automaticamente per i bilanciatori del carico interni, esegui:

    aws ec2 describe-subnets \
      --filters "Name=vpc-id,Values=VPC_ID" "Name=tag:kubernetes.io/role/internal-elb,Values=*"
    

Passaggi successivi