Patrones de actualización de cargas de trabajo con estado para Azure Kubernetes Service (AKS)

Use estos patrones para coordinar la disponibilidad de la base de datos con una actualización gradual del grupo de nodos de Azure Kubernetes Service (AKS).

Los procedimientos de este artículo son marcos de planificación, no garantías de disponibilidad ni durabilidad de datos. El resultado depende de la topología de la base de datos, el modo de replicación, el almacenamiento, el operador, la configuración de interrupción, el comportamiento de reintento del cliente y la carga de trabajo. Ensaye el procedimiento completo en un entorno representativo y mida si cumple el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO).

Patrones de actualización de base de datos descritos en este artículo

En este artículo se proporcionan patrones de actualización específicos de la base de datos para clústeres de AKS con cargas de trabajo con estado, entre las que se incluyen:

• Conmutación controlada de PostgreSQL.
• Actualización gradual de la réplica del clúster de Redis.
• Actualización gradual de un conjunto de réplicas de MongoDB, primero las secundarias.
• Listas de comprobación de actualización de emergencia para respuestas de seguridad.
• Planeamiento de validación y reversión.

A diferencia de una actualización estándar del grupo de nodos de AKS, estos patrones coordinan las comprobaciones de replicación de bases de datos y los cambios de rol con el reemplazo de nodos de Kubernetes. Los administradores de base de datos y AKS pueden usar estos patrones. Use la operación de cambio o actualización documentada para el operador de base de datos que administra la implementación. No sustituya estos patrones por instrucciones específicas del operador.

Para obtener más información, consulte estos artículos relacionados:

• Para actualizar los clústeres de AKS de producción, consulte Estrategias de actualización de producción de AKS.
• Para comparar los enfoques de actualización del clúster de AKS, consulte Opciones y recomendaciones de actualización.
• Para usar el centro de escenarios para ayudarle a elegir el enfoque de actualización de AKS adecuado, consulte Escenarios de actualización de AKS: Elija la ruta de acceso.

Para obtener un inicio rápido, seleccione el patrón del producto y la topología implementados:

• Lista de comprobación de actualización de emergencia
• Conmutación controlada de PostgreSQL
• Actualización gradual de la réplica del clúster de Redis
• Actualización gradual del conjunto de réplicas de MongoDB, primero las secundarias

Elección de un patrón de actualización de base de datos

Lista de comprobación de actualización de emergencia

Si necesita una actualización rápida para solucionar un problema de seguridad, no omita las comprobaciones de estado y recuperación de la base de datos.

1. Verifique la carga de trabajo y los requisitos previos para la actualización de AKS:

   # Verify the database pods and their node placement.
   kubectl get pods -l tier=database -o wide
   
   # Confirm that the latest backup job completed.
   kubectl get job backup-job -o jsonpath='{.status.completionTime}'
   

   Compruebe también el estado de replicación mediante un comando compatible con la base de datos o el operador . Restaure la copia de seguridad más reciente en un entorno aislado y confirme que los clientes reintentan los errores transitorios de conexión y elección.

2. Elija solo el patrón que coincida con el producto y la topología:

   • PostgreSQL: Use cambio controlado.
   • Clúster de Redis: use la actualización progresiva priorizando las réplicas.
   • Conjunto de réplicas de MongoDB: use la actualización progresiva empezando por los nodos secundarios.

   Para otros productos de base de datos, siga las instrucciones de actualización de ese producto o su operador de Kubernetes.

3. Ejecuta con una red de seguridad:

   • Pruebe siempre los procedimientos de reversión con antelación.
   • Supervise las métricas de la aplicación durante la actualización.
   • Mantenga el equipo de base de datos en espera.
   • Detenga la actualización si la replicación, el cuórum, la cobertura de ranuras o la salud de la aplicación empeoran.

Conmutación controlada de PostgreSQL

Use este patrón de conmutación controlada para una base de datos principal de PostgreSQL con esperas de streaming. Los ejemplos muestran comprobaciones de estado, pero los comandos para promover, aislar y reintegrar nodos dependen del operador de PostgreSQL o de la implementación de alta disponibilidad.

Prerequisites

• Use una versión de PostgreSQL compatible y un operador compatible o una implementación de alta disponibilidad.
• Distribuya los miembros entre dominios de error. Configura los presupuestos de interrupción de pods y las restricciones de distribución de topología para tu despliegue.
• Compruebe una copia de seguridad reciente restaurandola en un entorno aislado.
• Confirme que la aplicación se vuelve a conectar después de un cambio principal.
• Registre los comandos específicos del operador para la conmutación, la reversión y la reincorporación antes de comenzar la actualización de AKS.

Paso 1: Validar la topología de replicación

Ejecute la siguiente consulta en el nodo primario actual:

kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;"

El candidato previsto para la conmutación debe estar en estado streaming. Si su RPO requiere replicación sincrónica, verifique también que el candidato dispone del sync_state esperado para su configuración.

Ejecute la consulta siguiente en el modo de espera previsto:

kubectl exec <candidate-standby-pod> -- psql -X -c "
SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();"

Confirme que pg_is_in_recovery() devuelve true y que las ubicaciones de recepción y reproducción cumplen el umbral de conmutación probado. La replicación en streaming de PostgreSQL es asincrónica de forma predeterminada, por lo que el mero hecho de que un pod esté listo no demuestra que la réplica en espera esté sincronizada.

Paso 2: Pausar las escrituras y cambiar las primarias

Si todo el tráfico de la aplicación pasa a través de PgBouncer, conéctese a la base de datos de administración de PgBouncer y pause la base de datos de la aplicación:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "PAUSE app_db;"

PAUSE espera a que las conexiones del servidor se liberen según el modo de agrupación configurado. Compruebe que las operaciones de escritura de la aplicación no pueden eludir PgBouncer antes de confiar en este control.

Con las operaciones de escritura en pausa, complete estas acciones usando el operador o la implementación de alta disponibilidad:

1. Vuelva a comprobar las posiciones de recepción y reaplicación de WAL del candidato.
2. Ejecute la operación de conmutación admitida.
3. Compruebe que existe exactamente un nodo principal con capacidad de escritura.
4. Compruebe que el antiguo primario ha sido aislado o reconfigurado como nodo en espera.
5. Compruebe que el servicio de escritura o el punto de conexión apunte al nuevo nodo principal.

Reanude PgBouncer solo después de que se superen estas comprobaciones:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "RESUME app_db;"

Paso 3: Validar la conmutación

# Verify the new primary is writable and no longer in recovery.
kubectl exec <new-primary-pod> -- psql -X -c "SELECT pg_is_in_recovery();"

# Verify all expected standbys stream from the new primary.
kubectl exec <new-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

Pruebe el comportamiento de lectura, escritura, transacciones y reconexión de la aplicación. Compare el tiempo durante el cual las operaciones de escritura no estuvieron disponibles y el resultado de la replicación con su RTO y su RPO antes de continuar.

Configuración de replicación sincrónica opcional

La replicación sincrónica puede reducir el RPO de las transacciones reconocidas, pero añade latencia en la confirmación y puede reducir la disponibilidad de escritura si las réplicas en espera necesarias no están disponibles. El siguiente ejemplo espera a que cualesquiera dos servidores en espera con nombre y conectados directamente reproduzcan cada transacción confirmada:

# Use synchronous replication with multiple standbys
# postgresql.conf
synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)'
synchronous_commit = 'remote_apply'

Elija synchronous_standby_names y synchronous_commit en función de los requisitos de latencia medida, ubicación de dominio de error y durabilidad. Esta configuración no garantiza una duración de conmutación específica.

Validación exitosa

Para validar el progreso, use la siguiente lista de comprobación:

• El nuevo nodo primario acepta operaciones de lectura y escritura.
• Todas las réplicas muestran una replicación correcta.
• La aplicación se vuelve a conectar automáticamente.
• Se pasan las comprobaciones de integridad de datos y coherencia de la aplicación.
• Las pruebas de copia de seguridad y restauración se superan correctamente en el nuevo servidor principal.

Actualización del grupo de nodos de AKS

Una az aks nodepool upgrade operación actualiza todo el grupo de nodos. AKS agrega capacidad adicional, aísla y vacía los nodos antiguos, vuelve a aprovisionarlos con una imagen y repite el proceso de acuerdo con la configuración de actualización del grupo de nodos. No ejecute el comando una vez para cada nodo o desagüe manualmente los nodos antes de la operación administrada.

1. Enumere los destinos de actualización admitidos para el clúster:

   az aks get-upgrades \
      --resource-group <resource-group-name> \
      --name <cluster-name> \
      --output table
   

2. Confirme que el plano de control ya está en la versión de destino seleccionada. Configure la configuración de actualización gradual del grupo de nodos en función del comportamiento probado de la carga de trabajo, la cuota y las direcciones de subred disponibles. En el ejemplo siguiente se usa el valor de producción maxSurge recomendado:

   az aks nodepool update \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --max-surge 33% \
      --drain-timeout <minutes> \
      --node-soak-duration <minutes>
   

3. Inicie una actualización administrada para el grupo de nodos mediante un destino devuelto por az aks get-upgrades:

   az aks nodepool upgrade \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --kubernetes-version <target-version>
   

4. Supervise los eventos de actualización de AKS y el estado de la base de datos durante toda la operación:

   kubectl events --all-namespaces
   kubectl get pods -l app=postgres -o wide --watch
   

   Supervise la replicación, la disponibilidad de la base de datos, los errores de aplicación, la latencia y el estado de almacenamiento en el sistema de observabilidad. Si un Pod Disruption Budget impide drenar un nodo, corrija el problema de disponibilidad de la carga de trabajo en lugar de eludirlo.

Validar y recuperar

Una vez finalizada la actualización administrada, compruebe las versiones del nodo, la topología de PostgreSQL y el comportamiento de la aplicación:

kubectl get nodes
kubectl get pods -l app=postgres -o wide
kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

AKS no admite la degradación de un clúster o grupo de nodos a una versión anterior de Kubernetes. Si la base de datos no está en buen estado, detenga las operaciones de escritura de la aplicación y utilice el procedimiento de recuperación o conmutación que admita el operador de la base de datos. No redirija las operaciones de escritura al anterior nodo primario de PostgreSQL, a menos que se haya reincorporado de forma segura a la timeline actual y haya sido promovido por el mecanismo de alta disponibilidad. Si la actualización de Kubernetes provoca un problema de compatibilidad irrecuperable, restaure el servicio moviendo la carga de trabajo a un grupo de nodos o clúster probado y restaurando o replicando datos según el plan de recuperación.

Actualización gradual de la réplica del clúster de Redis

Use este patrón para un clúster de Redis con al menos tres nodos principales y al menos una réplica para cada principal. El orden documentado para actualizar los nodos del clúster de Redis es actualizar primero las réplicas, realizar manualmente la conmutación por error de cada nodo primario a una réplica actualizada y, a continuación, actualizar el antiguo primario degradado. El clúster de Redis puede devolver errores transitorios o redirecciones durante los cambios de topología. Dado que el clúster de Redis usa la replicación asincrónica, puede perder escrituras confirmadas. Valide el comportamiento de los reintentos del cliente y el RPO aceptable antes de la actualización.

Paso 1: Registrar y validar la topología

kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Registra el ID de cada nodo, el rol, la asignación de principal a réplica y el intervalo de ranuras hash. No continúe a menos que estén cubiertas las 16.384 ranuras, cada primario tenga una réplica en buen estado en un dominio de fallo diferente y el clúster informe de cluster_state:ok.

Paso 2: Actualizar réplicas

Para cada réplica, cada una por separado:

1. Use el operador o el mecanismo de implementación de cargas de trabajo para reemplazar o reiniciar la réplica en la capacidad de AKS actualizada.
2. Espere a que el pod esté listo y a que la replicación se sincronice.
3. Confirme con CLUSTER NODES que sigue asignado al primario previsto.

No ejecute CLUSTER FORGET para un reinicio de pod que conserve la identidad del nodo de Redis. Si el reemplazo tiene una nueva identidad de nodo, úsela redis-cli --cluster add-node con --cluster-slave y --cluster-master-id para agregarla como una réplica de la principal prevista. Espere hasta que aparezca la nueva réplica en la topología del clúster.

kubectl exec <existing-redis-pod> -- redis-cli --cluster add-node \
   <new-replica-ip>:6379 127.0.0.1:6379 \
   --cluster-slave \
   --cluster-master-id <primary-node-id>

Paso 3: Realizar la conmutación por error y actualizar los nodos principales

Para cada primario, de uno en uno:

1. Elija una réplica actualizada y puesta al día de esa primaria.

2. Ejecute CLUSTER FAILOVERen la réplica que desea promover, no en la principal actual:

   kubectl exec <candidate-replica-pod> -- redis-cli CLUSTER FAILOVER
   

3. Consulte ROLE, INFO REPLICATION o CLUSTER NODES hasta que el candidato sea el primario y el primario anterior sea su réplica. Una OK respuesta solo significa que Redis aceptó la solicitud de conmutación por error.

4. Sustituya o reinicie el antiguo nodo principal degradado en la capacidad de AKS actualizada.

5. Espere a que vuelva a estar como una réplica sincronizada antes de pasar al siguiente nodo principal.

No use CLUSTER FAILOVER FORCE ni TAKEOVER durante una actualización planeada. Estas opciones omiten la coordinación normal y requieren procedimientos independientes de recuperación de errores.

Paso 4: Validación del clúster de Redis

kubectl exec <redis-pod> -- redis-cli CLUSTER INFO
kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Compruebe la cobertura de las ranuras, las asignaciones de primaria a réplica, el estado de la replicación, las lecturas y escrituras de la aplicación, la gestión de redireccionamientos y el RPO observado.

Actualización gradual del conjunto de réplicas de MongoDB, primero los nodos secundarios

Use este patrón para un conjunto de réplicas de MongoDB de tres miembros o más grande que tenga una base de datos secundaria que se pueda elegir. Durante la renuncia del nodo primario y la elección, las operaciones de escritura fallan hasta que se elige un nuevo nodo primario. Las aplicaciones deben reintentar las escrituras aptas y las transacciones transitorias según las instrucciones del controlador de MongoDB.

Paso 1: Validar el conjunto de réplicas

kubectl exec <mongodb-pod> -- mongosh --quiet --eval "rs.status()"

Confirme que todos los miembros esperados están en buen estado, identifique el nodo principal actual y compruebe que al menos un secundario elegible está al día. Compruebe también la copia de seguridad más reciente a través de una restauración de prueba.

Paso 2: Actualizar secundarias

Para cada elemento secundario, de uno en uno:

1. Reemplace o reinicie el miembro en la capacidad actualizada de AKS mediante el operador o el mecanismo de implementación de la carga de trabajo.

2. Espere a que el pod esté listo.

3. Compruebe que el miembro vuelve al estado SECONDARY y se pone al día antes de actualizar otro miembro.

   kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
      "rs.status().members.map(member => ({name: member.name, state: member.stateStr, optime: member.optimeDate}))"
   

Paso 3: Bajar la base de datos principal

Ejecute rs.stepDown() solo en el servidor principal actual. El primer argumento especifica durante cuánto tiempo el antiguo primario no puede volver a ser elegido. El segundo argumento especifica de cuánto tiempo dispone un secundario elegible para ponerse al día. Elija los valores en función del comportamiento electoral probado.

kubectl exec <current-primary-pod> -- mongosh --quiet --eval "rs.stepDown(60, 30)"

El comando puede desconectar o devolver un error a medida que se reducen los pasos principales. Consulte el estado del conjunto de réplicas desde otro miembro hasta que se elija un único nuevo nodo primario:

kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
   "rs.status().members.map(member => ({name: member.name, state: member.stateStr}))"

Si no hay ninguna base de datos secundaria que se pueda elegir dentro del período configurado, la principal no se reduce. Solucione el estado de salud de la replicación antes de volver a intentarlo. No forzar el descenso durante una actualización planeada.

Paso 4: Actualizar y validar la base de datos principal anterior

Reemplace o reinicie la instancia principal anterior en la capacidad de AKS actualizada. Espere a que vuelva a estar como secundario en buen estado y, a continuación, valide:

• Hay exactamente un miembro: PRIMARY.
• Todos los demás miembros con datos están SECONDARY y sincronizados.
• Las operaciones de lectura y escritura de la aplicación, las escrituras con reintento y las transacciones funcionan según lo previsto.
• El intervalo de elección medido cumple el RTO de la aplicación.
• Las comprobaciones de copia de seguridad y restauración se han superado.