Abilita Oracle Cloud Infrastructure Service Mesh nelle tue applicazioni Kubernetes
I clienti di Oracle Cloud Infrastructure (OCI) si sono sempre più spostati verso un'architettura di microservizi che, insieme ai suoi vantaggi, comporta anche nuove sfide. In un'architettura di microservizi, le applicazioni monolitiche sono suddivise in microservizi più piccoli che comunicano tramite la rete utilizzando un'API. Ciò causa un aumento del traffico di rete e aumenta la complessità e la superficie di attacco complessiva nell'architettura.
- Consente di controllare il flusso di traffico dei microservizi.
- Fornisce visibilità sulle applicazioni.
- Consente ai microservizi di connettersi in modo sicuro senza apportare modifiche al codice dell'applicazione.
Funzionalità di OCI Service Mesh
- Applicazione dei criteri relativi alla sicurezza
OCI Service Mesh utilizza i criteri di accesso per definire le regole di accesso. I criteri di accesso applicano la comunicazione tra microservizi e consentono solo le richieste convalidate che hanno origine all'interno e all'esterno dell'applicazione. I criteri di accesso vengono utilizzati anche per definire la comunicazione consentita ai servizi esterni.
- Zero trust
OCI Service Mesh implementa automaticamente un'architettura di sicurezza zero-trust in tutti i microservizi. I dati tra i microservizi vengono cifrati. L'identificazione da microservizi a microservizi è richiesta all'inizio della comunicazione. Le due parti devono scambiare le credenziali con le loro informazioni di identità. Ciò consente ai servizi di identificarsi a vicenda per determinare se sono autorizzati a interagire. Questa soluzione viene implementata con TLS reciproco con certificato automatico e rotazione delle chiavi utilizzando il servizio Oracle Cloud Infrastructure Certificates (OCI Certificates) e Oracle Key Management Cloud Service per gestire certificati e chiavi.
- Traffic Shifting
OCI Service Mesh ti consente di eseguire distribuzioni canary. Quando pubblichi una nuova versione del codice in produzione, consenti solo a una parte del traffico di raggiungerlo. Questa funzione consente di eseguire la distribuzione in modo rapido e provoca il minimo disturbo per l'applicazione. È possibile definire regole di instradamento che regolano tutte le comunicazioni tra microservizi all'interno della mesh. È possibile instradare una parte del traffico a una determinata versione del servizio.
- Monitoraggio e registrazione
OCI Service Mesh si trova in una posizione unica per fornire informazioni di telemetria poiché tutte le comunicazioni tra microservizi devono attraversarle. Ciò consente al mesh del servizio di acquisire dati di telemetria quali origine, destinazione, protocollo, URL, durata, codice di stato, latenza, log e altre statistiche dettagliate. È possibile esportare le informazioni di log nel servizio Oracle Cloud Infrastructure Logging (OCI Logging). OCI Service Mesh fornisce due tipi di log: log degli errori e log del traffico. È possibile utilizzare questi log per eseguire il debug di 404 o 505 problemi o generare statistiche basate sui log. I dati delle metriche e della telemetria possono essere esportati in Prometheus e visualizzati con Grafana. Entrambi possono essere distribuiti direttamente in un cluster OKE.
Architettura
Oracle Cloud Infrastructure Service Mesh (OCI Service Mesh) utilizza un modello sidecar. Questa architettura incapsula il codice che implementa la funzionalità di rete in un proxy di rete e quindi si basa sul traffico da e verso i servizi da reindirizzare nel proxy sidecar. Si chiama sidecar perché un proxy è collegato ad ogni applicazione, proprio come una sidecar collegata a una moto. In OKE, il contenitore dell'applicazione si trova accanto al contenitore sidecar proxy nello stesso pod. Poiché si trovano nello stesso pod, condividono lo stesso spazio di nomi di rete e lo stesso indirizzo IP, consentendo ai container di comunicare tramite "localhost".
- Piano di controllo
Il piano di controllo OCI Service Mesh gestisce e configura l'intera raccolta di proxy per instradare il traffico. Gestisce l'inoltro, il controllo dello stato, il bilanciamento del carico, l'autenticazione, l'autorizzazione e l'aggregazione della telemetria. Il piano di controllo interagisce con il servizio di certificazione OCI e il servizio di gestione delle chiavi OCI per fornire a ogni proxy il proprio certificato.
- Piano di dati
Il piano dati è composto dalla raccolta di proxy sidecar distribuiti nell'ambiente ed è responsabile della sicurezza, delle funzioni di rete e dell'osservabilità dell'applicazione. Inoltre, raccolgono e segnalano la telemetria su tutto il traffico mesh. Il proxy Envoy viene utilizzato per il piano dati di OCI Service Mesh.
Il seguente diagramma illustra questa architettura di riferimento.
oci_service_mesh_oke_arch-oracle.zip
Questa architettura di riferimento mostra un'applicazione distribuita in un cluster OKE con tre servizi. Lo spazio di nomi in cui l'applicazione viene distribuita è stato "meshificato". Uno spazio di nomi "meshified" indica che i servizi distribuiti all'interno dello spazio di nomi faranno parte di un mesh di servizio e ogni nuovo pod distribuito verrà inserito con un container proxy inviato. Quando ogni pod viene distribuito, le configurazioni e i certificati vengono inviati a ciascuno dei container proxy dal piano di controllo OCI Service Mesh. Il piano di controllo OCI Service Mesh comunica con il servizio Certificati OCI e Oracle Key Management Cloud Service per ottenere i certificati per ogni proxy.
Viene distribuito un gateway in entrata per fornire l'accesso esterno all'applicazione. Il gateway in entrata fa parte del piano dati OCI Service Mesh ed è anche un proxy di invio che riceve configurazione e certificati dal piano di controllo OCI Service Mesh.
È responsabilità del contenitore proxy eseguire la ricerca automatica del servizio, la cifratura del traffico e l'autenticazione con il servizio di destinazione. I contenitori proxy applicano anche criteri di rete, ad esempio il modo in cui il traffico viene distribuito tra diverse versioni del servizio e applicano i criteri di accesso. Il gateway in entrata esegue la stessa funzione per il traffico esterno al mesh di servizio.
Prometheus e Grafana vengono distribuiti all'interno del cluster OKE in uno spazio di nomi separato che non fa parte del mesh di servizio. Il piano dati mesh del servizio invia alla distribuzione Prometheus statistiche operative chiave quali latenza, errori, richieste e telemetria. Grafana estrae i dati dalla distribuzione Prometheus, che può essere utilizzata per creare dashboard per la visualizzazione.
OCI Service Mesh è integrato con il servizio di log OCI e il log può essere abilitato quando viene creato il mesh di servizio. OCI Service Mesh fornisce due tipi di log: log degli errori e log del traffico. Questi log possono essere utilizzati per eseguire il debug di 404 o 505 problemi o per generare statistiche basate sui log.
Questa architettura dispone dei seguenti servizi OCI:
- OCI Kubernetes Engine (OKE)
Offre un cluster Kubernetes altamente disponibile e scalabile pronto per la produzione per distribuire le applicazioni containerizzate nel cloud.
- Load balancer
Fornisce l'accesso al gateway in entrata nel cluster OKE. L'ingresso indirizza il traffico ai servizi richiesti nel cluster OKE.
- Autorità di certificazione
Gestisce i certificati TLS per il servizio OCI Service Mesh.
- Gestione chiavi
Gestisce le chiavi utilizzate dal servizio Certificate Authority.
L'architettura presenta i seguenti componenti:
- Area
Un'area geografica Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).
- Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, le reti VCN consentono di controllare l'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. Puoi segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.
- Lista di sicurezza
Per ogni subnet, puoi creare regole di sicurezza che specificano l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.
Risorse OCI Service Mesh
| Risorse Kubernetes | Descrizione |
| Mesh | Il mesh di livello superiore è il contenitore logico per tutti i microservizi nell'applicazione. |
| Servizio virtuale | Un servizio virtuale è una rappresentazione logica del microservizio in un mesh di servizio. |
| Distribuzioni virtuali | Una distribuzione virtuale è una rappresentazione logica di una distribuzione che può essere raggruppata in un servizio virtuale. Ciò consente a un servizio virtuale di distribuire il traffico tra le diverse versioni del microservizio. Un microservizio Kubernetes può avere più versioni che sono distribuzioni separate nel cluster. |
| Associazioni di distribuzione virtuali | Le associazioni virtuali vengono utilizzate per associare un set di pod a una distribuzione virtuale. |
| Tabelle di instradamento servizio virtuale | Una tabella di instradamento virtuale definisce il modo in cui il traffico viene distribuito tra le distribuzioni virtuali in un servizio virtuale basato su protocollo e percorso. Ogni servizio virtuale avrà una tabella di instradamento virtuale. |
| Distribuzione del gateway in entrata | Una distribuzione del gateway in entrata creerà pod in entrata che fungono da load balancer per il traffico in entrata verso la rete. |
| Gateway in entrata | I gateway in entrata gestiscono il traffico in entrata nella rete. I gateway in entrata definiscono un set di regole per il modo in cui il traffico esterno comunica con la rete, ad esempio se è necessaria la cifratura per tutto il traffico in entrata e in uscita. Queste regole vengono applicate alla distribuzione del gateway in entrata. |
| Tabelle di instradamento gateway in entrata | Le tabelle di instradamento del gateway in entrata sono associate a una distribuzione del gateway in entrata. La tabella di instradamento definisce quali servizi virtuali all'interno del mesh sono accessibili dalla distribuzione del gateway in entrata. |
| Criteri di accesso | I criteri di accesso sono regole predefinite che definiscono la comunicazione consentita tra i microservizi nella rete e le applicazioni esterne. |
Il diagramma riportato di seguito descrive il modo in cui le risorse Mesh di servizio OCI configurate: Criteri di accesso, Gateway in entrata, Servizio virtuale e Distribuzione virtuale vengono mappate alle risorse dell'applicazione: K8s Service, K8s Service Load Balancer, Distribuzioni e Pod.
Suggerimenti
- VCN
Quando crei una VCN, determina il numero di blocchi CIDR necessari e la dimensione di ciascun blocco in base al numero di risorse che intendi collegare alle subnet nella VCN. Utilizzare i blocchi CIDR all'interno dello spazio di indirizzi IP privati standard.
Selezionare i blocchi CIDR che non si sovrappongono a qualsiasi altra rete (in Oracle Cloud Infrastructure, nel data center on premise o in un altro provider cloud) a cui si intende impostare connessioni private.
Dopo aver creato una VCN, puoi modificarne, aggiungerne e rimuoverne i blocchi CIDR.
Quando si progettano le subnet, considerare il flusso di traffico e i requisiti di sicurezza. Collega tutte le risorse all'interno di un livello o ruolo specifico alla stessa subnet, che può fungere da limite di sicurezza.
- Larghezza di banda del load balancer
Durante la creazione del load balancer, puoi selezionare una forma predefinita che fornisca una larghezza di banda fissa oppure specificare una forma personalizzata (flessibile) in cui impostare un intervallo di larghezza di banda e consentire al servizio di ridimensionare automaticamente la larghezza di banda in base ai pattern di traffico. Con entrambi gli approcci, puoi modificare la forma in qualsiasi momento dopo aver creato il load balancer.
Considerazioni
Quando si distribuisce questa architettura di riferimento, considerare le seguenti opzioni.
- Costo
Non è previsto alcun addebito per il piano di controllo di OCI Service Mesh nel cluster OKE. Ai clienti viene addebitato il costo per l'utilizzo delle risorse dei contenitori proxy per il piano dati Mesh di servizio. In pratica, tuttavia, i clienti stanno già pagando le risorse per il pool di nodi in un cluster OKE e, a meno che l'utilizzo dei container proxy non spinga l'utilizzo del pool di nodi oltre il 100%, non è previsto alcun costo aggiuntivo per l'aggiunta di OCI Service Mesh all'architettura dei microservizi.
- Disponibilità
Il piano di controllo di OCI Service Mesh viene sempre distribuito con alta disponibilità.