Déployer une base de données PostgreSQL hautement disponible sur Azure Kubernetes Service (AKS)

Dans cet article, vous déployez une base de données PostgreSQL à haute disponibilité sur AKS.

• Si vous avez toujours besoin de créer l’infrastructure requise pour ce déploiement, suivez les étapes décrites dans Créer une infrastructure pour déployer une base de données PostgreSQL hautement disponible sur AKS à configurer, puis revenez à cet article.

Créer un secret pour un utilisateur d’application d’amorçage

1. Générez un secret pour valider le déploiement PostgreSQL par connexion interactive pour un utilisateur d’application d’amorçage en utilisant la commande kubectl create secret.

PG_DATABASE_APPUSER_SECRET=$(echo -n | openssl rand -base64 16)

kubectl create secret generic db-user-pass \
    --from-literal=username=app \
     --from-literal=password="${PG_DATABASE_APPUSER_SECRET}" \
     --namespace $PG_NAMESPACE \
     --context $AKS_PRIMARY_CLUSTER_NAME

1. Vérifiez que le secret a été créé avec succès en utilisant la commande kubectl get.

   kubectl get secret db-user-pass --namespace $PG_NAMESPACE --context $AKS_PRIMARY_CLUSTER_NAME
   

Définir des variables d’environnement pour le cluster PostgreSQL

• Déployez un ConfigMap pour configurer l’opérateur CNPG à l’aide de la commande suivante kubectl apply . Ces valeurs remplacent la bascule ENABLE_AZURE_PVC_UPDATES héritée qui n’est plus nécessaire et permettent d’échelonner les mises à niveau et d’accélérer la reconnexion des réplicas. Avant de déployer cette configuration en production, vérifiez que tous les paramètres existants sur lesquels DRAIN_TAINTS vous vous appuyez restent compatibles avec votre environnement Azure.

  cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -f -
  apiVersion: v1
  kind: ConfigMap
  metadata:
      name: cnpg-controller-manager-config
  data:
      CLUSTERS_ROLLOUT_DELAY: '120'
      STANDBY_TCP_USER_TIMEOUT: '10'
  EOF
  

Installer Prometheus PodMonitors

Prometheus interroge CNPG à l’aide des règles d’enregistrement stockées dans le dépôt GitHub de CNPG. Étant donné que le PodMonitor, géré par l’opérateur, est déconseillé, créez et gérez la ressource PodMonitor vous-même afin que vous puissiez l’adapter à votre pile de surveillance.

1. Ajoutez le dépôt Helm de la communauté Prometheus en utilisant la commande helm repo add.

   helm repo add prometheus-community \
       https://prometheus-community.github.io/helm-charts
   

2. Mettez à niveau le référentiel Helm de la communauté Prometheus et installez-le sur le cluster principal en utilisant la commande helm upgrade avec l’indicateur --install.

   helm upgrade --install \
       --namespace $PG_NAMESPACE \
       -f https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/docs/src/samples/monitoring/kube-stack-config.yaml \
       prometheus-community \
       prometheus-community/kube-prometheus-stack \
       --kube-context=$AKS_PRIMARY_CLUSTER_NAME
   

3. Créez un PodMonitor pour le cluster. L’équipe CNPG met en désuétude le PodMonitor géré par l’opérateur, vous devez donc maintenant le gérer directement :

   cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
   apiVersion: monitoring.coreos.com/v1
   kind: PodMonitor
   metadata:
     name: $PG_PRIMARY_CLUSTER_NAME
     namespace: ${PG_NAMESPACE}
     labels:
       cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
   spec:
     selector:
       matchLabels:
         cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
     podMetricsEndpoints:
       - port: metrics
   EOF
   

Créer des informations d’identification fédérées

Dans cette section, vous créez un jeu d’identifiants d’identité fédérée pour la sauvegarde PostgreSQL, pour permettre à CNPG d’utiliser l’identité de charge de travail AKS pour s’authentifier auprès de la destination du compte de stockage des sauvegardes. L’opérateur CNPG crée un compte de service Kubernetes portant le même nom que le cluster nommé utilisé dans le manifeste de déploiement du cluster CNPG.

1. Obtenez l’URL de l’émetteur OIDC du cluster en utilisant la commande az aks show.

   export AKS_PRIMARY_CLUSTER_OIDC_ISSUER="$(az aks show \
       --name $AKS_PRIMARY_CLUSTER_NAME \
       --resource-group $RESOURCE_GROUP_NAME \
       --query "oidcIssuerProfile.issuerUrl" \
       --output tsv)"
   

2. Créez des informations d’identification d’une identité fédérée à l’aide de la commande az identity federated-credential create.

   az identity federated-credential create \
       --name $AKS_PRIMARY_CLUSTER_FED_CREDENTIAL_NAME \
       --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}" \
       --audience api://AzureADTokenExchange
   

Déployer un cluster PostgreSQL à haute disponibilité

Dans cette section, vous déployez un cluster PostgreSQL à haute disponibilité en utilisant la définition de ressource personnalisée (CRD) du cluster CNPG.

Paramètres CRD du cluster

Le tableau suivant présente les propriétés clés définies dans le manifeste de déploiement YAML pour la CRD de cluster :

Pour isoler davantage les charges de travail PostgreSQL, vous pouvez ajouter une teinte (par exemple node-role.kubernetes.io/postgres=:NoSchedule) à vos nœuds de plan de données et remplacer l’exemple nodeSelector/tolerations par les valeurs recommandées par CloudNativePG. Si vous effectuez cette approche, étiquetez les nœuds en conséquence et confirmez que les stratégies de mise à l’échelle automatique AKS s’alignent sur votre topologie.

Paramètres de performances PostgreSQL

Les performances postgreSQL dépendent fortement des ressources et de la charge de travail sous-jacentes de votre cluster. Le tableau suivant fournit des instructions de base pour un cluster à trois nœuds s’exécutant sur des nœuds Standard D4s v3 (mémoire de 16 Gio). Traitez ces valeurs comme un point de départ et ajustez-les une fois que vous comprenez votre profil de charge de travail :

Déploiement de PostgreSQL

2. Vérifiez que le cluster PostgreSQL principal a été correctement créé en utilisant la commande kubectl get. La CRD de cluster CNPG a spécifié trois instances, ce qui peut être validé en consultant les pods en cours d’exécution une fois que chaque instance est générée et jointe pour la réplication. Soyez patient, car un certain temps peut être nécessaire pour que les trois instances soient en ligne et rejoignent le cluster.

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

   Exemple de sortie

   NAME                         READY   STATUS    RESTARTS   AGE
   pg-primary-cnpg-r8c7unrw-1   1/1     Running   0          4m25s
   pg-primary-cnpg-r8c7unrw-2   1/1     Running   0          3m33s
   pg-primary-cnpg-r8c7unrw-3   1/1     Running   0          2m49s
   

kubectl cnpg destroy [cnpg-cluster-name] [instance-number]  

Valider que Prometheus PodMonitor est en cours d’exécution

PodMonitor créé manuellement lie la configuration de scraper kube-prometheus-stack aux pods CNPG déployés précédemment.

Vérifiez que PodMonitor est en cours d’exécution en utilisant la commande kubectl get.

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.monitoring.coreos.com \
    $PG_PRIMARY_CLUSTER_NAME \
    --output yaml

Exemple de sortie

kind: PodMonitor
metadata:
  labels:
    cnpg.io/cluster: pg-primary-cnpg-r8c7unrw
  name: pg-primary-cnpg-r8c7unrw
  namespace: cnpg-database
spec:
  podMetricsEndpoints:
  - port: metrics
  selector:
    matchLabels:
      cnpg.io/cluster: pg-primary-cnpg-r8c7unrw

Si vous utilisez Azure Monitor pour Prometheus managé, vous devez ajouter un autre moniteur de pod à l’aide du nom de groupe personnalisé. Managed Prometheus ne récupère pas les définitions de ressources personnalisées (CRD) de la communauté Prometheus. Outre le nom du groupe, les CRD sont identiques. Cette conception permet aux moniteurs de pods pour Managed Prometheus de fonctionner en parallèle des moniteurs de pods utilisant le CRD de la communauté. Si vous n’utilisez pas Managed Prometheus, vous pouvez ignorer cette section. Créez un moniteur de pod :

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
apiVersion: azmonitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-cluster-metrics-managed-prometheus
  namespace: ${PG_NAMESPACE}
  labels:
    azure.workload.identity/use: "true"
    cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
spec:
  selector:
    matchLabels:
      azure.workload.identity/use: "true"
      cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
  podMetricsEndpoints:
    - port: metrics
EOF

Vérifiez que le moniteur de pod est créé (notez la différence dans le nom de groupe).

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.azmonitoring.coreos.com \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME \
    -o yaml

Option A - Espace de travail Azure Monitor

Après avoir déployé le cluster Postgres et le moniteur de pod, vous pouvez afficher les métriques à l’aide du portail Azure dans un espace de travail Azure Monitor.

Option B : Managed Grafana

Vous pouvez, après avoir déployé le cluster Postgres et les moniteurs de pod, créer un tableau de bord des indicateurs sur l’instance Managed Grafana créée par le script de déploiement pour visualiser les métriques exportées vers l’espace de travail Azure Monitor. Vous pouvez accéder à Managed Grafana via le Portail Azure. Accédez à l’instance Managed Grafana créée par le script de déploiement et sélectionnez le lien Point de terminaison, comme indiqué ici :

La sélection du lien Point de terminaison ouvre une nouvelle fenêtre de navigateur dans laquelle vous pouvez créer des tableaux de bord sur l’instance Managed Grafana. En suivant les instructions pour configurer une source de données Azure Monitor, vous pouvez ensuite ajouter des visualisations pour créer un tableau de bord de métriques depuis le cluster Postgres. Après avoir configuré la connexion de source de données, dans le menu principal, sélectionnez l’option Sources de données. Vous devez voir un ensemble d’options de source de données pour la connexion à la source de données, comme indiqué ici :

Dans l’option Prometheus gérée, sélectionnez l’option permettant de générer un tableau de bord pour ouvrir l’éditeur de tableau de bord. Une fois la fenêtre de l’éditeur ouverte, sélectionnez l’option Ajouter une visualisation, puis sélectionnez l’option Prometheus gérée pour parcourir les métriques à partir du cluster Postgres. Après avoir sélectionné la métrique que vous souhaitez visualiser, sélectionnez le bouton Exécuter des requêtes pour extraire les données de la visualisation, comme indiqué ici :

Sélectionnez l’icône Enregistrer pour ajouter le panneau à votre tableau de bord. Vous pouvez ajouter d’autres panneaux en sélectionnant le bouton Ajouter dans l’éditeur de tableau de bord et en répétant ce processus pour visualiser d’autres métriques. L’ajout des visualisations de métriques doit ressembler à ceci :

Sélectionnez l’icône Enregistrer pour enregistrer votre tableau de bord.

Étapes suivantes

Contributors

La gestion de cet article est sous la responsabilité de Microsoft. Les contributeurs suivants ont rédigé sa version d’origine :

• 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.