Questa pagina illustra le best practice per l'esecuzione dei database nei container su GKE. Puoi utilizzare un deployment per creare un insieme di istanze di database containerizzate gestite da Kubernetes. Successivamente, crei un Service per fornire l'accesso al database indipendentemente da qualsiasi pod specifico. Il servizio rimane invariato anche se il pod viene spostato su un nodo diverso.
Per accedere ai dati nell'istanza del database, crea
una risorsa PersistentVolumeClaim (PVC) e rendila disponibile per il tuo workload.
I database si basano su dischi locali per la persistenza. Un database eseguito come servizio
in un cluster Kubernetes e i relativi file di database in un PersistentVolumeClaim sono
vincolati al ciclo di vita del cluster. Se il cluster viene eliminato, viene eliminato anche il database.
Se stai creando o eseguendo il deployment di un'applicazione stateful in esecuzione in GKE, valuta la possibilità di utilizzare una delle seguenti opzioni di deployment per le istanze di database:
- Database completamente gestiti: un database gestito, come Cloud SQL o Spanner, offre un overhead operativo ridotto ed è ottimizzato per l'infrastruttura Google Cloud . I database gestiti richiedono meno impegno per la manutenzione e l'operatività rispetto a un database che deploy direttamente in Kubernetes.
- Applicazione Kubernetes: puoi eseguire il deployment e l'esecuzione di un'istanza di database (ad esempio MySQL o PostgreSQL) su un cluster GKE.
Considerazioni sui deployment di database su GKE
Ciascuna delle opzioni precedenti presenta compromessi, dati i tuoi obiettivi commerciali e vincoli. Utilizza la seguente tabella per decidere se il deployment del database su GKE è la scelta giusta per te.
| Considerazione | Descrizione |
|---|---|
| Indipendenza dal database | Il ciclo di vita di un PersistentVolumeClaim è legato al cluster GKE corrispondente. Se non vuoi che il ciclo di vita del tuo database dipenda da un particolare cluster GKE, valuta la possibilità di mantenere il database separato, come database gestito o in un'istanza VM. |
| Scalabilità con GKE | Scalabilità verticale: puoi configurare le richieste dei tuoi pod in modo che vengano scalate automaticamente. Tuttavia, devi assicurarti che la tua applicazione di database possa resistere alle interruzioni quando i pod vengono scalati con la scalabilità automatica verticale dei pod. Scalabilità orizzontale: il tuo database potrebbe essere in grado di scalare orizzontalmente le letture o le scritture aggiungendo repliche. La tua database supporta lo scaling orizzontale a seconda che abbia un'architettura con un singolo writer o più writer. Per utilizzare lo scaling orizzontale, potrebbe essere necessario aggiornare la configurazione del database, oltre ad aumentare il numero di repliche. |
| Overhead di GKE |
Nei cluster Standard, GKE riserva risorse per le proprie operazioni. I database sui cluster Standard non vengono scalati automaticamente, quindi l'overhead potrebbe essere elevato per i pod di piccole dimensioni. |
| Numero di istanze di database | Nel contesto di Kubernetes, ogni istanza del database viene eseguita nel proprio pod e ha la propria PersistentVolumeClaim. Se hai un numero elevato di istanze, devi gestire un ampio insieme di pod, nodi e rivendicazioni di volumi. Potresti provare a utilizzare un database gestito. |
| Backup del database in GKE | Un PersistentVolumeClaim è limitato a un cluster GKE. Questo ambito significa che quando un cluster GKE viene eliminato, la rivendicazione del volume viene eliminata. Vengono eliminati anche tutti i file di database nel cluster. Per proteggerti dalla perdita accidentale dei file di database, ti consigliamo la replica o il backup frequente. Puoi utilizzare Backup per GKE per acquisire snapshot della configurazione dell'applicazione e dei dati dei volumi a intervalli periodici. Backup per GKE gestisce la pianificazione dei backup dei volumi, la gestione del ciclo di vita dei backup e il ripristino dei backup in un cluster. |
| Comportamento di ripristino specifico di Kubernetes | Quando un pod non funziona in Kubernetes, viene ricreato. Dal punto di vista di un'istanza di database, ciò significa che quando un pod viene ricreato, viene ricreata anche qualsiasi configurazione non persistente all'interno di un database o su un archivio stabile all'esterno dei pod. |
| Architettura del database | Se il tuo database è configurato per utilizzare un'architettura active-passive, devi assicurarti che solo una replica sia configurata come primaria. Molti database relazionali hanno un'opzione per il failover attivo-passivo, in cui un database secondario può essere promosso a primario in caso di errore del database primario. |
| Migrazione del database | Se prevedi di eseguire la migrazione del tuo sistema di database esistente a GKE, fai riferimento a Migrazione del database: concetti e principi (parte 1) e Migrazione del database: concetti e principi (parte 2). |
| Riassegnazione della formazione per gli utenti | Se passi da un deployment autogestito o gestito dal provider a un deployment del database Kubernetes, devi riqualificare gli amministratori di database per operare nel nuovo ambiente in modo affidabile come nell'ambiente attuale. Gli sviluppatori di applicazioni potrebbero anche dover conoscere le differenze in misura minore. |
La tabella precedente illustra alcune considerazioni per il deployment del database. Tuttavia, la tabella non include tutte le possibili considerazioni. Devi anche considerare il ripristino di emergenza, il raggruppamento delle connessioni e il monitoraggio.
Passaggi successivi
- Scopri come eseguire il deployment di una topologia MySQL ad alta disponibilità su GKE.
- Scopri come eseguire il deployment di un'istanza PostgreSQL a disponibilità elevata su GKE.
- Scopri di più su Backup per GKE, un servizio per il backup e il ripristino dei carichi di lavoro in GKE.
- Esplora i volumi permanenti in modo più dettagliato.