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

Bilanciamento del carico

I Load Balancer ricevono il traffico in entrata e lo distribuiscono tra le destinazioni dell'applicazione prevista ospitata in un cluster EKS. Ciò migliora la resilienza dell'applicazione. Quando viene distribuito in un cluster EKS, il controller AWS Load Balancer creerà e gestirà AWS Elastic Load Balancer per quel cluster. Quando LoadBalancer viene creato un servizio Kubernetes di tipo, AWS Load Balancer Controller crea un Network Load Balancer (NLB) che bilancia il carico del traffico ricevuto al livello 4 del modello OSI. Quando viene creato un oggetto Kubernetes Ingress, AWS Load Balancer Controller crea un Application Load Balancer (ALB) che bilancia il carico al livello 7 del modello OSI.

Scelta del tipo di Load Balancer

Il portafoglio AWS Elastic Load Balancing (ELB) supporta i seguenti sistemi di bilanciamento del carico: Application Load Balancers (ALB), Network Load Balancer (NLB), Gateway Load Balancers (GWLB) e Classic Load Balancer (CLB). Questa sezione sulle migliori pratiche si concentrerà su ALB e NLB, che sono i due più rilevanti per EKS Clusters.

La considerazione principale nella scelta del tipo di load balancer sono i requisiti del carico di lavoro.

Per informazioni più dettagliate e come riferimento per tutti i sistemi di bilanciamento del carico AWS, consulta Confronti tra prodotti https://aws.amazon.com/elasticloadbalancing/features/#Product_comparisons

Scegli l'Application Load Balancer (ALB) se il tuo carico di lavoro è HTTP/HTTPS

Se un carico di lavoro richiede il bilanciamento del carico al livello 7 del modello OSI, l'AWS Load Balancer Controller può essere utilizzato per effettuare il provisioning di un ALB; ne parleremo nella sezione seguente. L'ALB è controllato e configurato dalla risorsa Ingress menzionata in precedenza e indirizza il traffico HTTP o HTTPS verso diversi pod all'interno del cluster. L'ALB offre ai clienti la flessibilità necessaria per modificare l'algoritmo di routing del traffico delle applicazioni; l'algoritmo di routing predefinito è round robin, mentre anche l'algoritmo di routing delle richieste meno in sospeso è un'alternativa.

Scegliete il Network Load Balancer (NLB) se il carico di lavoro è TCP o se il carico di lavoro richiede la conservazione dell'IP di origine dei client

Un Network Load Balancer funziona al quarto livello (Transport) del modello Open Systems Interconnection (OSI). È adatto per carichi di lavoro basati su TCP e UDP. Network Load Balancer inoltre, per impostazione predefinita, conserva l'indirizzo IP di origine dei client quando presenta il traffico al pod.

Scegli Network Load Balancer (NLB) se il tuo carico di lavoro non può utilizzare il DNS

Un altro motivo fondamentale per utilizzare l'NLB è se i tuoi clienti non possono utilizzare il DNS. In questo caso, l'NLB potrebbe essere più adatto al carico di lavoro in quanto gli IP su un Network Load Balancer sono statici. Sebbene si consiglia ai client di utilizzare il DNS per la risoluzione dei nomi di dominio in indirizzi IP durante la connessione ai Load Balancer, se l'applicazione di un client non supporta la risoluzione DNS e accetta solo IP codificati, un NLB è più adatto in quanto gli IP sono statici e rimangono gli stessi per tutta la durata dell'NLB.

Fornitura di sistemi di bilanciamento del carico

Dopo aver determinato il Load Balancer più adatto ai carichi di lavoro, i clienti hanno a disposizione una serie di opzioni per il provisioning di un load balancer.

Effettua il provisioning dei Load Balancer distribuendo AWS Load Balancer Controller

Esistono due metodi chiave per il provisioning dei load balancer all'interno di un cluster EKS.

Per impostazione predefinita, il Kubernetes Service Controller, noto anche come controller in-tree, riconcilia il tipo di risorsa Kubernetes Service. LoadBalancer Questo controller è integrato nel componente AWS Cloud Provider che funziona come Kubernetes Cloud Controller Manager. https://kubernetes.io/docs/concepts/architecture/cloud-controller/

La configurazione dell'Elastic Load Balancer fornito è controllata da annotazioni che devono essere aggiunte al manifesto del servizio Kubernetes. Le annotazioni utilizzate dal Service Controller e da AWS Load Balancer Controller sono diverse.

Il Service Controller è una versione precedente e al momento riceve solo correzioni di bug critici. Quando si crea un servizio Kubernetes di tipo LoadBalancer, il Service Controller crea un AWS CLB per impostazione predefinita, ma può anche creare AWS NLB se si utilizza l'annotazione corretta. Vale la pena notare che Service Controller non supporta le risorse Kubernetes Ingress e inoltre non supporta IPv6.

Ti consigliamo di utilizzare AWS Load Balancer Controller nei tuoi cluster EKS per riconciliare le risorse Kubernetes Service e Ingress. È necessario utilizzare le annotazioni corrette nel manifesto del servizio Kubernetes o Ingress in modo che AWS Load Balancer Controller gestisca il processo di riconciliazione. (anziché Service Controller)

Se utilizzi la modalità EKS Auto, l'AWS Load Balancer Controller viene fornito automaticamente; non è necessaria alcuna installazione.

Scegliere Load Balancer Target-Type

Registra i pod come destinazioni utilizzando l'IP Target-Type

Un AWS Elastic Load Balancer: Network & Application invia il traffico ricevuto a destinazioni registrate in un gruppo target. Per un cluster EKS ci sono 2 tipi di destinazioni che puoi registrare nel gruppo di destinazione: Istanza e IP, il tipo di destinazione utilizzato ha implicazioni su ciò che viene registrato e su come il traffico viene indirizzato dal Load Balancer al pod. Per impostazione predefinita, il controller AWS Load Balancer registrerà i target utilizzando il tipo «Instance» e questo target sarà l'IP del Worker Node eNodePort, le implicazioni di ciò, includono:

Al contrario, se si configura il tipo di destinazione come «IP» come consigliato, l'implicazione sarà la seguente:

Per creare un AWS Elastic Load Balancing che utilizza IP Targets, aggiungi:

Configurazione dei controlli di integrità del Load Balancer

Sebbene Kubernetes fornisca i propri meccanismi di controllo dello stato (descritti in dettaglio nella prossima sezione), consigliamo di implementare i controlli di integrità ELB come protezione complementare che funzioni al di fuori del piano di controllo di Kubernetes. Questo livello indipendente continua a monitorare l'applicazione anche durante:

Per i carichi di lavoro critici che richiedono la massima disponibilità e un ripristino accelerato negli scenari sopra menzionati, i controlli sullo stato di salute dell'ELB forniscono una rete di sicurezza essenziale che funziona insieme, e non in sostituzione, dei meccanismi nativi di Kubernetes.

Per configurare e ottimizzare i controlli sullo stato dell'ELB, è necessario utilizzare annotazioni nel manifesto del servizio Kubernetes o Ingress che verrebbero riconciliate da Service Controller o AWS Load Balancer Controller.

Disponibilità e ciclo di vita dei pod

Durante l'aggiornamento di un'applicazione è necessario assicurarsi che l'applicazione sia sempre disponibile per elaborare le richieste in modo che gli utenti non subiscano tempi di inattività. Una sfida comune in questo scenario è la sincronizzazione dello stato di disponibilità dei carichi di lavoro tra il livello Kubernetes e l'infrastruttura, ad esempio i Load Balancer esterni. Le prossime sezioni evidenziano le migliori pratiche per affrontare tali scenari.

Usa i controlli sullo stato di salute

Per impostazione predefinita, Kubernetes esegue il controllo dello stato del processo in cui il processo kubelet sul nodo verifica se il processo principale del contenitore è in esecuzione o meno. In caso contrario, per impostazione predefinita riavvia quel contenitore. Tuttavia, puoi anche configurare le sonde Kubernetes per identificare quando un processo contenitore è in esecuzione ma in uno stato di deadlock o se un'applicazione è stata avviata correttamente o meno. Le sonde possono essere basate sui meccanismi exec, grpc, HttpGet e TcpSocket. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#probe-check-methods In base al tipo e al risultato della sonda, il contenitore può essere riavviato.

Consulta la sezione Creazione del Pod nella sezione Appendice qui sotto per rivedere la sequenza degli eventi nel processo di creazione del Pod.

Usa sonde di prontezza

Per impostazione predefinita, quando tutti i contenitori all'interno di un Pod sono in esecuzione, la condizione Pod è considerata «Pronto». Tuttavia, l'applicazione potrebbe non essere ancora in grado di elaborare le richieste dei clienti. Ad esempio, l'applicazione potrebbe dover estrarre alcuni dati o configurazioni da una risorsa esterna per poter elaborare le richieste. In tale stato non vorresti chiudere l'applicazione né inoltrarle alcuna richiesta. La sonda di prontezza consente di accertarsi che il Pod non sia considerato «Pronto», vale a dire che non verrà aggiunto all' EndpointSliceoggetto, fino al risultato della sonda. success D'altra parte, se la sonda si guasta ulteriormente lungo la linea, il Pod viene rimosso dall'oggetto. EndpointSlice È possibile configurare una sonda di prontezza nel manifesto del Pod per ogni contenitore. kubeletil processo su ogni nodo esegue la sonda di prontezza sui contenitori su quel nodo.

Utilizza i cancelli di disponibilità del Pod

Un aspetto della sonda di prontezza è il fatto che non contiene alcun feedback/influence meccanismo esterno, il processo kubelet sul nodo esegue la sonda e definisce lo stato della sonda. Ciò non ha alcun impatto sulle richieste tra i microservizi stessi nel livello Kubernetes (traffico est-ovest) poiché il EndpointSlice Controller mantiene l'elenco degli endpoint (Pod) sempre aggiornato. Perché e quando avresti bisogno di un meccanismo esterno allora?

Quando esponi le tue applicazioni utilizzando il tipo di Load Balancer di Kubernetes Service o Kubernetes Ingress (per il traffico da nord a sud), l'elenco degli IP Pod per il rispettivo servizio Kubernetes deve essere propagato al load balancer dell'infrastruttura esterna in modo che anche il load balancer abbia un elenco di destinazioni aggiornato. https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.htmlAWS Load Balancer Controller colma questa lacuna. Quando utilizzi AWS Load Balancer Controller e ne approfittitarget group: IP, proprio come kube-proxy AWS Load Balancer Controller riceve un aggiornamento (tramitewatch) e quindi comunica con l'API ELB per configurare e iniziare a registrare l'IP del Pod come destinazione sull'ELB.

Quando si esegue un aggiornamento continuo di una distribuzione, vengono creati nuovi Pod e non appena la condizione di un nuovo Pod è «Pronto», il Pod viene terminato. old/existing Durante questo processo, l' EndpointSliceoggetto Kubernetes viene aggiornato più velocemente del tempo impiegato dall'ELB per registrare i nuovi Pod come destinazioni, vedi registrazione dei target. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html Per un breve periodo potrebbe verificarsi una mancata corrispondenza di stato tra il livello Kubernetes e il livello dell'infrastruttura in cui le richieste dei client potrebbero essere ignorate. Durante questo periodo all'interno del livello Kubernetes, i nuovi Pod sarebbero pronti a elaborare le richieste, ma dal punto di vista di ELB non lo sono.

Pod Readiness Gates consente di definire requisiti aggiuntivi che devono essere soddisfatti prima che la condizione del Pod sia considerata «Pronto». Nel caso di AWS ELB, AWS Load Balancer Controller monitora lo stato del target (il Pod) su AWS ELB e una volta completata la registrazione del target e il suo stato diventa «integro», il controller aggiorna la condizione del Pod su «Pronto». Con questo approccio si influenza la condizione del Pod in base allo stato della rete esterna, che è lo stato di destinazione su AWS ELB. Pod Readiness Gates è fondamentale negli scenari di aggiornamento continuo in quanto consente di evitare che l'aggiornamento progressivo di una distribuzione interrompa i vecchi pod fino a quando lo stato di destinazione dei Pods appena creati non diventi «integro» su AWS ELB.

Chiudi facilmente le applicazioni

L'applicazione dovrebbe rispondere a un segnale SIGTERM avviando la chiusura regolare in modo che i client non subiscano tempi di inattività. Ciò significa che l'applicazione deve eseguire procedure di pulizia come il salvataggio dei dati, la chiusura dei descrittori di file, la chiusura delle connessioni al database, il completamento corretto delle richieste in volo e l'uscita in modo tempestivo per soddisfare la richiesta di terminazione del Pod. È necessario impostare il periodo di tolleranza su un periodo sufficientemente lungo da consentire il completamento della pulizia. Per sapere come rispondere al segnale SIGTERM puoi fare riferimento alle risorse del rispettivo linguaggio di programmazione che usi per la tua applicazione.

Se la tua applicazione non è in grado di chiudersi correttamente alla ricezione di un segnale SIGTERM o se ignores/does non riceve il segnale, puoi invece sfruttare PreStop hook per avviare una chiusura regolare dell'applicazione. Prestop hook viene eseguito immediatamente prima dell'invio del segnale SIGTERM e può eseguire operazioni arbitrarie senza doverle implementare nel codice dell'applicazione stessa.

La sequenza generale degli eventi è mostrata nel diagramma seguente. Nota: indipendentemente dal risultato di una corretta procedura di chiusura dell'applicazione o dal risultato dell' PreStop hook, i contenitori dell'applicazione vengono infine chiusi alla fine del periodo di tolleranza tramite SIGKILL.

Consulta la sezione Eliminazione dei Pod nella sezione Appendice di seguito per rivedere la sequenza degli eventi nel processo di eliminazione dei Pod.

Gestisci con garbo le richieste dei clienti

La sequenza degli eventi nell'eliminazione dei Pod è diversa dalla creazione del Pod. Quando viene creato un Pod kubelet aggiorna l'IP del Pod nell'API Kubernetes e solo allora l' EndpointSlice oggetto viene aggiornato. D'altra parte, quando un Pod viene terminato, l'API Kubernetes invia una notifica sia al kubelet che al controller contemporaneamente. EndpointSlice Ispeziona attentamente il seguente diagramma che mostra la sequenza degli eventi.

Il modo in cui lo stato si propaga dal server API fino alle regole di iptables sui nodi spiegati sopra crea un'interessante race condition. Poiché c'è un'alta probabilità che il contenitore riceva il segnale SIGKILL molto prima che il kube-proxy su ciascun nodo aggiorni le regole locali di iptables. In tal caso, due scenari degni di nota sono:

Impostare il periodo di tolleranza nelle specifiche Pod abbastanza a lungo può risolvere questo problema, ma a seconda del ritardo di propagazione e del numero di richieste effettive dei client, è difficile prevedere il tempo impiegato dall'applicazione per chiudere correttamente le connessioni. Quindi l'approccio non così perfetto ma più fattibile qui è usare un PreStop hook per ritardare il segnale SIGTERM fino all'aggiornamento delle regole di iptables per assicurarsi che nessuna nuova richiesta client venga inviata all'applicazione, piuttosto che continuino solo le connessioni esistenti. PreStop hook può essere un semplice gestore Exec come. sleep 10

Il comportamento e la raccomandazione sopra menzionati sarebbero ugualmente applicabili quando esponi le tue applicazioni utilizzando il tipo di Load Balancer di Kubernetes Service o Kubernetes Ingress (per il traffico da nord a sud) utilizzando AWS Load Balancer Controller e leverage. target group: IP Perché proprio come kube-proxy AWS Load Balancer Controller riceve anche un aggiornamento (tramite watch) sull' EndpointSlice oggetto e quindi comunica con l'API ELB per iniziare a cancellare l'IP del Pod dall'ELB. Tuttavia, a seconda del carico sull'API Kubernetes o sull'API ELB, ciò può richiedere anche del tempo e il SIGTERM potrebbe essere già stato inviato all'applicazione molto tempo fa. Una volta che l'ELB inizia a cancellare la registrazione del target, interrompe l'invio di richieste a quel target in modo che l'applicazione non riceva nuove richieste e inoltre l'ELB avvia un ritardo di cancellazione che è di 300 secondi per impostazione predefinita. Durante il processo di cancellazione, l'obiettivo è fondamentalmente il punto in draining cui l'ELB attende che le connessioni in volo verso quella destinazione si esauriscano. requests/existing Una volta scaduto il ritardo di cancellazione, l'obiettivo è inutilizzato e tutte le richieste in volo indirizzate a tale obiettivo vengono forzatamente ritirate.

Usa il budget per le interruzioni del Pod

Configura un Pod Disruption Budget (PDB) per le tue applicazioni. PDB limita il numero di pod di un'applicazione replicata che sono inattivi contemporaneamente a causa di interruzioni volontarie. https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#voluntary-and-involuntary-disruptions Assicura che un numero o una percentuale minima di pod rimanga disponibile in una distribuzione o. StatefulSet Ad esempio, un'applicazione basata sul quorum deve garantire che il numero di repliche in esecuzione non venga mai portato al di sotto del numero necessario per il raggiungimento del quorum. Oppure un front-end web potrebbe garantire che il numero di repliche che servono il carico non scenda mai al di sotto di una certa percentuale del totale. PDB proteggerà l'applicazione da azioni quali lo svuotamento dei nodi o il lancio di nuove versioni di Deployments. Tieni presente che i PDB non proteggeranno l'applicazione da interruzioni involontarie come un guasto del sistema operativo del nodo o la perdita della connettività di rete. Per ulteriori informazioni, consulta la documentazione Specificare un budget di interruzione per la tua applicazione in Kubernetes.

Riferimenti

Appendice

Creazione di pod

È fondamentale capire qual è la sequenza di eventi in uno scenario in cui viene implementato un Pod e poi si tratta di ricevere ed elaborare healthy/ready le richieste dei clienti. Parliamo della sequenza degli eventi.

Eliminazione del pod

Proprio come per la creazione di un Pod, è fondamentale capire qual è la sequenza di eventi durante l'eliminazione del Pod. Parliamo della sequenza degli eventi.