Partager via

Valider et tester un déploiement de base de données PostgreSQL sur Azure Kubernetes Service (AKS)

Dans cet article, vous effectuez différentes étapes de test et de validation sur une base de données PostgreSQL déployée sur AKS. Cela inclut la vérification du déploiement, la connexion à la base de données et le test des scénarios de basculement.

Important

Les logiciels open source sont mentionnés dans la documentation et les exemples AKS. Les logiciels que vous déployez sont exclus des contrats de niveau de service AKS, de la garantie limitée et du support Azure. Quand vous utilisez une technologie open source avec AKS, consultez les options de support disponibles auprès des communautés et responsables de projet respectifs pour élaborer un plan.

Microsoft assume la responsabilité de la génération des packages open source que nous déployons sur AKS. Cette responsabilité comprend la maîtrise complète des processus de génération, d’analyse, de signature et de validation ainsi que l’application de correctifs logiciels et le contrôle des fichiers binaires présents dans les images conteneur. Pour plus d’informations, consultez Gestion des vulnérabilités pour AKS et Couverture du support AKS.

Inspecter le cluster PostgreSQL déployé

Vérifiez que PostgreSQL est réparti sur plusieurs zones de disponibilité en récupérant les détails du nœud AKS en utilisant la commande kubectl get.

kubectl get nodes \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    --output json | jq '.items[] | {node: .metadata.name, zone: .metadata.labels."failure-domain.beta.kubernetes.io/zone"}'

Votre sortie doit ressembler à l’exemple de sortie suivant avec la zone de disponibilité indiquée pour chaque nœud :

{
    "node": "aks-postgres-15810965-vmss000000",
    "zone": "westus3-1"
}
{
    "node": "aks-postgres-15810965-vmss000001",
    "zone": "westus3-2"
}
{
    "node": "aks-postgres-15810965-vmss000002",
    "zone": "westus3-3"
}
{
    "node": "aks-systempool-26112968-vmss000000",
    "zone": "westus3-1"
}
{
    "node": "aks-systempool-26112968-vmss000001",
    "zone": "westus3-2"
}

Se connecter à PostgreSQL et créer un exemple de jeu de données

Dans cette section, vous créez une table et insérez des données dans la base de données d’application créée dans la CRD du cluster CNPG que vous avez déployé précédemment. Vous utilisez ces données pour valider les opérations de sauvegarde et de restauration pour le cluster PostgreSQL.

  • Créez une table et insérez des données dans la base de données d’application en utilisant les commandes suivantes :

    kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    -- Create a small dataset
CREATE TABLE datasample (id INTEGER, name VARCHAR(255));
INSERT INTO datasample (id, name) VALUES (1, 'John');
INSERT INTO datasample (id, name) VALUES (2, 'Jane');
INSERT INTO datasample (id, name) VALUES (3, 'Alice');
SELECT COUNT(*) FROM datasample;

    Tapez \q pour quitter psql lorsque vous avez terminé.

    Votre sortie doit ressembler à l’exemple suivant :

    CREATE TABLE
INSERT 0 1
INSERT 0 1
INSERT 0 1
count
-------
    3
(1 row)

Se connecter à des réplicas en lecture seule PostgreSQL

  • Connectez-vous aux réplicas en lecture seule PostgreSQL et validez l’exemple de jeu de données en utilisant les commandes suivantes :

    kubectl cnpg psql --replica $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    SELECT pg_is_in_recovery();

    Exemple de sortie

    pg_is_in_recovery
-------------------
t
(1 row)

    SELECT COUNT(*) FROM datasample;

    Exemple de sortie

    count
-------
  3
(1 row)

Configurer des sauvegardes PostgreSQL à la demande et planifiées en utilisant Barman

Remarque

CloudNativePG est censé déprécier la prise en charge native de Barman Cloud en faveur du plug-in Barman Cloud dans une prochaine version 1.29. Les étapes décrites dans ce guide continuent de fonctionner aujourd’hui, mais prévoyez de migrer vers le plug-in une fois qu’il se stabilise.

  1. Vérifiez que le cluster PostgreSQL peut accéder au compte de stockage Azure spécifié dans la CRD du cluster CNPG et que Working WAL archiving indique OK en utilisant la commande suivante :

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

    Exemple de sortie

    Continuous Backup status
First Point of Recoverability:  Not Available
Working WAL archiving:          OK
WALs waiting to be archived:    0
Last Archived WAL:              00000001000000000000000A   @   2024-07-09T17:18:13.982859Z
Last Failed WAL:                -

  2. Déployez une sauvegarde à la demande sur Stockage Azure, qui utilise l’intégration d’identité de charge de travail AKS, en utilisant le fichier YAML avec la commande kubectl apply.

    export BACKUP_ONDEMAND_NAME="on-demand-backup-1"

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: $BACKUP_ONDEMAND_NAME
spec:
  method: barmanObjectStore
  cluster:
    name: $PG_PRIMARY_CLUSTER_NAME
EOF

  3. Validez l’état de la sauvegarde à la demande en utilisant la commande kubectl describe.

    kubectl describe backup $BACKUP_ONDEMAND_NAME \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

    Exemple de sortie

    Type    Reason     Age   From                   Message
 ----    ------     ----  ----                   -------
Normal  Starting   6s    cloudnative-pg-backup  Starting backup for cluster pg-primary-cnpg-r8c7unrw
Normal  Starting   5s    instance-manager       Backup started
Normal  Completed  1s    instance-manager       Backup completed

  4. Vérifiez que le cluster a un premier point de récupération en utilisant la commande suivante :

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

    Exemple de sortie

    Continuous Backup status
First Point of Recoverability:  2024-06-05T13:47:18Z
Working WAL archiving:          OK

  5. Configurez une sauvegarde planifiée toutes les heures à 15 minutes après l’heure en utilisant le fichier YAML avec la commande kubectl apply.

    export BACKUP_SCHEDULED_NAME="scheduled-backup-1"

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: $BACKUP_SCHEDULED_NAME
spec:
  # Backup once per hour
  schedule: "0 15 * ? * *"
  backupOwnerReference: self
  cluster:
    name: $PG_PRIMARY_CLUSTER_NAME
EOF

  6. Validez l’état de la sauvegarde planifiée en utilisant la commande kubectl describe.

    kubectl describe scheduledbackup $BACKUP_SCHEDULED_NAME \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

  7. Affichez les fichiers de sauvegarde stockés sur le Stockage Blob Azure pour le cluster principal en utilisant la commande az storage blob list.

    az storage blob list \
    --account-name $PG_PRIMARY_STORAGE_ACCOUNT_NAME \
    --container-name backups \
    --query "[*].name" \
    --only-show-errors

    Votre sortie doit ressembler à l’exemple de sortie suivant, validant la réussite de la sauvegarde :

    [
  "pg-primary-cnpg-r8c7unrw/base/20240605T134715/backup.info",
  "pg-primary-cnpg-r8c7unrw/base/20240605T134715/data.tar",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000001",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000002",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000003",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000003.00000028.backup",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000004",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000005",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000005.00000028.backup",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000006",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000007",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000008",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000009"
]

Restaurer la sauvegarde à la demande sur un nouveau cluster PostgreSQL

Dans cette section, vous restaurez la sauvegarde à la demande que vous avez créée précédemment à l’aide de l’opérateur CNPG dans une nouvelle instance en utilisant la CRD de cluster d’amorçage. Un cluster d’instance unique est utilisé par souci de simplicité. N’oubliez pas que l’identité de charge de travail AKS (via CNPG inheritFromAzureAD) accède aux fichiers de sauvegarde et que le nom du cluster de récupération est utilisé pour générer un nouveau compte de service Kubernetes spécifique au cluster de récupération.

Vous créez également un deuxième jeu d’identifiants fédérés pour mapper le nouveau compte de service de cluster de récupération à l’UAMI existant disposant d’un accès « Contributeur aux données blob de stockage » aux fichiers de sauvegarde sur le stockage d’objets blob.

  1. Créez un second jeu d’identifiants d’identité fédérée en utilisant la commande az identity federated-credential create.

    export PG_PRIMARY_CLUSTER_NAME_RECOVERED="$PG_PRIMARY_CLUSTER_NAME-recovered-db"

az identity federated-credential create \
    --name $PG_PRIMARY_CLUSTER_NAME_RECOVERED \
    --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --issuer "${AKS_PRIMARY_CLUSTER_OIDC_ISSUER}" \
    --subject system:serviceaccount:"${PG_NAMESPACE}":"${PG_PRIMARY_CLUSTER_NAME_RECOVERED}" \
    --audience api://AzureADTokenExchange

  2. Restaurez la sauvegarde à la demande en utilisant la CRD de cluster avec la commande kubectl apply.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: $PG_PRIMARY_CLUSTER_NAME_RECOVERED
spec:

  inheritedMetadata:
    annotations:
      service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
    labels:
      azure.workload.identity/use: "true"

  instances: 1

  affinity:
    nodeSelector:
      workload: postgres

  # Point to cluster backup created earlier and stored on Azure Blob Storage
  bootstrap:
    recovery:
      source: clusterBackup

  storage:
    size: 2Gi
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 2Gi
      storageClassName: managed-csi-premium
      volumeMode: Filesystem

  walStorage:
    size: 2Gi
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 2Gi
      storageClassName: managed-csi-premium
      volumeMode: Filesystem

  serviceAccountTemplate:
    metadata:
      annotations:
        azure.workload.identity/client-id: "$AKS_UAMI_WORKLOAD_CLIENTID"
      labels:
        azure.workload.identity/use: "true"

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: https://${PG_PRIMARY_STORAGE_ACCOUNT_NAME}.blob.core.windows.net/backups
        serverName: $PG_PRIMARY_CLUSTER_NAME
        azureCredentials:
          inheritFromAzureAD: true
        wal:
          maxParallel: 8
EOF

  3. Connectez-vous à l’instance récupérée, puis vérifiez que le jeu de données créé sur le cluster d’origine où la sauvegarde complète a été effectuée est présent en utilisant la commande suivante :

    kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME_RECOVERED --namespace $PG_NAMESPACE

    SELECT COUNT(*) FROM datasample;

    Exemple de sortie

     count
-------
     3
(1 row)

Type \q to exit psql

  4. Supprimez le cluster récupéré en utilisant la commande suivante :

    kubectl cnpg destroy $PG_PRIMARY_CLUSTER_NAME_RECOVERED 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

  5. Supprimez le jeu d’identifiants d’identité fédérée en utilisant la commande az identity federated-credential delete.

    az identity federated-credential delete \
    --name $PG_PRIMARY_CLUSTER_NAME_RECOVERED \
    --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --yes

Exposer le cluster PostgreSQL en utilisant un équilibreur de charge public

Dans cette section, vous configurez l’infrastructure nécessaire pour exposer publiquement les points de terminaison en lecture-écriture et en lecture seule PostgreSQL avec des restrictions de source IP à l’adresse IP publique de votre station de travail cliente.

Vous récupérez également les points de terminaison suivants depuis le service IP du cluster :

  • Un point de terminaison en lecture-écriture principal qui se termine par *-rw.
  • Zéro à N (en fonction du nombre de réplicas) points de terminaison en lecture seule qui se terminent par *-ro.
  • Un point de terminaison de réplication qui se termine par *-r.

  1. Obtenez les détails du service IP du cluster en utilisant la commande kubectl get.

    kubectl get services \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME

    Exemple de sortie

    NAME                          TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
pg-primary-cnpg-sryti1qf-r    ClusterIP   10.0.193.27    <none>        5432/TCP   3h57m
pg-primary-cnpg-sryti1qf-ro   ClusterIP   10.0.237.19    <none>        5432/TCP   3h57m
pg-primary-cnpg-sryti1qf-rw   ClusterIP   10.0.244.125   <none>        5432/TCP   3h57m

    Remarque

    Il existe trois services : namespace/cluster-name-ro mappé au port 5433, namespace/cluster-name-rw et namespace/cluster-name-r mappé au port 5433. Il est important d’éviter d’utiliser le même port que le nœud de lecture/écriture du cluster de base de données PostgreSQL. Si vous voulez que les applications accèdent uniquement au réplica en lecture seule du cluster de base de données PostgreSQL, dirigez-les vers le port 5433. Le service final est généralement utilisé pour les sauvegardes de données, mais peut également fonctionner en tant que nœud en lecture seule.

  2. Obtenez les détails du service en utilisant la commande kubectl get.

    export PG_PRIMARY_CLUSTER_RW_SERVICE=$(kubectl get services \
    --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    -l "cnpg.io/cluster" \
    --output json | jq -r '.items[] | select(.metadata.name | endswith("-rw")) | .metadata.name')

echo $PG_PRIMARY_CLUSTER_RW_SERVICE

export PG_PRIMARY_CLUSTER_RO_SERVICE=$(kubectl get services \
    --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    -l "cnpg.io/cluster" \
    --output json | jq -r '.items[] | select(.metadata.name | endswith("-ro")) | .metadata.name')

echo $PG_PRIMARY_CLUSTER_RO_SERVICE

  3. Configurer le service d’équilibreur de charge avec les fichiers YAML suivants en utilisant la commande kubectl apply.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: $AKS_PRIMARY_CLUSTER_NODERG_NAME
    service.beta.kubernetes.io/azure-pip-name: $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME
    service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
  name: cnpg-cluster-load-balancer-rw
  namespace: "${PG_NAMESPACE}"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 5432
    targetPort: 5432
  selector:
    cnpg.io/instanceRole: primary
    cnpg.io/podRole: instance
  loadBalancerSourceRanges:
  - "$MY_PUBLIC_CLIENT_IP/32"
EOF

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: $AKS_PRIMARY_CLUSTER_NODERG_NAME
    service.beta.kubernetes.io/azure-pip-name: $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME
    service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
  name: cnpg-cluster-load-balancer-ro
  namespace: "${PG_NAMESPACE}"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 5433
    targetPort: 5432
  selector:
    cnpg.io/instanceRole: replica
    cnpg.io/podRole: instance
  loadBalancerSourceRanges:
  - "$MY_PUBLIC_CLIENT_IP/32"
EOF

  4. Obtenez les détails du service en utilisant la commande kubectl describe.

    kubectl describe service cnpg-cluster-load-balancer-rw \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

kubectl describe service cnpg-cluster-load-balancer-ro \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

export AKS_PRIMARY_CLUSTER_ALB_DNSNAME="$(az network public-ip show \
    --resource-group $AKS_PRIMARY_CLUSTER_NODERG_NAME \
    --name $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME \
    --query "dnsSettings.fqdn" --output tsv)"

echo $AKS_PRIMARY_CLUSTER_ALB_DNSNAME

Valider les points de terminaison PostgreSQL publics

Dans cette section, vous vérifiez que l’Azure Load Balancer est correctement configuré en utilisant l’adresse IP statique que vous avez créée précédemment et achemine les connexions aux réplicas en lecture-écriture et en lecture seule primaires, et utilisez l’interface CLI psql pour vous connecter aux deux.

N’oubliez pas que le point de terminaison principal en lecture-écriture est mappé au port TCP 5432 et que les points de terminaison de réplica en lecture seule sont mappés au port 5433, pour autoriser le même nom DNS PostgreSQL à utiliser pour les lecteurs et les enregistreurs.

Remarque

Vous avez besoin de la valeur du mot de passe utilisateur de l’application pour l’authentification de base PostgreSQL qui a été générée précédemment et stockée dans la variable d’environnement $PG_DATABASE_APPUSER_SECRET.

  • Valider les points de terminaison PostgreSQL publics en utilisant les commandes suivantes psql :

    echo "Public endpoint for PostgreSQL cluster: $AKS_PRIMARY_CLUSTER_ALB_DNSNAME"

# Query the primary, pg_is_in_recovery = false

psql -h $AKS_PRIMARY_CLUSTER_ALB_DNSNAME \
    -p 5432 -U app -d appdb -W -c "SELECT pg_is_in_recovery();"

    Exemple de sortie

    pg_is_in_recovery
-------------------
 f
(1 row)

    echo "Query a replica, pg_is_in_recovery = true"

psql -h $AKS_PRIMARY_CLUSTER_ALB_DNSNAME \
    -p 5433 -U app -d appdb -W -c "SELECT pg_is_in_recovery();"

    Exemple de sortie

    # Example output

pg_is_in_recovery
-------------------
t
(1 row)

    Lorsqu’elle est correctement connectée au point de terminaison en lecture-écriture principal, la fonction PostgreSQL retourne f pour false, indiquant que la connexion actuelle est accessible en écriture.

    Lorsqu’elle est connectée à un réplica, la fonction retourne t pour true, indiquant que la base de données est en cours de récupération et en lecture seule.

Simuler un basculement non planifié

Dans cette section, vous déclenchez une défaillance soudaine en supprimant le pod exécutant le serveur principal, ce qui simule un blocage soudain ou une perte de connectivité réseau sur le nœud hébergeant le serveur principal PostgreSQL.

  1. Vérifiez l’état des instances de pod en cours d’exécution en utilisant la commande suivante :

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    Exemple de sortie

    Name                        Current LSN Rep role        Status  Node
--------------------------- ----------- --------        ------- -----------
pg-primary-cnpg-sryti1qf-1  0/9000060   Primary         OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-2  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

  2. Supprimez le pod principal en utilisant la commande kubectl delete.

    PRIMARY_POD=$(kubectl get pod \
    --namespace $PG_NAMESPACE \
    --no-headers \
    -o custom-columns=":metadata.name" \
    -l role=primary)

kubectl delete pod $PRIMARY_POD --grace-period=1 --namespace $PG_NAMESPACE

  3. Vérifiez que l’instance de pod pg-primary-cnpg-sryti1qf-2 est désormais la principale en utilisant la commande suivante :

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    Exemple de sortie

    pg-primary-cnpg-sryti1qf-2  0/9000060   Primary         OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-1  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

  4. Réinitialisez l’instance de pod pg-primary-cnpg-sryti1qf-1 en tant que principale en utilisant la commande suivante :

    kubectl cnpg promote $PG_PRIMARY_CLUSTER_NAME 1 --namespace $PG_NAMESPACE

  5. Vérifiez que les instances de pod sont retournées à leur état d’origine avant le test de basculement non planifié en utilisant la commande suivante :

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    Exemple de sortie

    Name                        Current LSN Rep role        Status  Node
--------------------------- ----------- --------        ------- -----------
pg-primary-cnpg-sryti1qf-1  0/9000060   Primary         OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-2  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

Nettoyer les ressources

  • Une fois que vous avez terminé d’examiner votre déploiement, supprimez toutes les ressources que vous avez créées dans ce guide en utilisant la commande az group delete.

    az group delete --resource-group $RESOURCE_GROUP_NAME --no-wait --yes

Étapes suivantes

Dans ce guide pratique, vous avez appris à effectuer les opérations suivantes :

  • Utiliser Azure CLI pour créer un cluster AKS multizone.
  • Déployer un cluster et une base de données PostgreSQL à haute disponibilité en utilisant l’opérateur CNPG.
  • Configurer la supervision pour PostgreSQL en utilisant Prometheus et Grafana.
  • Déployer un exemple de jeu de données sur la base de données PostgreSQL.
  • Simuler une interruption de cluster et un basculement de réplica PostgreSQL.
  • Effectuer une sauvegarde et une restauration de la base de données PostgreSQL.

Pour en savoir plus sur la façon dont vous pouvez utiliser AKS pour vos charges de travail, consultez Qu’est-ce qu’Azure Kubernetes Service (AKS) ? Pour en savoir plus sur Azure Database pour PostgreSQL, consultez Présentation d’Azure Database pour PostgreSQL

Contributeurs

Microsoft gère cet article. Il a été écrit initialement par les contributeurs suivants.

  • Ken Kitty | Responsable de programme technique en chef
  • Russell de Pina | Responsable de programme technique en chef
  • Adrian Joian | Ingénieur client senior
  • Jenny Hayes | Développeuse de contenu confirmée
  • Carol Smith | Développeuse de contenu confirmée
  • Erin Schaffer | Développeuse de contenu 2
  • Adam Sharif | Ingénieur client 2

Accusé de réception

Cette documentation a été développée conjointement avec EnterpriseDB, les mainteneurs de l’opérateur CloudNativePG. Nous remercions Gabriele Bartolini d’avoir examiné les brouillons précédents de ce document et d’offrir des améliorations techniques.

  • Last updated on