Informazioni sul ripristino dei cluster Kubernetes in base agli snapshot etcd

Per garantire la continuità aziendale in caso di calamità, dovrai implementare una strategia di disaster recovery per le applicazioni in esecuzione sui cluster Kubernetes. Utilizza questi suggerimenti di Oracle Maximum Availability Architecture (Oracle MAA) che offrono la 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 implica l'adozione di Kubernetes per l'architettura del sistema IT, un sistema Kubernetes presenta paradigmi di disaster recovery (DR) simili a un'applicazione tradizionale (ad esempio Oracle Java SE, Oracle Java EE o JavaScript). Deve mantenere 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 calamità che causino tempi di inattività nell'area primaria.

Questa guida alle soluzioni fornisce consigli e utility Oracle MAA che creeranno un sistema Kubernetes secondario e ti consentiranno di eseguire il ripristino in scenari di emergenza che influiscono su una posizione e costringono il reindirizzamento dei carichi di lavoro a un sito di replica.

Sebbene questa guida sulla soluzione si concentri sul ripristino di un cluster Kubernetes in un'area diversa, è possibile utilizzare gli stessi script e le stesse procedure per ripristinare un cluster in loco in un point-in-time precedente. Questa operazione può essere utile in scenari diversi dal disaster recovery, ad esempio:

• Quando il piano di controllo non è configurato correttamente.
• Quando il database etcd viene perso, danneggiato o quando etcd non viene visualizzato correttamente.
• Quando una distribuzione errata o un errore dell'utente influisce su più applicazioni o microservizi, è necessario ripristinare una versione o una copia precedente del cluster. Un ripristino dello snapshot ETCD ripristinerà tutti gli artifact al momento in cui è stato eseguito lo snapshot (backup).

Questo documento si concentra sulla replica dei dati etcd di Kubernetes in una posizione secondaria. Tutte le informazioni di un cluster Kubernetes vengono memorizzate in etcd, un archivio di valori chiave utilizzato come area di memorizzazione di backup di Kubernetes per i dati del cluster. Questa guida alle soluzioni 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/) basato su etcd restore. 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é sia disponibile l'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 etcd snapshots) per visualizzare gli stessi artifact esistenti nel database primario.

Puoi 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, è possibile utilizzare etcd snapshots per i ripristini locali e per ripristinare i cluster Kubernetes in un point-in-time precedente. Se i sistemi etcd store e etcd cluster non sono in buono stato, l'esecuzione delle applicazioni potrebbe continuare, ma i riposizionamenti dei pod, le modifiche alla configurazione, l'accesso segreto e qualsiasi altra operazione che richieda la disponibilità del piano di controllo non funzioneranno correttamente. È per questo motivo che 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 runtime. 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 teorema BAC)
• Utilizza un'unica area di memorizzazione per tutti i diversi tipi di dati, microservizi e applicazioni con dipendenze il più possibile
• Consulta Oracle MAA Best Practices for Oracle Database per la protezione da errori irreversibili per il tuo runtime

Operazioni preliminari

Esistono diversi brief tecnici MAA (Oracle Maximum Availability Architecture) che descrivono come impostare un sistema di disaster recovery (DR) 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, vedere:

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

Per i dettagli sull'uso degli snapshot artifact per la protezione della configurazione specifica dell'applicazione, vedere Usa gli snapshot del motore Kubernetes OCI da errori irreversibili.

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 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. Le immagini utilizzate dai 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-etcd-multiregion-dr.png

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

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

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

• 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-apiserver del piano di controllo Kubernetes. Esegue il server API Kubernetes.

• Backup ETCD

  ETCD Backup è un backup del componente etcd del piano di controllo Kubernetes. etcd contiene 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. I cluster Kubernetes nelle due aree devono disporre di risorse simili, 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 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.
• Alias nome host e virtualizzazione: è 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, nelle mappe 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ò differire nel nome di dominio, ma il nome host deve essere lo stesso). Senza l'aliasing dei nomi host, un ripristino dello snapshot etcd non funzionerà correttamente poiché kubelet, 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 indirizzi IP per identificare i nodi in Kubernetes, ma utilizzare sempre i nomi host.
• Le immagini presentano un paradigma simile ai file binari: le immagini potrebbero non cambiare 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.
• Differenze tra cluster primario e secondario: si prevede (come avviene in generale per i sistemi DR) che primari e secondari siano una replica l'uno dell'altro in termini di versioni e configurazione utilizzate. Sono particolarmente rilevanti i seguenti aspetti:
  1. Versioni Kubernetes
  2. Runtime e versione runtime del contenitore
  3. Versioni plugin di rete e plugin di rete
  4. podSubnet e servicesubnet
  5. Directory del percorso host etcd e versione dell'immagine etcd
  6. Plugin di rete e versione dell'immagine dns
  7. Repository di immagini per i pod del piano di controllo

  Le configurazioni di protezione da calamità con differenze minori tra i siti nella versione Kubernetes potrebbero funzionare, ma potrebbero lasciare il cluster in uno stato incoerente dopo un ripristino dallo snapshot etcd di un primario. Le informazioni sui socket di runtime dei container, sulla versione Kubernetes e così via vengono memorizzate nello stesso Kubernetes. Ad esempio, le informazioni cri-socket sono specifiche di ogni nodo in base al runtime del contenitore utilizzato e vengono memorizzate nelle mappe di configurazione interne. Molte informazioni utilizzate per gli aggiornamenti da kubeadm si basano sulle mappe di configurazione nello spazio di nomi kube-system. Pertanto, è importante che sia primaria che secondaria utilizzino le stesse informazioni in queste configurazioni. È possibile utilizzare questo comando per memorizzare tutte le informazioni pertinenti dalle importanti configmap sia in database primario che in standby nei file yaml.

  [prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}

  Analogamente, è possibile creare una copia della configurazione del nodo in ogni sito con il comando seguente:

  [prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
  

Questo playbook di soluzioni presenta un esempio utilizzando i cluster Kubernetes creati utilizzando lo strumento kubeadm. I suggerimenti sono generici per i cluster Kubernetes personalizzati installati nei sistemi in locale, 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 incongruenze e cluster etcd instabili.

Informazioni sui prodotti e sui ruoli richiesti

Questa soluzione richiede i seguenti prodotti e ruoli:

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

Questi sono i ruoli necessari per ogni servizio.

Nome servizio: ruolo	Richiesto per...
Cluster Kubernetes (primario): administrator	eseguire tutti gli script.
Nodi Kubernetes (primari): utente con diritti sudo su root	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 su root	eseguire i seguenti script: maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh

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