Subnet del bilanciatore del carico

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

Perché devi specificare le subnet

Durante la creazione dei bilanciatori del carico, AWS deve sapere in quali subnet posizionarli. La subnet determina zone di disponibilità, indirizzi IP ed endpoint del bilanciatore del carico.

Normalmente, i bilanciatori del carico sono allocati a una subnet per ogni zona di disponibilità contenente un pool di nodi. AWS richiede almeno una subnet disponibile per creare un bilanciatore del carico di rete (NLB) e un minimo di due subnet per un Application Load Balancer (ALB).

Tutte le subnet AWS sono pubbliche (con IP pubblici e una route per il 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 trovarsi 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 hanno capacità, potrebbe creare il bilanciatore del carico in un'altra subnet. Per evitare che ciò accada e controllare in quali subnet sono inseriti i bilanciatori del carico, è consigliabile aggiungere un tag a tutte le subnet.

Rilevamento automatico subnet

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

Affinché GKE su AWS possa rilevare automaticamente una subnet, la subnet 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 devono contenere tag con il prefisso kubernetes.io/cluster/ o contenere il tag kubernetes.io/cluster/CLUSTER_UID, dove CLUSTER_UID è l'UID attuale del cluster.

Inoltre, una subnet destinata a essere utilizzata con un bilanciatore del carico rivolto a internet deve avere una route al gateway internet del VPC.

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

Applica il tagging alle subnet per l'uso previsto

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

  • kubernetes.io/role/elb: applica questo tag alla subnet per contrassegnarlo 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 contrassegnarlo 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 in cui stai eseguendo il tagging

Dopo aver assegnato alla subnet un tag kubernetes.io/role, puoi anche codificarla con uno o più tag kubernetes.io/cluster/CLUSTER_UID, dove CLUSTER_UID è l'UID di un cluster GKE su AWS. Questo impedisce a qualsiasi cluster non elencato in uno di questi tag di rilevare automaticamente la subnet per l'utilizzo da parte dei bilanciatori del carico.

Consulta la documentazione di Amazon aws ec2 create-tags per ulteriori informazioni sul comando aws ec2 create-tags.

Risoluzione dei problemi

Il problema più comune della configurazione del bilanciatore del carico è rappresentato dalle subnet contrassegnate in modo errato. Di conseguenza, l'algoritmo di rilevamento automatico potrebbe selezionare le subnet sbagliate. Per diagnosticare e risolvere il problema:

  • Se stai creando un bilanciatore del carico per internet, assicurati che in ciascuna zona di disponibilità sia presente almeno una subnet pubblica che contiene un pool di nodi e che le subnet siano contrassegnate con il tag kubernetes.io/role/elb.

  • Se stai creando un bilanciatore del carico interno, assicurati che in ciascuna zona di disponibilità sia presente almeno una subnet che contiene un pool di nodi e che le subnet siano contrassegnate con il tag kubernetes.io/role/internal-elb.

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

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

    kubectl get events -A | grep LoadBalancer

    Ad esempio, il messaggio evento could not find any suitable subnets for creating the ELB indica che non è possibile rilevare automaticamente subnet. Se viene visualizzato 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 questo comando:

    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