Déployer PostgreSQL sur GKE à l'aide de Zalando

Ce guide vous explique comment utiliser l'opérateur Zalando Postgres pour déployer des clusters Postgres sur Google Kubernetes Engine (GKE).

PostgreSQL est un système de base de données Open Source de type objet-relationnel à fort potentiel de développement actif depuis plusieurs décennies, qui lui a permis d'acquérir une solide réputation pour la fiabilité, la robustesse des fonctionnalités et les performances.

Ce guide est destiné aux administrateurs de plate-forme, aux architectes cloud et aux professionnels des opérations qui souhaitent exécuter PostgreSQL en tant qu'application de base de données sur GKE au lieu d'utiliser Cloud SQL pour PostgreSQL.

Objectifs

  • Planifier et déployer l'infrastructure GKE pour Postgres
  • Déployer et configurer l'opérateur Zalando Postgres
  • Configurer Postgres à l'aide de l'opérateur pour garantir la disponibilité, la sécurité, l'observabilité et les performances

Avantages

Zalando offre les avantages suivants :

  • Moyen déclaratif et Kubernetes natif de gérer et de configurer les clusters PostgreSQL
  • Haute disponibilité fournie par Patroni
  • Gestion des sauvegardes à l'aide de buckets Cloud Storage
  • Mises à jour progressives sur les modifications de cluster Postgres, y compris des mises à jour rapides de versions mineures
  • Gestion déclarative des utilisateurs avec génération et rotation de mots de passe à l'aide de ressources personnalisées
  • Compatibilité avec TLS, la rotation des certificats et les pools de connexions
  • Clonage de cluster et réplication de données

Architecture de déploiement

Dans ce tutoriel, vous utilisez l'opérateur Zalando Postgres pour déployer et configurer un cluster Postgres à disponibilité élevée sur GKE. Le cluster comporte une instance répliquée principale et deux instances répliquées de secours (en lecture seule) gérées par Patroni. Patroni est une solution Open Source gérée par Zalando afin de fournir des fonctionnalités de haute disponibilité et de basculement automatique à Postgres. En cas de défaillance de l'instance répliquée principale, une instance répliquée de secours est automatiquement promue à un rôle de responsable.

Vous allez également déployer un cluster GKE régional hautement disponible pour Postgres, avec plusieurs nœuds Kubernetes répartis sur plusieurs zones de disponibilité. Cette configuration permet d'assurer la tolérance aux pannes, l'évolutivité et la redondance géographique. Elle permet d'effectuer des mises à jour et des opérations de maintenance progressives tout en fournissant des contrats de niveau de service en matière de temps d'activité et de disponibilité. Pour en savoir plus, consultez la page Clusters régionaux.

Le schéma suivant montre un cluster Postgres s'exécutant sur plusieurs nœuds et zones dans un cluster GKE :

Dans le schéma, le StatefulSet Postgres est déployé sur trois nœuds dans trois zones différentes. Vous pouvez contrôler le déploiement de GKE sur les nœuds en définissant les règles affinité et anti-affinité du pod requises sur la spécification de ressource personnalisée postgresql. Si une zone échoue, à l'aide de la configuration recommandée, GKE replanifie les pods sur les autres nœuds disponibles de votre cluster. Pour les données persistantes, utilisez des disques SSD (StorageClass premium-rwo), qui sont recommandés dans la plupart des cas pour les bases de données à charge élevée, en raison de leur Latence faible et nombre élevé d'IOPS.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Pour obtenir une estimation des coûts en fonction de votre utilisation prévue, utilisez le simulateur de coût.

Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai sans frais.

Une fois que vous avez terminé les tâches décrites dans ce document, supprimez les ressources que vous avez créées pour éviter que des frais vous soient facturés. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

Les logiciels dont vous avez besoin pour ce tutoriel sont préinstallés sur Cloud Shell, y compris kubectl, la gcloud CLI, Helm et Terraform. Si vous n'utilisez pas Cloud Shell, vous devez installer la gcloud CLI.

  1. Connectez-vous à votre compte Google Cloud . Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $de crédits sans frais pour exécuter, tester et déployer des charges de travail.

  2. Installez la Google Cloud CLI.

  3. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

  4. Pour initialiser la gcloud CLI, exécutez la commande suivante : 

    gcloud init

  5. Créez ou sélectionnez un projet Google Cloud .

    Rôles requis pour sélectionner ou créer un projet

    • Sélectionnez un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique. Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
    • Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.

    • Créez un projet Google Cloud  :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.

    • Sélectionnez le projet Google Cloud que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre projet Google Cloud .

  6. Vérifiez que la facturation est activée pour votre projet Google Cloud .

  7. Activez les API Compute Engine, IAM, GKE et Sauvegarde pour GKE :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. Découvrez comment attribuer des rôles. 

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com

  8. Installez la Google Cloud CLI.

  9. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

  10. Pour initialiser la gcloud CLI, exécutez la commande suivante : 

    gcloud init

  11. Créez ou sélectionnez un projet Google Cloud .

    Rôles requis pour sélectionner ou créer un projet

    • Sélectionnez un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique. Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
    • Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.

    • Créez un projet Google Cloud  :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du projet Google Cloud que vous créez.

    • Sélectionnez le projet Google Cloud que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre projet Google Cloud .

  12. Vérifiez que la facturation est activée pour votre projet Google Cloud .

  13. Activez les API Compute Engine, IAM, GKE et Sauvegarde pour GKE :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. Découvrez comment attribuer des rôles. 

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com
    14.

  14. Attribuez des rôles à votre compte utilisateur. Exécutez la commande suivante une fois pour chacun des rôles IAM suivants : roles/storage.objectViewer, roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer 

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet
    • USER_IDENTIFIER : identifiant de votre compte d'utilisateur. Par exemple, myemail@example.com.
    • ROLE : rôle IAM que vous accordez à votre compte utilisateur.

Configurer votre environnement

Pour configurer votre environnement, procédez comme suit :

  1. Définissez les variables d'environnement :

    export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=postgres
export REGION=us-central1

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

  2. Clonez le dépôt GitHub.

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

  3. Accédez au répertoire de travail :

    cd kubernetes-engine-samples/databases/postgres-zalando

Créer l'infrastructure de votre cluster

Dans cette section, vous allez exécuter un script Terraform pour créer un cluster GKE régional, privé et à disponibilité élevée.

Vous pouvez installer l'opérateur à l'aide d'un cluster standard ou Autopilot.

Standard

Le schéma suivant présente un cluster GKE standard régional privé déployé sur trois zones différentes :

Déployez l'infrastructure suivante :

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply \
  -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Lorsque vous y êtes invité, saisissez yes. L'exécution de cette commande et le passage du cluster à l'état prêt peuvent prendre plusieurs minutes.

Terraform crée les ressources suivantes :

  • Un réseau VPC et un sous-réseau privé pour les nœuds Kubernetes.
  • Un routeur pour accéder à Internet via NAT.
  • Un cluster GKE privé dans la région us-central1.
  • Un pool de nœuds avec autoscaling activé (un à deux nœuds par zone, un nœud par zone au minimum).
  • Un ServiceAccount avec les autorisations de journalisation et de surveillance.
  • Sauvegarde pour GKE pour la reprise après sinistre.
  • Google Cloud Managed Service pour Prometheus pour la surveillance du cluster.

Le résultat ressemble à ce qui suit :

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...

Autopilot

Le schéma suivant présente un cluster GKE Autopilot régional privé :

Déployez l'infrastructure :

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply \
  -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Lorsque vous y êtes invité, saisissez yes. L'exécution de cette commande et le passage du cluster à l'état prêt peuvent prendre plusieurs minutes.

Terraform crée les ressources suivantes :

  • Un réseau VPC et un sous-réseau privé pour les nœuds Kubernetes.
  • Un routeur pour accéder à Internet via NAT.
  • Un cluster GKE privé dans la région us-central1.
  • Un objet ServiceAccount avec une autorisation de journalisation et de surveillance.
  • Google Cloud Managed Service pour Prometheus pour la surveillance du cluster.

Le résultat ressemble à ce qui suit :

...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.
...

Se connecter au cluster

Configurez kubectl pour communiquer avec le cluster :

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}

Déployer l'opérateur Zalando sur votre cluster

Déployez l'opérateur Zalando sur votre cluster Kubernetes à l'aide d'un chart Helm.

  1. Ajoutez le dépôt du chart Helm de l'opérateur Zalando :

    helm repo add postgres-operator-charts https://opensource.zalando.com/postgres-operator/charts/postgres-operator

  2. Créez un espace de noms pour l'opérateur Zalando et le cluster Postgres :

    kubectl create ns postgres
kubectl create ns zalando

  3. Déployez l'opérateur Zalando à l'aide de l'outil de ligne de commande Helm :

    helm install postgres-operator postgres-operator-charts/postgres-operator -n zalando \
    --set configKubernetes.enable_pod_antiaffinity=true \
    --set configKubernetes.pod_antiaffinity_preferred_during_scheduling=true \
    --set configKubernetes.pod_antiaffinity_topology_key="topology.kubernetes.io/zone" \
    --set configKubernetes.spilo_fsgroup="103"

    Vous ne pouvez pas configurer les paramètres podAntiAffinity directement sur la ressource personnalisée représentant le cluster Postgres. À la place, définissez les paramètres podAntiAffinity de manière globale pour tous les clusters Postgres dans les paramètres de l'opérateur.

  4. Vérifiez l'état de déploiement de l'opérateur Zalando à l'aide de Helm :

    helm ls -n zalando

    Le résultat ressemble à ce qui suit :

    NAME                 NAMESPACE    REVISION    UPDATED                                STATUS      CHART                       APP VERSION
postgres-operator    zalando     1           2023-10-13 16:04:13.945614 +0200 CEST    deployed    postgres-operator-1.10.1    1.10.1

Déployer Postgres

La configuration de base de l'instance de cluster Postgres inclut les composants suivants :

  • Trois instances répliquées Postgres : une instance répliquée principale et deux instances répliquées de secours.
  • Allocation de ressources de processeur pour une requête de processeur et deux limites de processeur, avec 4 Go de demandes et limites de mémoire.
  • Les tolérances, nodeAffinities et topologySpreadConstraints configurées pour chaque charge de travail, garantissant une répartition appropriée entre les nœuds Kubernetes, en utilisant leurs pools de nœuds respectifs et différentes zones de disponibilité.

Cette configuration représente la configuration minimale requise pour créer un cluster Postgres prêt pour la production.

Le fichier manifeste suivant décrit un cluster Postgres :

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  dockerImage: ghcr.io/zalando/spilo-15:3.0-p1
  teamId: "my-team"
  numberOfInstances: 3
  users:
    mydatabaseowner:
    - superuser
    - createdb
    myuser: []
  databases:
    mydatabase: mydatabaseowner
  postgresql:
    version: "15"
    parameters:
      shared_buffers: "32MB"
      max_connections: "10"
      log_statement: "all"
      password_encryption: scram-sha-256
  volume:
    size: 5Gi
    storageClass: premium-rwo
  enableShmVolume: true
  podAnnotations:
    cluster-autoscaler.kubernetes.io/safe-to-evict: "true"
  tolerations:
  - key: "app.stateful/component"
    operator: "Equal"
    value: "postgres-operator"
    effect: NoSchedule
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        - key: "app.stateful/component"
          operator: In
          values:
          - "postgres-operator"
  resources:
    requests:
      cpu: "1"
      memory: 4Gi
    limits:
      cpu: "2"
      memory: 4Gi
  sidecars:
    - name: exporter
      image: quay.io/prometheuscommunity/postgres-exporter:v0.14.0
      args:
      - --collector.stat_statements
      ports:
      - name: exporter
        containerPort: 9187
        protocol: TCP
      resources:
        limits:
          cpu: 500m
          memory: 256M
        requests:
          cpu: 100m
          memory: 256M
      env:
      - name: "DATA_SOURCE_URI"
        value: "localhost/postgres?sslmode=require"
      - name: "DATA_SOURCE_USER"
        value: "$(POSTGRES_USER)"
      - name: "DATA_SOURCE_PASS"
        value: "$(POSTGRES_PASSWORD)"

Ce fichier manifeste contient les champs suivants :

  • spec.teamId : préfixe des objets de cluster que vous choisissez.
  • spec.numberOfInstances : nombre total d'instances pour un cluster
  • spec.users : liste des utilisateurs dotés de droits
  • spec.databases : liste de la base de données au format dbname: ownername
  • spec.postgresql : paramètres postgres
  • spec.volume : paramètres de disque persistant
  • spec.tolerations : tolérances de modèle de pod permettant de planifier les pods du cluster sur des nœuds pool-postgres.
  • spec.nodeAffinity : nodeAffinity de modèle de pod qui indique à GKE que les pods du cluster préfèrent être programmés sur des nœuds pool-postgres.
  • spec.resources : requêtes et limites pour les pods de cluster
  • spec.sidecars : liste de conteneurs side-car, contenant postgres-exporter

Pour plus d'informations, consultez la documentation de référence sur les fichiers manifestes de cluster dans la documentation Postgres.

Créer un cluster Postgres de base

  1. Créez un cluster Postgres en utilisant la configuration de base :

    kubectl apply -n postgres -f manifests/01-basic-cluster/my-cluster.yaml

    Cette commande crée une ressource personnalisée PostgreSQL de l'opérateur Zalando avec :

    • Demandes et limites de ressources mémoire et de processeur
    • Rejets et affinités permettant de répartir les instances répliquées de pods provisionnées entre les nœuds GKE
    • Une base de données
    • Deux utilisateurs disposant des autorisations de propriétaire de base de données
    • Un utilisateur qui ne dispose d'aucune autorisation

  2. Attendez que GKE démarre les charges de travail requises :

    kubectl wait pods -l cluster-name=my-cluster  --for condition=Ready --timeout=300s -n postgres

    L'exécution de cette commande peut prendre quelques minutes.

  3. Vérifiez que GKE a créé les charges de travail Postgres :

    kubectl get pod,svc,statefulset,deploy,pdb,secret -n postgres

    Le résultat ressemble à ce qui suit :

    NAME                                    READY   STATUS  RESTARTS   AGE
pod/my-cluster-0                        1/1     Running   0         6m41s
pod/my-cluster-1                        1/1     Running   0         5m56s
pod/my-cluster-2                        1/1     Running   0         5m16s
pod/postgres-operator-db9667d4d-rgcs8   1/1     Running   0         12m

NAME                        TYPE        CLUSTER-IP  EXTERNAL-IP   PORT(S)   AGE
service/my-cluster          ClusterIP   10.52.12.109   <none>       5432/TCP   6m43s
service/my-cluster-config   ClusterIP   None        <none>      <none>  5m55s
service/my-cluster-repl     ClusterIP   10.52.6.152 <none>      5432/TCP   6m43s
service/postgres-operator   ClusterIP   10.52.8.176 <none>      8080/TCP   12m

NAME                        READY   AGE
statefulset.apps/my-cluster   3/3   6m43s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgres-operator   1/1     1           1           12m

NAME                                                MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
poddisruptionbudget.policy/postgres-my-cluster-pdb   1              N/A             0                   6m44s

NAME                                                            TYPE                DATA   AGE
secret/my-user.my-cluster.credentials.postgresql.acid.zalan.do  Opaque              2   6m45s
secret/postgres.my-cluster.credentials.postgresql.acid.zalan.do   Opaque            2   6m44s
secret/sh.helm.release.v1.postgres-operator.v1                  helm.sh/release.v1   1      12m
secret/standby.my-cluster.credentials.postgresql.acid.zalan.do  Opaque              2   6m44s
secret/zalando.my-cluster.credentials.postgresql.acid.zalan.do  Opaque              2   6m44s

L'opérateur crée les ressources suivantes :

  • Un StatefulSet Postgres, qui contrôle trois instances répliquées de pods pour Postgres
  • Un PodDisruptionBudgets, assurant au moins une instance répliquée disponible
  • Le service my-cluster, qui ne cible que l'instance répliquée principale
  • Le service my-cluster-repl, qui expose le port Postgres pour les connexions entrantes et pour la réplication entre les instances répliquées Postgres
  • Le service headless my-cluster-config, pour obtenir la liste des instances répliquées des pods Postgres en cours d'exécution
  • Des secrets avec des identifiants utilisateur pour accéder à la base de données et effectuer la réplication entre les nœuds Postgres.

S'authentifier auprès de Postgres

Vous pouvez créer des utilisateurs Postgres et leur attribuer des autorisations de base de données. Par exemple, le fichier manifeste suivant décrit une ressource personnalisée qui attribue des utilisateurs et des rôles :

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  ...
  users:
    mydatabaseowner:
    - superuser
    - createdb
    myuser: []
  databases:
    mydatabase: mydatabaseowner

Dans le fichier manifeste :

  • L'utilisateur mydatabaseowner dispose des rôles SUPERUSER et CREATEDB, qui accordent des droits d'administrateur complets (par exemple, gérer la configuration Postgres, créer des bases de données, tables et utilisateurs). Vous ne devez pas partager cet utilisateur avec des clients. Par exemple, Cloud SQL n'autorise pas les clients à accéder aux utilisateurs disposant du rôle SUPERUSER.
  • Aucun rôle n'a été attribué à l'utilisateur myuser. Ceci suit les bonnes pratiques d'utilisation de SUPERUSER pour créer des utilisateurs avec le moins de privilèges possible. Des droits précis sont accordés à myuser par mydatabaseowner. Pour des raisons de sécurité, vous ne devez partager les identifiants myuser qu'avec les applications clientes.

Stocker les mots de passe

Nous vous recommandons d'utiliser la méthode recommandée pour stocker les mots de passe scram-sha-256. Par exemple, le fichier manifeste suivant décrit une ressource personnalisée qui spécifie le chiffrement scram-sha-256 à l'aide du champ postgresql.parameters.password_encryption :

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  ...
  postgresql:
    parameters:
      password_encryption: scram-sha-256

Alterner les identifiants utilisateur

Vous pouvez effectuer une rotation des identifiants utilisateur stockés dans les secrets Kubernetes avec Zalando. Par exemple, le fichier manifeste suivant décrit une ressource personnalisée qui définit la rotation des identifiants utilisateur à l'aide du champ usersWithSecretRotation :

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  ...
  usersWithSecretRotation:
  - myuser
  - myanotheruser
  - ...

Exemple d'authentification : se connecter à Postgres

Cette section vous explique comment déployer un exemple de client Postgres et vous connecter à la base de données à l'aide du mot de passe d'un secret Kubernetes.

  1. Exécutez le pod client pour interagir avec votre cluster Postgres :

    kubectl apply -n postgres -f manifests/02-auth/client-pod.yaml

    Les identifiants des utilisateurs myuser et mydatabaseowner sont issus des secrets associés et installés en tant que variables d'environnement sur le pod.

  2. Connectez-vous au pod lorsque celui-ci est prêt :

    kubectl wait pod postgres-client --for=condition=Ready --timeout=300s -n postgres
kubectl exec -it postgres-client -n postgres -- /bin/bash

  3. Connectez-vous à Postgres et essayez de créer une table à l'aide des identifiants myuser :

    PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR ( 50 ) NOT NULL);"

    La commande doit échouer et renvoyer une erreur semblable à celle-ci :

    ERROR:  permission denied for schema public
LINE 1: CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR...

    La commande échoue, car les utilisateurs ne disposant pas de droits d'accès par défaut ne peuvent que se connecter à Postgres et répertorier les bases de données.

  4. Créez une table avec les identifiants mydatabaseowner et accordez tous les droits sur la table à myuser :

    PGPASSWORD=$OWNERPASSWORD psql \
  -h my-cluster \
  -U $OWNERUSERNAME \
  -d mydatabase \
  -c "CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR ( 50 ) NOT NULL);GRANT ALL ON test TO myuser;GRANT ALL ON SEQUENCE test_id_seq TO myuser;"

    Le résultat ressemble à ce qui suit :

    CREATE TABLE
GRANT
GRANT

  5. Insérez des données aléatoires dans la table à l'aide des identifiants myuser :

    for i in {1..10}; do
  DATA=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 13)
  PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "INSERT INTO test(randomdata) VALUES ('$DATA');"
done

    Le résultat ressemble à ce qui suit :

    INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1

  6. Récupérez les valeurs que vous avez insérées :

    PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "SELECT * FROM test;"

    Le résultat ressemble à ce qui suit :

    id |  randomdata
----+---------------
  1 | jup9HYsAjwtW4
  2 | 9rLAyBlcpLgNT
  3 | wcXSqxb5Yz75g
  4 | KoDRSrx3muD6T
  5 | b9atC7RPai7En
  6 | 20d7kC8E6Vt1V
  7 | GmgNxaWbkevGq
  8 | BkTwFWH6hWC7r
  9 | nkLXHclkaqkqy
 10 | HEebZ9Lp71Nm3
(10 rows)

  7. Quittez le shell du pod :

    exit

Comprendre comment Prometheus collecte les métriques pour votre cluster Postgres

Le schéma suivant illustre le fonctionnement de la collecte de métriques Prometheus :

Dans le schéma, un cluster privé GKE contient :

  • Un pod Postgres qui collecte des métriques sur le chemin / et le port 9187
  • Collecteurs basés sur Prometheus qui traitent les métriques à partir du pod Postgres
  • Une ressource PodMonitoring qui envoie des métriques à Cloud Monitoring

Le service Google Cloud Managed Service pour Prometheus accepte la collecte de métriques au format Prometheus. Cloud Monitoring utilise un tableau de bord intégré pour les métriques Postgres.

Zalando expose les métriques de cluster au format Prometheus en utilisant le composant postgres_exporter en tant que conteneur side-car.

  1. Créez la ressource PodMonitoring pour récupérer les métriques par labelSelector :

    kubectl apply -n postgres -f manifests/03-prometheus-metrics/pod-monitoring.yaml

  2. Dans la console Google Cloud , accédez à la page Tableau de bord des clusters GKE.

    Accéder au tableau de bord des clusters GKE

    Le tableau de bord affiche un taux d'ingestion de métriques différent de zéro.

  3. Dans la console Google Cloud , accédez à la page Tableaux de bord.

    Accéder à la page "Tableaux de bord"

  4. Ouvrez le tableau de bord "Présentation de PostgreSQL-Prometheus. Le tableau de bord indique le nombre de lignes récupérées. Le provisionnement automatique du tableau de bord peut prendre plusieurs minutes.

  5. Connectez-vous au pod client :

    kubectl exec -it postgres-client -n postgres -- /bin/bash

  6. Insérer des données aléatoires :

    for i in {1..100}; do
  DATA=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 13)
  PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "INSERT INTO test(randomdata) VALUES ('$DATA');"
done

  7. Actualisez la page. Les graphiques Lignes et Blocs sont mis à jour pour afficher l'état réel de la base de données.

  8. Quittez le shell du pod :

    exit

Effectuer un nettoyage

Supprimer le projet

    Supprimer un projet Google Cloud  :

    gcloud projects delete PROJECT_ID

Supprimer des ressources individuelles

  1. Définissez les variables d'environnement.

    export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=postgres
export REGION=us-central1

  2. Exécutez la commande terraform destroy :

    export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform  -chdir=terraform/FOLDER destroy \
  -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

    Remplacez FOLDER par gke-autopilot ou gke-standard.

    Lorsque vous y êtes invité, saisissez yes.

  3. Recherchez tous les disques non associés :

    export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")

  4. Supprimez les disques :

    for i in $disk_list; do
  disk_name=$(echo $i| cut -d'|' -f1)
  disk_zone=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
  echo "Deleting $disk_name"
  gcloud compute disks delete $disk_name --zone $disk_zone --quiet
done

  5. Supprimez le dépôt GitHub :

    rm -r ~/kubernetes-engine-samples/

Étapes suivantes

  • Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.