Bilanciamento del carico di rete su Amazon EKS
Il traffico di rete è bilanciato al carico L4 del modello OSI. Per bilanciare il carico del traffico delle applicazioni in L7, si implementa un ingress
Kubernetes, che fornisce un Application Load Balancer (ALB) AWS. Per ulteriori informazioni, consulta . Bilanciamento del carico di applicazione su Amazon EKS. Per ulteriori informazioni sulle differenze tra i due tipi di bilanciamento del carico, consulta le caratteristiche di Elastic Load Balancing
Quando crei un Kubernetes Service
di tipo LoadBalancer
, il controller di bilanciamento del carico del provider cloud AWS crea Classic Load Balancer AWS 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 bilanciatore del carico del provider cloud AWS, consultare Controller del bilanciatore del carico del provider cloud AWS
Per i nuovi servizi implementati in cluster versione 1.19 o successive, ti consigliamo di usare la versione 2.4.0
o successiva deli Installazione del componente aggiuntivo AWS Load Balancer Controller anziché il controller del bilanciatore del carico del provider cloud AWS. Se il cluster è precedente alla versione 1.19, ti consigliamo di utilizzare la versione 2.3.1 del controller. Il controller del bilanciatore del carico AWS crea bilanciatori del carico di rete AWS, ma non Classic Load Balancer AWS. Nella parte restante di questo argomento viene trattato l'utilizzo del controller del bilanciatore del carico AWS.
Un Network Load Balancer AWS è in grado di bilanciare il carico del traffico di rete ai pod implementati su IP Amazon EC2 e destinazioni di istanza o destinazioni IP di AWS Fargate. Per ulteriori informazioni, consultare Controller del Bilanciatore del Carico AWS
Prerequisiti
Prima di eseguire il bilanciamento del carico del traffico di rete tramite il controller del bilanciatore del carico AWS, è 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 di un cluster.
-
Avere il Controller del Bilanciatore del Carico AWS implementato sul cluster. Per ulteriori informazioni, consulta . Installazione del componente aggiuntivo AWS Load Balancer Controller. Consigliamo la versione 2.4.0 o successive per i cluster versione 1.19 o successive. Se il cluster è precedente alla versione 1.19, ti consigliamo di utilizzare la versione 2.3.1.
-
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 controller del bilanciatore del carico AWS versione
v2.1.1
o precedente, le sottoreti devono essere taggate come segue. Se si utilizza la versione 2.1.2 o successiva, questo tag è facoltativo. È possibile taggare una sottorete se si dispone di più cluster in esecuzione nello stesso VPC o di più servizi AWS che condividono sottoreti in un VPC e richiedono un maggiore controllo sulla posizione in cui viene eseguito il provisioning dei bilanciatori di carico per ciascun cluster. Se si specificano in modo esplicito gli ID sottorete come annotazione su un oggetto di servizio, Kubernetes e il controller del bilanciatore del carico AWS utilizza queste sottoreti direttamente per creare il bilanciatore del carico. Il tagging delle sottoreti non è obbligatorio se si sceglie di utilizzare questo metodo per il provisioning dei bilanciatori del carico ed è possibile ignorare i seguenti requisiti di assegnazione di tag delle sottoreti pubbliche e private. Sostituisci
con il nome del cluster.cluster-name
-
Chiave –
kubernetes.io/cluster/
cluster-name
-
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 si effettua il provisioning dei bilanciatori del carico specificando esplicitamente gli ID sottorete come annotazione in un oggetto di servizio o di ingresso, Kubernetes e il controller del bilanciatore del carico AWS utilizzano queste sottoreti direttamente per creare il bilanciatore del carico e non sono quindi necessari i seguenti tag.
-
Sottoreti private – Deve essere taggato nel seguente formato. In tal modo, Kubernetes e il Controller del Bilanciatore del Carico AWS sono consapevoli che le sottoreti possono essere utilizzate per i bilanciatori di carico interni. Se si utilizza
eksctl
o un modello AWS AWS CloudFormation 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 AWS AWS CloudFormation VPC Amazon EKS, vedere 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 utilizza solo tali sottoreti per bilanciatori del carico esterni, anziché scegliere una sottorete pubblica in ciascuna zona di disponibilità (in ordine lessicografico per ID sottorete). Se si utilizza
eksctl
o un modello AWS CloudFormation 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 AWS CloudFormation VPC Amazon EKS, vedere 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 routing 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 Controller del Bilanciatore del Carico AWS non esamina le tabelle di routing e richiede che i tag privati e pubblici siano presenti per il rilevamento automatico corretto.
-
Considerazioni
-
La configurazione del bilanciatore del carico è controllata da annotazioni che vengono aggiunte al manifest del servizio. Le annotazioni del servizio sono diverse quando si utilizza il controller del bilanciatore del carico AWS rispetto a quando si utilizza il controller del bilanciatore del carico del provider cloud AWS. Assicurarsi di rivedere le annotazioni
per il controller del bilanciatore del carico AWS prima di implementare i servizi. -
Quando utilizzi il plug-in CNI VPC di Amazon EKS, il controller del bilanciatore del carico AWS è 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 bilanciatore del carico quando o dopo la sua creazione, aggiungere la seguente annotazione nella specifica del servizio. Per ulteriori informazioni, consultare Tag delle risorse AWS
nella documentazione relativa al Controller del Bilanciatore del Carico AWS. 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 bilanciatore del carico. Per ulteriori informazioni, consultare la documentazione sul Controller del Bilanciatore del Carico AWS. 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 bilanciatore del carico nel VPC per i controlli dell'integrità di ogni Network Load Balancer creato. L'implementazione di un servizio di tipo
LoadBalancer
può non riuscire se Amazon EKS prova a creare regole che superano la quota per il numero massimo di regole consentito 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 bilanciatore del carico con un'annotazione. Per ulteriori informazioni, consultare Annotazioni
su GitHub. -
Utilizzare un ingresso invece di un servizio di tipo
LoadBalancer
per inviare traffico al tuo servizio. L'Application Load Balancer AWS richiede meno regole rispetto ai Network Load Balancer. È possibile condividere un ALB su più ingressi. Per ulteriori informazioni, consulta . Bilanciamento del carico di applicazione su Amazon EKS. Non è possibile condividere un Network Load Balancer su più servizi. -
Implementa i cluster su più account.
-
-
Se i pod vengono eseguiti su Windows in un cluster Amazon EKS, un singolo servizio con un bilanciatore del carico può supportare fino a 64 pod back-end. Ogni pod ha il proprio indirizzo IP univoco. Si tratta di una limitazione del sistema operativo Windows sui nodi Amazon EC2.
-
Si consiglia di creare solo nuovi Network Load Balancer con il controller del bilanciatore del carico AWS. Il tentativo di sostituire Network Load Balancer esistenti creati con il controller del bilanciatore del carico del provider cloud AWS potrebbe risultare in più Network Load Balancer che possono causare tempi di inattività dell'applicazione.
Creazione di un bilanciatore del carico di rete
È possibile creare un di bilanciatore del carico di rete con destinazioni IP o istanza.
(Facoltativo) Implementare un'applicazione di esempio
Prerequisiti
-
Almeno una sottorete pubblica o privata nel VPC del cluster.
-
Avere il Controller del Bilanciatore del Carico AWS implementato sul cluster. Per ulteriori informazioni, consulta . Installazione del componente aggiuntivo AWS Load Balancer Controller. Consigliamo la versione 2.4.0 o successive.
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. Sostituire ivalori di esempio
con i propri valori.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.21
ports: - name:tcp
containerPort:80
-
Applica il file manifesto al cluster.
kubectl apply -f
sample-deployment
.yaml
-
-
Creare un servizio con un Network Load Balancer interno 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
Output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
sample-service
LoadBalancer10.100.240.137
k8s-nlbsampl
-nlbsampl
-xxxxxxxxxx
-xxxxxxxxxxxxxxxx
.elb.us-west-2
.amazonaws.com80
:32400
/TCP
16hNota I valori per
10.100.240.137
exxxxxxxxxx
-xxxxxxxxxxxxxxxx
saranno diversi dall'output di esempio (saranno unici per il tuo bilanciatore del carico) eus-west-2
potrebbe essere diverso, a seconda della Regione AWS in cui si trova il cluster. -
Apri la AWS Management Console Amazon EC2
. 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 Bilanciatore del carico corrisponde al nome nella colonna EXTERNAL-IP
dell'output nella fase precedente. Ad esempio, è necessario selezionare il gruppo di destinazione denominatok8s-default-samplese-
se l'output era uguale all'output indicato sopra. 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
. -
Inviare traffico al servizio sostituendo
xxxxxxxxxx-xxxxxxxxxxxxxxxxxxx
eus-west-2
con i valori restituiti nell'output di un passaggio precedente perEXTERNAL-IP
. Se è stata eseguita l'implementazione a una sottorete privata, visualizzare la pagina da un dispositivo all'interno del VPC, ad esempio un bastion host. Per ulteriori informazioni, consultare Bastion host Linux in AWS. curl k8s-default-samplese-
xxxxxxxxxx-xxxxxxxxxxxxxxxx
.elb.us-west-2
.amazonaws.comL'output è il seguente.
<!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