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à.
Percorso TCP e UDP traffico con Network Load Balancers
Il traffico di rete è bilanciato al carico L4
del modello OSI. Per bilanciare il traffico delle applicazioni inL7
, si distribuisce un Kubernetesingress
, che fornisce un AWS Application Load Balancer. Per ulteriori informazioni, consulta Instrada l'applicazione e HTTP il traffico con Application Load Balancers. Per ulteriori informazioni sulle differenze tra i due tipi di bilanciamento del carico, consulta le funzionalità di Elastic Load Balancing
Quando crei un sistema di KubernetesService
bilanciamento del caricoLoadBalancer
, il controller di bilanciamento del carico del provider di servizi AWS cloud crea AWSClassic Load Balancer per impostazione predefinita, ma può anche creare Network Load Balancer. AWS Questo controller in futuro riceverà solo correzioni di bug critici. Per ulteriori informazioni sull'utilizzo del load balancer del provider di AWS cloud, consulta il controller di bilanciamento del carico del provider AWS cloud
Consigliamo di utilizzare la versione 2.7.2
o una versione successiva di AWS Load Balancer Controller anziché il controller del load balancer del provider del cloud AWS
. AWS Load Balancer ControllerCrea AWS Network Load Balancer, ma non crea AWS Classic Load Balancer. Il resto di questo argomento riguarda l'utilizzo del AWS Load Balancer Controller.
Un AWS Network Load Balancer può bilanciare il carico del traffico di rete da Pods distribuire su destinazioni IP e istanze di Amazon EC2 o su destinazioni IP. AWS Fargate Per ulteriori informazioni, consulta Controller del load balancer AWS
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 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 Indirizza il traffico Internet con AWS Load Balancer Controller. Consigliamo la versione
2.7.2
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 versione2.1.2
o successiva, questo tag è facoltativo. Potresti voler etichettare una sottorete se hai più cluster in esecuzione nello stesso VPC o più AWS servizi che condividono sottoreti in un VPC e desideri un maggiore controllo su dove vengono forniti i load balancer per ogni 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
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, 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 questo modo il AWS Load Balancer Controller sa che le sottoreti possono essere utilizzate per bilanciatori di carico interni. Kubernetes Se utilizzi
eksctl
o un AWS 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 AWS CloudFormation VPC Amazon EKS, vedere Crea 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. 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 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. Crea 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, 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 di bilanciamento del carico del provider di AWS cloud. 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
con gliexample values
Allocation IDs
degli indirizzi IP elastici. Il numero diAllocation 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 sistema di bilanciamento del carico nel VPC per i controlli dell'integrità per ogni Network Load Balancer creato. L'implementazione di un servizio di tipo
LoadBalancer
può non riuscire se Amazon EKS tenta di creare regole che superano la quota per il numero massimo di regole consentite 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' AWS Application Load Balancer richiede meno regole rispetto ai Network Load Balancer. È possibile condividere un ALB su più ingressi. Per ulteriori informazioni, consulta Instrada l'applicazione e HTTP il traffico con Application Load Balancers. 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 i Network Load Balancer esistenti creati con il controller di bilanciamento del carico del provider di servizi AWS cloud può comportare la creazione di più Network Load Balancer che potrebbero causare tempi di inattività delle applicazioni.
Creazione di un Network Load Balancer
È possibile creare un Network Load Balancer con destinazioni IP o istanza.
(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 Indirizza il traffico Internet con AWS Load Balancer Controller. Consigliamo la versione
2.7.2
o successiva.
Per implementare un'applicazione di esempio
-
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
enamespace
che si trovano nel comando. Sostituisci i
con i valori in tuo possesso.example values
eksctl create fargateprofile \ --cluster
\my-cluster
\ --regionregion-code
\ --namenlb-sample-app
--namespace nlb-sample-app
-
Implementa un'applicazione di esempio.
-
Crea uno spazio dei nomi per l'applicazione.
kubectl create namespace
nlb-sample-app
-
Salva nel computer i seguenti contenuti in un file denominato
.sample-deployment
.yamlapiVersion: 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.23
ports: - name:tcp
containerPort:80
-
Applica il file manifesto al cluster.
kubectl apply -f
sample-deployment
.yaml
-
-
Crea un servizio con un Network Load Balancer connesso a Internet che bilanci il carico sulle destinazioni IP.
-
Salva nel computer i seguenti contenuti in un file denominato
. Se stai eseguendo l'implementazione sui nodi Fargate, rimuovi la rigasample-service
.yamlservice.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
-
Applica il file manifesto al cluster.
kubectl apply -f
sample-service
.yaml
-
-
Verificare che il servizio sia stato implementato.
kubectl get svc
nlb-sample-service
-nnlb-sample-app
Di seguito viene riportato un output di esempio:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
sample-service
LoadBalancer10.100.240.137
k8s-nlbsampl
-nlbsampl
-xxxxxxxxxx
-xxxxxxxxxxxxxxxx
.elb.region-code
.amazonaws.com80
:32400
/TCP
16hNota
I valori per
e10.100.240.137
-xxxxxxxxxx
xxxxxxxxxxxxxxxx
saranno diversi dall'output di esempio (saranno univoci per il sistema di bilanciamento del carico) eus-west-2
potrebbe essere diverso per te, a seconda del cluster in cui si trova. Regione AWS -
Apri Amazon EC2 AWS Management Console
. 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 denominatok8s-default-samplese-
. Target type (Tipo di destinazione) èxxxxxxxxxx
IP
perché è stato specificato nel manifesto del servizio di esempio. -
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 statounhealthy
prima di passare a uno statohealthy
. -
Invia il traffico al servizio sostituendo
exxxxxxxxxx-xxxxxxxxxxxxxxxx
con i valori restituiti nell'output di un operazione precedente perus-west-2
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.comDi seguito viene riportato un output di esempio:
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> [...]
-
Al termine dell'implementazione, del servizio e dello spazio dei nomi di esempio, rimuoverli.
kubectl delete namespace
nlb-sample-app