initcontainer - kubernetes yaml example

Implementaciones móviles de Kubernetes y migraciones de bases de datos.

Question

Al procesar una actualización sucesiva con migraciones de base de datos, ¿cómo maneja esto los gobernadores?

Por ejemplo, tengo una aplicación que se actualiza de app-v1 a app-v2, que incluye un paso de migración para modificar una tabla existente. Por lo tanto, esto significaría que debo ejecutar algo como db:migrate para una aplicación de Rails una vez implementada.

Cuando se lleva a cabo una implementación rodante en 3 conjuntos de réplicas Se desplegará de una vaina a otra. Permitir potencialmente que los POD que no tienen la nueva versión de la aplicación se rompan.

Aunque este escenario no es algo que sucede muy a menudo. Es muy posible que lo haría. Me gustaría aprender sobre los mejores enfoques recomendados para este escenario.

Answer 1

Kubernetes NO maneja de forma nativa las actualizaciones sucesivas con migraciones de base de datos. Esto es específico de la aplicación, por lo que el desarrollador de la aplicación tendrá que manejarlo. Puede que tenga que hacer las mismas cosas que haría en una configuración que no sea k8.

De todos modos, la forma en que lo haría es:

• Escala tus réplicas a 1.
• Actualiza la imagen.
• Escala tus réplicas a 3.

Esto no es infalible pero no implica cambio de código. Hay una pequeña ventana entre el paso db: migrate y la escucha del servidor real donde una solicitud irá a la réplica más antigua (que terminará tan pronto como la nueva réplica esté lista). Esa solicitud puede o no fallar dependiendo de si el bloque de código está directamente relacionado con el cambio de esquema.

Si no me importara mucho el tiempo de inactividad, solo usaría la estrategia de recreación.

Answer 2

Resolví este problema recientemente, y aquí está mi camino:

• Use las anotaciones de implementación para almacenar los comandos que normalmente necesita ejecutar antes o después de la implementación.
• Cree un script que pueda leer su implementación por nombre y luego cree un trabajo para ejecutar los comandos especificados en las anotaciones de implementación.
• Al insertar una imagen en el registro de una ventana acoplable, agregue un webhook que llamará a su script especificado en el punto anterior.
• Para evitar problemas con una estructura de base de datos incompatible:
  • No modifique las columnas db de una manera incompatible hacia atrás.
  • No elimine las columnas no utilizadas inmediatamente en sus migraciones. Puedes hacerlo en la próxima versión. De esta manera, solo tendrá un script de migración que ejecutará antes de la implementación.

PD: Para poder trabajar con Kubernetes en su script, es posible que desee familiarizarse con estos enlaces: API de Kubernetes , Descripción general de la API de Kubernetes , Clústeres de acceso mediante la API de Kubernetes , Bibliotecas de clientes .

Answer 3

Una forma de evitar que una versión anterior se rompa es dividir una migración en varios pasos.

Por ejemplo, desea cambiar el nombre de una columna en la base de datos. Cambiar el nombre de la columna directamente rompería las versiones antiguas de la aplicación. Esto se puede dividir en varios pasos:

• Agregar una migración de base de datos que inserta la nueva columna
• Cambia la aplicación para que todas las escrituras vayan a la columna antigua y nueva.
• Ejecuta una tarea que copia todos los valores de la columna antigua a la nueva
• Cambia la aplicación que lee de la nueva columna.
• Agregar una migración que elimine la columna antigua.

Desafortunadamente, esto es bastante complicado, pero evita tener un tiempo de inactividad con una página de mantenimiento arriba.