Implementación de una base de datos PostgreSQL de alta disponibilidad en Azure Kubernetes Service (AKS)

En este artículo, implementará una base de datos PostgreSQL de alta disponibilidad en AKS.

• Si todavía necesita crear la infraestructura necesaria para esta implementación, siga los pasos descritos en Creación de una infraestructura para implementar una base de datos postgreSQL de alta disponibilidad en AKS para configurarla y, a continuación, vuelva a este artículo.

Creación de un secreto para el usuario de la aplicación de arranque

1. Genere un secreto para validar la implementación de PostgreSQL mediante el inicio de sesión interactivo de un usuario de aplicación de arranque mediante el comando 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. Compruebe que el secreto se creó correctamente mediante el comando kubectl get.

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

Establecimiento de variables de entorno para el clúster de PostgreSQL

• Implemente un configMap para configurar el operador CNPG mediante el siguiente kubectl apply comando. Estos valores reemplazan el interruptor heredado ENABLE_AZURE_PVC_UPDATES, que ya no es necesario, y ayudan a escalonar las actualizaciones y acelerar las reconexiones de réplicas. Antes de implementar esta configuración en producción, compruebe que cualquier configuración existente DRAIN_TAINTS que confíe siga siendo compatible con el entorno de 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
  

Instalación de PodMonitors de Prometheus

Prometheus extrae datos de CNPG mediante las reglas de grabación almacenadas en el repositorio de ejemplos de CNPG en GitHub. Dado que el PodMonitor administrado por el operador está quedando obsoleto, cree y gestione usted mismo el recurso PodMonitor para adaptarlo adecuadamente a su pila de supervisión.

1. Agregue el repositorio de Helm de la comunidad de Prometheus mediante el comando helm repo add.

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

2. Actualice el repositorio de Helm de la comunidad de Prometheus e instálelo en el clúster principal mediante el comando helm upgrade con la marca --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. Cree un PodMonitor para el clúster. El equipo de CNPG está dejando de usar el PodMonitor gestionado por el operador, por lo que ahora lo gestiona directamente:

   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
   

Creación de una credencial federada

En esta sección, creará una credencial de identidad federada para la copia de seguridad de PostgreSQL para permitir que CNPG use la identidad de carga de trabajo de AKS para autenticarse en el destino de la cuenta de almacenamiento para las copias de seguridad. El operador CNPG crea una cuenta de servicio de Kubernetes con el mismo nombre que el clúster denominado usado en el manifiesto de implementación del clúster CNPG.

1. Obtenga la dirección URL del emisor de OIDC del clúster mediante el comando 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. Cree una credencial de identidad federada mediante el comando 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
   

Implementación de un clúster de PostgreSQL de alta disponibilidad

En esta sección, implementará un clúster de PostgreSQL de alta disponibilidad mediante la definición de recursos personalizados (CRD) del clúster CNPG.

Parámetros de CRD de clúster

En la tabla siguiente se describen las propiedades clave establecidas en el manifiesto de implementación de YAML para el CRD de clúster:

Para aislar aún más las cargas de trabajo de PostgreSQL, puede agregar un taint (por ejemplo, node-role.kubernetes.io/postgres=:NoSchedule) a los nodos del plano de datos y reemplazar el ejemplo nodeSelector/tolerations por los valores recomendados por CloudNativePG. Si adopta este enfoque, etiquete los nodos en consecuencia y confirme que las directivas de escalador automático de AKS se alinean con la topología.

Parámetros de rendimiento de PostgreSQL

El rendimiento de PostgreSQL depende en gran medida de los recursos y la carga de trabajo subyacentes del clúster. En la tabla siguiente se proporcionan instrucciones de línea base para un clúster de tres nodos que se ejecutan en nodos estándar D4s v3 (memoria de 16 GiB). Considere estos valores como punto de partida y ajústelos cuando comprenda su perfil de carga de trabajo.

Implementación de PostgreSQL

2. Compruebe que el clúster de PostgreSQL principal se creó correctamente mediante el comando kubectl get. La CRD del clúster CNPG especificó tres instancias, que se pueden validar mediante la visualización de pods en ejecución una vez que cada instancia se abre y se une para la replicación. Tenga paciencia, ya que puede tardar algún tiempo en conectarse a las tres instancias y unirse al clúster.

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

   Salida de ejemplo

   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]  

Validar que Prometheus PodMonitor se está ejecutando

El PodMonitor creado manualmente vincula la configuración de extracción kube-prometheus-stack a los pods CNPG que implementó anteriormente.

Valide que PodMonitor se está ejecutando con el comando kubectl get.

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

Salida de ejemplo

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 usa Azure Monitor para Managed Prometheus, debe agregar otro monitor de pod mediante el nombre del grupo personalizado. Prometheus administrado no recoge las definiciones de recursos personalizados (CRD) de la comunidad de Prometheus. Aparte del nombre del grupo, los CRD son los mismos. Ese diseño permite que los monitores de pod para Prometheus administrado se ejecuten junto con monitores de pod que usan la CRD de la comunidad. Si no usa Prometheus administrado, puede omitir esta sección. Cree un nuevo monitor 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

Compruebe que se crea el monitor de pods (tenga en cuenta la diferencia en el nombre del grupo).

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

Opción A: área de trabajo de Azure Monitor

Después de implementar el clúster de Postgres y el monitor de pods, puede ver las métricas mediante Azure Portal en un área de trabajo de Azure Monitor.

Opción B: Grafana administrada

Como alternativa, después de implementar los monitores de pod y clúster de Postgres, puede crear un panel de métricas en la instancia de Grafana administrada creada por el script de implementación para visualizar las métricas exportadas al área de trabajo de Azure Monitor. Puede acceder a Grafana administrada a través de Azure Portal. Vaya a la instancia de Grafana administrada creada por el script de implementación y seleccione el enlace endpoint como se indica aquí:

Al seleccionar el vínculo de endpoint, se abre una nueva ventana del navegador donde puede crear paneles en la instancia administrada de Grafana. Siguiendo las instrucciones para configurar un origen de datos de Azure Monitor, puede agregar visualizaciones para crear un panel de métricas desde el clúster de Postgres. Después de configurar la conexión de origen de datos, en el menú principal, seleccione la opción Orígenes de datos. Debería ver un conjunto de opciones de origen de datos para la conexión del origen de datos, como se muestra aquí:

En la opción Managed Prometheus (Prometheus administrado), seleccione la opción para crear un panel para abrir el editor del panel. Una vez que se abra la ventana del editor, seleccione la opción Agregar visualización y, después, seleccione la opción Managed Prometheus para examinar las métricas desde el clúster de Postgres. Después de seleccionar la métrica que desea visualizar, seleccione el botón Ejecutar consultas para capturar los datos de la visualización, como se muestra aquí:

Seleccione el icono Guardar para agregar el panel al tablero. Puede agregar otros paneles seleccionando el botón Agregar en el editor del panel y repitiendo este proceso para visualizar otras métricas. Al agregar las visualizaciones de métricas, debe tener algo similar al siguiente:

Seleccione el icono Guardar para guardar el panel.

Pasos siguientes

Contributors

Microsoft se encarga del mantenimiento de este artículo. Los siguientes colaboradores lo escribieron originalmente:

• Ken Kilty | TPM de entidad de seguridad
• Russell de Pina | TPM de entidad de seguridad
• Adrian Joian | Ingeniero de clientes sénior
• Jenny Hayes | Desarrollador de contenido sénior
• Carol Smith | Desarrollador de contenido sénior
• Erin Schaffer | Desarrollador de contenido 2
• Adam Fabric | Ingeniero de clientes 2

Reconocimiento

Esta documentación se desarrolló conjuntamente con EnterpriseDB, los mantenedores del operador CloudNativePG. Agradecemos a Gabriele Bartolini por revisar los borradores anteriores de este documento y ofrecer mejoras técnicas.