¡Kubernetes tiene 10 años! A mediados de 2024 se cumple el décimo aniversario de la plataforma de orquestación de contenedores líder en el mercado. Pero, dice Sergey Pronin, gerente de productos del grupo Percona, que desarrolla productos de código abierto para bases de datos SQL y NoSQL, no siempre estuvo en esa posición.
Pronin recuerda los primeros años en que Kubernetes llegó al mercado, prácticamente atrapado en la orquestación de aplicaciones sin estado, con una funcionalidad de almacenamiento y protección de datos que era prácticamente inexistente.
Él también fue un defensor de “Kubernetes para apátridas”. Pero con el tiempo, con la funcionalidad de servicios con estado agregada a través de Kubernetes Operadores y StatefulSet, la plataforma de orquestación se convirtió en la opción ideal para los desarrolladores que querían una plataforma de contenedor madura para aplicaciones nativas de la nube con todo lo necesario para el almacenamiento de datos con estado.
Celebramos la primera década de Kubernetes con una serie de entrevistas con ingenieros que ayudaron a desarrollar Kubernetes y abordar los desafíos en almacenamiento y protección de datos (incluido el uso de operadores de Kubernetes) mientras miramos hacia un futuro caracterizado por cargas de trabajo de inteligencia artificial (IA).
¿Cómo era el mercado cuando se lanzó Kubernetes por primera vez?
Sergei Pronin: Debido a que las organizaciones habían adoptado cada vez más la arquitectura de microservicios, era necesario gestionar y escalar una gran cantidad de contenedores de manera eficiente. Las implementaciones y el escalado de contenedores se habían realizado manualmente, lo que era propenso a errores y consumía mucho tiempo, por lo que existía una demanda de herramientas de orquestación automatizadas.
En 2014, Kubernetes ingresó a un mercado de orquestación de contenedores que rebosaba potencial pero que carecía de un líder claro. Docker había iniciado la revolución de los contenedores, pero gestionarlos a escala seguía siendo un rompecabezas complejo. Existían opciones como Apache Mesos, pero a menudo eran difíciles de manejar y requerían conocimientos especializados.
¿Cómo empezó a trabajar en la infraestructura de datos en torno a Kubernetes?
Pronín: En aquel entonces, dirigí varios equipos de ingeniería que creaban varias soluciones de plataforma como servicio. Los desarrolladores siempre quieren eliminar el trabajo duro mediante la automatización y simplificar la orquestación era algo que todos querían. Kubernetes no era tan sofisticado como lo es hoy, pero poco a poco estaba ganando terreno en la comunidad.
La curiosidad abre muchas puertas y vi a Kubernetes detrás de una de ellas. Una vez que vi lo que implicaba, pensé que era un proyecto al que debía seguirle la pista. No sabía cuánto sería parte de mi futura carrera.
¿Cómo se dio cuenta de que Kubernetes ocupaba la posición de liderazgo en el mercado?
Pronín: No fue una comprensión repentina para mí. Sucedió lentamente. Se utilizaron ampliamente soluciones como Apache Mesos, Docker Swarm e incluso AWS ECS (Elastic Container Service). La razón por la que Kubernetes ganó es la comunidad. Su arquitectura conectable y su rápido desarrollo impulsaron su adopción y poco a poco consumieron la cuota de mercado de otras soluciones.
Cuando analizó Kubernetes, ¿cómo abordó los datos?
Pronín: Para mí, durante mucho tiempo, Kubernetes era solo para aplicaciones sin estado. Incluso teníamos barras de calidad bastante estrictas en nuestras plataformas donde no permitíamos aplicaciones con estado en Kubernetes. Se trataba de una aplicación de 12 factores que pensaba en su máxima expresión sobre cómo diseñar y crear aplicaciones nativas de la nube escalables y resistentes. Uno de los principios básicos es tratar los servicios back-end, incluidas las bases de datos, como recursos adjuntos, para promover el diseño de aplicaciones sin estado.
¿Qué problemas le surgieron primero en torno a los datos y el almacenamiento con Kubernetes?
Pronín: El mayor problema fue la inmadurez. El aprovisionamiento de volúmenes persistentes era como un conocimiento sagrado, solo conocido por unos pocos, no completamente automatizado y disponible mediante algún tipo de piratería central. La integración con los proveedores de almacenamiento era inexistente, lo que significaba que la experiencia del usuario era bastante complicada.
Luego, en 2019, AWS EKS (Elastic Kubernetes Service) comenzó oficialmente a admitir AWS EBS (Elastic Block Storage). Este podría ser el hito que empezó a cambiar las percepciones.
¿Qué tuvo que cambiar?
Pronín: El lanzamiento de Stateful Sets and Operadores se produjo tres años después del primer lanzamiento, por lo que tomó algún tiempo preparar a Kubernetes. Una vez que fueron liberados, todavía tomó tiempo superar las reticencias a desplegarlos. Se necesitaron muchas pruebas para superar ese obstáculo antes de que estuviéramos listos para cambiar nuestras políticas.
¿Cómo se involucró con los operadores de Kubernetes?
Pronín: Me uní a Percona hace 3,5 años para liderar el equipo de gestión de productos responsable de los operadores y las implementaciones de aplicaciones nativas de la nube. En aquel entonces era completamente nuevo, con mucha incertidumbre y una comunidad relativamente pequeña. Yo creía firmemente en “Kubernetes para apátridas”, por lo que fue todo un desafío captar la idea. El equipo directivo de Percona vio una oportunidad y percibió la tendencia del mercado mucho antes de que se generalizara.
¿Qué pasó con los operadores que los convirtió en un éxito para los datos y el almacenamiento?
Pronín: Es una combinación de eventos.
En la era de los microservicios, los usuarios intentaban ejecutar bases de datos en contenedores Docker, fuera de Kubernetes. Esta es una tarea compleja, especialmente si hay agrupaciones en clústeres en las implementaciones, que podrían ser necesarias para las bases de datos.
Kubernetes se estaba convirtiendo en un estándar de facto para ejecutar microservicios y crear plataformas. Se describió como “una plataforma para construir plataformas” y creo que esa definición es precisa ahora.
Kubernetes prometió resolver algunos de los problemas de complejidad, pero administrar bases de datos es difícil. Aprender todas las primitivas de Kubernetes y comprender los conceptos es para valientes. Los operadores abstrajeron toda esta complejidad y redujeron significativamente la barrera de entrada.
No sólo eso, los operadores resolvieron el problema de las operaciones del segundo día. De aquí proviene la mayor parte de la complejidad de la base de datos: tareas como mantenimiento continuo, actualizaciones, copias de seguridad y restauraciones, seguridad, etc. Kubernetes puede ayudar a mejorar la rapidez con la que se puede implementar la infraestructura, pero no puede realizar una consulta de base de datos por usted.
¿Cómo respaldó esto enfoques más nativos de la nube? ¿Cuáles fueron las consecuencias?
Pronín: Los operadores, especialmente para las bases de datos, dieron un impulso adicional a Kubernetes y al ecosistema CNCF y facilitaron la adopción de esas opciones de código abierto.
La dependencia del proveedor era un problema en la nube pública, mientras que Kubernetes proporcionaba una forma de ejecutar aplicaciones en cualquier lugar utilizando una API uniforme. Kubernetes había demostrado que podía funcionar perfectamente con aplicaciones sin estado y con operadores, por lo que las bases de datos también tuvieron la oportunidad de ejecutarse de la misma manera.
Kubernetes ahora tiene 10 años. ¿Cómo lo piensas hoy?
Pronín: Durante los últimos 10 años, Kubernetes se ha convertido en el estándar de la industria y ha cambiado fundamentalmente la forma en que se desarrollan e implementan las aplicaciones. Su impacto es innegable. Ha fomentado la innovación e impulsado el surgimiento de la arquitectura de microservicios.
Si bien persisten desafíos como la complejidad y la seguridad, el futuro de Kubernetes es brillante. La creciente comunidad y toda la innovación que se está produciendo garantizarán que siga siendo adaptable a las nuevas tendencias.
¿Qué problemas existen todavía en torno a Kubernetes en lo que respecta a datos y almacenamiento?
Pronín: La complejidad sigue siendo un problema, incluso cuando los operadores facilitan la gestión de datos y recursos de almacenamiento. Principalmente, se debe a la falta de estandarización entre varias interfaces de almacenamiento de contenedores (CSI) y a las complejidades de las integraciones con diferentes proveedores de almacenamiento.
La gestión de datos y almacenamiento en múltiples nubes o entornos híbridos puede resultar un desafío debido a las diferencias en las API y las configuraciones de almacenamiento. Hay varios intentos de simplificar esto a través de planos de control de federación o de múltiples clústeres.
Los motores de bases de datos como MySQL o PostgreSQL se diseñaron mucho antes que los microservicios. Los ingenieros los han adaptado para ejecutarse en Kubernetes, pero a veces se requieren soluciones alternativas para que funcionen.
¿Alguna otra anécdota o información para compartir?
Pronín: Los operadores y las bases de datos de Kubernetes pasaron rápidamente de los hacks totalmente nuevos a hacer que todo funcionara y pasara a ser de nivel empresarial. Ahora se trata más de “cómo” que de “por qué” de organizaciones de diferentes niveles. Los datos sobre Kubernetes ya no son “sólo para los valientes”. Es la corriente principal.