En esta página, se explican las prácticas recomendadas para ejecutar bases de datos en contenedores en GKE. Puedes usar una Deployment para crear un conjunto de instancias de base de datos en contenedores administradas por Kubernetes. Luego, creas un Service para proporcionar acceso a la base de datos sin importar cualquier Pod en particular. El Service no se modifica, incluso si el Pod se mueve a un nodo diferente.
Para acceder a los datos en tu instancia de base de datos, crea un recurso PersistentVolumeClaim (PVC) y haz que esté disponible para la carga de trabajo.
Las bases de datos dependen en gran medida de los discos locales para la persistencia. Una base de datos que se ejecuta como un servicio en un clúster de Kubernetes y sus archivos de base de datos en un PersistentVolumeClaim están vinculadas al ciclo de vida del clúster. Si se borra el clúster, también se borrará la base de datos.
Si compilas o implementas una aplicación con estado que se ejecuta en GKE, considera usar una de las siguientes opciones de implementación para instancias de bases de datos:
- Bases de datos completamente administradas: Una base de datos administrada, como Cloud SQL o Spanner, proporciona una sobrecarga operativa reducida y está optimizado para la infraestructura de Google Cloud. Las bases de datos administradas requieren menos esfuerzo de mantener y operar que una base de datos que implementas de forma directa en Kubernetes.
- Aplicación de Kubernetes: Puedes implementar y ejecutar una instancia de base de datos (como MySQL o PostgreSQL) en un clúster de GKE.
Consideraciones para las implementaciones de bases de datos en GKE
Cada una de las opciones anteriores tiene compensaciones en función de tus objetivos y restricciones empresariales. Usa la siguiente tabla para decidir si la implementación de la base de datos en GKE es la opción adecuada para ti.
| Consideración | Descripción |
|---|---|
| Independencia de la base de datos | El ciclo de vida de un PersistentVolumeClaim está vinculado al clúster de GKE correspondiente. Si no quieres que el ciclo de vida de la base de datos dependa de un clúster de GKE en particular, considera mantener la base de datos separada, como una base de datos administrada o en una instancia de VM. |
| Escala con GKE | Escalamiento vertical: Puedes configurar tus solicitudes de Pods para escalar de forma automática. Sin embargo, debes asegurarte de que la aplicación de la base de datos pueda soportar interrupciones cuando los Pods se escalen verticalmente con el Ajuste de escala automático vertical de Pods. Escalamiento horizontal: Es posible que tu base de datos pueda escalar horizontalmente las lecturas o escrituras mediante la adición de réplicas. La compatibilidad de tu base de datos con el escalamiento horizontal depende de si tiene una sola arquitectura de escritor o de varios escritores. Para usar el escalamiento horizontal, es posible que debas actualizar la configuración de la base de datos, además de escalar verticalmente la cantidad de réplicas. |
| Sobrecarga de GKE | En los clústeres de Autopilot, no se te facturará por las reservas de recursos, solo por las solicitudes de recursos. En los clústeres estándar, GKE reserva recursos para sus propias operaciones. Las bases de datos en clústeres estándar no se escalan de forma automática, por lo que la sobrecarga puede ser alta para los Pods pequeños. |
| Cantidad de instancias de base de datos | En el contexto de Kubernetes, cada instancia de base de datos se ejecuta en su propio Pod y tiene su propia PersistentVolumeClaim. Si tienes una gran cantidad de instancias, debes operar y administrar un gran conjunto de Pods, nodos y reclamaciones de volumen. En cambio, te recomendamos usar una base de datos administrada. |
| Copia de seguridad de la base de datos en GKE | Un PersistentVolumeClaim tiene un alcance en un clúster de GKE. Este alcance indica que cuando se borra un clúster de GKE, se borra la reclamación de volumen. También se borran todos los archivos de la base de datos del clúster. Para protegerte contra la pérdida accidental de los archivos de la base de datos, recomendamos la replicación o la copia de seguridad frecuente. Puedes usar la Copia de seguridad para GKE a fin de tomar instantáneas de la configuración de tu aplicación y los datos de volumen en intervalos periódicos. La copia de seguridad para GKE controla la programación de las copias de seguridad del volumen, la administración del ciclo de vida de la copia de seguridad y el restablecimiento de las copias de seguridad en un clúster. |
| Comportamiento de recuperación específico de Kubernetes | Cuando un Pod falla en Kubernetes, se vuelve a crear. Desde la perspectiva de la instancia de base de datos, esto significa que cuando se vuelve a crear un Pod, también se vuelve a crear cualquier configuración que no sea persistente dentro de una base de datos o en un almacenamiento estable fuera de los Pods. |
| Arquitectura de la base de datos | Si tu base de datos está configurada para usar una arquitectura activa-pasiva, debes asegurarte de que solo una réplica esté configurada como principal. Muchas bases de datos relacionales tienen la opción de conmutación por error activa-pasiva, en la que un secundario puede ascender a principal en caso de una falla principal. |
| Migración de bases de datos | Si planeas migrar tu sistema de base de datos existente a GKE, consulta Migración de bases de datos: Conceptos y principios (parte 1) y Migración de bases de datos: Conceptos y principios (parte 2) |
| Vuelve a entrenar a los usuarios | Reentrenamiento: Si pasas de una implementación autoadministrada o administrada por el proveedor a una implementación de base de datos de Kubernetes, debes volver a entrenar a los administradores de base de datos para que funcionen en la nueva implementación de forma tan confiable como operan en el entorno actual. Es posible que los desarrolladores de aplicaciones también deban aprender sobre las diferencias de menor alcance. |
En la tabla anterior, se analizan algunas de las consideraciones para la implementación de la base de datos. Sin embargo, la lista no incluye todas las consideraciones posibles. También debes considerar la recuperación ante desastres, la agrupación de conexiones y la supervisión.
¿Qué sigue?
- Aprende a implementar una topología de MySQL con alta disponibilidad en GKE.
- Aprende a implementar una instancia de PostgreSQL con alta disponibilidad en GKE.
- Obtén más información sobre la Copia de seguridad para GKE, un servicio para crear copias de seguridad y restablecer cargas de trabajo en GKE.
- Explora los volúmenes persistentes con más detalle.