Usa snapshot artifact per proteggere i cluster Kubernetes da errori irreversibili

Per garantire la continuità del business in caso di disastri, dovrai implementare una strategia di disaster recovery (DR) per le applicazioni in esecuzione sul cluster Kubernetes che offre la protezione dei dati e ti consente di passare rapidamente a un sistema in standby con una perdita minima di dati e produttività. Nonostante l'enorme cambiamento che l'adozione di Kubernetes implica per l'architettura del sistema IT, un sistema Kubernetes presenta paradigmi DR simili a un'applicazione tradizionale (Oracle Java SE, Oracle Java EE e così via). È necessario mantenere una copia coerente e aggiornata del sistema principale in una posizione secondaria in grado di riprendere i carichi di lavoro in caso di errori irreversibili nell'area primaria.

Oracle Maximum Availability Architecture (MAA) fornisce suggerimenti e utility che consentono di eseguire il recupero in scenari di emergenza che influiscono su una posizione e il reindirizzamento dei carichi di lavoro a un sito di replica. Lo scopo principale di questo manuale è la replica della configurazione Kubernetes per le applicazioni. Le applicazioni in esecuzione sui cluster Kubernetes dipendono da numerosi componenti diversi da utilizzare, inclusi nodi del piano di controllo, nodi di lavoro, load balancer e storage. Allo stesso tempo, i dati di runtime generati dalle applicazioni in esecuzione su Kubernetes presentano le stesse problematiche delle applicazioni tradizionali, durante le quali le applicazioni runtime possono generare, leggere e aggiornare i dati persistenti. Questa guida sulla soluzione 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 sugli Application Server, incluse le seguenti:

• Evitare la persistenza poliglotta. L'uso di diversi tipi di aree di memorizzazione persistenti per i dati di runtime è un problema quasi impossibile da risolvere, in base al tema BAC (Backup Availability Consistenza).
• Utilizza un'unica area di memorizzazione per tutti i diversi tipi di dati, microservizi e applicazioni con dipendenze, il più possibile.
• Consulta le migliori prassi Oracle MAA per Oracle Database per la protezione da errori irreversibili per i tuoi dati di runtime.

Inoltre, è necessario proteggere il piano di controllo del cluster Kubernetes. Utilizzare gli snapshot etcd appropriati per evitare danneggiamenti, errori e per fornire un flashback ai cluster di lavoro. Sebbene Oracle Maximum Availability fornisca migliori prassi per la protezione dei piani di controllo da errori irreversibili, non rientra nell'ambito di questo documento per descrivere le tecniche richieste in tale area.

Prima di cominciare

Sono disponibili diversi brief tecnici su Oracle Maximum Availability Architecture (MAA) che descrivono come impostare un sistema di recupero da errori irreversibili per i sistemi middleware tradizionali. Questi documenti descrivono in dettaglio i requisiti di protezione da errori irreversibili per i componenti dell'infrastruttura esterna (ad esempio storage, load balancer e database) utilizzati dalle applicazioni Kubernetes.

Per ulteriori dettagli, esaminare quanto riportato di seguito.

• Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery
• SOA Suite su Oracle Cloud Infrastructure Marketplace Disaster Recovery

Architettura

Questa architettura mostra la topologia del sistema di recupero da errori irreversibili per il cluster Kubernetes.

Tutte le informazioni su runtime, configurazione e metadati presenti nel database primario vengono replicate dall'area 1 all'area 2 con Oracle Autonomous Data Guard. La configurazione 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, consulta la sezione relativa al ripristino dei cluster Kubernetes in base agli snapshot etcd. Le immagini utilizzate dal container sono ospitate in registri, locali per ogni cluster o in repository esterni (le immagini non vengono considerate da sole 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'illustrazione kubernetes-multiregion-dr.png

kubernetes-multiregion-dr-oracle.zip

Questa architettura supporta i componenti elencati di seguito.

• Area

  Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, definiti domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (in tutti i paesi o anche in continenti).

• Load balancer

  Il servizio Oracle Cloud Infrastructure Load Balancing offre la distribuzione automatica del traffico da un unico punto di accesso a più server nel back-end.

• Gateway di instradamento dinamico (DRG)

  DRG è un router virtuale che fornisce un percorso per il traffico di rete privato tra VCN nella stessa area, tra una VCN e una rete esterna all'area, come una VCN in un'altra area Oracle Cloud Infrastructure, una rete in locale o una rete in un altro provider cloud.

• Data Guard

  Oracle Data Guard offre un set completo di servizi che consente di creare, gestire, gestire e monitorare uno o più database in standby per consentire ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database in standby come copie del database di produzione. Quindi, se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare qualsiasi database in standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'indisponibilità.

• Oracle Real Application Clusters (Oracle RAC)

  Oracle RAC 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 di Oracle RAC possono eseguire il failover e riprodurre in tutta sicurezza le modifiche durante le indisponibilità, senza apportare modifiche alle applicazioni dell'utente finale.

• Registro contenitore

  Oracle Cloud Infrastructure Registry è un registro gestito da Oracle che consente di semplificare il flusso di lavoro dallo sviluppo alla produzione. Il registro semplifica la memorizzazione, la condivisione e la gestione di artifact e immagini di sviluppo. L'architettura altamente disponibile e scalabile di Oracle Cloud Infrastructure assicura che tu possa distribuire e gestire le tue applicazioni in modo affidabile.

• Container Engine per Kubernetes

  Oracle Cloud Infrastructure Container Engine for Kubernetes è un servizio completamente gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le tue applicazioni gestite in container nel cloud. Puoi specificare le risorse di computazione richieste dalle tue applicazioni, mentre Container Engine for Kubernetes le esegue sul provisioning di Oracle Cloud Infrastructure in una tenancy esistente. Container Engine for Kubernetes utilizza Kubernetes per automatizzare la distribuzione, il ridimensionamento e la gestione delle applicazioni in container su cluster di host.

• Cluster Kubernetes

  Un cluster Kubernetes è un set di computer che eseguono applicazioni gestite in container. Kubernetes offre una piattaforma open source, portatile ed estendibile per gestire carichi di lavoro e servizi in container in tali nodi. Un cluster kubernetes è formato da nodi di lavoro e nodi del piano di controllo.

• Nodo di lavoro Kubernetes

  Un nodo di lavoro Kubernetes è un computer di lavoro in cui vengono eseguite applicazioni gestite in container 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 schedulazione 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 il nodo su cui verranno eseguiti nuovi pod non assegnati.
  • kube-controller-manager: esegue processi controller.
  • cloud-controller-manager: collega il cluster con un'API specifica per il cloud.
• Controller in entrata

  Un controller in entrata è un componente eseguito in un cluster Kubernetes e gestisce le risorse in entrata. Riceve il traffico dalla rete esterna, lo instrada al servizio corretto ed esegue il bilanciamento del carico e l'interruzione SSL. Il controller in entrata in genere viene eseguito come pod separato nel cluster e può essere ridimensionato indipendentemente dai servizi gestiti.

• API KUBE-Endpoint

  L'API KUBE-Endpoint è il componente kube-apiserver del piano di controllo Kubernetes. Esegue il server API Kubernetes.

• Backup ETCD

  Backup ETCD è un backup del componente etcd del piano di controllo Kubernetes. etcd contiene l'area di memorizzazione delle chiavi distribuite 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) contenenti la definizione degli artifact in un cluster Kubernetes. Lo snapshot è un file tar che puoi usare per ripristinare quegli artifact nello stesso cluster Kubernetes o in un altro cluster.

Considerazioni per la protezione da errori irreversibili Kubernetes

Quando si implementa la protezione da errori irreversibili per Kubernetes, considerare quanto riportato di seguito.

• Recupero da errori irreversibili simmetrici (DR): Oracle consiglia di utilizzare la stessa capacità e configurazione delle risorse sia primaria che secondaria. Gli spazi di nomi Kubernetes coinvolti devono avere risorse simili disponibili, ad esempio il numero di nodi di lavoro (e la relativa 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 stare al passo con gli stessi carichi di lavoro del database primario. Inoltre, i due sistemi devono essere coerenti in modo funzionale 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 container presentano un paradigma simile ai file binari: le immagini non cambiano frequentemente rispetto alla configurazione Kubernetes e potrebbe non essere necessario aggiornare le immagini con ogni replica del cluster Kubernetes. Le immagini usate dal sistema primario devono essere uguali a quelle utilizzate nel sistema secondario oppure possono verificarsi incongruenze e errori. Tuttavia, la replica delle immagini non rientra nell'ambito di questa guida. Esistono più strategie che è possibile utilizzare per mantenere un uso coerente delle immagini tra due posizioni, tra cui:
  • Salva le immagini nel database primario e caricale nei nodi di lavoro del database secondario. Questo approccio è molto semplice da implementare, ma comporta un sovraccarico di gestione. L'uso dei registri dei container offre notevoli vantaggi e il salvataggio di immagini a livello locale rende più difficile la gestione di versioni e aggiornamenti.
  • Le immagini possono risiedere in registri container completamente esterni in aree o data center diverse da quelli utilizzati dal database primario e in standby. I prodotti e le librerie esterne vengono gestiti da terze parti e la loro disponibilità è in genere implicita nelle loro release.
  • Le immagini possono risiedere nei registri container situati in database primario e in standby. Ogni area viene aggiornata in parallelo quando viene rilasciata una nuova versione di un'immagine. Ciò garantisce un migliore controllo del 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. Per questo approccio vengono in genere utilizzati strumenti CI/CD.

Sebbene questo playbook presenti un esempio utilizzando Oracle Cloud Infrastructure, i suggerimenti sono generici per i cluster Kubernetes personalizzati installati nei sistemi on-premise. Puoi utilizzare i passi e gli script forniti tra un cluster Kubernetes primario in esecuzione in Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) e un cluster secondario in esecuzione in un cluster Kubernetes on premise o personalizzato. Inoltre, puoi 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 on premise o personalizzati.

Informazioni sui prodotti e i ruoli richiesti

Questa soluzione richiede i seguenti prodotti e ruoli:

• Cluster Kubernetes
• Nodo bastion in grado di gestire il sistema kubernetes
• Oracle Cloud Infrastructure (OCI)

  Questa guida si basa sull'utilizzo delle aree e delle risorse OCI per le aree primarie e secondarie. Tuttavia, questa soluzione è applicabile anche ai cluster Kubernetes che non si trovano in OCI.

Si tratta dei ruoli necessari per ogni servizio.

Nome servizio: ruolo	Richiesto a...
Oracle Cloud Infrastructure: admin	eseguire il provisioning e l'impostazione di risorse e servizi se si utilizzano una o più aree geografiche OCI.
Cluster Kubernetes (primario): administrator	eseguire tutti gli script.
Nodi Kubernetes (primari): utente del sistema operativo con autorizzazioni di esecuzione e autorizzazioni ssh per utenti secondari	eseguire i seguenti script: maak8-get-all-artifacts.sh maak8DR-apply.sh
Cluster Kubernetes (secondario): administrator	eseguire tutti gli script.
Nodi Kubernetes (secondari): utente del sistema operativo con autorizzazioni di esecuzione	eseguire i seguenti script: removeyamlblock.sh apply-artifacts.sh maak8-push-all-artifacts.sh

Scopri i prodotti, le soluzioni e i servizi Oracle per ottenere ciò di cui hai bisogno.

Log modifiche

Questo log elenca le modifiche significative:

12 luglio 2023

È stato revisionato il diagramma dell'architettura. Contenuto avanzato.