Informazioni sul ripristino dei cluster Kubernetes in base agli snapshot etcd

Per garantire la continuità aziendale in caso di errori irreversibili, dovrai implementare una strategia di recupero da errori irreversibili per le applicazioni in esecuzione sui cluster Kubernetes. Utilizza questi suggerimenti di Oracle Maximum Availability Architecture (Oracle MAA) che offrono protezione dei dati e consentono 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 di recupero da errori irreversibili simili a quelli di un'applicazione tradizionale (come Oracle Java SE, Oracle Java EE o JavaScript). Deve conservare una copia coerente e "il più aggiornata possibile" del sistema primario in una posizione secondaria in grado di riprendere i carichi di lavoro in caso di errori irreversibili nell'area primaria.

Questa guida sulla soluzione fornisce consigli e utility MAA di Oracle che creeranno un sistema Kubernetes secondario e ti consentirà di eseguire il recupero in scenari di emergenza che influiscono su una posizione e forzando il reindirizzamento dei carichi di lavoro a un sito di replica.

Sebbene questa guida sulle soluzioni si concentri sul ripristino di un cluster Kubernetes in un'area diversa, puoi utilizzare gli stessi script e le stesse procedure per ripristinare un cluster in loco su un point in time precedente. Questa operazione può essere utile in scenari diversi dal disaster recovery, come quelli riportati di seguito.

• Una volta configurato in modo errato il piano di controllo.
• Quando il database etcd viene perso, danneggiato o quando etcd non viene visualizzato correttamente.
• Quando una distribuzione o un errore utente non corretti interessa più applicazioni o microservizi e il cluster deve essere ripristinato a una versione o a una versione precedente. Un ripristino snapshot ETCD ripristinerà tutti gli artifact nel momento in cui è stato eseguito lo snapshot (backup).

Questo documento è incentrato sulla replica dei dati etcd di Kubernetes in una posizione secondaria. Tutte le informazioni di un cluster Kubernetes vengono memorizzate in etcd, ovvero un'area di memorizzazione dei valori chiave utilizzata come area di memorizzazione dei backup di Kubernetes per i dati del cluster. Questa guida sulla soluzione fornisce suggerimenti per replicare un cluster Kubernetes creato con lo strumento kubeadm di Kubernetes (vedere https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) in base al ripristino etcd. Le procedure di impostazione e gli script forniti potrebbero richiedere personalizzazioni per altri tipi di cluster (quelli non creati con kubeadm), ma in generale sono validi purché si disponga dell'accesso agli endpoint etcd utilizzati dal piano di controllo di Kubernetes. Questa soluzione di replica richiede un'impostazione specifica per il cluster secondario e utilizzerà una copia di etcd (chiamata anche snapshot etcd) per attivare gli stessi artifact esatti esistenti nel cluster primario.

È possibile utilizzare snapshot di artifact o strumenti di backup Kubernetes di terze parti per replicare spazi di nomi e applicazioni specifici nei sistemi Kubernetes. Tuttavia, non proteggono i cluster da danneggiamenti dei file e configurazioni errate nei metadati del piano di controllo. Oltre a utilizzarli per la protezione da errori irreversibili, puoi usare snapshot etcd per i ripristini locali e ripristinare i cluster Kubernetes in un momento precedente. Se il sistema cluster etcd e del negozio etcd non sono integri, le applicazioni potrebbero continuare a essere in esecuzione ma le rilocazioni dei pod, le modifiche alla configurazione, l'accesso segreto e qualsiasi altra operazione che richieda la disponibilità del piano di controllo non funzioneranno in modo corretto. Per questo motivo, la conservazione etcd deve essere una parte fondamentale di qualsiasi procedura del ciclo di vita del cluster Kubernetes.

Oltre ai dati di configurazione Kubernetes, le applicazioni e i microservizi in esecuzione su Kubernetes possono generare dati in fase di esecuzione. 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:

• Evitare la persistenza poliglotta (l'uso di diversi tipi di aree di memorizzazione persistenti per i dati di runtime è un "quasi" impossibile da risolvere il problema in base al Theorem BAC)
• Utilizza un'unica area di memorizzazione per tutti i diversi tipi di dati, microservizi e applicazioni con le dipendenze il più possibile
• Consulta Oracle MAA Best Practices for Oracle Database per la protezione da errori irreversibili per il tuo runtime

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 richiesta viene replicata tramite snapshot etcd per la protezione del piano di controllo. È possibile utilizzare copie etcd o snapshot di artifact per la protezione della configurazione specifica dell'applicazione. Per ulteriori dettagli, consulta la sezione relativa all'uso degli snapshot degli artifact per proteggere i cluster Kubernetes da errori irreversibili. Le immagini utilizzate dai container vengono gestite in hosting nei registri locale in ogni cluster o in repository esterni (le immagini non vengono considerate di per sé 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-etcd-multiregion-dr.png

kubernetes-etcd-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.

• 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.
• 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.

• 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. I cluster Kubernetes nelle due aree devono avere risorse simili disponibili, ad esempio il numero di nodi di lavoro (e la relativa capacità hardware) e un'altra infrastruttura (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.
• Alias e virtualizzazione del nome host: è importante pianificare i nomi host utilizzati dai nodi nel sito secondario. I nomi host o i nomi host alias per il piano di controllo e i nodi di lavoro devono essere "attivi" nella posizione secondaria prima di ripristinare uno snapshot etcd da un cluster Kubernetes primario. I nomi dei nodi vengono memorizzati in artifact diversi di un cluster Kubernetes per identificare i nodi di lavoro, contrassegnare le allocazioni dei pod, nei mapping di configurazione (config) che descrivono il cluster stesso e in più file e voci di configurazione. La posizione secondaria deve identificare gli indirizzi kube-api del lavoratore, del piano di controllo e del front-end con gli stessi nomi host utilizzati nel cluster Kubernetes primario (un nome completamente qualificato può essere diverso nel nome di dominio, ma il nome host deve essere lo stesso. Senza l'alias del nome host, un ripristino dello snapshot etcd non funzionerà correttamente poiché kubelets, scheduler, controller e, in generale, i servizi del piano di controllo non saranno in grado di raggiungere gli endpoint e gli host appropriati utilizzati dalla configurazione replicata. Non utilizzare gli IP per identificare i nodi in kubernetes, usare sempre i nomi host.
• Le immagini container presentano un paradigma simile ai file binari: le immagini potrebbero non cambiare frequentemente rispetto alla configurazione Kubernetes e potrebbe non essere necessario aggiornare le immagini in 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.

Questo playbook sulle soluzioni illustra un esempio utilizzando i cluster Kubernetes creati utilizzando lo strumento kubeadm. I suggerimenti sono generici per i cluster Kubernetes personalizzati installati nei sistemi on premise, ma la maggior parte degli script potrebbe richiedere modifiche per i cluster non creati con lo strumento kubeadm. È necessario utilizzare i passi e gli script forniti tra i cluster Kubernetes che eseguono la stessa versione etcd e Kubernetes. Il ripristino degli snapshot etcd in diverse versioni di kubernetes può causare incoerenze e cluster etcd instabili.

Informazioni sui prodotti e i ruoli richiesti

Questa soluzione richiede i seguenti prodotti e ruoli:

• Cluster Kubernetes
• Bastion in grado di gestire l'accesso del sistema Kubernetes agli endpoint etcd del cluster e accedere ai diversi nodi del piano di controllo con ssh
• (Opzionale) 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 si trovano on premise.

Si tratta dei ruoli necessari per ogni servizio.

Nome servizio: ruolo	Richiesto a...
Cluster Kubernetes (primario): administrator	eseguire tutti gli script.
Nodi Kubernetes (primari): utente con diritti sudo alla radice	eseguire i seguenti script: maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh
Cluster Kubernetes (secondario): administrator	eseguire tutti gli script.
Nodi Kubernetes (secondari): utente con diritti sudo alla radice	eseguire i seguenti script: maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh

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