5 cosas a considerar antes de implementar bases de datos en Kubernetes

Docker y Kubernetes (abreviado se le dice K8s) están siendo ampliamente adaptadas en la industria tecnológica. En sus comienzos, K8s y Docker no tenían las funcionalidades necesarias para manejar bases de datos. Los contenedores en Docker son efímeros, aunque Kubernetes ofrece excelente manejo de contenedores, no tiene los mecanismos necesarios para manejar por sí solo lo que necesita para automatizar conmutación por error (failover), configurar cambios en la replicación y procesos únicos en bases de datos.

La comunidad está haciendo un excelente trabajo mejorando y añadiendo funcionalidades a K8s. Crearon volúmenes persistentes para montarlos en los “pods” y así contener datos de manera consistente. Esto es que no se borre cuando se elimine y reemplace un “pod”. Para satisfacer las necesidades particulares de cada aplicación, ahora se puede crear CRD (“Custom Resource Definition” o Definición de Recursos Personalizados). Con CRD, y la habilidad de instalar operadores personalizados en K8s, las comunidades “open source” (código abierto”) han creado diferentes operadores que manejan la automatización de tareas pertinentes a las diferentes tecnologías de bases de datos. ¿Es esto suficiente para implementar bases de datos de producción en K8s?

La opinión de este servidor es que sí, pero no en todos los casos. Yo todavía me retraigo de implementar en K8s bases de datos que se utilicen para operaciones intensas de análisis. Un ejemplo sería una base de datos que cada mes recoja 100 GB de datos para procesarlo, analizarlo y al final producir reportes. Esto sin duda requiere un servidor muy poderoso con muchos recursos. Pero hay otras bases de datos que se utilizan para reportes diarios, guardar contraseñas, y recopilar metadata sobre una aplicación. Estas bases de datos, yo me atrevo a decir que se pueden implementar en K8s, aunque tenga miles de usuarios.

Solo porque se puede implementar bases de datos en K8s, no necesariamente signifique que deba hacerlo. Aquí les tengo mi lista de 5 cosas a considerar antes de implementar bases de datos en K8s:

  1. El personal que diseña la arquitectura de la aplicación debe conocer el uso de las bases de datos que se van a administrar. Si se utilizan para cálculos complejos y procesan grandes cantidades de datos, probablemente K8s no es la solución más adecuada para usted. Asegúrese de que los “pods” de K8s tengan los recursos necesarios para operar con alto rendimiento.
  2. El personal que administra las bases de datos en K8s, debe tener entrenamiento en operar K8s. Es cierto que uno no va a ser experto en todo, pero debe conocer lo suficiente como para pedirle a los ingenieros que operan K8s lo que se necesita para operar las bases de datos. K8s es complejo y dentro del nodo de K8s existen redes, “namespaces”, roles, agentes, volúmenes persistentes, etc. Pudieran adjudicar problemas a limitaciones en K8s que en realidad sea configuración incorrecta. Debe tener expertos en K8s para trabajar los problemas que puedan surgir al operar bases de datos.
  3. Sea experto en la tecnología de bases de datos que va a implementar. K8s no es responsable de las configuraciones internas de PostgreSQL, ScyllaDB o cualquier otra base de datos. Eso es responsabilidad del administrador de bases de datos.
  4. Asegúrese de que el hardware de los nodos de K8s sea adecuado. Las bases de datos son aplicaciones robustas que requieren discos, CPUs y memoria de alto rendimiento. Si dispone de discos baratos, la aplicación tendrá problemas con el rendimiento y no será culpa de K8s.
  5. Utilice un buen operador personalizado para manejar bases de datos. K8s no maneja replicación entre “pods”, seleccionar el “pod” que servirá de primario, automatizar conmutación por error (failover) cuando un “pod” falla, etc. Hay varios operadores y no todos funcionan igual. Analice bien las opciones que tenga y elija el que más le convenga. Aquí hay una lista de operadores con buena reputación en la industria:
    1. Stolon (PostgreSQL)
    2. Zalando\postgresq-operator y patroni.
    3. KubeDB
    4. Scylla-operator todavía no está en producción, pero es prometedor.

En resumen, automatizar el manejo de bases de datos no es asunto de lanzarlo en K8s y asumir que todo va a ser automático. Igual que todo en la vida, requiere destreza, planificación y estrategia. Esa inversión vale la pena ya que puede lograr alta disponibilidad y estará más cerca de realizar ese elusivo “cero interrupción de servicio”.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .