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. Poi crei un servizio per fornire l'accesso al database indipendentemente da un 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 PersistentVolumeClaim (PVC) risorsa e rendila disponibile per il tuo workload.
I database si basano sui dischi locali per la persistenza. Un database che viene 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 sovraccarico operativo ridotto ed è ottimizzato per l'infrastruttura. Google Cloud I database gestiti richiedono meno impegno per la manutenzione e l'utilizzo rispetto a un database di cui esegui il deployment 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 per i deployment di database su GKE
Ognuna delle opzioni precedenti presenta compromessi, in base ai tuoi obiettivi e vincoli aziendali. 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 è legato al cluster GKE corrispondente. Se non vuoi che il ciclo di vita del database dipenda da un cluster GKE specifico, 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 pod in modo che vengano scalate automaticamente. Tuttavia, devi assicurarti che l'applicazione del database possa resistere alle interruzioni quando i pod fanno lo scale up con la scalabilità automatica verticale dei pod. Scalabilità orizzontale: il database potrebbe essere in grado di scalare orizzontalmente le letture o le scritture aggiungendo repliche. La possibilità di scalare orizzontalmente il database dipende dal fatto che abbia un'architettura a singolo writer o multi-writer. Per utilizzare la scalabilità orizzontale, potrebbe essere necessario aggiornare la configurazione del database, oltre ad aumentare il numero di repliche. |
| Sovraccarico di GKE | Nei cluster Autopilot, non ti vengono addebitate le prenotazioni di risorse, ma solo le richieste di risorse. Nei cluster Standard, GKE riserva le risorse per le proprie operazioni. I database sui cluster Standard non vengono scalati automaticamente, quindi il sovraccarico 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 il proprio PersistentVolumeClaim. Se hai un numero elevato di istanze, devi gestire un insieme di pod, nodi e richieste di volumi di grandi dimensioni. Potresti voler utilizzare un database gestito. |
| Backup del database in GKE | Un PersistentVolumeClaim è limitato a un cluster GKE. Questa limitazione significa che quando un cluster GKE viene eliminato, viene eliminata anche la richiesta di volume. Vengono eliminati anche tutti i file di database nel cluster. Per proteggerti dalla perdita accidentale dei file di database, ti consigliamo di eseguire la replica o il backup frequente. Puoi utilizzare Backup per GKE per creare 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 uno spazio di archiviazione stabile al di fuori dei pod. |
| Architettura del database | Se il database è configurato per utilizzare un'architettura attiva-passiva, devi assicurarti che solo una replica sia configurata come primaria. Molti database relazionali hanno un'opzione per il failover attivo-passivo, in cui una replica secondaria può essere promossa a primaria in caso di errore della primaria. |
| Migrazione del database | Se prevedi di migrare il sistema di database esistente a GKE, consulta Migrazione del database: concetti e principi (parte 1) e Migrazione del database: concetti e principi (parte 2). |
| Riqualificazione degli utenti | Se passi da un deployment autogestito o gestito dal fornitore a un deployment di database Kubernetes, devi riqualificare gli amministratori di database per operare nel nuovo ambiente in modo affidabile come nell'ambiente attuale. Anche gli sviluppatori di applicazioni potrebbero dover apprendere le differenze in misura minore. |
La tabella precedente fornisce una discussione di alcune delle considerazioni per il deployment del database. Tuttavia, la tabella non include tutte le possibili considerazioni. Devi anche considerare il ripristino di emergenza, il pool di 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 workload in GKE.
- Esplora i volumi permanenti in modo più dettagliato.