Percorso TCP e UDP traffico con Network Load Balancer - Amazon EKS
PrerequisitiConsiderazioniCreazione di un Network Load Balancer(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à.

Percorso TCP e UDP traffico con Network Load Balancer

Il carico del traffico di rete è bilanciato in base al modello. L4 OSI Per bilanciare il carico del traffico delle applicazioni inL7, si implementa un Kubernetes ingress, che fornisce un AWS Application Load Balancer. Per ulteriori informazioni, consulta Indirizza l'applicazione e HTTP il traffico con Application 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.

Quando crei un Kubernetes Servicedi tipoLoadBalancer, il controller del load balancer del provider di AWS cloud crea AWS Classic Load Balancer per impostazione predefinita, ma può anche creare AWS Network Load Balancer. Questo controller in futuro riceverà solo correzioni di bug critici. Per ulteriori informazioni sull'utilizzo del load balancer del provider AWS cloud, consulta AWS Cloud Provider Load Balancer Controller nel Kubernetes documentazione. Il suo utilizzo non è descritto in questo argomento.

Ti consigliamo di utilizzare una versione 2.7.2 o successiva del AWS Load Balancer Controller anziché il controller di bilanciamento del carico del provider AWS cloud. Il AWS Load Balancer Controller crea 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 verso Pods distribuito su destinazioni EC2 IP e istanze di Amazon o su destinazioni IP AWS Fargate. Per ulteriori informazioni, consulta AWS Load Balancer Controller su GitHub.

Prerequisiti

Prima di poter bilanciare il carico del traffico di rete utilizzando il AWS Load Balancer Controller, è necessario soddisfare i seguenti requisiti.

  • Avere un cluster esistente. Se non disponi di un cluster esistente, consultaInizia 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.

  • 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 stai usando il AWS Load Balancer Controller versione 2.1.1 o precedente, le sottoreti devono essere etichettate come segue. Se si utilizza la versione 2.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 unico cluster e desideri un VPC maggiore controllo su dove vengono forniti i load balancer per ogni cluster. Se specifichi esplicitamente la sottorete IDs come annotazione su un oggetto di servizio, allora Kubernetes e il AWS Load Balancer Controller usa direttamente quelle sottoreti per creare il load balancer. Il tagging delle sottoreti non è necessario se si sceglie di utilizzare questo metodo per il provisioning dei sistemi di bilanciamento del carico e si possono ignorare i seguenti requisiti di tagging delle sottoreti pubbliche e private. 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, a meno che non si specifichi esplicitamente subnet IDs come annotazione su un servizio o un oggetto di ingresso. Se esegui il provisioning dei sistemi di bilanciamento del carico specificando esplicitamente la sottorete IDs come annotazione su un servizio o un oggetto in ingresso, allora Kubernetes e il AWS Load Balancer Controller usa queste sottoreti direttamente per creare il load balancer e i seguenti tag non sono richiesti.

    • Sottoreti private: deve essere taggato nel seguente formato. Questo è così Kubernetes e il AWS Load Balancer Controller sanno che le sottoreti possono essere utilizzate per bilanciatori di carico interni. Se utilizzi eksctl o un EKS AWS AWS CloudFormation modello Amazon 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 EKS AWS 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 utilizzare solo quelle sottoreti per i bilanciatori del carico esterni invece di scegliere una sottorete pubblica in ogni zona di disponibilità (in base all'ordine lessicografico della sottorete). IDs Se utilizzi eksctl o un EKS AWS CloudFormation modello Amazon 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 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 VPC sottoreti del cluster per determinare se la sottorete è privata o pubblica. Ti consigliamo di non fare affidamento su questo comportamento e di aggiungere invece esplicitamente i tag di ruolo privati o pubblici. Il AWS Load Balancer Controller non esamina le tabelle delle rotte e richiede la presenza dei tag privati e pubblici per una corretta individuazione automatica.

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. Assicurati di controllare le annotazioni relative a AWS Load Balancer Controller prima di distribuire i servizi.

  • Quando si utilizza il VPCCNIplug-in Amazon per Kubernetes, AWS Load Balancer Controller può bilanciare il carico su destinazioni EC2 IP o istanze Amazon e destinazioni IP Fargate. Quando si utilizzano CNIplug-in compatibili con Alternate, il controller può bilanciare il carico solo in base alle destinazioni dell'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 desideri aggiungere tag al load balancer durante o dopo la sua creazione, aggiungi la seguente annotazione nelle specifiche del servizio. Per ulteriori informazioni, consulta AWS Resource Tags nel AWS Load Balancer Controller documentazione.

    service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags

  • È possibile assegnare Indirizzi IP elastici al Network Load Balancer aggiungendo la seguente annotazione. Sostituisci il example values con i Allocation IDs tuoi indirizzi IP elastici. Il numero di Allocation IDs deve corrispondere al numero di sottoreti utilizzate per il load balancer. Per ulteriori informazioni, consultare la documentazione sul Controller del load balancer 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 di bilanciamento del carico nei controlli di integrità VPC per ogni Network Load Balancer che crei. L'implementazione di un servizio di questo tipo LoadBalancer può fallire 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, consulta la sezione Gruppi di sicurezza nelle VPC quote Amazon nella Amazon VPC User Guide. 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 Annotations on 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 file ALB tra più ingressi. Per ulteriori informazioni, consulta Indirizza l'applicazione e HTTP il traffico con Application Load Balancer. Non puoi condividere un Network Load Balancer tra più servizi.

    • Implementa i cluster su più account.

  • Se le ricette di Pods eseguire su Windows in un EKS cluster Amazon, un singolo servizio con bilanciamento del carico può supportare fino a 1024 back-end Pods. Ciascuno Pod ha il proprio indirizzo IP univoco.

  • Si consiglia di creare nuovi Network Load Balancer solo con 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.

Crea un sistema di bilanciamento del carico di rete: obiettivi IP

  • È possibile utilizzare destinazioni IP con Pods distribuito su EC2 nodi Amazon o Fargate. Il tuo Kubernetes il servizio deve essere creato come tipoLoadBalancer. Per ulteriori informazioni, vedere LoadBalancerDigitare il Kubernetes documentazione.

    Per creare un load balancer che utilizzi destinazioni IP, aggiungere le seguenti annotazioni a un manifesto del servizio e implementare il servizio. Il external valore per aws-load-balancer-type è ciò che causa il AWS Load Balancer Controller, anziché il controller del load balancer del provider AWS cloud, per creare il Network Load Balancer. É possibile visualizzare un manifesto del servizio di esempio con le annotazioni.

    service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    Nota

    Se stai effettuando il bilanciamento del carico su IPv6 Pods, aggiungi la seguente annotazione. È 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.

    service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack

    Per impostazione predefinita, i Network Load Balancer vengono creati con internal aws-load-balancer-scheme. Puoi avviare Network Load Balancer in qualsiasi sottorete del clusterVPC, incluse le sottoreti che non sono state specificate al momento della creazione del cluster.

    Kubernetes esamina la tabella di routing delle sottoreti per identificare se sono pubbliche o private. Le sottoreti pubbliche hanno una route direttamente a Internet tramite un gateway Internet; non vale altrettanto per le sottoreti private.

    Se desideri creare un Network Load Balancer in una sottorete pubblica per bilanciare il carico sui nodi Amazon EC2 (Fargate può essere solo privato), internet-facing specificalo con la seguente annotazione:

    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
    Nota

    Al fine di garantire la compatibilità con le versioni precedenti, l'annotazione service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" è ancora supportata. Consigliamo, tuttavia, di utilizzare le annotazioni precedenti per i load balancer anziché service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip".

    Importante

    Non modificare le annotazioni dopo aver creato il servizio. Se è necessario modificarlo, eliminare l'oggetto di servizio e crearlo nuovamente con il valore desiderato per questa annotazione.

Crea un sistema di bilanciamento del carico di rete — Instance Targets

  • Il controller del load balancer del provider di servizi AWS cloud crea Network Load Balancer solo con obiettivi di istanza. La versione 2.2.0 e le successive del AWS Load Balancer Controller creano anche Network Load Balancer con destinazioni di istanza. Ti consigliamo di utilizzarlo, anziché il controller di bilanciamento del carico del provider AWS cloud, per creare nuovi Network Load Balancer. È possibile utilizzare gli obiettivi delle istanze di Network Load Balancer con Pods distribuito EC2 sui nodi Amazon, ma non su Fargate. Per bilanciare il carico del traffico di rete su Pods distribuiti su Fargate, è necessario utilizzare obiettivi IP.

    Per implementare un Network Load Balancer in una sottorete privata, la specifica del servizio deve avere le seguenti annotazioni. É possibile visualizzare un manifesto del servizio di esempio con le annotazioni. Il external valore per aws-load-balancer-type è ciò che fa sì che il AWS Load Balancer Controller, anziché il controller del load balancer del provider AWS cloud, crei il Network Load Balancer.

    service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"

    Per impostazione predefinita, i Network Load Balancer vengono creati con internal aws-load-balancer-scheme. Per i Network Load Balancer interni, il tuo EKS cluster Amazon deve essere configurato per utilizzare almeno una sottorete privata nel tuo. VPC Kubernetes esamina la tabella di routing delle sottoreti per identificare se sono pubbliche o private. Le sottoreti pubbliche hanno una route direttamente a Internet tramite un gateway Internet; non vale altrettanto per le sottoreti private.

    Se desideri creare un Network Load Balancer in una sottorete pubblica per bilanciare il carico EC2 sui nodi Amazon, specificalo internet-facing con la seguente annotazione:

    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
    Importante

    Non modificare le annotazioni dopo aver creato il servizio. Se è necessario modificarlo, eliminare l'oggetto di servizio e crearlo nuovamente con il valore desiderato per questa annotazione.

(Facoltativo) Implementare un'applicazione di esempio

  • Almeno una sottorete pubblica o privata nel cluster. VPC

  • 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.

    1. Se stai distribuendo su Fargate, assicurati di avere una sottorete privata disponibile nel VPC tuo account e crea un profilo Fargate. Se non ti stai schierando a Fargate, salta questo passaggio. É 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 nlb-sample-app \
    --namespace nlb-sample-app

    2. Implementa un'applicazione di esempio.

      1. Crea uno spazio dei nomi per l'applicazione.

        kubectl create namespace nlb-sample-app

      2. Salva il seguente contenuto in un file denominato sample-deployment.yaml` sul tuo computer.

        apiVersion: 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

      3. Applica il file manifesto al cluster.

        kubectl apply -f sample-deployment.yaml

    3. Crea un servizio con un Network Load Balancer connesso a Internet che bilanci il carico sulle destinazioni IP.

      1. Salva il seguente contenuto in un file denominato sample-service.yaml` sul tuo computer. Se stai effettuando la distribuzione sui nodi Fargate, service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing rimuovi la linea.

        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

      2. Applica il file manifesto al cluster.

        kubectl apply -f sample-service.yaml

    4. Verifica che il servizio sia stato distribuito.

      kubectl get svc nlb-sample-service -n nlb-sample-app

      Di seguito viene riportato un output di esempio:

      NAME            TYPE           CLUSTER-IP         EXTERNAL-IP                                                                    PORT(S)        AGE
sample-service  LoadBalancer   10.100.240.137   k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com  80:32400/TCP   16h
      Nota

      I valori per 10.100.240.137 e xxxxxxxxxx-xxxxxxxxxxxxxxxx saranno diversi dall'output di esempio (saranno unici per il sistema di bilanciamento del carico) e us-west-2 potrebbe essere diverso per te, a seconda della AWS regione in cui si trova il cluster.

    5. 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 target in cui il valore nella colonna Load balancer corrisponde a una parte del nome nella EXTERNAL-IP colonna dell'output del passaggio precedente. Ad esempio, dovresti selezionare il gruppo target denominato k8s-default-samplese-xxxxxxxxxx se l'output fosse lo stesso dell'output precedente. Target type (Tipo di destinazione) è IP perché è stato specificato nel manifesto del servizio di esempio.

    6. 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 stato unhealthy prima di passare a uno stato healthy.

    7. Invia traffico al servizio sostituendo xxxxxxxxxx-xxxxxxxxxxxxxxxx e us-west-2 con i valori restituiti nell'output di un passaggio precedente perEXTERNAL-IP. 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.

      curl k8s-default-samplese-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com

      Di seguito viene riportato un output di esempio:

      <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

    8. Quando hai finito con la distribuzione, il servizio e lo spazio dei nomi di esempio, rimuovili.

      kubectl delete namespace nlb-sample-app