Llegamos a ustedes gracias a:



Casos de éxito

Por qué Mercedes-Benz funciona con 900 clústeres de Kubernetes

[29/06/2022] El equipo de tecnología detrás del fabricante de automóviles alemán Mercedes-Benz, ha pasado los últimos siete años construyendo una flota propia de 900 clústeres Kubernetes para apoyar a cientos de equipos de desarrolladores independientes, dando a la compañía una plataforma de infraestructura moderna que dice ser escalable y fácil de administrar.

El fabricante de automóviles empezó a probar Kubernetes para el despliegue de aplicaciones en el 2015, después de que Google abriera el sistema de orquestación de contenedores en el 2014. Desde entonces, Mercedes-Benz Tech Innovation -la filial centrada en la tecnología de propiedad absoluta del histórico fabricante de automóviles- ha desarrollado la experiencia interna para apoyar a cientos de equipos de aplicaciones alineados con la unidad de negocio con sus propias necesidades tecnológicas únicas.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

"Sabíamos que un único clúster compartido [Kubernetes] no se adaptaría a nuestras necesidades, ninguna distribución de proveedor se ajustaba a nuestros requisitos, y teníamos los ingenieros con experiencia", señala Jens Erat, un ingeniero de devops en Mercedes-Benz Tech Innovation durante KubeCon Europe el mes pasado. "Construimos una plataforma 100% FOSS [software libre de código abierto] construida y desarrollada por el mismo equipo de devops, sin problemas de licencias ni solicitudes de soporte".

En la actualidad, Mercedes-Benz está operando en 900 clústeres Kubernetes locales en cuatro centros de datos globales que utilizan OpenStack, ejecutando la versión 1.23 desde finales del 2021.

Aunque puede que no sea el mayor patrimonio de Kubernetes si se compara con los proveedores de la nube, solo el 10% de las organizaciones utilizan más de 50 clústeres, según la encuesta del 2019 de la Cloud Native Computing Foundation. También es casi cinco veces más grande que el entorno de Kubernetes del orador principal de KubeCon Europe, CERN, que ejecuta 210 clústeres en el momento de escribir este artículo.

¿Cuántas instancias de Kubernetes podría ejecutar Mercedes-Benz?

"Nos esforzamos mucho en hacer las cosas de manera que seamos capaces de gestionarlas", señala Peter Müller, experto principal de Mercedes-Benz Tech Innovation. "Para nosotros, los sistemas circundantes funcionan bien si estamos gestionando 500 clústeres, o mil, porque todo está automatizado... Si tuviéramos que añadir 500 clústeres más, tendríamos que añadir solo un ingeniero más".

Una parte clave de ese rompecabezas de gestión es Cluster API on OpenStack, un proyecto de Kubernetes que permite la creación, configuración y gestión declarativa de clústeres, por el que la empresa optó recientemente, en lugar de Terraform y algunas herramientas personalizadas. Sin embargo, como todo en tecnología, no es una solución perfecta. "El número de clústeres no es un problema. El problema que tenemos son algunos de los sistemas circundantes y a veces OpenStack", sostiene Müller. "Pero Kubernetes funciona bastante bien, se escala".

Cambiar la cultura

Cada uno de los varios cientos de equipos de aplicaciones en todo Mercedes-Benz tiene ahora la opción de solicitar su propio clúster Kubernetes, a través de un proceso automatizado que utiliza un conjunto de herramientas de cosecha propia, construido y gestionado por el equipo de Müller en Mercedes-Benz Tech Innovation. El resultado suele ser un clúster de producción preaprovisionado, así como clústeres de ensayo y desarrollo más pequeños, a las pocas horas, o incluso minutos, de realizar la solicitud.

"Desde una perspectiva organizativa, hace cinco o seis años, devops era el nuevo chico del barrio, todo el mundo hablaba de 'usted lo construye, usted lo ejecuta'. Como proveedor de una plataforma compartida, eso significa que cada equipo de aplicaciones dentro de Mercedes-Benz obtiene su propio clúster de Kubernetes", anota, por su parte, Jörg Schüler, jefe de equipo de Mercedes-Benz Tech Innovation.

"Nuestro objetivo es proporcionar un ecosistema y conseguir equipos de aplicaciones empoderados", añade. "Ese ecosistema se sustenta en los principios de autoservicio y de ser impulsado por las API".

Ese patrimonio está gestionado no por uno, sino por cinco equipos de plataforma separados. Dos de ellos forman un equipo combinado de alrededor de una docena de ingenieros que se centran en el núcleo de la plataforma Kubernetes-as-a-service. Además, hay equipos de plataforma responsables de la base de datos como servicio, el registro y la supervisión como servicio, y la seguridad de los contenedores, incluidos el tiempo de ejecución, el registro y el escaneo de imágenes.

Sin embargo, la incorporación de estos equipos sigue siendo difícil para la empresa. "Buscar buenos expertos en Kubernetes es difícil", comenta Schüler. "Proporcionar educación, formación y otras ofertas en torno a esta plataforma es realmente útil. Se necesita un enfoque comunitario para que los equipos de desarrolladores se ayuden mutuamente con campamentos de entrenamiento, portales de formación y entornos sandbox".

Caminos de oro hacia la nube

Después de haber acumulado todo este músculo para la gestión de Kubernetes a escala, Mercedes-Benz Tech Innovation se está preparando para empezar a mover más y más cargas de trabajo a la nube pública, donde podría utilizar más servicios gestionados como Azure Kubernetes Service (AKS) de Microsoft y Elastic Kubernetes Service (EKS) de Amazon, para ayudar a aligerar la carga cognitiva de la plataforma y los equipos de devops.

"Todavía estamos evaluando si optamos por EKS, pero de momento preferimos hacerlo por nuestra cuenta, porque así tenemos la misma arquitectura on-prem y off-prem", señala Müller.

Aunque esas versiones gestionadas de Kubernetes pueden ayudar a aligerar la carga de los equipos de la plataforma Mercedes-Benz Tech Innovation, los equipos de aplicaciones siguen necesitando ayuda para pasar a los contenedores y a Kubernetes.

Una ruta para acelerar el progreso aquí es la idea de las rutas doradas, que son esencialmente gráficos de Helm que se pueden utilizar como plantillas para ciertas funcionalidades -como la gestión de identidades y accesos- ahorrando en el trabajo repetido a través de diferentes equipos.

"Tenemos que proporcionar rutas doradas y algunas cosas como servicio para reducir esa carga cognitiva y permitirles ofrecer lo que mejor saben hacer: valor empresarial", señala Müller.

Por supuesto, los niveles de madurez variarán en todos esos equipos de aplicaciones, por lo que Müller considera que su función es ofrecerles un entorno seguro en el que aprender. Una vez que hayan madurado lo suficiente, podrán pasar a la nube, anota.

Utilizando algunas técnicas de código interno, Mercedes-Benz Tech Innovation gestiona algunas de estas rutas doradas, mientras que otras se encuentran en lo que Müller denomina "un estado de comunidad", en el que podrían considerarse para la propiedad y gestión completas si obtienen una buena respuesta.

Lo ideal es que estas rutas doradas acaben codificándose en un "catálogo al estilo de Spotify Backstage". Müller señala que actualmente están trabajando en "pruebas de concepto para un portal central de desarrolladores para la integración de todos los servicios, pero aún no hemos llegado a ese punto".

Para nosotros, la gestión de Kubernetes no es "difícil.

"Kubernetes sigue siendo difícil, no hay que dejar a los equipos de devops y desarrolladores solos", señala Sabine Wolz, propietaria de producto en Mercedes-Benz Tech Innovation, en el escenario durante la KubeCon Europe.

Sin embargo, Müller cree firmemente que la curva de aprendizaje espera ahora a los equipos de aplicaciones y no a los de la plataforma.

"Gestionar Kubernetes es difícil si no se está muy metido en ello. Pero en nuestra opinión, si lo estamos gestionando, queremos estar muy metidos en él, así que, para nosotros, gestionar Kubernetes no es difícil", dijo. "Kubernetes para proyectos de aplicaciones sigue siendo difícil. Consumir Kubernetes como un equipo de devops es a veces difícil".

Ayudar a los equipos de aplicaciones a entender la infraestructura subyacente sin necesariamente construir una experiencia profunda, es donde Müller espera que su equipo de plataforma pueda brillar. "Algunos equipos todavía están en máquinas virtuales y se mueven a un clúster de Kubernetes, y tienen que dividir su monolito, entender cómo se manejan las transacciones, pensar en la comunicación asíncrona y entender cómo funciona Kubernetes", sostiene. "Eso es difícil, así que no los dejen solos, ayúdenlos".

Volver a la portada

Primer Contacto

Más »

Casos de éxito

Más »