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

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Bilanciamento del carico di applicazione su Amazon EKS

Quando si crea un Kubernetesingress, viene eseguito il provisioning di un AWS Application Load Balancer (ALB) che bilancia 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 di Kubernetes. Gli ALB possono essere utilizzati con Pods 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 su L4, implementa un service Kubernetes di tipo LoadBalancer. Questo tipo fornisce un AWS Network Load Balancer. Per ulteriori informazioni, consulta Bilanciamento del carico di rete 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 .

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 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 Che cosa è la AWS Load Balancer Controller?. Consigliamo la versione 2.7.1 o successiva.

  • Almeno due sottoreti devono trovarsi in diverse zone di disponibilità. Il AWS Load Balancer Controller 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 si utilizzano più gruppi di sicurezza collegati al nodo (worker), esattamente un gruppo di sicurezza deve essere taggato come segue. Sostituisci my-cluster con il nome del cluster.

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

    • Valore: shared o owned

  • Se si utilizza il AWS Load Balancer Controller versione 2.1.1 o precedenti, le sottoreti devono essere taggate nel formato seguente. Se si utilizza 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. Hai più cluster in esecuzione nello stesso VPC o AWS più servizi 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. 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. 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 load balancer AWS utilizzeranno queste sottoreti direttamente per creare il load balancer senza che siano necessari i seguenti tag.

    • Sottoreti private: deve essere taggato nel seguente formato. In questo modo Kubernetes e il controller del AWS load balancer sanno che le sottoreti possono essere utilizzate per bilanciamenti del carico interni. Se utilizzi eksctl o un AWS CloudFormation modello Amazon EKS per creare il tuo VPC dopo il 26 marzo 2020, le sottoreti vengono etichettate in modo appropriato al momento della creazione. Per ulteriori informazioni sui modelli AWS CloudFormation VPC di Amazon EKS, consulta. 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 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 AWS CloudFormation modello Amazon EKS per creare il tuo VPC dopo il 26 marzo 2020, le sottoreti vengono etichettate in modo appropriato al momento della creazione. Per ulteriori informazioni sui modelli AWS CloudFormation VPC di Amazon EKS, consulta. 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. 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 AWS Load Balancer Controller non esamina le tabelle di instradamento. Richiede inoltre la presenza di tag privati e pubblici per un efficiente rilevamento automatico.

Considerazioni

  • Il AWS Load Balancer Controller crea ALB e le AWS risorse di supporto necessarie ogni volta che viene creata una risorsa in Kubernetes ingresso sul cluster con l'annotazione. kubernetes.io/ingress.class: alb La risorsa di ingresso configura l'ALB per instradare il traffico HTTP o HTTPS verso Pods differenti all'interno del cluster. Per fare in modo che gli oggetti di ingresso utilizzino il AWS Load Balancer Controller, aggiungi 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 stai bilanciando il carico sui Pods 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 AWS Load Balancer Controller supporta le modalità di traffico seguenti:

    • 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 tuo servizio e quindi inoltrato ai Pods. Questa è la modalità di traffico predefinita. È anche possibile specificarla esplicitamente con l'annotazione alb.ingress.kubernetes.io/target-type: instance.

      Nota

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

    • IP: registra Pods come destinazioni per l'ALB. Il traffico che raggiunge l'ALB viene indirizzato direttamente ai Pods 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 è richiesta quando i Pods di destinazione sono in esecuzione su Fargate.

  • 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 AWS Load Balancer Controller, consulta 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, consulta le note di rilascio del controller ALB su GitHub.

Condivisione di un Application Load Balancer su più risorse di servizio tramite IngressGroups

Per aggiungere un ingresso a un gruppo, aggiungi 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

Possibili rischi 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.

É possibile aggiungere un numero d'ordine della tua risorsa di ingresso.

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

Il numero può variare tra 1 e 1000. 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 dello spazio dei nomi e del nome.

Importante

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

(Facoltativo) Implementare un'applicazione di esempio

Prerequisiti

  • Almeno una sottorete pubblica o privata nel VPC del cluster.

  • Aver implementato AWS Load Balancer Controller nel cluster. Per ulteriori informazioni, consulta Che cosa è la AWS Load Balancer Controller?. Consigliamo la versione 2.7.1 o successiva.

Per implementare un'applicazione di esempio

Puoi eseguire l'applicazione di esempio in un cluster che abbia nodi Amazon EC2, Pods Fargate o entrambi.

  1. Se non stai eseguendo l'implementazione su Fargate, salta questa fase. Se si sta eseguendo l'implementazione su Fargate, creare un profilo Fargate. É 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. Sostituisci i example values con i valori in tuo possesso.

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

  2. Implementa il gioco 2048 come applicazione di esempio per verificare che AWS Load Balancer Controller crei un AWS ALB come risultato dell'oggetto di ingresso. Completare i passaggi per il tipo di sottorete verso la quale si sta eseguendo l'implementazione.

    1. Se stai eseguendo l'implementazione su Pods 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.7.1/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.7.1/docs/examples/2048/2048_full.yaml

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

        3. Modificare internet-facing in internal e salvare il file.

        4. Applicare il file manifesto al cluster.

          kubectl apply -f 2048_full.yaml

    2. Se si sta eseguendo l'implementazione su Pods 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.7.1/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 Pods interni piuttosto che sui Pods 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. Applicare 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 utilizzare il comando seguente per visualizzare i registri del AWS Load Balancer Controller. 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

  4. 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 si visualizza nulla, aggiornare il browser e riprovare. 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.

    Applicazioni di esempio 2048

  5. 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.7.1/docs/examples/2048/2048_full.yaml

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

      kubectl delete -f 2048_full.yaml