Pianifica i deployment di database su GKE

Questa pagina illustra le best practice per l'esecuzione di database in 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 determinato pod. Il servizio rimane invariato anche se il pod viene spostato su un altro nodo.

Per accedere ai dati dell'istanza del database, crea una risorsa PersistentVolumeClaim (PVC) e rendila disponibile per il tuo carico di lavoro.

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, prendi in considerazione l'utilizzo di 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 il funzionamento 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 dei compromessi, in base agli scopi e ai vincoli della tua attività. 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 dependa da un determinato cluster GKE, valuta la possibilità di mantenerlo 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 vengono scalati con la scalabilità automatica verticale dei pod.

Scalabilità orizzontale: il tuo database potrebbe essere in grado di eseguire lo scale up o lo scale out delle letture o delle scritture aggiungendo repliche. Il supporto dello scaling orizzontale da parte del database dipende dal fatto che abbia un'architettura a singolo autore o multi-autore. Per utilizzare la scalabilità orizzontale, potresti dover aggiornare la configurazione del database, oltre ad aumentare il numero di repliche.
Overhead di GKE

Nei cluster Autopilot, non ti vengono addebitate le prenotazioni di risorse, ma solo le richieste di risorse.

Nei cluster Standard, GKE riserva risorse per le proprie operazioni. I database sui cluster standard non vengono scalati automaticamente, pertanto il carico 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 utilizzare e gestire un ampio insieme di pod, nodi e rivendicazioni di volume. Ti consigliamo di utilizzare un database gestito.
Backup del database in GKE

Un'istanza PersistentVolumeClaim è limitata a un cluster GKE. Questo ambito significa che quando un cluster GKE viene eliminato, anche la rivendicazione del volume viene eliminata. Verranno eliminati anche tutti i file di database nel cluster. Per proteggerti dalla perdita accidentale dei file del database, ti consigliamo di eseguire la replica o il backup frequente.

Puoi utilizzare Backup per GKE per acquisire snapshot della configurazione e dei dati dei volumi dell'applicazione 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 recupero 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 viene ricreato un pod, viene ricreata anche qualsiasi configurazione non persistente all'interno di un database o in 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 principale. Molti database relazionali hanno un'opzione per il failover attivo-passivo, in cui un secondario può essere promosso a principale in caso di guasto del principale.
Migrazione del database Se prevedi di eseguire la migrazione del tuo sistema di database esistente a GKE, consulta Migrazione del database: concetti e principi (Parte 1) e Migrazione del database: concetti e principi (Parte 2).
Riaddestramento degli utenti Se passi da un deployment autonomo o gestito dal provider a un deployment del database Kubernetes, devi addestrare nuovamente gli amministratori del database in modo che operino nel nuovo ambiente con la stessa affidabilità con cui operano nell'ambiente attuale. Anche gli sviluppatori di app potrebbero 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 inoltre tenere in considerazione il ripristino di emergenza, il pooling delle connessioni e il monitoraggio.

Passaggi successivi