Bilanciamento del carico di rete su Amazon EKS - Amazon EKS
Creazione di un load balancer di rete(Facoltativo) Implementare un'applicazione di esempio

Bilanciamento del carico di rete su Amazon EKS

Il traffico di rete è bilanciato al carico L4 del modello OSI. Per bilanciare il carico del traffico delle applicazioni in L7, si implementa un Kubernetes ingress, che fornisce un Application Load Balancer AWS. Per ulteriori informazioni, consulta Bilanciamento del carico di applicazione su Amazon EKS. Per ulteriori informazioni sulle differenze tra i due tipi di bilanciamento del carico, consulta le caratteristiche di Elastic Load Balancing sul sito Web AWS.

Quando crei un Service Kubernetes di tipo LoadBalancer, il controller del load balancer del provider cloud AWS crea Classic Load Balancer AWS per impostazione predefinita, ma può creare anche AWS Network Load Balancer. Questo controller in futuro riceverà solo correzioni di bug critici. Per ulteriori informazioni sull'utilizzo del load balancer del provider cloud AWS, consulta Controller del load balancer del provider cloud AWS nella documentazione di Kubernetes. Il suo utilizzo non è descritto in questo argomento.

Consigliamo di utilizzare la versione 2.4.4 o una versione successiva di AWS Load Balancer Controller anziché il controller del load balancer del provider del cloud AWS. Il AWS Load Balancer Controller crea Network Load Balancers AWS, ma non Classic Load Balancer AWS. Nella parte restante di questo argomento viene trattato l'utilizzo del controller del load balancer AWS.

Un Network Load Balancer AWS è in grado di bilanciare il carico del traffico di rete ai pods implementati su destinazioni di IP o istanze Amazon EC2 o destinazioni IP di AWS Fargate. Per ulteriori informazioni, consulta Controller del load balancer AWS su GitHub.

Prerequisiti

Prima di eseguire il bilanciamento del carico del traffico di rete utilizzando il AWS Load Balancer Controller, è necessario soddisfare i seguenti requisiti.

  • Avere un cluster esistente. Se non si dispone di un cluster esistente, consultare Guida introduttiva ad Amazon EKS. Se è necessario aggiornare la versione di un cluster esistente, vedere Aggiornamento della versione di Kubernetes del cluster Amazon EKS.

  • Aver implementato AWS Load Balancer Controller nel cluster. Per ulteriori informazioni, consulta Installazione del componente aggiuntivo AWS Load Balancer Controller. Consigliamo la versione 2.4.4 o successiva.

  • Disporre di almeno una sottorete. Se si trovano più sottoreti con tag in una zona di disponibilità, il controller sceglie la sottorete il cui ID sottorete viene prima in ordine lessicografico. La sottorete deve avere a disposizione almeno otto indirizzi IP.

  • Se si utilizza il AWS Load Balancer Controller versione 2.1.1 o precedente, le sottoreti devono essere taggate come segue. Se si utilizza la versione 2.1.2 o successiva, questo tag è facoltativo. È possibile taggare una sottorete se si dispone di più cluster in esecuzione nello stesso VPC o di più servizi AWS che condividono sottoreti in un VPC e richiedono un maggiore controllo sulla posizione in cui viene eseguito il provisioning dei bilanciatori di carico per ciascun cluster. Se specifichi in modo esplicito gli ID sottorete come annotazione su un oggetto di servizio, Kubernetes e il AWS Load Balancer Controller utilizzano queste sottoreti direttamente per creare il load balancer. Il tagging delle sottoreti non è obbligatorio se si sceglie di utilizzare questo metodo per il provisioning dei load balancer ed è possibile ignorare i seguenti requisiti di assegnazione di tag delle sottoreti pubbliche e private. Sostituisci my-cluster con il nome del cluster.

    • Chiave: kubernetes.io/cluster/my-cluster

    • Valore: shared o owned

  • Le sottoreti pubbliche e private devono soddisfare i seguenti requisiti, a meno che non si specifichino esplicitamente gli ID sottorete come annotazione in un oggetto di servizio o di ingresso. Se effettui il provisioning dei load balancer specificando esplicitamente gli ID sottorete come annotazione in un oggetto di servizio o di ingresso, Kubernetes e il AWS Load Balancer Controller utilizzano queste sottoreti direttamente per creare il load balancer e non sono quindi necessari i seguenti tag.

    • Sottoreti private: deve essere taggato nel seguente formato. In tal modo, Kubernetes e il controller del load balancer AWS sono consapevoli che le sottoreti possono essere utilizzate per i load balancer interni. Se si utilizza eksctl o un modello AWS AWS CloudFormation Amazon EKS per creare il VPC in data successiva al 26 marzo 2020, le sottoreti vengono taggate in maniera appropriata al momento della creazione. Per ulteriori informazioni sui modelli AWS AWS CloudFormation VPC Amazon EKS, vedere Creazione di un VPC per il cluster Amazon EKS.

      • Chiave: kubernetes.io/role/internal-elb

      • Valore: 1

    • Sottoreti pubbliche: deve essere taggato nel seguente formato. In questo modo, Kubernetes utilizza solo tali sottoreti per load balancer esterni, anziché scegliere una sottorete pubblica in ciascuna zona di disponibilità (in ordine lessicografico per ID sottorete). Se si utilizza eksctl o un modello AWS CloudFormation Amazon EKS per creare il VPC in data successiva al 26 marzo 2020, le sottoreti vengono taggate in maniera appropriata al momento della creazione. Per ulteriori informazioni sui modelli AWS CloudFormation VPC Amazon EKS, vedere Creazione di un VPC per il cluster Amazon EKS.

      • Chiave: kubernetes.io/role/elb

      • Valore: 1

    Se i tag del ruolo della sottorete non vengono aggiunti in modo esplicito, il controller del servizio Kubernetes esamina la tabella di instradamento delle sottoreti VPC del cluster per determinare se la sottorete è privata o pubblica. Si consiglia di non fare affidamento su questo comportamento e di aggiungere esplicitamente i tag di ruolo pubblici o privati. Il AWS Load Balancer Controller non esamina le tabelle di instradamento e richiede che i tag privati e pubblici siano presenti per il rilevamento automatico corretto.

Considerazioni

  • La configurazione del load balancer è controllata da annotazioni che vengono aggiunte al manifest del servizio. Le annotazioni del servizio sono diverse quando si utilizza il AWS Load Balancer Controller rispetto a quando si utilizza il controller del load balancer del provider cloud AWS. Assicurarsi di rivedere le annotazioni per il AWS Load Balancer Controller prima di implementare i servizi.

  • Quando utilizzi Amazon VPC CNI plugin for Kubernetes, il AWS Load Balancer Controller è in grado di bilanciare il carico su destinazioni IP o di istanza Amazon EC2 e su destinazioni IP Fargate. Quando utilizzi plug-in CNI compatibili alternativi, il controller può bilanciare il carico solo per le destinazioni istanza. Per ulteriori informazioni sui tipi di destinazioni dei Network Load Balancer, consultare Target type (Tipo di destinazione) nella Guida per l'utente di Network Load Balancer.

  • Se si desidera aggiungere tag al load balancer quando o dopo la sua creazione, aggiungere la seguente annotazione nella specifica del servizio. Per ulteriori informazioni, consulta Tag delle risorse AWS nella documentazione di AWS Load Balancer Controller.

    service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags

  • È possibile assegnare Indirizzi IP elastici al Network Load Balancer aggiungendo la seguente annotazione. Sostituire i example values con gli Allocation IDs degli indirizzi IP elastici. Il numero di Allocation IDs deve corrispondere al numero di sottoreti utilizzate per il load balancer. Per ulteriori informazioni, consulta la documentazione AWS Load Balancer Controller.

    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-xxxxxxxxxxxxxxxxx,eipalloc-yyyyyyyyyyyyyyyyy

  • Amazon EKS aggiunge una regola in entrata al gruppo di sicurezza del nodo per il traffico client e una regola per ogni sottorete del load balancer nel VPC per i controlli dell'integrità di ogni Network Load Balancer creato. L'implementazione di un servizio di tipo LoadBalancer può non riuscire se Amazon EKS prova a creare regole che superano la quota per il numero massimo di regole consentito per un gruppo di sicurezza. Per ulteriori informazioni, consultare Gruppi di sicurezza in Quote di Amazon VPC nella Guida per l'utente di Amazon VPC. Considerare le opzioni seguenti per ridurre al minimo le possibilità di superare il numero massimo di regole per un gruppo di sicurezza:

    • Richiedere un aumento delle regole per ogni quota di gruppo di sicurezza. Per ulteriori informazioni, consultare Richiesta di un aumento di quota nella Guida per l'utente di Service Quotas.

    • Al posto di destinazioni di istanza, utilizzare destinazioni IP. Con le destinazioni IP, è possibile condividere le regole per le stesse porte di destinazione. È possibile specificare manualmente le sottoreti del load balancer con un'annotazione. Per ulteriori informazioni, consulta Annotazioni su GitHub.

    • Utilizzare un ingresso invece di un servizio di tipo LoadBalancer per inviare traffico al tuo servizio. L'Application Load Balancer AWS richiede meno regole rispetto ai Network Load Balancer. È possibile condividere un ALB su più ingressi. Per ulteriori informazioni, consulta Bilanciamento del carico di applicazione su Amazon EKS. Non è possibile condividere un Network Load Balancer su più servizi.

    • Implementa i cluster su più account.

  • Se i pods vengono eseguiti su Windows in un cluster Amazon EKS, un singolo servizio con un load balancer può supportare fino a 1024 pods di back-end. Ogni pod ha il proprio indirizzo IP univoco.

  • Si consiglia di creare solo nuovi Network Load Balancer con il AWS Load Balancer Controller. Il tentativo di sostituire Network Load Balancer esistenti creati con il controller del load balancer del provider cloud AWS potrebbe risultare in più Network Load Balancer che possono causare tempi di inattività dell'applicazione.

Creazione di un load balancer di rete

È possibile creare un di load balancer di rete con destinazioni IP o istanza.

IP targets

Puoi utilizzare le destinazioni IP con pods implementati su nodi Amazon EC2 o Fargate. Il servizio Kubernetes deve essere creato come tipo LoadBalancer. Per ulteriori informazioni, consulta Tipo LoadBalancer nella documentazione di Kubernetes.

Per creare un load balancer che utilizzi destinazioni IP, aggiungere le seguenti annotazioni a un manifesto del servizio e implementare il servizio. Il valore external per aws-load-balancer-type è responsabile del AWS Load Balancer Controller e non del controller del load balancer del provider cloud AWS per la creazione del Network Load Balancer. É possibile visualizzare un manifesto del servizio di esempio con le annotazioni.

service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
Nota

Se stai eseguendo il bilanciamento del carico sui pods IPv6, aggiungi la seguente annotazione alla specifica. È possibile bilanciare il carico solo su destinazioni da IPv6 a IP, non su destinazioni di istanza. Senza questa annotazione, il bilanciamento del carico è su IPv4.

service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack

Per impostazione predefinita, i Network Load Balancer vengono creati con internal aws-load-balancer-scheme. Puoi avviare i Network Load Balancer in qualunque sottorete nel VPC del tuo cluster, incluse sottoreti non specificate quando hai creato il cluster.

Kubernetes esamina la tabella di instradamento delle sottoreti per stabilire se sono pubbliche o private. Le sottoreti pubbliche hanno una route direttamente a Internet tramite un gateway Internet; non vale altrettanto per le sottoreti private.

Se si desidera creare un Network Load Balancer in una sottorete pubblica per il bilanciamento del carico sui nodi Amazon EC2 (Fargate può essere solo privato), specificare internet-facing con la seguente annotazione:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Nota

Al fine di garantire la compatibilità con le versioni precedenti, l'annotazione service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" è ancora supportata. Consigliamo, tuttavia, di utilizzare le annotazioni precedenti per i load balancer anziché service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip".

Importante

Non modificare le annotazioni dopo aver creato il servizio. Se è necessario modificarlo, eliminare l'oggetto di servizio e crearlo nuovamente con il valore desiderato per questa annotazione.

Instance targets

Il controller del load balancer del provider cloud AWS crea Network Load Balancer solo con destinazioni di istanza. La versione 2.2.0 e successive di AWS Load Balancer Controller crea anche Network Load Balancer con destinazioni di istanza. Consigliamo di utilizzarlo al posto del controller del load balancer del provider cloud AWS per creare nuovi Network Load Balancer. Puoi utilizzare le destinazioni di istanza di Network Load Balancer con pods implementati sui nodi Amazon EC2, ma non in Fargate. Per bilanciare il carico del traffico di rete tra i pods implementati in Fargate, è necessario utilizzare destinazioni IP.

Per implementare un Network Load Balancer in una sottorete privata, la specifica del servizio deve avere le seguenti annotazioni. É possibile visualizzare un manifesto del servizio di esempio con le annotazioni. Il valore external per aws-load-balancer-type è responsabile del controller del load balancer AWS e non del controller del load balancer del provider cloud AWS per la creazione del Network Load Balancer.

service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"

Per impostazione predefinita, i Network Load Balancer vengono creati con internal aws-load-balancer-scheme. Per i Network Load Balancer interni, il cluster Amazon EKS deve essere configurato per l'utilizzo di almeno una sottorete privata nel VPC. Kubernetes esamina latabella di instradamento delle sottoreti per stabilire se sono pubbliche o private. Le sottoreti pubbliche hanno una route direttamente a Internet tramite un gateway Internet; non vale altrettanto per le sottoreti private.

Se si desidera creare un Network Load Balancer in una sottorete pubblica per il bilanciamento del carico sui nodi Amazon EC2, specificare internet-facing con la seguente annotazione:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Importante

Non modificare le annotazioni dopo aver creato il servizio. Se è necessario modificarlo, eliminare l'oggetto di servizio e crearlo nuovamente con il valore desiderato per questa annotazione.

(Facoltativo) Implementare un'applicazione di esempio

Prerequisiti
Per implementare un'applicazione di esempio

  1. Se stai eseguendo l'implementazione su Fargate, assicurati di avere una sottorete privata disponibile nel VPC e di creare un profilo Fargate. Se non stai eseguendo l'implementazione su Fargate, salta questa fase. É possibile creare il profilo eseguendo il seguente comando o nella AWS Management Console utilizzando gli stessi valori per name e namespace che si trovano nel comando. Sostituire il example values con quello in proprio possesso.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name nlb-sample-app \
    --namespace nlb-sample-app

  2. Implementa un'applicazione di esempio.

    1. Crea uno spazio dei nomi per l'applicazione.

      kubectl create namespace nlb-sample-app

    2. Salva nel computer i seguenti contenuti in un file denominato sample-deployment.yaml.

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: nlb-sample-app
  namespace: nlb-sample-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: public.ecr.aws/nginx/nginx:1.21
          ports:
            - name: tcp
              containerPort: 80

    3. Applica il file manifesto al cluster.

      kubectl apply -f sample-deployment.yaml

  3. Crea un servizio con un Network Load Balancer connesso a Internet che bilanci il carico sulle destinazioni IP.

    1. Salva nel computer i seguenti contenuti in un file denominato sample-service.yaml. Se stai eseguendo l'implementazione sui nodi Fargate, rimuovi la riga service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing.

      apiVersion: v1
kind: Service
metadata:
  name: nlb-sample-service
  namespace: nlb-sample-app
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app: nginx

    2. Applica il file manifesto al cluster.

      kubectl apply -f sample-service.yaml

  4. Verificare che il servizio sia stato implementato.

    kubectl get svc nlb-sample-service -n nlb-sample-app

    Di seguito è riportato l'output di esempio.

    NAME            TYPE           CLUSTER-IP         EXTERNAL-IP                                                                    PORT(S)        AGE
sample-service  LoadBalancer   10.100.240.137   k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com  80:32400/TCP   16h
    Nota

    I valori per 10.100.240.137 e xxxxxxxxxx-xxxxxxxxxxxxxxxx saranno diversi da quelli dell'output di esempio (saranno univoci per il load balancer) e us-west-2 potrebbero essere diversi per te, a seconda della Regione AWS in cui si trova il cluster.

  5. Apri la AWS Management Console Amazon EC2. Seleziona Target Groups (Gruppi di destinazioni) in Load Balancing (Bilanciamento del carico) nel pannello di navigazione a sinistra. Nella colonna Nome, seleziona il nome del gruppo di destinazione in cui il valore nella colonna load balancer corrisponde al nome nella colonna EXTERNAL-IP dell'output nella fase precedente. Ad esempio, se l'output era uguale all'output indicato sopra sarà necessario selezionare il gruppo di destinazione denominato k8s-default-samplese-xxxxxxxxxx. Target type (Tipo di destinazione) è IP perché è stato specificato nel manifesto del servizio di esempio.

  6. Selezionare il proprio Gruppo di destinazione e poi scegliere la scheda Destinazioni. In Destinazioni registrate, verranno visualizzati tre indirizzi IP delle tre repliche implementate in un passaggio precedente. Prima di continuare, attendere fino a quando lo stato di tutti gli obiettivi è Integro. Potrebbero passare diversi minuti prima che tutti gli obiettivi siano healthy. Gli obiettivi potrebbero essere in uno stato unhealthy prima di passare a uno stato healthy.

  7. Invia il traffico al servizio sostituendo xxxxxxxxxx-xxxxxxxxxxxxxxxx e us-west-2 con i valori restituiti nell'output di un'operazione precedente per EXTERNAL-IP. Se è stata eseguita l'implementazione a una sottorete privata, devi visualizzare la pagina da un dispositivo all'interno del VPC, ad esempio un bastion host. Per ulteriori informazioni, consulta Host bastione Linux su AWS.

    curl k8s-default-samplese-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com

    Di seguito è riportato l'output di esempio.

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

  8. Al termine dell'implementazione, del servizio e dello spazio dei nomi di esempio, rimuoverli.

    kubectl delete namespace nlb-sample-app