Per il servizio di backup Clumio Protect, utilizziamo Amazon Elastic Kubernetes Service (EKS) per gestire i nostri cluster Kubernetes. Il vantaggio principale dell’utilizzo di un Kubernetes gestito è la stretta integrazione con gli altri servizi offerti dal proprio provider cloud. Nello specifico, quando si crea un nuovo servizio Kubernetes, un controller di servizio – fornito da AWS e installato nel cluster – crea una nuova istanza di Elastic Load Balancer (ELB) e la configura per instradare il traffico verso il servizio. Allo stesso tempo, tale controller gestisce l’intero ciclo di vita del bilanciatore di carico corrispondente: fornisce una configurazione corretta per i suoi controlli di integrità e mantiene aggiornato il gruppo di destinazione del bilanciatore di carico quando si aggiungono o si rimuovono nodi dal cluster. Infine, elimina il bilanciatore di carico quando si elimina il servizio Kubernetes dal cluster.
Sebbene sia molto pratico utilizzare i servizi Kubernetes supportati dai bilanciatori di carico AWS, vi sono diverse considerazioni di cui occorre tenere conto.
L’architettura cloud-native di Clumio
La nostra architettura si basa sui microservizi e ciascuno dei nostri cluster Kubernetes ospita diverse decine di questi servizi. Il numero di servizi è particolarmente elevato nei nostri cluster di sviluppo, dove ospitiamo il maggior numero possibile di ambienti di sviluppo isolati all’interno di un singolo cluster. In alcuni cluster di sviluppo abbiamo più di 300 servizi e il numero continua a crescere. Inutile dire che ogni bilanciatore di carico AWS ha un costo e non sarebbe ragionevole per noi disporre di oltre 300 bilanciatori di carico AWS solo per un singolo cluster di sviluppo. Un altro problema è il limite al numero di bilanciatori di carico che ogni cluster EKS può supportare. Questo limite è legato al numero massimo di regole nel gruppo di sicurezza EC2. Nello specifico, un nostro cluster EKS medio non potrebbe avere più di 60 bilanciatori di carico classici. Per risolvere questo problema, abbiamo deciso di utilizzare Kubernetes Ingress per la maggior parte dei nostri servizi. Il meccanismo Ingress ci offre la possibilità di condividere un unico ELB tra più servizi all’interno di un cluster EKS, riducendo così l’utilizzo delle risorse e i costi.
Perché aggiungere Kubernetes Ingress
La creazione di un nuovo bilanciatore di carico AWS richiede in genere un po’ di tempo. Questo ritardo è accettabile per la maggior parte delle operazioni; tuttavia, per alcune modifiche, ad esempio la distribuzione simultanea di più microservizi, volevamo ridurre al minimo il tempo necessario per raggiungere lo stato di Readiness. Per risolvere questo caso d’uso, l’aggiunta di un nuovo Ingress di Kubernetes garantisce un funzionamento immediato. A seconda dell’implementazione specifica, un controller Ingress deve ricaricare la nuova configurazione, analogamente ai controller Ingress Nginx, oppure applicare la nuova configurazione in fase di esecuzione, come nei controller Ingress basati su Envoy.
Quando si lavora con i servizi, ci si aspetta che ciascuno di essi abbia un nome DNS, possibilmente esterno. Con l’approccio “ELB per servizio”, non è possibile creare un nome DNS finché non viene creato l’ELB. Con un unico ELB preassegnato al controller Ingress, è possibile assegnare in anticipo a quell’ELB tutti gli alias DNS desiderati, in modo che tutti i nostri servizi diventino disponibili non appena creiamo le definizioni di Ingress per essi.
Alcuni dei nostri servizi espongono API REST, ma la stragrande maggioranza dei nostri servizi dispone di endpoint gRPC. Avevamo bisogno di un controller Ingress che supportasse contemporaneamente sia HTTPS che gRPC e volevamo che il TLS terminasse sul controller Ingress stesso. Quest’ultimo non era un requisito imprescindibile e abbiamo valutato l’utilizzo dei sidecar di Istio per terminare il TLS direttamente in un pod di microservizio. Tuttavia, abbiamo deciso di utilizzare il controller Ingress per terminare il TLS poiché è più semplice da gestire e comporta, in generale, un overhead minore per il cluster. Un altro requisito che avevamo era quello di poter distribuire diverse istanze del controller Ingress nello stesso cluster. Una definizione Ingress specifica può avere un’annotazione kubernetes.io/ingress.class per specificare quale controller Ingress debba essere utilizzato.
Abbiamo testato diversi controller Ingress e abbiamo scoperto che era sorprendentemente difficile trovarne uno che soddisfacesse tutti i requisiti. Alcuni controller non funzionavano correttamente con gRPC, altri non supportavano più istanze di controller nello stesso cluster. Alla fine, abbiamo scoperto che il controller Ingress di NGINX fa al caso nostro. Abbiamo dovuto apportare solo una piccola modifica alla sua configurazione per aumentare la dimensione del buffer gRPC e renderlo compatibile con il nostro stack gRPC.
Miglioriamo costantemente i nostri servizi a livello di infrastruttura per far scalare la nostra infrastruttura e ottimizzare i costi di manutenzione. Inizialmente, utilizzavamo un bilanciatore di carico dedicato per ogni servizio, ma ben presto abbiamo raggiunto il limite del numero di bilanciatori di carico consentiti per cluster. A quel punto abbiamo aggiornato la nostra infrastruttura per utilizzare controller Ingress ospitati per la connettività esterna dei nostri servizi, riducendo in modo significativo il numero di bilanciatori di carico classici AWS necessari per il prodotto. L’utilizzo di AWS Application Load Balancer (ALB) non era un’opzione in quel momento, poiché ALB non supportava gRPC. Alla fine del 2020, AWS ha annunciato di aver aggiunto il supporto per HTTP/2 end-to-end e gRPC per Application Load Balancer. Ora possiamo utilizzare il controller AWS Load Balancer, precedentemente noto come “AWS ALB Ingress Controller”, che è stato donato al Kubernetes AWS Special Interest Group (SIG-AWS) per consentire ad AWS e agli altri collaboratori del SIG-AWS di gestire ufficialmente il progetto. Non vediamo l’ora di utilizzare questo controller Ingress per la nostra infrastruttura. Un altro oggetto del nostro interesse è la Kubernetes Gateway API, una nuova API di Kubernetes attualmente in fase di sviluppo da parte del Network Special Interest Group (SIG-Network). Rispetto all’API Ingress, l’API Gateway espone un’API più generica per il proxy, utilizzabile per un numero maggiore di protocolli oltre a HTTP, e modella un maggior numero di componenti dell’infrastruttura per fornire migliori opzioni di distribuzione e gestione agli operatori dei cluster. Non vediamo l’ora di provare i futuri controller Kubernetes che implementeranno l’API Gateway.
Riduzione dell’utilizzo delle risorse e dei costi
Il meccanismo Ingress di Kubernetes ci aiuta a ridurre l’utilizzo delle risorse e i costi. Non siamo più vincolati dai limiti di EC2 ed EKS per quanto riguarda il numero di servizi distribuiti su un singolo cluster Kubernetes gestito. Alcuni controller Ingress open source funzionano con i servizi gRPC fin da subito, ma richiedono un’ulteriore verifica per accertarsi che funzionino per un caso d’uso specifico. La comunità Kubernetes fornisce e migliora costantemente le API di Kubernetes, come l’API Ingress o l’API Gateway, mentre i fornitori commerciali e open source offrono varie implementazioni di tali API. Ciò consente di scegliere l’implementazione più adatta a un caso d’uso specifico e di sostituirle senza apportare modifiche significative a livello di applicazione.
