Kubernetes se ha convertido en un estándar de la industria, con hasta el 94% de las organizaciones que implementan sus servicios y aplicaciones en la plataforma de orquestación de contenedores, según las encuestas. Una de las razones clave por las que las empresas implementan Kubernetes es la estandarización, que permite a los usuarios avanzados ver beneficios que duplican la productividad.
La estandarización en Kubernetes brinda a las organizaciones la capacidad de implementar cualquier contenedor, en cualquier lugar. Pero faltaba una pieza: la tecnología asumía que los contenedores eran temporales, lo que significa que solo aquellos sin estado podían implementarse de manera segura en Kubernetes. Sin embargo, la comunidad cambió recientemente el paradigma y trajo características como StatefulSets y Storage Classes, que hacen posible el uso de datos en Kubernetes.
Si bien es posible ejecutar contenedores con estado en Kubernetes, sigue siendo un desafío.
Hacerlo progresivamente
Kubernetes está en camino de ser tan popular como Linux y la forma de facto de ejecutar cualquier aplicación, en cualquier lugar, de forma distribuida. Usar Kubernetes implica aprender muchos conceptos técnicos y vocabulario. Por ejemplo, los recién llegados pueden tener problemas con las muchas unidades lógicas de Kubernetes, como contenedores, pods, nodos y clústeres.
Si aún no está ejecutando Kubernetes en producción, no es bueno saltar directamente a los contenedores de datos. Es mejor empezar moviendo aplicaciones sin estado para evitar la pérdida de datos cuando las cosas van mal.
Si no puede encontrar un operador que se ajuste a sus necesidades, no se preocupe, porque la mayoría de ellos son de código abierto.
Comprender las limitaciones y especificidades
Una vez familiarizado con los conceptos generales de Kubernetes, se puede profundizar en los detalles de los conceptos con estado. Por ejemplo, debido a que las aplicaciones pueden tener diferentes necesidades de almacenamiento, como requisitos de rendimiento o capacidad, se debe proporcionar el sistema de almacenamiento subyacente correcto.
Lo que la industria generalmente llama «perfiles» de almacenamiento se denomina clases de almacenamiento en Kubernetes. Proporcionan una forma de describir los diferentes tipos de clases a los que puede acceder un clúster de Kubernetes. Las clases de almacenamiento pueden tener diferentes niveles de calidad de servicio, como operaciones de E/S por segundo por GiB, políticas de copia de seguridad o políticas arbitrarias, como modos de enlace y topologías permitidas.
Otro componente crítico para entender es StatefulSet. Es el objeto de la API de Kubernetes que se utiliza para administrar aplicaciones con estado y ofrece características clave como:
- Identificadores de red únicos y estables que le permiten realizar un seguimiento del volumen y desconectarlos y volver a conectarlos cuando lo desee
- Almacenamiento estable y persistente para que sus datos estén seguros
- Implementación y escalado ordenados y ordenados, que son necesarios para muchas operaciones del día 2.
Si bien StatefulSet ha sido un reemplazo exitoso del infame PetSet (ahora obsoleto), aún es imperfecto y tiene limitaciones. Por ejemplo, el controlador StatefulSet viene sin soporte incorporado para el cambio de tamaño de volumen (PVC) — lo cual es un gran desafío si el tamaño del conjunto de datos de su aplicación está a punto de crecer por encima de la capacidad de almacenamiento asignada actual. Existen soluciones alternativas pero tales limitaciones deben comprenderse con mucha anticipación para que el equipo de ingeniería sepa cómo manejarlas.
Tener un plan
Una vez cómodos con los conceptos de estado de Kubernetes, se puede migrar progresivamente las tareas relacionadas con datos en un orden específico. Esto permite aprender de los errores y evitar sentirse abrumado, porque no todas las tecnologías de datos son igualmente fáciles de ejecutar en Kubernetes.
Las tecnologías establecidas, como bases de datos y almacenamiento, deben migrarse primero, y las tecnologías emergentes, como IA y ML, deben migrarse en último lugar. Esto se refleja en un informe reciente, que encontró que la base de datos y el almacenamiento persistente son las dos cargas de trabajo de datos más ejecutadas en Kubernetes. La razón principal es la falta de herramientas para las operaciones del Día 2.
Disponibilidad de operadores
Mover los contenedores con estado a Kubernetes es solo la mitad del trabajo, también conocido como Día 1. Ahora hay que manejar las operaciones del Día 2 (uno de los temas más discutidos en la última KubeCon). Aquí es donde las cosas se ponen complicadas. Hay toneladas de operaciones del Día 2 que Kubernetes no puede manejar de forma nativa, como la aplicación de parches y la actualización, la copia de seguridad y la recuperación, el procesamiento de registros, la supervisión, el escalado y el ajuste.
Todas estas operaciones son específicas de la aplicación. Por ejemplo, un clúster de PostgreSQL y MySQL requerirá dos enfoques completamente diferentes al elegir un nuevo servidor principal en una configuración de clúster HA. Kubernetes no puede conocer todas las operaciones específicas del Día 2 de la aplicación. Aquí es donde entran los operadores.
Los operadores son extensiones programables que realizan operaciones que Kubernetes no puede manejar de forma nativa. Los operadores brindan capacidades de administración dinámicas e inteligentes al ampliar la funcionalidad de la API de Kubernetes. Uno de los usos más comunes es realizar estas operaciones del día 2. Estos operadores no son desarrollados por los mantenedores de Kubernetes sino por desarrolladores y organizaciones de terceros.
Antes de mover un trabajo de datos a Kubernetes, hay que asegurarse de que haya un operador para ello. OperatorHub hace un gran trabajo al indexarlos. Con 282 operadores disponibles en el sitio, la distribución se hace eco de lo anterior: algunos trabajos tienen herramientas de apoyo y otros no. Por ejemplo, la categoría de base de datos tiene 38 operadores (hay ocho solo para PostgreSQL), mientras que toda la categoría ML/IA solo tiene siete.
El nivel adecuado de capacidad del operador
Tener un operador para su tecnología no es suficiente, ya que pueden tener diferentes capacidades y, a menudo, existen en varios niveles de madurez. El OperatorFramework sugiere un modelo de capacidad que categoriza a los operadores según sus características:
- Nivel 1: funciona para la instalación básica, como el aprovisionamiento automatizado de aplicaciones y la gestión de la configuración.
- Nivel 2: Admite actualizaciones, parches y actualizaciones de versiones menores sin inconvenientes.
- Nivel 3: maneja el ciclo de vida completo de la aplicación y el almacenamiento (copia de seguridad, recuperación de fallas, etc.).
- Nivel 4: proporciona información profunda, métricas, alertas, procesamiento de registros y análisis de carga de trabajo.
- Nivel 5: ofrece escalado horizontal/vertical automático, ajuste de configuración automática, detección de anomalías y ajuste de programación.
Al elegir un operador, hay que asegurar de que sus capacidades coinciden con sus necesidades. Si no se está seguro de qué nivel es el adecuado, el informe Data on Kubernetes 2022 descubrió que la mayoría de las organizaciones buscan operadores que estén al menos en el nivel 3. Tener una copia de seguridad para sus contenedores es una buena práctica.
Si no puede encontrar un operador que se ajuste a las necesidades, no es problema porque la mayoría de ellos son de código abierto. Puede ampliar las capacidades de los operadores existentes con desarrollo interno o, mejor aún, contribuir al proyecto de código abierto.
Comprender al operador
La extensibilidad de los operadores es su fortaleza, pero también su debilidad. La falta de estándares significa que están programados de diferentes formas, por lo que debe atender a sus archivos de configuración para elegir el formato que más se ajuste.
Además, los operadores pueden utilizar diferentes rutas técnicas para lograr el mismo objetivo. Por ejemplo, uno de los ocho operadores de PostgreSQL, CloudNativePG, no usa StatefulSets y, en su lugar, usa su propio controlador personalizado. Eso es bastante inesperado considerando que StatefulSets es la base para los contenedores con estado en Kubernetes.
Sus desarrolladores decidieron optar por este diseño debido a la incapacidad de StatefulSet para cambiar el tamaño de los PVC (como discutimos anteriormente). Como explica la documentación del operador, elegir «diferentes opciones de diseño conduce por varios caminos». Por lo tanto, al elegir un operador, hay que asegurar comprender su implementación y sus ventajas y desventajas, y elegir el que le resulte más cómodo.
Vale la pena el esfuerzo
Ejecutar datos en Kubernetes no siempre es fácil, pero la buena noticia es que vale la pena el trabajo duro: el 54 % de las organizaciones encuestadas atribuyó más del 10 % de sus ingresos al hecho de que ejecutan datos en Kubernetes. Además, el 33% dijo que tiene un impacto transformador en la productividad y otro 51% vio un impacto positivo significativo.
A medida que las organizaciones adoptan cada vez más la infraestructura multinube para optimizar su costo y el rendimiento de la infraestructura, Kubernetes se ha convertido en la herramienta preferida. Dado que aproximadamente el 66 % de los países tienen algún tipo de legislación sobre privacidad de datos y derechos del consumidor, que a menudo requiere hacer cumplir el gobierno de los datos, las empresas deben alojar cada vez más los datos de los usuarios en los países en los que operan.
