PostgreSQL è un database relazionale open source con oggetti noto per l'affidabilità e l'integrità dei dati. È conforme all'ACID e supporta chiavi esterne, join, visualizzazioni, trigger e stored procedure.
Questo documento è destinato agli amministratori di database, ai Cloud Architect e ai professionisti operativi interessati al deployment di una topologia PostgreSQL ad alta disponibilità su Google Kubernetes Engine (GKE).
Obiettivi
In questo tutorial imparerai a:- Utilizza Terraform per creare un cluster GKE a livello di regione.
- Esegui il deployment di un database PostgreSQL ad alta disponibilità.
- Configurare il monitoraggio per l'applicazione PostgreSQL.
- Esegui upgrade di database PostgreSQL e cluster GKE.
- Simula l'interruzione del cluster e il failover della replica PostgreSQL.
- Esegui il backup e il ripristino del database PostgreSQL.
Architettura
Questa sezione descrive l'architettura della soluzione che creerai in questo tutorial.
Eseguirai il provisioning di due cluster GKE in regioni diverse: un cluster principale e un cluster di backup. Per questo tutorial, il cluster principale si trova nella regione us-central1
e il cluster di backup si trova nella regione us-west1
. Questa architettura consente di eseguire il provisioning di un database PostgreSQL ad alta disponibilità e di testare il ripristino di emergenza, come descritto più avanti in questo tutorial.
Per il cluster di origine, utilizzerai un grafico Helm
(bitnami/postgresql-ha
) per
configurare un cluster PostgreSQL ad alta disponibilità.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.
Prima di iniziare
Configura il progetto
- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
-
In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM.
-
In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM.
Configura i ruoli
-
Concedi i ruoli al tuo Account Google. Esegui questo comando una volta per ciascuno dei seguenti ruoli IAM:
role/storage.objectViewer, role/logging.logWriter, role/artifactregistry.Admin, roles/container.clusterAdmin, role/container.serviceAgent, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin
$ gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS" --role=ROLE
- Sostituisci
PROJECT_ID
con l'ID progetto. - Sostituisci
EMAIL_ADDRESS
con il tuo indirizzo email. - Sostituisci
ROLE
con ogni singolo ruolo.
- Sostituisci
configura l'ambiente
In questo tutorial utilizzerai Cloud Shell per gestire le risorse ospitate su Google Cloud. Cloud Shell è preinstallato con il software necessario per questo tutorial, tra cui Docker, kubectl
, gcloud CLI, Helm e Terraform.
Per utilizzare Cloud Shell per configurare il tuo ambiente:
Avvia una sessione di Cloud Shell dalla console Google Cloud facendo clic su
Attiva Cloud Shell nella console Google Cloud. In questo modo viene avviata una sessione nel riquadro inferiore della console Google Cloud.
Imposta le variabili di ambiente.
export PROJECT_ID=PROJECT_ID export SOURCE_CLUSTER=cluster-db1 export REGION=us-central1
Sostituisci i seguenti valori:
- PROJECT_ID: il tuo ID progetto Google Cloud.
Imposta le variabili di ambiente predefinite.
gcloud config set project PROJECT_ID
clona il repository di codice.
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Passa alla directory di lavoro.
cd kubernetes-engine-samples/databases/gke-stateful-postgres
Crea l'infrastruttura del cluster
In questa sezione eseguirai uno script Terraform per creare un Virtual Private Cloud (VPC) personalizzato, un repository Artifact Registry per l'archiviazione di immagini PostgreSQL e due cluster GKE a livello di regione.
Il deployment di un cluster in us-central1
verrà eseguito e del secondo cluster per il backup in us-west1
.
Per creare il cluster, segui questi passaggi:
Autopilot
In Cloud Shell, esegui questi comandi:
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply -var project_id=$PROJECT_ID
Quando richiesto, digita yes
.
Informazioni sulla configurazione di Terraform
I file di configurazione Terraform creano le seguenti risorse per eseguire il deployment dell'infrastruttura:
- Crea un repository Artifact Registry per l'archiviazione delle immagini Docker.
- Crea la rete VPC e la subnet per l'interfaccia di rete della VM.
Creare un cluster GKE principale.
Terraform crea un cluster privato nella regione
us-central1
e abilita Backup per GKE per il ripristino di emergenza e Managed Service per Prometheus per il monitoraggio del cluster.Managed Service per Prometheus è supportato solo su cluster Autopilot che eseguono GKE versione 1.25 o successiva.
Crea un cluster di backup nella regione
us-west1
per il ripristino di emergenza.
Standard
In Cloud Shell, esegui questi comandi:
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply -var project_id=$PROJECT_ID
Quando richiesto, digita yes
.
Informazioni sulla configurazione di Terraform
I file di configurazione Terraform creano le seguenti risorse per eseguire il deployment dell'infrastruttura:
- Crea un repository Artifact Registry per l'archiviazione delle immagini Docker.
- Crea la rete VPC e la subnet per l'interfaccia di rete della VM.
Creare un cluster GKE principale.
Terraform crea un cluster privato nella regione
us-central1
e abilita Backup per GKE per il ripristino di emergenza e Managed Service per Prometheus per il monitoraggio del cluster.Crea un cluster di backup nella regione
us-west1
per il ripristino di emergenza.
Esegui il deployment di PostgreSQL sul tuo cluster
In questa sezione eseguirai il deployment di un'istanza di database PostgreSQL da eseguire su GKE utilizzando un grafico Helm.
Installa PostgreSQL
Per installare PostgreSQL sul tuo cluster, segui questi passaggi.
Configurare l'accesso a Docker.
gcloud auth configure-docker us-docker.pkg.dev
Completare Artifact Registry con le immagini Docker PostgreSQL richieste.
./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r0 ./scripts/gcr.sh bitnami/postgres-exporter 0.11.1-debian-11-r27 ./scripts/gcr.sh bitnami/pgpool 4.3.3-debian-11-r28
Lo script esegue il push delle seguenti immagini Bitnami in Artifact Registry per Helm per l'installazione:
postgresql-repmgr
: Questa soluzione cluster PostgreSQL include il gestore di replica PostgreSQL (repmgr), uno strumento open source per la gestione della replica e del failover nei cluster PostgreSQL.postgres-exporter
: PostgreSQL Exporter raccoglie metriche PostgreSQL per l'utilizzo di Prometheus.pgpool
: Pgpool-II è il proxy PostgreSQL. Offre pool di connessioni e bilanciamento del carico.
Verifica che nel repository siano archiviate le immagini corrette.
gcloud artifacts docker images list us-docker.pkg.dev/$PROJECT_ID/main \ --format="flattened(package)"
L'output è simile al seguente:
--- image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/pgpool --- image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/postgres-exporter --- image: us-docker.pkg.dev/h[PROJECT_ID]/main/bitnami/postgresql-repmgr
Configura l'accesso da riga di comando di
kubectl
al cluster primario.gcloud container clusters get-credentials $SOURCE_CLUSTER \ --region=$REGION --project=$PROJECT_ID
Crea uno spazio dei nomi.
export NAMESPACE=postgresql kubectl create namespace $NAMESPACE
Se esegui il deployment in un cluster Autopilot, configura il provisioning dei nodi in tre zone. Puoi saltare questo passaggio se esegui il deployment in un cluster Standard.
Per impostazione predefinita, Autopilot esegue il provisioning delle risorse solo in due zone. Il deployment definito in
prepareforha.yaml
assicura che Autopilot esegua il provisioning dei nodi in tre zone del tuo cluster, impostando questi valori:replicas:3
podAntiAffinity
conrequiredDuringSchedulingIgnoredDuringExecution
etopologyKey: "topology.kubernetes.io/zone"
kubectl -n $NAMESPACE apply -f scripts/prepareforha.yaml
Aggiorna la dipendenza Helm.
cd helm/postgresql-bootstrap helm dependency update
Ispeziona e verifica i grafici che Helm installerà.
helm -n postgresql template postgresql . \ --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"
Installa il grafico Helm.
helm -n postgresql upgrade --install postgresql . \ --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"
L'output è simile al seguente:
NAMESPACE: postgresql STATUS: deployed REVISION: 1 TEST SUITE: None
Verifica che le repliche PostgreSQL siano in esecuzione.
kubectl get all -n $NAMESPACE
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE pod/postgresql-postgresql-bootstrap-pgpool-75664444cb-dkl24 1/1 Running 0 8m39s pod/postgresql-postgresql-ha-pgpool-6d86bf9b58-ff2bg 1/1 Running 0 8m39s pod/postgresql-postgresql-ha-postgresql-0 2/2 Running 0 8m39s pod/postgresql-postgresql-ha-postgresql-1 2/2 Running 0 8m39s pod/postgresql-postgresql-ha-postgresql-2 2/2 Running 0 8m38s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/postgresql-postgresql-ha-pgpool ClusterIP 192.168.99.236 <none> 5432/TCP 8m39s service/postgresql-postgresql-ha-postgresql ClusterIP 192.168.90.20 <none> 5432/TCP 8m39s service/postgresql-postgresql-ha-postgresql-headless ClusterIP None <none> 5432/TCP 8m39s service/postgresql-postgresql-ha-postgresql-metrics ClusterIP 192.168.127.198 <none> 9187/TCP 8m39s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/postgresql-postgresql-bootstrap-pgpool 1/1 1 1 8m39s deployment.apps/postgresql-postgresql-ha-pgpool 1/1 1 1 8m39s NAME DESIRED CURRENT READY AGE replicaset.apps/postgresql-postgresql-bootstrap-pgpool-75664444cb 1 1 1 8m39s replicaset.apps/postgresql-postgresql-ha-pgpool-6d86bf9b58 1 1 1 8m39s NAME READY AGE statefulset.apps/postgresql-postgresql-ha-postgresql 3/3 8m39s
crea un set di dati di test
In questa sezione creerai un database e una tabella con valori di esempio. Il database funge da set di dati di test per il processo di failover che testerai più avanti in questo tutorial.
Connetterti all'istanza PostgreSQL.
cd ../../ ./scripts/launch-client.sh
L'output è simile al seguente:
Launching Pod pg-client in the namespace postgresql ... pod/pg-client created waiting for the Pod to be ready Copying script files to the target Pod pg-client ... Pod: pg-client is healthy
Avvia una sessione di shell.
kubectl exec -it pg-client -n postgresql -- /bin/bash
Crea un database e una tabella, quindi inserisci alcune righe di test.
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/generate-db.sql
Verifica il numero di righe per ogni tabella.
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql
L'output è simile al seguente:
select COUNT(*) from tb01; count -------- 300000 (1 row) select COUNT(*) from tb02; count -------- 300000 (1 row)
Generare dati di test.
export DB=postgres pgbench -i -h $HOST_PGPOOL -U postgres $DB -s 50
L'output è simile al seguente:
dropping old tables... creating tables... generating data (client-side)... 5000000 of 5000000 tuples (100%) done (elapsed 29.85 s, remaining 0.00 s) vacuuming... creating primary keys... done in 36.86 s (drop tables 0.00 s, create tables 0.01 s, client-side generate 31.10 s, vacuum 1.88 s, primary keys 3.86 s).
Esci dal pod del client postgres.
exit
Monitora PostgreSQL
In questa sezione, vedrai le metriche e imposterai avvisi per l'istanza PostgreSQL. Utilizzerai Google Cloud Managed Service per Prometheus per eseguire il monitoraggio e gli avvisi.
Visualizza metriche
Il deployment PostgreSQL include un container collaterale postgresql-exporter
. Questo container espone un endpoint /metrics
.
Google Cloud Managed Service per Prometheus è configurato per monitorare i pod PostgreSQL su questo endpoint. Puoi visualizzare queste metriche tramite le dashboard della console Google Cloud.
La console Google Cloud offre alcuni modi per creare e salvare la configurazione della dashboard:
- Creazione ed esportazione: puoi creare dashboard direttamente nella console Google Cloud, quindi esportarle e archiviarle in un repository di codice. Per farlo, apri l'editor JSON nella barra degli strumenti della dashboard e scarica il file JSON della dashboard.
- Archiviazione e importazione: puoi importare una dashboard da un file JSON facendo clic su +Crea dashboard e caricando i contenuti JSON della dashboard tramite il menu Editor JSON.
Per visualizzare i dati dell'applicazione PostgreSQL e del cluster GKE, segui questi passaggi:
Crea le dashboard seguenti.
cd monitoring gcloud monitoring dashboards create \ --config-from-file=dashboard/postgresql-overview.json \ --project=$PROJECT_ID gcloud monitoring dashboards create \ --config-from-file dashboard/gke-postgresql.json \ --project $PROJECT_ID
Nella console Google Cloud, vai alla dashboard di Cloud Monitoring. Vai alla dashboard di Cloud Monitoring
Seleziona Personalizzato dall'elenco delle dashboard. Vengono visualizzate le seguenti dashboard:
- Panoramica di PostgreSQL: visualizza le metriche dell'applicazione PostgreSQL, inclusi uptime del database, dimensione del database e latenza delle transazioni.
- Cluster GKE PostgreSQL: visualizza le metriche del cluster GKE su cui è in esecuzione PostgreSQL, tra cui utilizzo della CPU, utilizzo della memoria e utilizzo del volume.
Fai clic su ciascun link per esaminare le dashboard generate.
Configurazione degli avvisi
Gli avvisi ti consentono di conoscere tempestivamente i problemi delle tue applicazioni, in modo da poterli risolvere rapidamente. Puoi creare un criterio di avviso per specificare le circostanze in cui vuoi ricevere l'avviso e come. Puoi anche creare canali di notifica che ti consentono di selezionare dove inviare gli avvisi.
In questa sezione utilizzerai Terraform per configurare i seguenti avvisi di esempio:
db_max_transaction
: monitora il ritardo massimo delle transazioni in secondi; se il valore è maggiore di 10, verrà attivato un avviso.db_node_up
: monitora lo stato dei pod di database; 0 indica che un pod non è attivo e attiva un avviso.
Per impostare gli avvisi, segui questi passaggi:
Configurare avvisi con Terraform.
EMAIL=YOUR_EMAIL cd alerting/terraform terraform init terraform plan -var project_id=$PROJECT_ID -var email_address=$EMAIL terraform apply -var project_id=$PROJECT_ID -var email_address=$EMAIL
Sostituisci i seguenti valori:
- YOUR_EMAIL: il tuo indirizzo email.
L'output è simile al seguente :
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
Connettiti al pod del client.
cd ../../../ kubectl exec -it --namespace postgresql pg-client -- /bin/bash
Genera un test di carico per testare l'avviso
db_max_transaction
.pgbench -i -h $HOST_PGPOOL -U postgres -s 200 postgres
L'output è simile al seguente:
dropping old tables... creating tables... generating data (client-side)... 20000000 of 20000000 tuples (100%) done (elapsed 163.22 s, remaining 0.00 s) vacuuming... creating primary keys... done in 191.30 s (drop tables 0.14 s, create tables 0.01 s, client-side generate 165.62 s, vacuum 4.52 s, primary keys 21.00 s).
L'avviso si attiva e invia un'email a YOUR_EMAIL con oggetto che inizia con "[AVVISO] Ritardo massimo della transazione".
Nella console Google Cloud, vai alla pagina Criterio di avviso.
Seleziona
db_max_transaction
dai criteri elencati. Dal grafico dovresti notare un picco del test di carico che supera la soglia di 10 per la metrica di Prometheuspg_stat_activity_max_tx_duration/gauge
.Esci dal pod del client postgres.
exit
Gestisci gli upgrade di PostgreSQL e GKE
Gli aggiornamenti della versione sia per PostgreSQL che per Kubernetes vengono rilasciati secondo una pianificazione regolare. Segui le best practice operative per aggiornare regolarmente il tuo ambiente software. Per impostazione predefinita, GKE gestisce gli upgrade dei cluster e del pool di nodi.
Upgrade di PostgreSQL
Questa sezione mostra come eseguire un upgrade della versione per PostgreSQL. Per questo tutorial, utilizzerai una strategia di aggiornamento in sequenza per eseguire l'upgrade dei pod, in modo che in nessun momento tutti i pod siano inattivi.
Per eseguire un upgrade della versione, segui questi passaggi:
Esegui il push di una versione aggiornata dell'immagine
postgresql-repmgr
ad Artifact Registry. Definisci la nuova versione (ad esempio,postgresql-repmgr 15.1.0-debian-11-r1
).NEW_IMAGE=us-docker.pkg.dev/$PROJECT_ID/main/bitnami/postgresql-repmgr:15.1.0-debian-11-r1 ./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r1
Attiva un aggiornamento in sequenza utilizzando
kubectl
.kubectl set image statefulset -n postgresql postgresql-postgresql-ha-postgresql postgresql=$NEW_IMAGE kubectl rollout restart statefulsets -n postgresql postgresql-postgresql-ha-postgresql kubectl rollout status statefulset -n postgresql postgresql-postgresql-ha-postgresql
Vedrai che lo StatefulSet completa un aggiornamento in sequenza, a partire dalla replica ordinale più alta fino a quella più bassa.
L'output è simile al seguente:
Waiting for 1 pods to be ready... waiting for statefulset rolling update to complete 1 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49... Waiting for 1 pods to be ready... Waiting for 1 pods to be ready... waiting for statefulset rolling update to complete 2 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49... Waiting for 1 pods to be ready... Waiting for 1 pods to be ready... statefulset rolling update complete 3 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...
Pianifica gli upgrade di GKE sui cluster Standard
Questa sezione si applica se esegui cluster standard. Puoi adottare misure proattive e impostare configurazioni per mitigare i rischi e semplificare un upgrade dei cluster più fluido quando esegui servizi stateful, tra cui:
Segui le best practice di GKE per l'upgrade dei cluster. Scegli una strategia di upgrade appropriata per assicurarti che gli upgrade vengano eseguiti durante il periodo del periodo di manutenzione:
- Scegli gli upgrade di picco se l'ottimizzazione dei costi è importante e se i tuoi carichi di lavoro possono tollerare un arresto controllato in meno di 60 minuti.
- Scegli gli upgrade blu/verde se i tuoi carichi di lavoro tollerano meno le interruzioni ed è accettabile un aumento temporaneo dei costi dovuto a un utilizzo più elevato delle risorse.
Per saperne di più, consulta Eseguire l'upgrade di un cluster che esegue un carico di lavoro stateful.
Utilizza il servizio Motore per suggerimenti per verificare la presenza di insight e suggerimenti sul ritiro al fine di evitare interruzioni del servizio.
Utilizza i periodi di manutenzione per assicurarti che gli upgrade vengano eseguiti quando previsto. Prima del periodo di manutenzione, assicurati che i backup del database siano riusciti.
Prima di consentire il traffico ai nodi di cui è stato eseguito l'upgrade, utilizza i probe di idoneità e attività per assicurarti che siano pronti per il traffico.
Crea probe che valutano se la replica è sincronizzata prima di accettare il traffico. Questo può essere fatto tramite script personalizzati, a seconda della complessità e della scala del database.
Verificare la disponibilità dei database durante gli upgrade dei cluster standard
Questa sezione si applica se esegui cluster standard. Per verificare la disponibilità di PostgreSQL durante gli upgrade, il processo generale consiste nel generare traffico sul database PostgreSQL durante il processo di upgrade. Quindi, utilizza pgbench
per verificare che il database sia in grado di gestire un livello di base di traffico durante un upgrade rispetto a quando il database è completamente disponibile.
Connetterti all'istanza PostgreSQL.
./scripts/launch-client.sh
L'output è simile al seguente:
Launching Pod pg-client in the namespace postgresql ... pod/pg-client created waiting for the Pod to be ready Copying script files to the target Pod pg-client ... Pod: pg-client is healthy
In Cloud Shell, esegui la shell nel pod del client.
kubectl exec -it -n postgresql pg-client -- /bin/bash
Inizializza pgbench .
pgbench -i -h $HOST_PGPOOL -U postgres postgres
Utilizza il seguente comando per ottenere risultati di riferimento per confermare che la tua applicazione PostgreSQL rimane ad alta disponibilità durante la finestra temporale per un upgrade. Per ottenere un risultato di riferimento, esegui un test con più connessioni tramite più job (thread) per 30 secondi.
pgbench -h $HOST_PGPOOL -U postgres postgres -c10 -j4 -T 30 -R 200
L'output è simile al seguente:
pgbench (14.5) starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 10 number of threads: 4 duration: 30 s number of transactions actually processed: 5980 latency average = 7.613 ms latency stddev = 2.898 ms rate limit schedule lag: avg 0.256 (max 36.613) ms initial connection time = 397.804 ms tps = 201.955497 (without initial connection time)
Per garantire la disponibilità durante gli upgrade, puoi generare un certo carico sul database e assicurarti che l'applicazione PostgreSQL fornisca un tasso di risposta coerente durante l'upgrade. Per eseguire questo test, genera del traffico sul database utilizzando il comando
pgbench
. Il seguente comando verrà eseguitopgbench
per un'ora, scegliendo come target 200 TPS (transazioni al secondo) ed elencando la tasso di richieste ogni 2 secondi.pgbench -h $HOST_PGPOOL -U postgres postgres --client=10 --jobs=4 --rate=200 --time=3600 --progress=2 --select-only
Dove:
--client
: numero di client simulati, ovvero il numero di sessioni di database simultanee.--jobs
: numero di thread di worker in pgbench. L'utilizzo di più di un thread può essere utile sulle macchine con più CPU. I client vengono distribuiti nel modo più uniforme possibile tra i thread disponibili. Il valore predefinito è 1.--rate
: la frequenza è espressa in transazioni al secondo--progress
: mostra il report sull'avanzamento ogni secondo.
L'output è simile al seguente:
pgbench (14.5) starting vacuum...end. progress: 5.0 s, 354.8 tps, lat 25.222 ms stddev 15.038 progress: 10.0 s, 393.8 tps, lat 25.396 ms stddev 16.459 progress: 15.0 s, 412.8 tps, lat 24.216 ms stddev 14.548 progress: 20.0 s, 405.0 tps, lat 24.656 ms stddev 14.066
Nella console Google Cloud, torna alla dashboard Panoramica di PostgreSQL in Cloud Monitoring. Osserva il picco nei grafici Connessione per database e Connessione per pod.
Esci dal pod del client.
exit
Eliminare il pod del client.
kubectl delete pod -n postgresql pg-client
Simulare un'interruzione del servizio PostgreSQL
In questa sezione simulerai un'interruzione del servizio in una delle repliche PostgreSQL arrestando il servizio del gestore di replica. Ciò impedirà al pod di gestire il traffico verso le sue repliche peer e i suoi probe di attività.
Apri una nuova sessione di Cloud Shell e configura l'accesso da riga di comando di
kubectl
al cluster principale.gcloud container clusters get-credentials $SOURCE_CLUSTER \ --region=$REGION --project=$PROJECT_ID
Visualizza gli eventi PostgreSQL emessi in Kubernetes.
kubectl get events -n postgresql --field-selector=involvedObject.name=postgresql-postgresql-ha-postgresql-0 --watch
Nella sessione Cloud Shell precedente, simula un errore del servizio arrestando PostgreSQL
repmgr
.Collega la sessione al container di database.
kubectl exec -it -n $NAMESPACE postgresql-postgresql-ha-postgresql-0 -c postgresql -- /bin/bash
Arresta il servizio utilizzando
repmgr
e rimuovi il checkpoint e l'argomentodry-run
.export ENTRY='/opt/bitnami/scripts/postgresql-repmgr/entrypoint.sh' export RCONF='/opt/bitnami/repmgr/conf/repmgr.conf' $ENTRY repmgr -f $RCONF node service --action=stop --checkpoint
Il probe di attività configurato per il container PostgreSQL inizierà a restituire errori entro cinque secondi. L'operazione si ripete ogni dieci secondi, finché non viene raggiunta la soglia di sei errori. Una volta raggiunto il valore failureThreshold
, il container viene riavviato. Puoi configurare questi parametri per ridurre la tolleranza del probe di attività al fine di ottimizzare i requisiti SLO del deployment.
Dal flusso di eventi, vedrai che i probe di attività e di idoneità del pod hanno esito negativo, e un messaggio che ti informa che il container deve essere riavviato. L'output è simile al seguente:
0s Normal Killing pod/postgresql-postgresql-ha-postgresql-0 Container postgresql failed liveness probe, will be restarted
0s Warning Unhealthy pod/postgresql-postgresql-ha-postgresql-0 Readiness probe failed: psql: error: connection to server at "127.0.0.1", port 5432 failed: Connection refused...
0s Normal Pulled pod/postgresql-postgresql-ha-postgresql-0 Container image "us-docker.pkg.dev/psch-gke-dev/main/bitnami/postgresql-repmgr:14.5.0-debian-11-r10" already present on machine
0s Normal Created pod/postgresql-postgresql-ha-postgresql-0 Created container postgresql
0s Normal Started pod/postgresql-postgresql-ha-postgresql-0 Started container postgresql
Preparati per il ripristino di emergenza
Per garantire che i carichi di lavoro di produzione rimangano disponibili in caso di evento che interrompe il servizio, devi preparare un piano di ripristino di emergenza (RE). Per scoprire di più sulla pianificazione RE, consulta la Guida alla pianificazione del ripristino di emergenza.
Il ripristino di emergenza per Kubernetes può essere implementato in due fasi:
- Il backup comporta la creazione di uno snapshot point-in-time dello stato o dei dati prima che si verifichi un evento che interrompe il servizio.
- Il ripristino prevede il ripristino dello stato o dei dati da una copia di backup dopo il verificarsi di un'emergenza.
Per eseguire il backup e il ripristino dei carichi di lavoro sui cluster GKE, puoi utilizzare Backup per GKE. Puoi abilitare questo servizio su cluster nuovi ed esistenti. Questa operazione esegue il deployment di un agente Backup per GKE in esecuzione nei tuoi cluster. L'agente è responsabile dell'acquisizione dei dati della configurazione e del backup del volume, nonché dell'orchestrazione del recupero.
Backup e ripristino possono limitare l'ambito a un intero cluster, a uno spazio dei nomi o a un'applicazione (definiti da selettori come matchLabels
).
Scenario di esempio di backup e ripristino di PostgreSQL
L'esempio in questa sezione mostra come eseguire un'operazione di backup e ripristino
nell'ambito dell'applicazione, utilizzando la risorsa personalizzata ProtectedApplication
.
Il seguente diagramma mostra le risorse del componente in ProtectedApplication, ovvero uno StatefulSet che rappresenta l'applicazione postgresql-ha
e un deployment di pgpool
, che utilizzano la stessa etichetta (app.kubernetes.io/name: postgresql-ha
).
Per prepararti a eseguire il backup e il ripristino del carico di lavoro PostgreSQL, segui questi passaggi:
Configura le variabili di ambiente. In questo esempio utilizzerai ProtectedApplication per ripristinare il carico di lavoro PostgreSQL e i relativi volumi dal cluster GKE di origine (
us-central1
), quindi eseguirai il ripristino in un altro cluster GKE in un'altra regione (us-west1
).export SOURCE_CLUSTER=cluster-db1 export TARGET_CLUSTER=cluster-db2 export REGION=us-central1 export DR_REGION=us-west1 export NAME_PREFIX=g-db-protected-app export BACKUP_PLAN_NAME=$NAME_PREFIX-bkp-plan-01 export BACKUP_NAME=bkp-$BACKUP_PLAN_NAME export RESTORE_PLAN_NAME=$NAME_PREFIX-rest-plan-01 export RESTORE_NAME=rest-$RESTORE_PLAN_NAME
Verifica che Backup per GKE sia abilitato sui tuoi cluster. Dovrebbe essere già abilitato nell'ambito della configurazione di Terraform eseguita in precedenza.
gcloud container clusters describe $SOURCE_CLUSTER \ --project=$PROJECT_ID \ --region=$REGION \ --format='value(addonsConfig.gkeBackupAgentConfig)'
Se Backup per GKE è abilitato, l'output del comando mostra
enabled=True
.
Configura un piano di backup ed esegui un ripristino
Backup per GKE consente di creare un piano di backup come cron job. Un piano di backup contiene una configurazione di backup che comprende il cluster di origine, la selezione dei carichi di lavoro di cui eseguire il backup e la regione in cui sono archiviati gli artefatti di backup prodotti in questo piano.
Per eseguire un backup e ripristino, procedi nel seguente modo:
Verifica lo stato di ProtectedApplication il giorno
cluster-db1
.kubectl get ProtectedApplication -A
L'output è simile al seguente:
NAMESPACE NAME READY TO BACKUP postgresql postgresql-ha true
Crea un piano di backup per ProtectedApplication.
export NAMESPACE=postgresql export PROTECTED_APP=$(kubectl get ProtectedApplication -n $NAMESPACE | grep -v 'NAME' | awk '{ print $1 }')
gcloud beta container backup-restore backup-plans create $BACKUP_PLAN_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --cluster=projects/$PROJECT_ID/locations/$REGION/clusters/$SOURCE_CLUSTER \ --selected-applications=$NAMESPACE/$PROTECTED_APP \ --include-secrets \ --include-volume-data \ --cron-schedule="0 3 * * *" \ --backup-retain-days=7 \ --backup-delete-lock-days=0
Crea manualmente un backup.
gcloud beta container backup-restore backups create $BACKUP_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --backup-plan=$BACKUP_PLAN_NAME \ --wait-for-completion
Configura un piano di ripristino.
gcloud beta container backup-restore restore-plans create $RESTORE_PLAN_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --backup-plan=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME \ --cluster=projects/$PROJECT_ID/locations/$DR_REGION/clusters/$TARGET_CLUSTER \ --cluster-resource-conflict-policy=use-existing-version \ --namespaced-resource-restore-mode=delete-and-restore \ --volume-data-restore-policy=restore-volume-data-from-backup \ --selected-applications=$NAMESPACE/$PROTECTED_APP \ --cluster-resource-scope-selected-group-kinds="storage.k8s.io/StorageClass","scheduling.k8s.io/PriorityClass"
Ripristina dal backup.
gcloud beta container backup-restore restores create $RESTORE_NAME \ --project=$PROJECT_ID \ --location=$DR_REGION \ --restore-plan=$RESTORE_PLAN_NAME \ --backup=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME/backups/$BACKUP_NAME \ --wait-for-completion
Verifica che il cluster sia stato ripristinato
Per verificare che il cluster ripristinato includa tutti i pod, le risorse PersistentVolume e StorageClass previsti, segui questi passaggi:
Configura l'accesso da riga di comando di
kubectl
al cluster di backupcluster-db2
.gcloud container clusters get-credentials $TARGET_CLUSTER --region $DR_REGION --project $PROJECT_ID
Verifica che lo StatefulSet sia pronto con 3/3 pod.
kubectl get all -n $NAMESPACE
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE pod/postgresql-postgresql-ha-pgpool-778798b5bd-k2q4b 1/1 Running 0 4m49s pod/postgresql-postgresql-ha-postgresql-0 2/2 Running 2 (4m13s ago) 4m49s pod/postgresql-postgresql-ha-postgresql-1 2/2 Running 0 4m49s pod/postgresql-postgresql-ha-postgresql-2 2/2 Running 0 4m49s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/postgresql-postgresql-ha-pgpool ClusterIP 192.168.241.46 <none> 5432/TCP 4m49s service/postgresql-postgresql-ha-postgresql ClusterIP 192.168.220.20 <none> 5432/TCP 4m49s service/postgresql-postgresql-ha-postgresql-headless ClusterIP None <none> 5432/TCP 4m49s service/postgresql-postgresql-ha-postgresql-metrics ClusterIP 192.168.226.235 <none> 9187/TCP 4m49s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/postgresql-postgresql-ha-pgpool 1/1 1 1 4m49s NAME DESIRED CURRENT READY AGE replicaset.apps/postgresql-postgresql-ha-pgpool-778798b5bd 1 1 1 4m49s NAME READY AGE statefulset.apps/postgresql-postgresql-ha-postgresql 3/3 4m49s
Verifica che tutti i pod nello spazio dei nomi
postgres
siano in esecuzione.kubectl get pods -n $NAMESPACE
L'output è simile al seguente:
postgresql-postgresql-ha-pgpool-569d7b8dfc-2f9zx 1/1 Running 0 7m56s postgresql-postgresql-ha-postgresql-0 2/2 Running 0 7m56s postgresql-postgresql-ha-postgresql-1 2/2 Running 0 7m56s postgresql-postgresql-ha-postgresql-2 2/2 Running 0 7m56s
Verificare gli oggetti PersistentVolume e StorageClass. Durante il processo di ripristino, Backup per GKE crea una classe proxy nel carico di lavoro di destinazione per sostituire il valore StorageClass di cui è stato eseguito il provisioning nel carico di lavoro di origine (
gce-pd-gkebackup-dn
nell'output di esempio).kubectl get pvc -n $NAMESPACE
L'output è simile al seguente:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-postgresql-postgresql-ha-postgresql-0 Bound pvc-be91c361e9303f96 8Gi RWO gce-pd-gkebackup-dn 10m data-postgresql-postgresql-ha-postgresql-1 Bound pvc-6523044f8ce927d3 8Gi RWO gce-pd-gkebackup-dn 10m data-postgresql-postgresql-ha-postgresql-2 Bound pvc-c9e71a99ccb99a4c 8Gi RWO gce-pd-gkebackup-dn 10m
Verifica che i dati previsti vengano ripristinati
Per confermare che i dati previsti vengano ripristinati:
Connetterti all'istanza PostgreSQL.
./scripts/launch-client.sh kubectl exec -it pg-client -n postgresql -- /bin/bash
Verifica il numero di righe per ogni tabella.
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql select COUNT(*) from tb01;
Dovresti vedere un risultato simile a quello dei dati che hai scritto in precedenza nella sezione Creare un set di dati di test. L'output è simile al seguente:
300000 (1 row)
Esci dal pod del client.
exit
Esegui la pulizia
Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
Elimina il progetto
Il modo più semplice per evitare la fatturazione è eliminare il progetto che hai creato per il tutorial.
Elimina un progetto Google Cloud:
gcloud projects delete PROJECT_ID
Passaggi successivi
- Scopri le best practice per il deployment dei database su GKE.
- Esplora i volumi permanenti in modo più dettagliato.
- Guarda un esempio di come utilizzare Pgpool-II per la replica dei flussi di dati con i cluster PostgreSQL ad alta disponibilità.