Usa gli snapshot degli artifact per proteggere i cluster del motore Kubernetes OCI dal disastro
Oracle Maximum Availability Architecture (Oracle MAA) fornisce consigli e utility che consentono di eseguire il ripristino in scenari di calamità che interessano una posizione e che costringono il reindirizzamento dei carichi di lavoro a un sito di replica. L'obiettivo di questo contenuto è la replica della configurazione Kubernetes per le applicazioni. Le applicazioni in esecuzione sui cluster Kubernetes dipendono da molti componenti diversi da utilizzare, tra cui i nodi del piano di controllo, i nodi di lavoro, i load balancer e lo storage. Allo stesso tempo, i dati di runtime generati dalle applicazioni in esecuzione su Kubernetes presentano le stesse sfide delle applicazioni tradizionali: durante le applicazioni runtime possono generare, leggere e aggiornare i dati persistenti. Questa guida sulle soluzioni fornisce suggerimenti per replicare la configurazione di un'applicazione in esecuzione su Kubernetes. La protezione da errori irreversibili dei dati di runtime non rientra nell'ambito di questo documento e deve essere trattata esattamente come nelle applicazioni tradizionali in esecuzione su Application Server, tra cui:
- Evitare la persistenza poliglotta. L'utilizzo di diversi tipi di aree di memorizzazione persistenti per i dati di runtime è quasi impossibile da risolvere, secondo il teorema della coerenza della disponibilità del backup (BAC).
- Utilizza un'unica area di memorizzazione per tutti i diversi tipi di dati, microservizi e applicazioni con dipendenze, per quanto possibile.
- Consulta le migliori prassi Oracle MAA per Oracle Database per la protezione da errori irreversibili per i tuoi dati runtime.
Inoltre, devi proteggere il piano di controllo del cluster Kubernetes. Utilizzare gli snapshot etcd appropriati per evitare danneggiamenti, errori e fornire un flashback ai cluster funzionanti. Sebbene Oracle MAA fornisca le best practice per la protezione del piano di controllo dai disastri, è fuori dall'ambito di questo documento descrivere le tecniche richieste in quell'area.
Operazioni preliminari
Per ulteriori dettagli, vedere:
Architettura
Questa architettura mostra la topologia del sistema di disaster recovery (DR) per il cluster Kubernetes.
Tutte le informazioni su runtime, configurazione e metadati che risiedono nel database primario vengono replicate dall'area 1 all'area 2 con Oracle Autonomous Data Guard. La configurazione del cluster Kubernetes (K8s) richiesta viene replicata tramite snapshot ETCD per la protezione del piano di controllo e con snapshot YAML per la protezione della configurazione dell'applicazione. È possibile utilizzare snapshot di artifact oppure copie etcd o snapshot di artifact per la protezione della configurazione specifica dell'applicazione per la protezione della configurazione specifica dell'applicazione. Per ulteriori dettagli, vedere Ripristino dei cluster Kubernetes basato su snapshot etcd. Le immagini utilizzate dal container sono ospitate in registri, locali per ogni cluster o in repository esterni (le immagini non sono considerate una configurazione cluster Kubernetes).
Nota
L'impostazione di Oracle Autonomous Data Guard per il database runtime non rientra nell'ambito di questo documento.
Descrizione dell'immagine kubernetes-multiregion-dr.png
kubernetes-multiregion-dr-oracle.zip
Questa architettura supporta i componenti elencati di seguito.
- 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).
- Load balancer
Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un unico punto di accesso a più server.
- Gateway di instradamento dinamico (DRG)
Il gateway DRG è un router virtuale che fornisce un percorso per il traffico di rete privato tra le reti VCN nella stessa area, tra una rete VCN e una rete esterna all'area, ad esempio una rete VCN in un'altra area Oracle Cloud Infrastructure, una rete on premise o una rete in un altro provider cloud.
- Data Guard
Oracle Data Guard e Oracle Active Data Guard offrono un set completo di servizi che creano, mantengono, gestiscono e monitorano uno o più database di standby e che consentono ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database di standby come copie del database di produzione utilizzando la replica in-memory. Se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare qualsiasi database di standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'indisponibilità. Oracle Active Data Guard offre la possibilità aggiuntiva di scaricare i carichi di lavoro in lettura, principalmente sui database in standby e offre inoltre funzioni avanzate di protezione dei dati.
- Oracle Real Application Clusters (Oracle RAC)
Oracle RAC ti consente di eseguire un singolo Oracle Database su più server per massimizzare la disponibilità e abilitare la scalabilità orizzontale, accedendo allo storage condiviso. Le sessioni utente che si connettono alle istanze Oracle RAC possono eseguire il failover e ripetere le modifiche in modo sicuro durante le interruzioni, senza apportare modifiche alle applicazioni dell'utente finale.
- 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.
- Motore Kubernetes
Oracle Cloud Infrastructure Kubernetes Engine (OCI 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.
- Cluster Kubernetes
Un cluster Kubernetes è un set di computer che eseguono applicazioni containerizzate. Kubernetes offre una piattaforma portatile, estendibile e open source per la gestione di carichi di lavoro e servizi containerizzati in quei nodi. Un cluster Kubernetes è formato da nodi di lavoro e nodi del piano di controllo.
- Nodo di lavoro Kubernetes
Un nodo di lavoro Kubernetes è una macchina operativa che esegue applicazioni containerizzate all'interno di un cluster Kubernetes. Ogni cluster dispone di almeno un nodo di lavoro.
- Piano di controllo Kubernetes
Un piano di controllo Kubernetes gestisce le risorse per i nodi di lavoro e i pod all'interno di un cluster Kubernetes. I componenti del piano di controllo rilevano e rispondono agli eventi, eseguono la pianificazione e spostano le risorse del cluster.
Di seguito sono riportati i componenti del piano di controllo.- kube-apiserver: esegue il server API Kubernetes.
- etcd: area di memorizzazione chiave-valore distribuita per tutti i dati del cluster.
- kube-scheduler: determina su quale nodo verranno eseguiti i nuovi pod non assegnati.
- kube-controller-manager: esegue i processi del controller.
- cloud-controller-manager: collega il cluster con un'API specifica per il cloud.
- Controller di ingresso
Un controller in entrata è 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.
- API endpoint KUBE
L'API KUBE-Endpoint è il componente
kube-apiserverdel piano di controllo Kubernetes. Esegue il server API Kubernetes. - Backup ETCD
ETCD Backup è un backup del componente
etcddel piano di controllo Kubernetes.etcdcontiene l'area di memorizzazione chiave-valore distribuita per tutti i dati del cluster. È importante creare un backup ETCD per recuperare i cluster Kubernetes per il recupero da errori irreversibili. - Snapshot YAML
Uno snapshot YAML è una copia point-in-time dei file (YAML) che contengono la definizione degli artifact in un cluster Kubernetes. Lo snapshot è un file tar che è possibile utilizzare per ripristinare tali artifact nello stesso cluster Kubernetes o in un altro cluster.
Considerazioni per la protezione da calamità Kubernetes
Quando si implementa la protezione da errori irreversibili per Kubernetes, tenere presente quanto riportato di seguito.
- DR (Symmetric Disaster Recovery): Oracle consiglia di utilizzare la stessa capacità e configurazione delle risorse in database primario e secondario. Gli spazi di nomi Kubernetes coinvolti dovrebbero avere risorse simili disponibili, come il numero di nodi di lavoro (e la loro capacità hardware) e altre infrastrutture (storage condiviso, load balancer, database e così via). Le risorse da cui dipende il cluster Kubernetes nell'area secondaria devono essere in grado di tenere il passo con gli stessi carichi di lavoro del database primario. Inoltre, i due sistemi devono essere coerenti funzionalmente con gli stessi servizi da cui dipende il sistema ripristinato, le auto laterali, le mappe di configurazione (CM) devono essere utilizzate in entrambe le posizioni.
- Le immagini presentano un paradigma simile ai file binari: le immagini non cambiano con la stessa frequenza della configurazione Kubernetes e potrebbe non essere necessario aggiornare le immagini con ogni replica del cluster Kubernetes. Le immagini utilizzate dal sistema primario devono essere identiche a quelle utilizzate nel sistema secondario oppure possono verificarsi incongruenze e guasti. Tuttavia, la replica delle immagini non rientra nell'ambito di questo playbook. Esistono più strategie che è possibile utilizzare per mantenere un uso coerente delle immagini tra due posizioni, tra cui:
- Salvare le immagini nel database primario e caricarle nei nodi di lavoro secondari. Questo approccio è molto facile da implementare, ma comporta un sovraccarico di gestione. L'utilizzo dei registri dei container offre notevoli vantaggi e il salvataggio delle immagini a livello locale rende più difficile la gestione di versioni e aggiornamenti.
- Le immagini possono risiedere in registri dei container totalmente esterni in aree o data center diversi da quelli utilizzati dal database primario e dal database di standby. I prodotti e le librerie esterni sono gestiti da terze parti e la loro disponibilità è in genere implicita nelle loro release.
- Le immagini possono risiedere nei registri dei container presenti nel database primario e in standby. Ogni area viene aggiornata in parallelo quando viene rilasciata una nuova versione di un'immagine. Ciò fornisce un migliore controllo sul software utilizzato, ma comporta un maggiore sovraccarico di gestione. Richiede la duplicazione delle immagini e la gestione delle credenziali per accedere a due registri diversi. Gli strumenti CI/CD sono in genere utilizzati per questo approccio.
Sebbene questo playbook presenti un esempio utilizzando Oracle Cloud Infrastructure, i suggerimenti sono generici ai cluster Kubernetes personalizzati installati nei sistemi on-premise. Puoi utilizzare i passi e gli script forniti tra un cluster Kubernetes primario in esecuzione in OCI Kubernetes Engine (OKE) e un cluster secondario in esecuzione in un cluster Kubernetes on premise o personalizzato. Puoi anche utilizzare i passi e gli script tra un cluster Kubernetes primario in esecuzione in OKE e un cluster secondario in esecuzione anche in OKE o tra due cluster Kubernetes in locale o personalizzati.
Informazioni sui prodotti e sui ruoli richiesti
Questa soluzione richiede i seguenti prodotti e ruoli:
- Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine o OKE) cluster
- Nodo bastion in grado di gestire il sistema kubernetes
- Oracle Cloud Infrastructure (OCI)
Questa guida si basa sull'utilizzo delle region e delle risorse OCI per le region primarie e secondarie. Tuttavia, questa soluzione è applicabile anche ai cluster Kubernetes che non si trovano nell'infrastruttura OCI.
Questi sono i ruoli necessari per ogni servizio.
| Nome servizio: ruolo | Richiesto per... |
|---|---|
Oracle Cloud Infrastructure: admin |
eseguire il provisioning e l'impostazione di risorse e servizi se si utilizza una o più region OCI. |
Cluster Kubernetes Engine (primario): administrator |
eseguire tutti gli script. |
| Nodi Kubernetes Engine (primario): utente del sistema operativo con autorizzazioni di esecuzione e autorizzazioni SSH per i nodi secondari |
eseguire i seguenti script:
|
Cluster Kubernetes Engine (secondario): administrator |
eseguire tutti gli script. |
| Nodi Kubernetes Engine (secondari): utente del sistema operativo con autorizzazioni di esecuzione |
eseguire i seguenti script:
|
Consulta i prodotti, le soluzioni e i servizi Oracle per ottenere ciò di cui hai bisogno.