Questa pagina illustra le best practice per l'esecuzione di database nei container su GKE. Puoi utilizzare un deployment per creare un set di istanze di database containerizzate gestite da Kubernetes. Quindi creerai un servizio 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 nella tua istanza di database, crea una risorsa PersistentVolumeClaim (PVC) e rendila disponibile per il tuo carico di lavoro.
I database si basano su dischi locali per la persistenza. Un database eseguito come Service in un cluster Kubernetes e i relativi file di database in un PersistentVolumeClaim sono associati 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, fornisce un overhead operativo ridotto ed è ottimizzato per l'infrastruttura Google Cloud. I database gestiti richiedono uno sforzo minimo di manutenzione e gestione rispetto a un database di cui esegui il deployment direttamente in Kubernetes.
- Applicazione Kubernetes: puoi eseguire il deployment di un'istanza di database (ad esempio MySQL o PostgreSQL) ed eseguirla su un cluster GKE.
Considerazioni sui deployment dei database su GKE
Ognuna delle opzioni precedenti presenta dei compromessi, considerati i tuoi obiettivi commerciali e i tuoi vincoli. Utilizza la tabella seguente per decidere se il deployment del database su GKE è la scelta giusta per te.
| Considerazione | Descrizione |
|---|---|
| Indipendenza del database | Il ciclo di vita di un PersistentVolumeClaim è collegato al cluster GKE corrispondente. Se non vuoi che il ciclo di vita del database dipenda da un determinato 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 di pod per la scalabilità automatica. Tuttavia, devi assicurarti che la tua applicazione di database possa resistere a interruzioni dello scale up dei pod con la scalabilità automatica verticale dei pod. Scalabilità orizzontale: il database può essere in grado di scalare orizzontalmente le letture o le scritture aggiungendo repliche. Il supporto della scalabilità orizzontale del database dipende dalla presenza o meno di un'architettura con un solo writer o uno multi-writer. Per utilizzare la scalabilità orizzontale, potrebbe essere necessario aggiornare la configurazione del database, oltre allo scale up del numero di repliche. |
| Overhead di GKE | Nei cluster Autopilot non ti viene addebitato alcun costo per le prenotazioni di risorse, ma solo per le richieste di risorse. Sui cluster Standard, GKE riserva risorse per le proprie operazioni. I database sui cluster standard non vengono scalati automaticamente, pertanto l'overhead potrebbe essere elevato per i pod di piccole dimensioni. |
| Numero di istanze di database | Nel contesto di Kubernetes, ogni istanza di database viene eseguita nel proprio pod e ha un proprio PersistentVolumeClaim. Se hai un numero elevato di istanze, devi operare e gestire un grande insieme di pod, nodi e attestazioni di volume. Potresti voler utilizzare un database gestito. |
| Backup dei database in GKE | Un PersistentVolumeClaim ha come ambito un cluster GKE. Questo ambito significa che quando un cluster GKE viene eliminato, viene eliminata la richiesta di volume. Vengono eliminati anche tutti i file di database nel cluster. Per evitare perdite accidentali dei file di database, consigliamo la replica o il backup frequente. Puoi utilizzare Backup per GKE per creare snapshot a intervalli periodici dei dati di volume e della configurazione dell'applicazione. 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 recupero specifico per Kubernetes | In caso di errore in Kubernetes, un pod viene ricreato. Dal punto di vista delle istanze di database, ciò significa che quando un pod viene ricreato, viene ricreata anche qualsiasi configurazione non permanente all'interno di un database o nello spazio di archiviazione stabile all'esterno dei pod. |
| Architettura del database | Se il database è configurato per utilizzare un'architettura attivo-passivo, devi assicurarti che solo una replica sia configurata come principale. Molti database relazionali offrono un'opzione per il failover attivo-passivo, in cui un elemento secondario può essere promosso a primario in caso di errore principale. |
| Migrazione dei database | Se prevedi di eseguire la migrazione del tuo sistema di database esistente a GKE, consulta gli articoli Migrazione dei database: concetti e principi (Parte 1) e Migrazione dei database: concetti e principi (Parte 2). |
| Riaddestramento dell'utente | Se passi da un deployment autogestito o gestito dal provider a un deployment di database Kubernetes, devi riaddestrare gli amministratori di database per operare nel nuovo ambiente con la stessa affidabilità con cui operano nell'ambiente attuale. Gli sviluppatori di applicazioni potrebbero anche dover conoscere le differenze in misura minore. |
La tabella precedente fornisce una discussione su alcune considerazioni relative al deployment del database. Tuttavia, la tabella non include tutte le possibili considerazioni. Devi inoltre prendere in considerazione il ripristino di emergenza, il pooling 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 ad alta disponibilità 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.