En esta página se explican las prácticas recomendadas para ejecutar bases de datos en contenedores en GKE. Puedes usar una implementación para crear un conjunto de instancias de bases de datos en contenedores gestionadas por Kubernetes. A continuación, crea un servicio para proporcionar acceso a la base de datos independientemente de cualquier pod concreto. El servicio no cambia aunque el pod se mueva a otro nodo.
Para acceder a los datos de tu instancia de base de datos, crea un recurso PersistentVolumeClaim (PVC) y hazlo disponible para tu carga de trabajo.
Las bases de datos dependen de los discos locales para la persistencia. Una base de datos que se ejecuta como servicio en un clúster de Kubernetes y sus archivos de base de datos en un PersistentVolumeClaim están vinculados al ciclo de vida del clúster. Si se elimina el clúster, también se elimina la base de datos.
Si vas a crear o desplegar una aplicación con reconocimiento del estado que se ejecuta en GKE, te recomendamos que utilices una de las siguientes opciones de despliegue para las instancias de base de datos:
- Bases de datos totalmente gestionadas: una base de datos gestionada, como Cloud SQL o Spanner, reduce la sobrecarga operativa y se optimiza para la infraestructura. Google Cloud Las bases de datos gestionadas requieren menos esfuerzo para mantenerlas y operarlas que una base de datos que implementes directamente en Kubernetes.
- Aplicación de Kubernetes: puedes desplegar y ejecutar una instancia de base de datos (como MySQL o PostgreSQL) en un clúster de GKE.
Consideraciones sobre las implementaciones de bases de datos en GKE
Cada una de las opciones anteriores tiene sus ventajas e inconvenientes, en función de tus objetivos y limitaciones empresariales. Usa la siguiente tabla para decidir si la implementación de bases 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 tu base de datos dependa de un clúster de GKE concreto, te recomendamos que la mantengas por separado, como base de datos gestionada o en una instancia de VM. |
| Escalar con GKE | Escalado vertical: puedes configurar las solicitudes de tus pods para que se escalen automáticamente. Sin embargo, debes asegurarte de que tu aplicación de base de datos pueda resistir las interrupciones cuando tus pods se escalen con el autoescalado de pods vertical. Escalado horizontal: tu base de datos puede escalar horizontalmente las lecturas o las escrituras añadiendo réplicas. Si tu base de datos admite el escalado horizontal, depende de si tiene una arquitectura de un solo escritor o de varios escritores. Para usar el escalado horizontal, es posible que tengas que actualizar la configuración de la base de datos, además de aumentar el número de réplicas. |
| Sobrecarga de GKE | En los clústeres Autopilot, no se te factura por las reservas de recursos, sino solo por las solicitudes de recursos. En los clústeres estándar, GKE reserva recursos para sus propias operaciones. Las bases de datos de los clústeres Standard no se escalan automáticamente, por lo que la sobrecarga puede ser alta en los pods pequeños. |
| Número 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 propio PersistentVolumeClaim. Si tienes un gran número de instancias, tendrás que operar y gestionar un gran conjunto de pods, nodos y reclamaciones de volumen. En su lugar, puedes usar una base de datos gestionada. |
| Copia de seguridad de bases de datos en GKE | Un PersistentVolumeClaim se limita a un clúster de GKE. Esto significa que, cuando se elimina un clúster de GKE, también se elimina la reclamación de volumen. También se eliminan los archivos de base de datos del clúster. Para evitar la pérdida accidental de los archivos de la base de datos, te recomendamos que hagas una réplica o una copia de seguridad con frecuencia. Puedes usar Backup for GKE para crear capturas de la configuración de tu aplicación y de los datos de volumen a intervalos periódicos. Copia de seguridad de GKE se encarga de programar las copias de seguridad de los volúmenes, gestionar el ciclo de vida de las copias de seguridad y restaurar 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 una 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 en una base de datos o en un almacenamiento estable fuera de los pods. |
| Arquitectura de 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 una opción de conmutación por error activa-pasiva, en la que se puede convertir una base de datos secundaria en principal en caso de que falle la principal. |
| Migración de bases de datos | Si tienes previsto migrar tu sistema de bases de datos a GKE, consulta los artículos Migración de bases de datos: conceptos y principios (parte 1) y Migración de bases de datos: conceptos y principios (parte 2). |
| Volver a formar a los usuarios | Si pasas de una implementación autogestionada o gestionada por un proveedor a una implementación de base de datos de Kubernetes, debes volver a formar a los administradores de bases de datos para que trabajen en el nuevo entorno con la misma fiabilidad que en el entorno actual. Los desarrolladores de aplicaciones también pueden tener que aprender sobre las diferencias en menor medida. |
En la tabla anterior se analizan algunas de las consideraciones sobre la implementación de bases de datos. Sin embargo, la tabla no incluye todas las consideraciones posibles. También debes tener en cuenta la recuperación ante desastres, la agrupación de conexiones y la monitorización.
Siguientes pasos
- Consulta cómo desplegar una topología de MySQL de alta disponibilidad en GKE.
- Consulta cómo desplegar una instancia de PostgreSQL de alta disponibilidad en GKE.
- Consulta más información sobre Copia de seguridad de GKE, un servicio con el que puedes crear copias de seguridad y restaurar cargas de trabajo en GKE.
- Consulta más información sobre los volúmenes persistentes.