A continuación se detalla cómo cada estrategia afecta internamente al despliegue, incluyendo implicaciones operativas y temporales: | Dimensión | Escalado Horizontal | Escalado Vertical | |---|---|---| | Objetivo principal | Ajustar el número de instancias: réplicas en un conjunto de réplicas o fragmentos (shards) en un clúster fragmentado. | Modificar los límites y solicitudes de recursos (CPU/memoria) de los contenedores mongod, mongos o configsvr. | | Campo de configuración relevante | spec.members (replica set), spec.shardCount, spec.mongodsPerShard, spec.mongosCount, spec.configServerCount | spec.podSpec.podTemplate.spec.containers[0].resources | | Mecanismo subyacente | Creación o eliminación de Pods gestionados por StatefulSet; integración automática al conjunto de réplicas o al clúster fragmentado. | Actualización del pod template, lo que desencadena una actualización gradual del StatefulSet (reinicio secuencial de Pods). | | Impacto en disponbiilidad | Bajo en réplicas (sincronización asincrónica); moderado en clústeres fragmentados durante la redistribución de chunks. | Interrupción breve (segundos) por Pod, requiere soporte de reconexión en la capa de aplicación. | | Tiempo estimado | De 2 a 10 minutos: depende de tiempo de arranque, sincronización de oplog y migración de datos. | De 1 a 15 minutos: depende del número de Pods, políticas de readinessProbe y tiempo de cierre limpio. | | Manejo de almacenamiento persistente | Los PersistentVolumeClaim (PVC) asociados suelen conservarse tras la reducción (según reclaimPolicy del StorageClass). | No afecta los PVC existentes ni el contenido de los volúmenes. |

Parámetros específicos por arquitectura

La ubicación y nombre de los campos varían según el tipo de despliegue definido en spec.type: - Conjunto de réplicas (ReplicaSet): - Horizontal: ajuste de spec.members (ej. de 3 a 5). - Vertical: modificación de spec.podSpec.podTemplate.spec.containers[0].resources.

• Clúster fragmentado (ShardedCluster):
  • Horizontal: puede ajustarse independientemente:
    • spec.shardCount: cantidad total de fragmentos.
    • spec.mongodsPerShard: réplicas por fragmento (cada uno es un conjunto de réplicas interno).
    • spec.mongosCount: número de instancias de enrutamiento.
    • spec.configServerCount: miembros del conjunto de servidores de configuración (siempre debe ser impar y ≥3).
  • Vertical: aplica a cada componente mediante sus respectivos bloques podSpec (por ejemplo, spec.mongos.podSpec o spec.shard.podSpec).

Flujo operativo paso a paso

1. Preparación previa
   • Realice una copia de seguridad del CR YAML y de los datos críticos (usando mongodump o integración con MongoDB Atlas/Cloud Manager).
   • Valide el estado del clúster: kubectl get pods -n <namespace>, kubectl get mongodb -n <namespace>, y rs.status() desde un mongod conectado.
   • Verifique capacidad disponible en los nodos de Kubernetes (para escalado vertical): kubectl describe nodes | grep -A 10 "Allocatable".
   • Planifique la operación fuera de horarios pico, especialmente si implica reinicios.
2. Ejecución
   • Edite el archivo CR. Ejemplo para añadir una réplica: ``` apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: prod-rs spec: members: 4 # ← Cambio clave version: "7.0.12" type: ReplicaSet security: tls: enabled: true # ... resto de la configuración

   • Aplique los cambios: ``` kubectl apply -f prod-rs.yaml -n mongodb

3. Supervisión y validación
   • Monitoree la transición de los Pods: ``` kubectl get pods -n mongodb -l mongodb.mongodb.com/name=prod-rs -w

   • Revise los registros del operador para confirmar etapas de reconciliación: ``` kubectl logs -n mongodb deployment/mongodb-kubernetes-operator --tail=50 -f

   • Verifique coherencia lógica:
     • En un conjunto de réplicas: rs.status().members.length === spec.members.
     • En un clúster fragmentado: sh.status() debe reflejar el nuevo conteo de shards y mongos.

Advertencias críticas y buenas prácticas

• No se admite conversión de tipo de despliegue: No es posible cambiar type: Standalone a ReplicaSet o de ReplicaSet a ShardedCluster mediante edición del CR. Requiere migración manual de datos y creación de un nuevo recurso.
• Restriccioens en reinicios: Durante el escalado vertical, cada Pod se recrea individualmente. Asegure que:
  • Las aplicaciones cliente usen drivers con reconexión automática y exponenciación de reintentos.
  • Se defina un PodDisruptionBudget (p. ej., minAvailable: 2) para evitar caídas completas durante actualizaciones.
• Balanceo de datos en clústeres fragmentados: Incrementar shardCount activa la migración automática de chunks. Monitoree métricas como moveChunk.totalTimeMillis y sharding.moveChunk.count para detectar cuellos de botella.
• Compatibilidad de versiones: Valide que la versión de MongoDB especificada en spec.version esté soportada explícitamente por la versión del operador instalada (consulte la matriz de compatibilidad oficial).
• Dependencia infraestructural: El rendimiento y la resiliencia finales dependen de la calidad del almacenamiento (preferiblemente ReadWriteOnce con soporte para fsGroup), baja latencia de red entre nodos y políticas de QoS adecuadas (evitar BestEffort para cargas críticas).