Aiutaci a migliorare questa pagina
Vuoi contribuire a questa guida per l'utente? Scorri fino alla fine di questa pagina e seleziona Modifica questa pagina su GitHub. I tuoi contributi contribuiranno a rendere la nostra guida utente migliore per tutti.
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à.
Instrada l'applicazione e HTTP il traffico con Application Load Balancers
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
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 Percorso TCP e UDP traffico con Network Load Balancers. Per ulteriori informazioni sulle differenze tra i due tipi di bilanciamento del carico, consulta le caratteristiche di Elastic Load Balancing
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 Inizia a usare Amazon EKS. Se è necessario aggiornare la versione di un cluster esistente, vedere Aggiorna il cluster esistente alla nuova versione di Kubernetes.
-
Aver implementato AWS Load Balancer Controller nel cluster. Per ulteriori informazioni, consulta Che cosa è la 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 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
con il nome del cluster.my-cluster
-
Chiave:
kubernetes.io/cluster/
my-cluster
-
Valore:
shared
oowned
-
-
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 versione2.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
con il nome del cluster.my-cluster
-
Chiave:
kubernetes.io/cluster/
my-cluster
-
Valore –
shared
oowned
-
-
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 ingressosu 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 daIPv6
a IP, non su destinazioni di istanza. Senza questa annotazione, il bilanciamento del carico è suIPv4
.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'annotazionealb.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 ingressosu 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.2
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.
-
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
enamespace
che si trovano nel comando. Sostituisci i
con i valori in tuo possesso.example values
eksctl create fargateprofile \ --cluster
my-cluster
\ --regionregion-code
\ --namealb-sample-app
\ --namespace game-2048 -
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. -
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.2/docs/examples/2048/2048_full.yaml
-
Privata
-
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
-
Modificare il file e individuare la riga
alb.ingress.kubernetes.io/scheme: internet-facing
. -
Modificare
ininternet-facing
e salvare il file.internal
-
Applicare il file manifesto al cluster.
kubectl apply -f 2048_full.yaml
-
-
-
Se si sta eseguendo l'implementazione su Pods in un cluster creato con la famiglia IPv6, completa la seguente procedura.
-
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
-
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
-
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:
ininternet-facing
alb.ingress.kubernetes.io/scheme:
internal
-
Salvare il file.
-
Applicare il file manifesto al cluster.
kubectl apply -f 2048_full.yaml
-
-
-
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 2m32sNota
Se hai creato il load balancer in una sottorete privata, il valore in
ADDRESS
nell'output precedente è preceduto dainternal-
.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
-
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. -
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
-