Indirizza l'applicazione e HTTP il traffico con Application Load Balancer - Amazon EKS
PrerequisitiRiutilizzo ALBs con Ingress Groups(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à.

Indirizza l'applicazione e HTTP il traffico con Application Load Balancer

Quando crei un Kubernetes ingress, viene fornito un AWS Application Load Balancer (ALB) che bilancia il carico del traffico delle applicazioni. Per ulteriori informazioni, consulta Cos'è un Application Load Balancer? nella Guida per l'utente di Application Load Balancers e Ingress nella Kubernetes documentazione. ALBspuò essere usato con Pods che vengono distribuiti sui nodi o su AWS Fargate. È possibile distribuirne uno su ALB sottoreti pubbliche o private.

Il traffico delle applicazioni è bilanciato in base al modelloL7. OSI Per bilanciare il carico del traffico di rete suL4, si implementa un Kubernetes servicedel LoadBalancer tipo. Questo tipo fornisce un AWS Network Load Balancer. Per ulteriori informazioni, consulta Percorso TCP e UDP traffico con Network Load Balancer. Per ulteriori informazioni sulle differenze tra i due tipi di bilanciamento del carico, consulta le funzionalità di Elastic Load Balancing sul AWS sito Web.

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. Inizia a usare Amazon EKS Se è necessario aggiornare la versione di un cluster esistente, vedere Aggiorna il cluster esistente alla nuova versione di Kubernetes.

  • Avere il AWS Load Balancer Controller distribuito sul tuo 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 AWS Load Balancer Controller sceglie una sottorete da 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 di lavoro, esattamente un gruppo di sicurezza deve essere etichettato come segue. Replace (Sostituisci) my-cluster con il nome del tuo cluster.

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

    • Valore: shared o owned

  • Se stai usando il AWS Load Balancer Controller versione 2.1.1 o precedente, le sottoreti devono essere etichettate nel formato seguente. Se utilizzi la versione 2.1.2 o una versione successiva, l'aggiunta 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 hai più AWS 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. Replace (Sostituisci) my-cluster con il nome del tuo cluster.

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

    • Valore – shared o owned

  • Le sottoreti pubbliche e private devono soddisfare i seguenti requisiti. Questo a meno che non si specifichi esplicitamente subnet IDs come annotazione su un servizio o un oggetto di ingresso. Si supponga di effettuare il provisioning dei sistemi di bilanciamento del carico specificando esplicitamente la sottorete IDs come annotazione su un servizio o un oggetto in ingresso. In questa situazione, Kubernetes e il controller del bilanciamento del AWS carico utilizza direttamente quelle sottoreti per creare il sistema di bilanciamento del carico e i seguenti tag non sono richiesti.

    • Sottoreti private: deve essere taggato nel seguente formato. Questo è così Kubernetes e il controller del bilanciamento del AWS carico sa che le sottoreti possono essere utilizzate per bilanciatori di carico interni. Se utilizzi eksctl o un EKS AWS CloudFormation modello Amazon per creare le tue VPC dopo il 26 marzo 2020, le sottoreti vengono etichettate in modo appropriato al momento della creazione. Per ulteriori informazioni sui EKS AWS CloudFormation VPC modelli Amazon, consultaCrea un Amazon VPC per il tuo EKS cluster Amazon.

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

      • Valore: 1

    • Sottoreti pubbliche: deve essere taggato nel seguente formato. Questo è così Kubernetes sa usare solo le sottoreti specificate per i bilanciatori di carico esterni. In questo modo Kubernetes non sceglie una sottorete pubblica in ogni zona di disponibilità (lessicograficamente in base all'ID della sottorete). Se utilizzi eksctl o un EKS AWS CloudFormation modello Amazon per creare le tue VPC dopo il 26 marzo 2020, le sottoreti vengono etichettate in modo appropriato al momento della creazione. Per ulteriori informazioni sui EKS AWS CloudFormation VPC modelli Amazon, consultaCrea un Amazon VPC per il tuo EKS cluster Amazon.

      • Chiave: kubernetes.io/role/elb

      • Valore: 1

    Se i tag del ruolo della sottorete non vengono aggiunti in modo esplicito, Kubernetes il controller di servizio esamina la tabella di routing delle sottoreti del cluster. VPC Ciò consente di determinare se la sottorete è privata o pubblica. Ti consigliamo 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 delle rotte. Richiede inoltre la presenza di tag privati e pubblici per un efficiente rilevamento automatico.

  • Il AWS Load Balancer Controller crea ALBs le AWS risorse di supporto necessarie ogni volta che Kubernetes la risorsa di ingresso viene creata sul cluster con l'kubernetes.io/ingress.class: albannotazione. La risorsa di ingresso configura il percorso o il traffico ALB in modo diverso HTTP HTTPS Pods all'interno del cluster. Per garantire che gli oggetti in ingresso utilizzino il AWS Load Balancer Controller, aggiungi la seguente annotazione al tuo Kubernetes specifiche di ingresso. Per ulteriori informazioni, vedere le specifiche di Ingress su GitHub.

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

    Se stai effettuando il bilanciamento del carico su IPv6 Pods, aggiungi la seguente annotazione alle specifiche 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 seguenti modalità di traffico:

    • Istanza: registra i nodi all'interno del cluster come destinazioni per. ALB Il traffico che arriva a ALB viene indirizzato al servizio dell'NodePortutente e quindi inviato tramite proxy al Pods. Questa è la modalità di traffico predefinita. È anche possibile specificarla esplicitamente con l'annotazione alb.ingress.kubernetes.io/target-type: instance.

      Nota

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

    • IP — Registri Pods come obiettivi per. ALB Il traffico che raggiunge il ALB viene indirizzato direttamente a Pods per il tuo servizio. È necessario specificare l'annotazione alb.ingress.kubernetes.io/target-type: ip per utilizzare questa modalità di traffico. Il tipo di destinazione IP è obbligatorio quando si utilizza la destinazione Pods stanno correndo su Fargate.

  • Per etichettare ALBs creato dal controller, aggiungi la seguente annotazione al controller:. alb.ingress.kubernetes.io/tags Per un elenco di tutte le annotazioni disponibili supportate da AWS Load Balancer Controller, consulta le annotazioni di Ingress su GitHub.

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

Riutilizzo ALBs con Ingress Groups

È possibile condividere un sistema di bilanciamento del carico delle applicazioni tra più risorse di servizio utilizzando. IngressGroups

Per aggiungere un ingresso a un gruppo, aggiungi la seguente annotazione a Kubernetes specificazione delle risorse di ingresso.

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. Li supporta con un singoloALB. 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 a nessun gruppo di ingresso.

avvertimento

Potenziale rischio per la sicurezza

Specificate un gruppo di ingresso per un ingresso solo quando tutti i Kubernetes gli utenti RBAC autorizzati a creare o modificare risorse in ingresso rientrano nello stesso limite di trust. Se aggiungi l'annotazione con un nome di gruppo, altro Kubernetes gli utenti possono creare o modificare i propri ingressi in modo che appartengano allo stesso gruppo di ingresso. 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

Puoi eseguire l'applicazione di esempio su un cluster con EC2 nodi Amazon, Fargate Podso entrambi.

  1. Se non ti stai schierando a Fargate, salta questo passaggio. Se ti stai schierando su Fargate, crea 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 il example values con il tuo.

    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 crea un AWS ALB come risultato dell'oggetto di ingresso. Completa i passaggi relativi al tipo di sottorete in cui stai effettuando la distribuzione.

    1. Se stai eseguendo la distribuzione in Pods in un cluster creato con la IPv6 famiglia, vai al passaggio successivo.

      • Pubblico:

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

      • Privato::

        1. Eseguire il download del manifesto.

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

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

        3. Modifica internet-facing internalapri e salva il file.

        4. Applica il manifesto al cluster.

          kubectl apply -f 2048_full.yaml

    2. Se ti stai schierando in Pods in un cluster creato con la IPv6famiglia, completa i seguenti passaggi.

      1. Eseguire il download del manifesto.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/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 effettuando il bilanciamento del carico a livello interno Pods, piuttosto che rivolto a Internet Pods, cambia la riga che dice alb.ingress.kubernetes.io/scheme: internet-facing a 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 il tuo ingresso non è stato creato correttamente dopo alcuni minuti, esegui il comando seguente per visualizzare il AWS Load Balancer Controller registri. 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 la distribuzione è stata effettuata su una sottorete pubblica, aprite un browser e passate all'output ADDRESS URL del comando precedente per visualizzare l'applicazione di esempio. Se non vedi nulla, aggiorna il browser e riprova. Se hai effettuato la distribuzione su una sottorete privata, dovrai visualizzare la pagina da un dispositivo interno al tuoVPC, ad esempio un host bastion. Per ulteriori informazioni, consultare 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.7.2/docs/examples/2048/2048_full.yaml

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

      kubectl delete -f 2048_full.yaml