¡Kubernetes cumple 10 años! A mediados de 2024 se cumplirá el décimo aniversario de la plataforma de orquestación de contenedores líder en el mercado. Pero, como dice Sergey Pronin, gerente de productos del grupo en 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 limitado a 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 era un defensor de «Kubernetes para aplicaciones sin estado». Pero con el tiempo, con la funcionalidad de servicios con estado agregada a través de Kubernetes Operators y StatefulSet, la plataforma de orquestación se convirtió en la opción preferida por los desarrolladores que querían una plataforma de contenedores madura para aplicaciones nativas de la nube con todo lo necesario para el almacenamiento de datos con estado. EspañolMarcamos la primera década de Kubernetes con una serie de entrevistas con ingenieros que ayudaron a desarrollar Kubernetes y a enfrentar los desafíos en materia de 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? Sergey Pronin: Debido a que las organizaciones habían adoptado cada vez más la arquitectura de microservicios, existía la necesidad de administrar y escalar grandes cantidades de contenedores de manera eficiente. Las implementaciones y el escalamiento de contenedores se habían realizado de forma manual, 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 estaba repleto de potencial pero carecía de un líder claro. Docker había iniciado la revolución de los contenedores, pero la gestión de contenedores 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 se involucró en el trabajo sobre la infraestructura de datos en torno a Kubernetes? Pronin: En aquel entonces, dirigía varios equipos de ingeniería que creaban diversas soluciones de plataforma como servicio. Los desarrolladores siempre quieren eliminar el trabajo pesado 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 seguir de cerca. No sabía cuánto sería parte de mi futura carrera. ¿Cómo se dio cuenta de que Kubernetes estaba en la posición líder en el mercado? Pronin: No fue algo repentino para mí. Sucedió lentamente. Soluciones como Apache Mesos, Docker Swarm e incluso AWS ECS (Elastic Container Service) se usaban ampliamente. La razón por la que Kubernetes ganó fue la comunidad. Su arquitectura conectable y su rápido desarrollo impulsaron su adopción y lentamente se comieron la participación de mercado de otras soluciones. Cuando analizó Kubernetes, ¿cómo abordó los datos? Pronin: Durante mucho tiempo, para mí, Kubernetes solo era para aplicaciones sin estado. Incluso teníamos barras de calidad bastante estrictas en nuestras plataformas donde no permitíamos aplicaciones con estado en Kubernetes. Este fue el pensamiento de aplicación de 12 factores en su máxima expresión sobre cómo diseñar y construir aplicaciones nativas de la nube escalables y resilientes. Uno de los principios básicos es tratar los servicios de back-end, incluidas las bases de datos, como recursos adjuntos, para promover el diseño de aplicaciones sin estado. ¿Qué problemas surgieron primero en relación con los datos y el almacenamiento con Kubernetes para usted? Pronin: 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 a través de algún hackeo básico. La integración con los proveedores de almacenamiento era inexistente, lo que significaba que la experiencia del usuario era bastante torpe. Luego, en 2019, AWS EKS (Elastic Kubernetes Service) comenzó oficialmente a admitir AWS EBS (Elastic Block Storage). Este podría ser el hito que comenzó a cambiar las percepciones. ¿Qué tuvo que cambiar? Pronin: El lanzamiento de Stateful Sets and Operators fue tres años después del primer lanzamiento, por lo que llevó algo de tiempo preparar Kubernetes. Una vez que se lanzaron, todavía llevó tiempo superar la reticencia a implementarlos. Se necesitaron muchas pruebas para superar ese obstáculo antes de que estuviéramos listos para cambiar nuestras políticas. ¿Cómo se involucró en el trabajo con operadores de Kubernetes? Pronin: 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 ese entonces era un campo completamente nuevo, con mucha incertidumbre y una comunidad relativamente pequeña. Yo creía firmemente en «Kubernetes para sin estado», por lo que fue todo un desafío comprender la idea. El equipo de liderazgo de Percona vio una oportunidad y percibió la tendencia del mercado mucho antes de que se volviera común. ¿Qué sucedió con los operadores que los convirtió en un éxito para los datos y el almacenamiento? Pronin: Es una combinación de eventos. En la era de los microservicios, los usuarios intentaron ejecutar bases de datos en contenedores Docker, fuera de Kubernetes. Esta es una tarea compleja, especialmente si hay agrupamiento en las implementaciones, que puede ser necesario para las bases de datos. Kubernetes se estaba convirtiendo en un estándar de facto para ejecutar microservicios y crear plataformas. Se lo describía como «una plataforma para crear plataformas» y creo que esa definición es precisa ahora. Kubernetes prometía resolver algunos de los problemas de complejidad, pero administrar bases de datos es difícil. Aprender todos los primitivos de Kubernetes y comprender los conceptos es para los valientes. Los operadores abstrajeron toda esta complejidad y redujeron significativamente la barrera de entrada. No solo 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 velocidad con la que se puede implementar la infraestructura, pero no puede encargarse de una consulta de base de datos por usted. ¿Cómo respaldó esto más enfoques nativos de la nube? ¿Cuáles fueron las consecuencias? Pronin: 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. El bloqueo de proveedores 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 para 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 ve hoy? Pronin: En los últimos 10 años, Kubernetes se ha convertido en el estándar de la industria y cambió fundamentalmente la forma en que se desarrollan e implementan las aplicaciones. Su impacto es innegable. Ha fomentado la innovación e impulsado el auge 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 aún existen en torno a Kubernetes en lo que respecta a los datos y el almacenamiento? Pronin: La complejidad sigue siendo un problema, incluso cuando los operadores están facilitando la gestión de los datos y los recursos de almacenamiento. En su mayoría, se debe a la falta de estandarización entre las distintas interfaces de almacenamiento de contenedores (CSI) y a las complejidades de las integraciones con diferentes proveedores de almacenamiento. Gestionar datos y almacenamiento en múltiples nubes o entornos híbridos puede ser un desafío debido a las diferencias en las API y configuraciones de almacenamiento. Existen varios intentos de simplificarlo a través de la federación o planos de control 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 que se ejecuten en Kubernetes, pero a veces se requieren soluciones alternativas para que funcionen. ¿Alguna otra anécdota o información para compartir? Pronin: Los operadores y las bases de datos en Kubernetes pasaron rápidamente de los trucos desde cero para que las cosas funcionaran a ser de nivel empresarial. Ahora se trata más de «cómo» que de «por qué» de las organizaciones de diferentes niveles. Los datos en Kubernetes ya no son «solo para los valientes». Son la corriente principal.