Distribuisci Kubernetes serverless con i nodi virtuali del motore Kubernetes OCI
Entrambe le modalità operative possono supportare applicazioni di base fino a quelle più strategiche. Con i nodi virtuali, le operazioni Kubernetes sono semplificate e offrono il miglior rapporto prezzo/prestazioni. Il compromesso tra i nodi gestiti e i nodi virtuali riguarda i nodi gestiti e avrai un maggiore controllo sull'infrastruttura dei nodi. Puoi configurare le risorse Kubernetes in modo che utilizzino HostPort e HostNetwork oppure eseguire DaemonSets e altre opzioni che potrebbero essere necessarie per le tue applicazioni o i tuoi strumenti. Nella maggior parte dei casi d'uso, queste opzioni non sono necessarie.
I nodi virtuali hanno più senso quando non è necessario ottimizzare il controllo sull'esecuzione e la gestione dei container. Se le applicazioni richiedono la configurazione dell'infrastruttura dei nodi non disponibile con i nodi virtuali, utilizzare i nodi gestiti.
Architettura
Per integrare il cluster OKE con OCI Vault, l'operatore dei segreti esterni viene distribuito nel cluster OKE. Ciò consente di definire una risorsa SecretStore mappata al Vault OCI per contenere la password per il database. Una volta mappata la risorsa SecretStore, il cluster OKE può accedere alla password come segreto Kubernetes. Un ruolo OCI Identity and Access Management con l'autorizzazione di lettura dal Vault OCI consente al pod di accedere al segreto. Il ruolo è associato all'account di servizio Kubernetes utilizzato nella definizione del pod per concedere l'accesso alla lettura dal Vault OCI.
Il seguente diagramma illustra questa architettura di riferimento.
Descrizione dell'immagine k8n-virtual-nodes.png
L'architettura presenta i seguenti componenti:
- Tenancy
Una tenancy è una partizione sicura e isolata che Oracle imposta all'interno di Oracle Cloud quando ti iscrivi a Oracle Cloud Infrastructure. Puoi creare, organizzare e amministrare le risorse in Oracle Cloud all'interno della tua tenancy. Una tenancy è sinonimo di azienda o organizzazione. Di solito, un'azienda avrà una singola tenancy e rifletterà la sua struttura organizzativa all'interno di quella tenancy. Una singola tenancy viene in genere associata a una singola sottoscrizione e una singola sottoscrizione in genere ha una sola tenancy.
- 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).
- Compartimento
I compartimenti sono partizioni logiche tra più aree all'interno di una tenancy Oracle Cloud Infrastructure. Usare i compartimenti per organizzare le risorse in Oracle Cloud, controllare l'accesso alle risorse e impostare le quote d'uso. Per controllare l'accesso alle risorse in un determinato compartimento, definire criteri che specificano chi può accedere alle risorse e quali azioni possono eseguire.
- Domini di disponibilità
I domini di disponibilità sono data center standalone e indipendenti all'interno di un'area geografica. Le risorse fisiche in ciascun dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.
- Domini di errore
Un dominio di errore consiste in un gruppo di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità dispone di tre domini di errore con alimentazione e hardware indipendenti. Quando distribuisci le risorse su più domini di errore, le tue applicazioni possono tollerare errori fisici del server, manutenzione del sistema e errori di alimentazione all'interno di un dominio di errore.
- 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.
- Load balancer
Il servizio Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un unico punto di accesso a più server nel back-end.
- Gateway Internet
Il gateway Internet consente il traffico tra le subnet pubbliche in una VCN e la rete Internet pubblica.
- Gateway NAT (Network Address Translation)
Un gateway NAT consente alle risorse private in una VCN di accedere agli host su Internet, senza esporre tali risorse alle connessioni Internet in entrata.
- Gateway del servizio
Il gateway di servizi fornisce l'accesso da una VCN ad altri servizi, come Oracle Cloud Infrastructure Object Storage. Il traffico dalla VCN al servizio Oracle viene instradato sul fabric di rete Oracle e non attraversa Internet.
- Vault
Oracle Cloud Infrastructure Vault ti consente di gestire centralmente le chiavi di cifratura che proteggono i tuoi dati e le credenziali segrete utilizzate per proteggere l'accesso alle tue risorse nel cloud. È possibile utilizzare il servizio Vault per creare e gestire vault, chiavi e segreti.
- Registro
Oracle Cloud Infrastructure Registry è un registro gestito da Oracle e che ti consente di semplificare il flusso di lavoro da sviluppo a produzione. Registry semplifica la memorizzazione, la condivisione e la gestione degli artifact di sviluppo, ad esempio le immagini Docker. L'architettura altamente disponibile e scalabile di Oracle Cloud Infrastructure ti assicura di poter distribuire e gestire le tue applicazioni in modo affidabile.
- 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.
- Tabella di instradamento
Le tabelle di instradamento virtuali contengono regole per instradare il traffico dalle subnet alle destinazioni esterne a una VCN, in genere attraverso i gateway.
- Motore Kubernetes OCI
Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine o OKE) è un servizio completamente gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le tue applicazioni containerizzate nel cloud. Puoi specificare le risorse di computazione richieste dalle tue applicazioni e Kubernetes Engine le esegue sul Oracle Cloud Infrastructure in una tenancy esistente. OKE utilizza Kubernetes per automatizzare l'implementazione, la scalabilità e la gestione di applicazioni containerizzate tra cluster di host.
- Oracle MySQL Database Service
Oracle MySQL Database Service è un servizio di database Oracle Cloud Infrastructure (OCI) completamente gestito che consente agli sviluppatori di sviluppare e distribuire rapidamente applicazioni cloud native sicure. Ottimizzato ed esclusivamente disponibile in OCI, Oracle MySQL Database Service è stato creato, gestito e supportato al 100% dai team di progettazione OCI e MySQL.
Oracle MySQL Database Service dispone di un motore di analitica integrato e ad alte prestazioni (HeatWave) per eseguire sofisticate analisi in tempo reale direttamente su un database MySQL operativo.
- Controller di ingresso
Un controller in entrata (ing) è un componente che viene eseguito in un cluster Kubernetes e gestisce le risorse in entrata. Riceve traffico dalla rete esterna, lo instrada al servizio corretto ed esegue il bilanciamento del carico e l'interruzione SSL. Il controller Ingress viene in genere eseguito come pod separato nel cluster e può essere ridimensionato indipendentemente dai servizi gestiti.
- Segreti Kubernetes
I segreti Kubernetes possono includere dati di configurazione sensibili come token di autenticazione, password e chiavi SSH. I segreti consentono di controllare i dati sensibili e riducono il rischio di esporre i dati a utenti non autorizzati. Oracle Container Engine for Kubernetes supporta la cifratura dei segreti Kubernetes in archivio.
- Operatore segreti esterni
L'operatore dei segreti esterni Kubernetes integra Oracle Container Engine for Kubernetes con Oracle Cloud Infrastructure Vault. L'operatore legge le informazioni dalle API esterne e inserisce automaticamente i valori in un segreto Kubernetes.
- SecretStore
Il piano di controllo del cluster Kubernetes memorizza i dati di configurazione riservati (ad esempio token di autenticazione, certificati e credenziali) come oggetti segreti Kubernetes in
etcd.Etcdè un archivio chiavi-valore distribuito open source che Kubernetes utilizza per il coordinamento dei cluster e la gestione dello stato. Nei cluster Kubernetes creati da Container Engine per Kubernetes,etcdscrive e legge i dati da e verso i volumi di storage a blocchi nel servizio Oracle Cloud Infrastructure Block Volumes. Per impostazione predefinita, Oracle cifra i dati nei volumi a blocchi in archivio, inclusi i segretietcde Kubernetes. Oracle gestisce questa cifratura predefinita utilizzando una chiave di cifratura master, senza richiedere alcuna azione da parte dell'utente. Per un ulteriore controllo sul ciclo di vita della chiave di cifratura master e sul modo in cui viene utilizzata, è possibile scegliere di gestire la chiave di cifratura master autonomamente, anziché far sì che Oracle la gestisca automaticamente.Quando crei un nuovo cluster, puoi specificare che i segreti Kubernetes in
etcddevono essere cifrati utilizzando Oracle Key Management Cloud Service. - Pod
Un pod è un gruppo di uno o più container e il relativo storage condiviso e qualsiasi opzione specifica su come questi devono essere eseguiti insieme. In genere, i contenitori di un pod condividono la stessa rete e lo stesso spazio di memoria e possono accedere ai volumi condivisi per lo storage. Queste risorse condivise consentono ai container di un pod di comunicare internamente in modo trasparente come se fossero installati su un singolo host logico.
- Nodo virtuale
Un nodo virtuale è un'astrazione software di un nodo reale. I nodi virtuali vengono distribuiti nella tenancy di OCI e sono interamente monitorati e gestiti da OCI.
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.
Utilizzare le subnet regionali.
- Gruppi di sicurezza di rete (NSG)
Puoi utilizzare i gruppi NSG per definire un set di regole in entrata e in uscita che si applicano a VNIC specifiche. Si consiglia di utilizzare i gruppi NSG anziché gli elenchi di sicurezza, poiché i gruppi NSG consentono di separare l'architettura della subnet della VCN dai requisiti di sicurezza dell'applicazione.
Puoi utilizzare i gruppi NSG per definire un set di regole in entrata e in uscita che si applicano a VNIC specifiche. Si consiglia di utilizzare i gruppi NSG anziché gli elenchi di sicurezza, poiché i gruppi NSG consentono di separare l'architettura della subnet della VCN dai requisiti di sicurezza dell'applicazione.
- 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 utilizzano i nodi virtuali, tenere presente quanto riportato di seguito.
Per iniziare con i nodi virtuali, è innanzitutto necessario creare un cluster OCI Kubernetes Engine con un pool di nodi virtuali o aggiungere un pool di nodi virtuali a un cluster OKE (Kubernetes Engine) esistente.
- Selezionare la forma e il posizionamento dei nodi virtuali.
-
La forma determina il tipo di processori e la quantità di risorse di CPU e memoria che possono essere allocate a ciascun pod. Ogni pod può allocare fino ai limiti di memoria e CPU della forma selezionata.
-
I nodi virtuali scaleranno i pod con la configurazione di Horizontal Pod Autoscaler (HPA). Non è necessario configurare l'Autoscaler del nodo.
-
Puoi posizionare i tuoi nodi virtuali in domini di disponibilità e domini di errore specifici più adatti alle tue esigenze di High Availability (HA). Per il livello massimo di ridondanza, posizionare un nodo virtuale in ogni dominio di errore nel dominio di disponibilità del cluster OKE.
-
Utilizzare le etichette dei nodi Kubernetes per specificare il posizionamento dei pod nei nodi virtuali. Per ottenere una distribuzione uniforme dei pod tra i nodi, utilizzare il vincolo
PodTopologySpread.
-
-
I nodi virtuali utilizzano il networking pod VCN nativo. Il numero di pod disponibili nel cluster è limitato dal numero di indirizzi IP disponibili nella subnet.
- Il pod networking nativo fornisce a ogni pod un indirizzo IP nativo delle subnet della VCN, che consente a ogni pod di trarre vantaggio dalle funzioni di sicurezza di rete OCI integrate, quali i log di flusso della VCN, i criteri di instradamento, il VTAP e i gruppi di sicurezza.
- Prendi in considerazione l'utilizzo di un intervallo di subnet che consente il numero di pod e nodi che prevedi di utilizzare e offre spazio per la crescita.
- Definire i gruppi di sicurezza di rete (NSG) per limitare il tipo di traffico che può entrare e uscire dai pod.
- Utilizza i log di flusso della VCN per ispezionare tutto il traffico di rete tra i pod o utilizzare VTAP per acquisire il traffico di rete.
- Ai pod nei nodi virtuali viene concesso l'accesso ad altri servizi OCI con identità del carico di lavoro.
Ci sono casi in cui un pod potrebbe aver bisogno dell'accesso ad altri servizi all'interno di OCI.
- Usare Identità carico di lavoro per concedere privilegi ai pod nei nodi virtuali. L'identità del carico di lavoro associa i ruoli OCI Identity and Access Management agli account del servizio Kubernetes assegnati ai pod.
- I nodi virtuali forniscono l'isolamento a livello di hypervisor per il pod.
Le vulnerabilità di sicurezza potrebbero potenzialmente consentire ai processi dannosi all'interno di un contenitore di "escape" e influenzare il kernel del nodo, potenzialmente riducendo il nodo. Il codice dannoso può anche accedere ai dati in memoria o archiviazione ed estrarre i dati. I dati filtrati possono potenzialmente appartenere a un altro tenant in un ambiente multi-tenant.
- Il nodo virtuale fornisce l'isolamento a livello di hypervisor per i pod. Un pod non condivide computazione, memoria e rete con altri pod nel cluster, mitigando la possibilità di un nodo inattivo o di dati esfiltrabili appartenenti a un altro tenant causati da codice dannoso.