Instradare il traffico di applicazioni e HTTP con Application Load Balancer - Amazon EKS
PrerequisitiRiutilizzare ALB con gruppi di ingresso(Facoltativo) Implementare un’applicazione di esempio

Contribuisci a migliorare questa pagina

Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.

Instradare il traffico di applicazioni e HTTP con Application Load Balancer

Nota

Novità: Amazon EKS Auto Mode automatizza le attività di routine per il bilanciamento del carico. Per ulteriori informazioni, consulta:

Quando crei un ingress Kubernetes, viene eseguito il provisioning di un Application Load Balancer AWS (ALB) per bilanciare il carico del traffico dell’applicazione. Per ulteriori informazioni, consulta Cos’è un Application Load Balancer? nella Guida per l’utente di Application Load Balancer e Ingressi nella documentazione Kubernetes. Gli ALB possono essere utilizzati con pod implementati sui nodi o su AWS Fargate. È possibile implementare un ALB a sottoreti pubbliche o private.

Il traffico delle applicazioni è bilanciato a L7 del modello OSI. Per bilanciare il carico del traffico di rete a L4, implementare un service Kubernetes del tipo LoadBalancer. Questo tipo prevede un AWS Network Load Balancer. Per ulteriori informazioni, consulta Esecuzione del routing del traffico TCP e UDP con Network Load Balancer. Per ulteriori informazioni sulle differenze tra i due tipi di bilanciamento del carico, consulta le caratteristiche di Elastic Load Balancing sul sito Web AWS.

Prerequisiti

Prima di poter bilanciare il carico del traffico dell’applicazione in un’applicazione, è necessario soddisfare i seguenti requisiti.

  • Avere un cluster esistente. Se non disponi di un cluster esistente, consulta Nozioni di base su Amazon EKS. Se è necessario aggiornare la versione di un cluster esistente, vedere Aggiornamento del cluster esistente alla nuova versione di Kubernetes.

  • Avere il Controller del load balancer AWS implementato sul cluster. Per ulteriori informazioni, consulta Indirizza il traffico Internet con AWS Load Balancer Controller. Consigliamo la versione 2.7.2 o successiva.

  • Almeno due sottoreti devono trovarsi in diverse zone di disponibilità. Il controller del bilanciatore del carico di AWS sceglie una sottorete per ogni zona di disponibilità. Quando si trovano più sottoreti taggate in una zona di disponibilità, il controller sceglie la sottorete il cui ID sottorete viene prima in ordine lessicografico. Ogni sottorete deve avere a disposizione almeno otto indirizzi IP.

    Se utilizzi più gruppi di sicurezza collegati al nodo (worker), esattamente un gruppo di sicurezza deve essere taggato come segue. Sostituire my-cluster con il nome del cluster.

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

    • Valore: shared o owned

  • Se utilizzi il controller del bilanciatore del carico AWS versione 2.1.1 o precedenti, le sottoreti devono essere taggate nel formato seguente. Se utilizzi la versione 2.1.2 o successiva, l’assegnazione di tag è facoltativa. Tuttavia, si consiglia di taggare una sottorete nel caso si verifichi una delle seguenti situazioni. Si dispone di più cluster che sono in esecuzione nello stesso VPC o hanno più servizi AWS che condividono sottoreti in un VPC. Oppure, si desidera un maggiore controllo sulla posizione in cui viene eseguito il provisioning dei bilanciatori di carico per ciascun cluster. Sostituire 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. Ciò avviene a condizione che non si indichino esplicitamente gli ID sottorete come annotazione in un oggetto di servizio o di ingresso. Si supponga di effettuare il provisioning dei load balancer specificando esplicitamente gli ID sottorete come annotazione in un oggetto di servizio o di ingresso. In questa situazione, Kubernetes e il controller del bilanciatore del carico AWS utilizzeranno queste sottoreti direttamente per creare il bilanciatore del carico. Non saranno 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 bilanciatori di carico interni. Se utilizzi eksctl o un modello AWS CloudFormation di 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 VPC CloudFormation AWS Amazon EKS, consulta Creazione di un Amazon 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 sa di utilizzare solo le sottoreti specificate per i load balancer esterni. In questo modo, Kubernetes non sceglie una sottorete pubblica in ogni zona di disponibilità (in base all’ordine lessicografico degli ID sottorete). Se utilizzi eksctl o un modello AWS CloudFormation di 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 VPC CloudFormation AWS Amazon EKS, consulta Creazione di un Amazon 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 routing delle sottoreti VPC del cluster. Ciò consente di determinare se la sottorete è privata o pubblica. Si consiglia di non fare affidamento su questo comportamento. È preferibile, invece, aggiungere esplicitamente i tag del ruolo privato o pubblico. Il controller del bilanciatore del carico AWS non esamina le tabelle di routing. Richiede inoltre la presenza di tag privati e pubblici per un efficiente rilevamento automatico.

  • Il controller del load balancer AWS crea gli ALB e le risorse AWS di supporto necessarie ogni volta che una risorsa di ingresso Kubernetes viene creata nel cluster con l’annotazione kubernetes.io/ingress.class: alb. La risorsa di ingresso configura l’ALB per instradare il traffico HTTP o HTTPS verso pod differenti all’interno del cluster. Per fare in modo che gli oggetti di ingresso utilizzino il controller del load balancer AWS, aggiungere la seguente annotazione alla specifica di ingresso Kubernetes. Per ulteriori informazioni, consulta Specifiche di ingresso su GitHub.

    annotations:
    kubernetes.io/ingress.class: alb
    Nota

    Se bilanci il carico sui pod IPv6, aggiungi la seguente annotazione alla specifica di ingresso. È 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.

    alb.ingress.kubernetes.io/ip-address-type: dualstack

  • Il controller del load balancer AWS supporta le seguenti modalità di traffico:

    • Istanza: registra i nodi all’interno del cluster come destinazioni per l’ALB. Il traffico che raggiunge l’ALB viene indirizzato a NodePort per il servizio e quindi inoltrato ai pod. Questa è la modalità di traffico predefinita. È anche possibile specificarla esplicitamente con l’annotazione alb.ingress.kubernetes.io/target-type: instance.

      Nota

      Il servizio Kubernetes deve specificare il tipo NodePort o LoadBalancer per utilizzare questa modalità di traffico.

    • IP – Registra i pod come destinazioni per l’ALB. Il traffico che raggiunge l’ALB viene indirizzato direttamente ai pod per il servizio. È necessario specificare l’annotazione alb.ingress.kubernetes.io/target-type: ip per utilizzare questa modalità di traffico. Il tipo di destinazione IP è richiesto quando i pod di destinazione sono in esecuzione su Fargate o Amazon EKS Hybrid Nodes.

  • Per assegnare i tag agli ALB creati dal controller, aggiungere la seguente annotazione al controller: alb.ingress.kubernetes.io/tags. Per un elenco di tutte le annotazioni disponibili supportate dal Controller del load balancer AWS, vedere Annotazioni in ingresso su GitHub.

  • L’aggiornamento o il downgrade della versione del controller ALB può introdurre modifiche importanti alle funzionalità che si basano su di essa. Per ulteriori informazioni sulle modifiche che vengono introdotte in ogni versione, fare riferimento alle note di rilascio del controller ALB su GitHub.

Riutilizzare ALB con gruppi di ingresso

Puoi condividere un Application Load Balancer su più risorse di servizio tramite IngressGroups.

Per aggiungere un ingresso a un gruppo, aggiungere la seguente annotazione a una specifica di risorsa di ingresso Kubernetes.

alb.ingress.kubernetes.io/group.name: my-group

Il nome del gruppo deve:

  • Avere una lunghezza pari o inferiore a 63 caratteri.

  • Essere formato da lettere minuscole, numeri, -, e .

  • Iniziare e finire con una lettera o un numero.

Il controller unisce automaticamente le regole di ingresso per tutti gli ingressi nello stesso gruppo di ingresso. Le supporta con un singolo ALB. La maggior parte delle annotazioni definite in un ingresso si applica solo ai percorsi definiti da tale ingresso. Per impostazione predefinita, le risorse in ingresso non appartengono ad alcun gruppo di ingresso.

avvertimento

Potenziale rischio per la sicurezza

Specifica un gruppo di ingressi per un ingresso solo quando tutti gli utenti Kubernetes che dispongono dell’autorizzazione RBAC per creare o modificare le risorse di ingresso rientrano nello stesso limite di attendibilità. Se si aggiunge l’annotazione con un nome di gruppo, altri utenti Kubernetes potrebbero creare o modificare i propri ingressi così da appartenere allo stesso gruppo di ingressi. Ciò può causare comportamenti indesiderati, ad esempio la sovrascrittura delle regole esistenti con regole con priorità più alta.

Puoi aggiungere un numero d’ordine della risorsa di ingresso.

alb.ingress.kubernetes.io/group.order: '10'

Il numero può variare tra 1 e 1.000. Viene considerato prima il numero più basso per tutti gli ingressi nello stesso gruppo di ingressi. Tutti gli ingressi senza questa annotazione vengono valutati con un valore pari a zero. La duplicazione delle regole con un numero più alto può causare la sovrascrittura delle regole con un numero più basso. Per impostazione predefinita, l’ordine delle regole tra ingressi all’interno dello stesso gruppo di ingressi viene determinato in base all’ordine lessicografico del namespace e del nome.

Importante

Assicurarsi che ogni ingresso nello stesso gruppo di ingressi disponga di un numero di priorità univoco. Non puoi avere numeri d’ordine duplicati tra gli ingressi.

(Facoltativo) Implementare un’applicazione di esempio

È possibile eseguire l’applicazione di esempio in un cluster che abbia nodi Amazon EC2, pod Fargate o entrambi.

  1. Se non stai eseguendo l’implementazione su Fargate, salta questa fase. Se stai eseguendo l’implementazione su Fargate, crea un profilo Fargate. Puoi creare il profilo eseguendo il seguente comando o nella Console di gestione AWS utilizzando gli stessi valori per name e namespace che si trovano nel comando. Sostituire i valori di esempio con i propri valori.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name alb-sample-app \
    --namespace game-2048

  2. Implementare il gioco 2048 come un’applicazione di esempio per verificare che il controller del load balancer AWS crei un ALB AWS come risultato dell’oggetto di ingresso. Completa i passaggi per il tipo di sottorete verso la quale stai eseguendo l’implementazione.

    1. Se stai eseguendo l’implementazione su pod in un cluster creato con la famiglia IPv6, passa alla fase successiva.

      • Pubblica:

      kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

      • Privata:

        1. Eseguire il download del manifesto.

          curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

        2. Modificare il file e individuare la riga alb.ingress.kubernetes.io/scheme: internet-facing.

        3. Cambiare internet-facing a internal e salvare il file.

        4. Applica il file manifesto al cluster.

          kubectl apply -f 2048_full.yaml

    2. Se stai eseguendo l’implementazione su pod in un cluster creato con la famiglia IPv6, completa la seguente procedura.

      1. Eseguire il download del manifesto.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

      2. Aprire il file in un editor e aggiungere la seguente riga alle annotazioni nella specifica di ingresso.

        alb.ingress.kubernetes.io/ip-address-type: dualstack

      3. Se stai bilanciando il carico sui pod interni piuttosto che sui pod rivolti a Internet, modifica la riga che indica alb.ingress.kubernetes.io/scheme: internet-facing in alb.ingress.kubernetes.io/scheme: internal

      4. Salvare il file.

      5. Applica il file manifesto al cluster.

        kubectl apply -f 2048_full.yaml

  3. Dopo pochi minuti, verificare che la risorsa di ingresso sia stata creata con il comando seguente.

    kubectl get ingress/ingress-2048 -n game-2048

    Di seguito viene riportato un output di esempio:

    NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGE
ingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.region-code.elb.amazonaws.com   80      2m32s
    Nota

    Se hai creato il load balancer in una sottorete privata, il valore in ADDRESS nell’output precedente è preceduto da internal-.

Se, dopo alcuni minuti, l’ingresso non è stato creato, utilizza il comando seguente per visualizzare i registri del controller del bilanciatore del carico AWS. Questi registri possono contenere messaggi di errore che consentono di diagnosticare eventuali problemi relativi all’implementazione.

kubectl logs -f -n kube-system -l app.kubernetes.io/instance=aws-load-balancer-controller

  1. Se è stata eseguita l’implementazione a una sottorete pubblica, aprire un browser e accedere all’URL ADDRESS dall’output del comando precedente per visualizzare l’applicazione di esempio. Se non visualizzi nulla, aggiorna il browser e riprova. Se hai eseguito l’implementazione a una sottorete privata, devi visualizzare la pagina da un dispositivo all’interno del VPC, ad esempio un host bastione. Per ulteriori informazioni, consulta Bastion host Linux in AWS.

    Applicazioni di esempio 2048

  2. Dopo aver provato l’applicazione di esempio, eliminarla utilizzando uno dei comandi seguenti.

    • Se è stato applicato il manifesto anziché una copia scaricata, utilizzare il comando seguente.

      kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

    • Se è stato il manifesto scaricato e modificato, utilizzare il seguente comando.

      kubectl delete -f 2048_full.yaml