Utilizzo di GitOps con Amazon Elastic Kubernetes Service con Landbay

Nel panorama in evoluzione del prestito digitale, Landbay, un prestatore ipotecario pluripremiato nel mercato buy-to-let del Regno Unito, sta rivoluzionando la sua infrastruttura digitale. Con una piattaforma di broker all'avanguardia che supporta le sue operazioni di sottoscrizione, la piattaforma di Landbay è basata sui servizi AWS e comprende circa 60 microservizi, seguendo un'architettura a tre livelli, che unisce server Web, Amazon Elastic Kubernetes Service (Amazon EKS) e un livello di dati a più livelli. Combinando la potenza dei servizi cloud AWS con progetti open source, Landbay è riuscita a sfruttare questo nuovo approccio per creare un'architettura all'avanguardia basata su Amazon Elastic Kubernetes Service.

Il vantaggio di GitOps

Man mano che le architetture di microservizi acquisiscono importanza, GitOps è emerso come nuovo standard per questo meccanismo di implementazione. All'interno della Cloud Native Computing Foundation (CNCF) sono emersi due prodotti degni di nota: Flux e ArgoCD. Landbay ha scelto Flux per la sua integrazione nativa con Kubernetes esponendo definizioni di risorse personalizzate (CRD) per descrivere implementazioni, versioni helm, personalizzazioni e altro ancora. Questo, a sua volta, ha consentito agli ingegneri del software di padroneggiare Kubernetes, comprendendo così più facilmente come Flux si integra nell'ecosistema.

Panoramica della soluzione

Per fornire una comprensione completa dell'implementazione GitOps di Landbay, esaminiamo i componenti architetturali chiave e le loro relazioni all'interno dell'ecosistema AWS:

• Amazon Elastic Container Registry (ECR): Landbay si appoggia su Amazon ECR per archiviare grafici Helm e immagini Docker.
• Controller DNS esterni e AWS Elastic Load Balancing: questi controller vengono utilizzati per configurare Route53 e i bilanciatori del carico, garantendo l'accesso esterno agli ingressi Kubernetes.
  
• Integrazione con AWS Secrets Manager: per motivi architettonici e di sicurezza, Landbay ha optato per l'integrazione diretta con AWS Secrets manager, anziché utilizzare strumenti esterni come il controller segreto esterno, che si allinea al modello di responsabilità condivisa AWS e migliora lo stato generale di sicurezza della soluzione.
  
• Gestione della configurazione Terraform: Terraform può essere utilizzato per colmare il divario fornendo una ConfigMap e riepilogando gli elementi di configurazione chiave (endpoint, sottoreti CIDR, ecc.). Flux può quindi utilizzare la config-map tramite la sua funzionalità di post-compilazione (vedi figura 2).
  

Ambiente Kubernetes e architettura dei dati di Landbay

Landbay adotta assiduamente Terraform e tutta la sua infrastruttura è codificata con infrastructure-as-code (IAC). Questo approccio garantisce la sincronicità tra gli ambienti di test e produzione e garantisce che tutte le modifiche all'infrastruttura passino attraverso il processo standard del ciclo di vita dello sviluppo del software.

Per garantire zero tempi di inattività durante gli aggiornamenti di Amazon EKS, Landbay utilizza gruppi di nodi gestiti EKS con tre gruppi di nodi gestiti, ciascuno destinato a una specifica zona di disponibilità. Questa configurazione consente loro di utilizzare volumi persistenti, facilitati dal driver CSI di Amazon Elastic Block Store (EBS). Inoltre, Landbay utilizza topologySpreadConstraints (DoNotSchedule) per garantire che gli StatefulSets siano distribuiti nelle zone di disponibilità.

Per i servizi critici, le classi di priorità personalizzate vengono utilizzate per eliminare le implementazioni con priorità inferiore.

Per ridurre i costi nell'ambiente di test, Landbay sfrutta la potenza delle istanze spot di Amazon EC2 tramite i gruppi di nodi gestiti Terraform e Amazon EKS.

Infine, Landbay ha incorporato Bottlerocket, presentando una superficie di attacco molto ridotta. Il suo operatore Kubernetes viene utilizzato per aggiornare gradualmente i nodi di un cluster utilizzando il concetto di onde. Sebbene l'accesso al file system root sia bloccato, l'integrazione con IAM e Systems Manager (SSM) soddisfa i requisiti fondamentali di Landbay.

Componenti aggiuntivi di Amazon EKS

Oltre al plug-in CNI di Amazon Virtual Private Cloud (Amazon VPC), Landbay esegue i seguenti componenti aggiuntivi:

1. CoreDNS: garantisce la risoluzione del servizio DNS all'interno del cluster
2. KubeProxy: sostiene il rilevamento servizi e la rete all'interno di Kubernetes.
   
3. Amazon VPC CNI con enableNetworkPolicy: consente l'applicazione di policy di rete supportando Landbay nel proteggere vari accessi a spazi dei nomi e pod.
   
4. Driver CSI di Amazon EBS: consente l'uso di volumi persistenti.
   

Configurazione della gestione degli accessi

Landbay utilizza il Centro identità AWS IAM per controllare tutti gli accessi alle API AWS. Amazon EKS consente la mappatura dei ruoli SSO nei gruppi Kubernetes, consentendo la mappatura indiretta ai gruppi Azure Entra ID tramite il team di amministratori IT. Questo approccio garantisce una separazione delle problematiche tra il team di amministrazione IT e il resto dell'organizzazione.

Il frammento precedente può quindi essere utilizzato per impostare una risorsa kubernetes_config_map_v1-data aws_auth:

Per evitare una proliferazione di ruoli, Kubernetes fornisce un meccanismo per aggregare le autorizzazioni di altre versioni di Helm in gruppi esistenti utilizzando “aggregate-to-admin”:

AWS Load Balancer Controller

Per migliorare l'integrazione tra i servizi, Landbay ha sfruttato AWS Load Balancer Controller (LBC) e External DNS Controller.

AWS Load Balancer Controller consente il provisioning del bilanciatore del carico direttamente da Ingresses, nonché la possibilità di riutilizzare bilanciatori del carico gestiti esternamente e assegnare pod di destinazione. Separando il provisioning dei bilanciatori del carico in un progetto separato, i team DevOps possono avere maggiori privilegi su un unico repository di codice sorgente, fornendo al contempo gli strumenti necessari per il lavoro ai tecnici che gestiscono le destinazioni.

Il controller gestisce anche i gruppi di sicurezza, se necessario, sul backend tra il bilanciatore del carico e le sue destinazioni. Inoltre, utilizzando l'annotazione group.name, lo stesso bilanciatore del carico può essere condiviso con più gruppi di destinazione in background

Landbay utilizza inoltre AWS Load Balancer Controller per fornire il Network Load Balancer per consentire l'ingresso dalle funzioni AWS Lambda in esecuzione all'interno del VPC nell'infrastruttura EKS.

A complemento di ciò, il controller DNS esterno consente ai pod Kubernetes un accesso limitato in scrittura verso Route53. Questa funzionalità facilita automaticamente l'esposizione automatica di servizi esterni con nomi DNS intuitivi, migliorando l'esperienza complessiva dell'utente.

Dal punto di vista della sicurezza, il controller dell'Application Load Balancer (ALB) e il controller DNS esterno richiedono un set limitato di autorizzazioni IAM, le quali possono essere bloccate saldamente. Ad esempio, il controller DNS richiede semplicemente l'accesso in scrittura a specifiche zone di Route 53 (route53:ChangeResourceRecordSets) e una manciata di elenchi di autorizzazione.

Gestione dei segreti all'interno di Kubernetes

Sebbene la maggior parte delle soluzioni risolva i problemi relativi alla gestione dei segreti, come la rotazione e l'integrazione dei segreti, l'utilizzo dell'archiviazione segreta di Kubernetes o la sincronizzazione di segreti esterni in Kubernetes comporterà l'archiviazione dei segreti in chiaro nell'etcd sottostante di Kubernetes.  Sebbene l'uso di “segreti crittografati in EKS” aiuti a mitigare i vettori di attacco fisico, l'accesso tramite l'API Kubernetes espone i valori grezzi del segreto, secondo il modello di responsabilità condivisa AWS.

L'utilizzo del driver CSI (Container Storage Interface) fornito da AWS offre vantaggi ma allontana anche l'architettura dalla gestione nativa di Kubernetes. Considerando che sia il driver CSI che una soluzione di provider esterno richiedono l'integrazione diretta con il provider di servizi segreti esterno, Landbay ha deciso di integrare i suoi microservizi direttamente con AWS Secret Manager.

L'opzione di integrazione diretta evita di introdurre una maggiore complessità nell'ambiente che potrebbe altrimenti comportare costi di manutenzione e supporto più elevati. Inoltre, evita la presenza di informazioni segrete in chiaro nei volumi dei container, migliorando ulteriormente la sicurezza.

Provisioning di Flux nell'ambiente AWS

Flux, la soluzione GitOps scelta da Landbay, fornisce un provider di Terraform per il bootstrap di cluster EKS. A intervalli regolari e configurabili, Flux assicura che tutti i manifesti di Kubernetes definiti nel repository Git si riconciliino con le risorse esistenti implementate su Kubernetes, annullando qualsiasi scostamento rilevato. Una volta avviato, Flux può eseguire la prima riconciliazione, installando servizi configurati, pod, set stateful e altro nel cluster Kubernetes, come mostrato nella figura seguente.

Flux può sfruttare AWS Elastic Container Registry (ECR) come repository Helm poiché ECR offre un supporto di prima classe per gli artefatti OCI. Ciò consente a Flux di fungere da collante tra ECR ed EKS, utilizzando personalizzazioni per applicare configurazioni specifiche dell'ambiente.

Un vantaggio chiave di questo approccio è la separazione logica tra la parte di integrazione continua (CI) della pipeline di implementazione (sviluppo, test e pacchettizzazione) e la parte di implementazione continua (CD) (distribuzione nell'ambiente). Dal punto di vista della sicurezza, Flux apporta le modifiche, consentendo di bloccare in modo significativo le autorizzazioni di accesso per le implementazioni quotidiane. Per evitare ritardi nell'implementazione, l'unica autorizzazione richiesta consiste nel fatto che lo strumento di compilazione “notifichi” a Flux una riconciliazione anticipata, che può essere effettuata tramite un kubeconfig bloccato, con un utente limitato.

Di conseguenza, implementare, ripristinare o promuovere un nuovo microservizio diventa semplice come aggiornare un frammento di controllo delle versioni semantico (semver) in un file YAML o ripristinare un commit. Dopo aver osservato una modifica di Git, Flux attiva una riconciliazione con Kubernetes e aggiorna di conseguenza il servizio pertinente.

Struttura del repository Flux e componenti condivisi

Flux fornisce una documentazione completa sulle strutture di repository suggerite. L'approccio di Landbay è relativamente semplice e segue tali best practice.

Le configurazioni dei cluster sono definite nelle proprie cartelle dedicate, ognuna delle quali fa riferimento a componenti condivisi. All'interno di queste cartelle di cluster, l'uso estensivo di personalizzazioni garantisce l'isolamento tra i cluster. Ciò consente configurazioni specifiche dell'ambiente, come il controllo delle versioni e memoria.

La struttura illustrata soprastante trova un equilibrio tra la condivisione del codice e il mantenimento della natura dichiarativa ed esplicita del paradigma GitOps, consentendo a un ingegnere di leggere un repository Git e accertare quali componenti, versioni o pacchetti sono stati installati nel cluster.

Separando i componenti, Landbay può semplificare il processo di creazione di nuovi cluster. Da qui, la configurazione dei cluster diventa una questione di scegliere i “mattoncini LEGO” e assemblarli con una configurazione specifica per l'ambiente.

Inoltre, mentre alcuni cluster operano nel cloud e richiedono componenti aggiuntivi, altri cluster possono essere destinati agli ingegneri DevOps che lavorano localmente. Questo approccio di sviluppo locale fornisce un ciclo di feedback più rapido e non include componenti direttamente correlati ai servizi AWS.

Lo sviluppo locale come trampolino di lancio

Questo approccio allo sviluppo locale è anche il trampolino di lancio per implementazioni rapide di ambienti di sviluppo temporanei basati su cloud. Utilizzando spazi dei nomi Kubernetes e rimuovendo le dipendenze dai servizi gestiti AWS, Landbay è in grado di utilizzare Flux per avviare rapidamente nuovi ambienti autonomi.

In questo caso, l'ambiente di sviluppo di Landbay potrebbe sostituire Amazon Relational Database Service (RDS) con un semplice container MariaDB, e il Servizio OpenSearch di Amazon con l'equivalente container OpenSearch. Sebbene questo approccio mantenga gli ambienti di sviluppo “al passo” dal punto di vista architettonico (ad esempio spazi dei nomi simili, rilevamento servizi, rete), il compromesso è la mancanza di resilienza operativa, che può essere accettabile per alcuni ambienti di sviluppo.

Integrazione dei servizi EKS, GitOps e AWS

In Landbay, l'infrastruttura AWS è gestita interamente da Terraform. È quindi fondamentale colmare il divario tra gli elementi forniti da Terraform (RDS, OpenSearch, ecc.) e altri pod in esecuzione all'interno del cluster. Il modo nativo per accedere alla configurazione in Kubernetes nei microservizi è tramite ConfigMaps.

Il diagramma seguente mostra l'interrelazione tra i nostri progetti Terraform e Flux.

Il primo progetto Terraform è responsabile della configurazione di tutte le reti di base, dei bilanciatori del carico rivolti a Internet e dei servizi gestiti AWS. Il secondo progetto stabilisce il cluster EKS, avvia Flux nel cluster, protegge il cluster EKS, imposta qualsiasi ruolo IAM e gestisce problemi di basso livello come i gruppi di nodi gestiti che eseguono Bottlerocket. Questo progetto crea un ambiente ConfigMap che interroga AWS per tutte le variabili ambientali e le inserisce in Kubernetes.

Il progetto finale è un progetto Flux dedicato. Questo definisce la configurazione del cluster per l'ambiente, si collega a un set di componenti condivisi e quindi personalizza le versioni di Helm e i manifesti di Kubernetes per adattarli all'ambiente pertinente. L'ambiente ConfigMap può quindi essere utilizzato come parte delle personalizzazioni all'interno del repository Flux. Flux offre inoltre una funzionalità di sostituzione delle variabili post-compilazione, ciò consente l'uso di sostituzioni di variabili con un ricco set di funzioni di sostituzione delle stringhe bash ben definite.

Ad esempio, all'interno di un grafico Helm, i valori possono utilizzare la sostituzione delle variabili dopo la creazione. Come si può vedere nella figura seguente, questo approccio migliora il repository GitOps in modo che i componenti condivisi possano essere indipendenti dall'ambiente.

Conclusioni

La decisione di Landbay di adottare GitOps tramite Flux, strettamente integrata sia con Amazon EKS che con il più ampio ecosistema AWS, si è dimostrata rivoluzionaria. Adottando questo approccio all'avanguardia, Landbay ha ottenuto una miriade di vantaggi che hanno semplificato le operazioni e innalzato il livello di sicurezza. Forse uno dei vantaggi più significativi è stata la realizzazione di efficienze ingegneristiche su tutta la linea. Da implementazioni più rapide e tempi di attesa ridotti al perfetto sfruttamento di soluzioni di terze parti, l'integrazione di GitOps con i servizi EKS e AWS ha rivoluzionato i processi di sviluppo di Landbay.

Inoltre, il panorama della sicurezza di Landbay è stato rafforzato, diventando più solido ed economico da mantenere. Sfruttando Bottlerocket, separando i compiti tramite le autorizzazioni SCM/Git e consentendo aggiornamenti semplici tramite Helm, Landbay ha consolidato il suo impegno per la sicurezza ottimizzando al contempo i costi operativi.

L'impatto più profondo di questo percorso trasformativo risiede nella maggiore visibilità e trasparenza dello stato e dei cambiamenti del carico di lavoro EKS. Con GitOps, la configurazione viene dichiarata utilizzando YAML e tutte le modifiche vengono archiviate come commit Git. Questo cambio di paradigma ha portato vantaggi significativi ai team di supporto, rischio, conformità e audit di Landbay, fornendo loro una visione e un controllo senza precedenti sui loro sistemi mission-critical.

Se hai intenzione di trasformare la tua startup seguendo il modello di Landbay, iscriviti ad AWS Activate per accedere a modelli implementabili, crediti AWS e opportunità di apprendimento.