Capítulo 1. Introducción a Kubeflow Introducción a Kubeflow

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Kubeflow es una plataforma de código abierto nativa de Kubernetes para desarrollar, orquestar, implementar y ejecutar cargas de trabajo de aprendizaje automático (ML) escalables y portátiles. Es una plataforma nativa de la nube basada en las canalizaciones internas de ML de Google. El proyecto se dedica a hacer que las Implementaciones de flujos de trabajo de ML en Kubernetes sean sencillas, portátiles y escalables.

En este libro echamos un vistazo a la evolución del aprendizaje automático en la empresa, cómo ha cambiado la infraestructura y, a continuación, cómo Kubeflow satisface las necesidades de la empresa moderna.

El funcionamiento de Kubeflow en un mundo cada vez más multicloud e hybrid-cloud será un tema clave a medida que crezca el mercado y aumente la adopción de Kubernetes. Un único flujo de trabajo puede tener un ciclo de vida que comience en las instalaciones, pero que rápidamente requiera recursos que sólo están disponibles en la nube. La creación de herramientas de aprendizaje automático en la plataforma emergente Kubernetes es donde empezó la vida de Kubeflow, así que empecemos por ahí.

Aprendizaje automático en Kubernetes

Kubeflow nació como una forma básica de conseguir una infraestructura rudimentaria de aprendizaje automático en Kubernetes. Las dos fuerzas impulsoras de su desarrollo y adopción son la evolución del aprendizaje automático en las empresas y la aparición de Kubernetes como capa de gestión de infraestructuras de facto.

Hagamos un rápido recorrido por la historia reciente del aprendizaje automático en la empresa para comprender mejor cómo hemos llegado hasta aquí.

La evolución del aprendizaje automático en la empresa

En la última década, la popularidad y el interés por el aprendizaje automático han aumentado considerablemente. Esto puede atribuirse a desarrollos en la industria informática como:

  • Avances en los coches autónomos
  • Adopción generalizada de las aplicaciones de visión por ordenador (VC) de
  • Integración de herramientas como Amazon Echo en la vida cotidiana

El aprendizaje profundo tiende a llevarse gran parte del mérito de muchas herramientas en la actualidad, pero fundamentalmente el aprendizaje automático aplicado es la base de todos los desarrollos. El aprendizaje automático puede definirse como:

En el lenguaje cotidiano, cuando decimos aprendizaje, queremos decir algo así como "adquirir conocimientos mediante el estudio, la experiencia o la enseñanza". Afinando un poco nuestro enfoque, podemos pensar en el aprendizaje automático como el uso de algoritmos para adquirir descripciones estructurales a partir de ejemplos de datos. Un ordenador aprende algo sobre las estructuras que representan la información en los datos brutos.

Aprendizaje profundo por Josh Patterson y Adam Gibson (O'Reilly)

Algunos ejemplos de algoritmos de aprendizaje automático son la regresión lineal, los árboles de decisión y las redes neuronales. Debes considerar el aprendizaje automático como un subconjunto del dominio más amplio de la inteligencia artificial (IA).

A mediados de la década de 2000 se produjo el auge de la investigación en aprendizaje profundo, impulsado por la disponibilidad de GPU, conjuntos de datos mejor etiquetados y mejores herramientas. Este auge reavivó el interés por el aprendizaje automático aplicado en todas las empresas a principios de la década de 2010, en su búsqueda por aprovechar los datos y la inteligencia de las máquinas para ser "más como Google y Amazon".

Muchos de los primeros esfuerzos en el aprendizaje automático aplicado se centraron en la plataforma Apache Hadoop, ya que había experimentado un ascenso meteórico en su adopción por parte de las empresas en la primera mitad de la década de 2010. Sin embargo, mientras que Apache Hadoop se centraba en aprovechar el hardware básico con CPU y el procesamiento distribuido, los profesionales del aprendizaje profundo se centraban en máquinas individuales con una o más GPU y el entorno de programación Python. Apache Spark sobre Apache Hadoop ofrecía sólidas opciones para el aprendizaje automático aplicado en la JVM, aunque el profesional de nivel universitario tendía a formarse con el lenguaje de programación Python.

Las empresas empezaron a contratar a más profesionales del aprendizaje automático formados en programas de posgrado, lo que creó una gran afluencia de usuarios que demandaban soporte de Python para sus flujos de trabajo de aprendizaje automático aplicado.

En años anteriores, Spark había sido una tecnología clave para ejecutar trabajos de aprendizaje automático, pero en los últimos años vemos que las empresas están cambiando hacia la formación basada en GPU en contenedores que pueden no vivir en un clúster Hadoop. Los equipos de DevOps, TI y plataformas que trabajan con estos científicos de datos querían asegurarse de que estaban preparando a los equipos para el éxito, al tiempo que disponían de una estrategia de infraestructura manejable.

Los responsables de estas plataformas querían utilizar la nube de forma que no costara demasiado, y aprovechar la naturaleza transitoria de las cargas de trabajo basadas en la nube.

Existe una necesidad creciente de hacer que estos mundos funcionen juntos en los lagos de datos, ya sea en las instalaciones, en la nube o en algún lugar intermedio. En la actualidad, algunos de los principales retos en el espacio empresarial de los profesionales del aprendizaje automático son:

  • Los científicos de datos tienden a preferir su propio conjunto de bibliotecas y herramientas.
  • Este tipo de herramientas suelen ser heterogéneas, tanto dentro de los equipos como entre organizaciones.
  • Los científicos de datos necesitan interoperar con el resto de la empresa para la implementación de recursos, datos y modelos.
  • Muchas de sus herramientas están basadas en Python, donde los entornos Python resultan difíciles de gestionar en una gran organización.
  • Muchas veces, los científicos de datos quieren crear contenedores y luego "moverlos" para aprovechar recursos más potentes que su portátil, ya sea en el centro de datos local o en la nube.

Esto hace que el funcionamiento de una plataforma para apoyar a los diferentes componentes que utilizan el sistema sea más difícil que nunca.

Es más difícil que nunca gestionar la infraestructura empresarial

Vivimos progresivamente en una época en la que los desarrolladores y los científicos de datos se sienten capacitados para crear su propia infraestructura en la nube, por lo que para muchas organizaciones se ha vuelto antitético imponer normas estrictas de infraestructura a los profesionales del aprendizaje automático. Lo hemos visto en el espacio, donde los clientes acaban con tres o cuatro sistemas de canalización de aprendizaje automático diferentes porque los grupos no se ponen de acuerdo (y simplemente huyen a AWS o GCP para conseguir lo que quieren cuando les dicen "no").

Hadoop y Spark siguen siendo herramientas clave para el almacenamiento y procesamiento de datos, pero cada vez más Kubernetes ha entrado en escena para gestionar las cargas de trabajo locales, en la nube e híbridas. En los dos últimos años hemos visto cómo la adopción de Kubernetes aumentaba rápidamente. Muchas empresas han realizado inversiones en infraestructura en ciclos tecnológicos anteriores, como:

  • RDBMs
  • RDBM paralelos
  • Hadoop
  • Almacenes clave-valor
  • Chispa

Al igual que los sistemas anteriores, estos sistemas tienen un cierto nivel de inercia heredada en sus organizaciones adoptivas. Por lo tanto, es fácil predecir que la integración entre las cargas de trabajo de Hadoop y las cargas de trabajo especializadas de aprendizaje automático basadas en Kubernetes están en el horizonte, como vemos cuando Cloudera utiliza Kubernetes para sus nuevas herramientas de ciencia de datos en lugar de YARN, y Google cambia YARN por Kubernetes para Spark.

Otros factores que hacen que la ejecución de la infraestructura sea más compleja que nunca son la evolución de la aceptación del código abierto en la empresa, que utiliza tanto la infraestructura local como la de la nube. Además, los requisitos de seguridad son necesarios para soportar la complejidad de múltiples plataformas y multitenancy. Por último, también estamos viendo demandas de hardware especializado, como GPUs y TPUs.

Algunas tendencias generales de las infraestructuras que señalamos como interesantes de cara al futuro:

  • Cada vez son más populares entre las empresas las implementaciones mixtas en las instalaciones, en la nube e híbridas.
  • Los tres principales proveedores de "grandes nubes" siguen captando una serie de cargas de trabajo que se trasladan a la nube; algunas de estas cargas de trabajo oscilan entre la nube y las instalaciones locales.
  • Docker es sinónimo del término contenedor.
  • Muchas empresas utilizan Kubernetes o están considerando seriamente utilizarlo como plataforma de orquestación de contenedores.

Más allá de un clúster local, los clústeres Kubernetes pueden unirse mediante la federación de clústeres dentro de Kubernetes. En un mundo verdaderamente híbrido, podemos tener una política de programación de trabajos que coloque determinadas cargas de trabajo en la nube porque los recursos locales están sobreocupados o, por el contrario, restringir determinadas cargas de trabajo para que se ejecuten sólo en las instalaciones y nunca se ejecuten en la nube. Kubernetes también hace que las cargas de trabajo sean más agnósticas con respecto a la plataforma, porque abstrae las especificidades de la plataforma subyacente, convirtiendo a Kubernetes en la abstracción clave.

Hay muchos factores a tener en cuenta cuando se trata de una infraestructura en la nube, o de una infraestructura híbrida de clúster federado, entre ellos:

  • Integración con Active Directory (AD)
  • Consideraciones de seguridad
  • Consideraciones sobre el coste de las instancias en la nube
  • Qué usuarios deben tener acceso a las instancias en la nube

En el Capítulo 2 y en el resto de este libro profundizamos en todos estos temas.

Identificación de los Principios Básicos de la Infraestructura de Nueva Generación (NGI)

En la era de la infraestructura en la nube, lo que hace la "gran nube" (AWS, Azure, Google Cloud Platform [GCP]) tiende a influir significativamente en la forma en que las empresas construyen hoy su propia infraestructura. En 2018 vimos que los tres principales proveedores de la nube ofrecían Kubernetes gestionado como parte de su infraestructura :

A finales de 2017, tras ofrecer inicialmente su propio servicio de contenedores, Amazon se unió a los otros dos miembros de big cloud y ofreció Amazon EKS como ciudadano de primera clase compatible en AWS.

Los tres principales proveedores de la nube están impulsando Kubernetes, y estos vientos de cola deberían acelerar el interés por Kubernetes y Kubeflow. Más allá de eso, hemos visto cómo los contenedores son una parte clave de cómo los científicos de datos quieren operar en la gestión de contenedores desde la ejecución local, pasando por la infraestructura local, hasta la ejecución en la nube (de forma fácil y limpia).

Los equipos necesitan equilibrar la multitenencia con el acceso a opciones de almacenamiento y computación (NAS, HDFS, FlashBlade) y GPU de gama alta (Nvidia DGX-1, etc.). Los equipos también necesitan una forma flexible de personalizar sus aplicaciones completas de aprendizaje automático aplicado, desde ETL, a modelado, a implementación de modelos; pero de una forma que se mantenga dentro de los inquilinos anteriores.

Vemos que los proveedores de la nube tienen una influencia cada vez mayor en la forma en que las empresas construyen su infraestructura, donde los servicios gestionados que suelen propugnar probablemente consigan una adopción acelerada. Sin embargo, la mayoría de las organizaciones están separadas de la obtención de resultados de los esfuerzos de la ciencia de datos en su organización por los obstáculos enumerados en la última sección. Podemos desglosar estos obstáculos en los siguientes componentes clave :

Composibilidad

Este componente consiste en descomponer los flujos de trabajo de aprendizaje automático en una serie de componentes (o etapas) en una secuencia, y permitirnos juntarlos en diferentes formaciones. Muchas veces, estas etapas son cada una sus propios sistemas y necesitamos trasladar la salida de un sistema a otro como entrada.

Portabilidad

Este componente implica disponer de una forma coherente de ejecutar y probar el código:

  • Desarrollo
  • Puesta en escena
  • Producción

Cuando tenemos deltas entre esos entornos, introducimos oportunidades de tener interrupciones en la producción. Tener una pila de aprendizaje automático que pueda ejecutarse en tu portátil, del mismo modo que se ejecuta en una DGX-1 multi-GPU y luego en una nube pública, sería considerado deseable por la mayoría de los profesionales de hoy en día.

Escalabilidad

La mayoría de las organizaciones también desean escalabilidad, y se ven limitadas por:

  • Acceso a hardware específico de la máquina (por ejemplo, GPUs, TPUs)
  • Computación limitada
  • Red
  • Almacenamiento
  • Hardware heterogéneo

Por desgracia, la escala no consiste en "añadir más hardware", en muchos casos se trata de la arquitectura de sistemas distribuidos subyacente. Kubernetes nos ayuda con estas limitaciones.

Kubernetes para la Implementación de Aplicaciones de Producción

Kubernetes es un sistema de orquestación de contenedores destinado a coordinar clusters de nodos a escala, en producción, de forma eficiente. Kubernetes funciona en torno a la idea de pods, que son unidades de programación (cada pod contiene uno o más contenedores) en el ecosistema Kubernetes. Estos pods se distribuyen entre los hosts de un clúster para proporcionar alta disponibilidad. Kubernetes en sí no es una solución completa y está pensada para integrarse con otras herramientas como Docker, una popular tecnología de contenedores .

Una imagen de contenedor es un paquete ejecutable ligero e independiente de un programa informático que incluye todo lo necesario para ejecutarlo (código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema, configuración). Coloquialmente, se hace referencia a los contenedores como "Docker", pero lo que el hablante suele querer decir son contenedores en sentido general. Los contenedores Docker facilitan significativamente que los desarrolladores disfruten de paridad entre sus entornos locales, de pruebas, de ensayo y de producción. Los contenedores permiten a los equipos ejecutar el mismo artefacto o imagen en todos esos entornos, incluido el portátil de un desarrollador y en la nube. Esta propiedad de los contenedores, especialmente cuando se combina con la orquestación de contenedores con un sistema como Kubernetes, está impulsando el concepto de nube híbrida en la práctica.

Una de las principales razones por las que vemos hoy en día una adopción generalizada de contenedores (por ejemplo, Docker) y Kubernetes es porque juntos son una solución de infraestructura excepcional para los problemas inherentes a la componibilidad, la portabilidad y la escalabilidad. Kubernetes brilla cuando tenemos muchos contenedores que deben gestionarse en muchas máquinas (locales, en la nube o una mezcla de ambas).

¿Qué son los contenedores?

Una imagen de contenedor es un paquete de software ejecutable, ligero e independiente que incluye el código, el tiempo de ejecución, las herramientas y bibliotecas del sistema y la configuración necesaria para ejecutarlo. Los contenedores y las plataformas de contenedores ofrecen más ventajas que la virtualización tradicional porque:

  • El aislamiento se realiza a nivel del núcleo, sin necesidad de un sistema operativo invitado.
  • Los contenedores son mucho más eficaces, rápidos y ligeros.

Esto permite que las aplicaciones se encapsulen en entornos autocontenidos. Otras ventajas son la rapidez de las Implementaciones, la escalabilidad y una mayor paridad entre los entornos de desarrollo.

Docker y Kubernetes no son competidores directos, sino tecnologías complementarias. Una forma de verlo es que Docker sirve para gestionar imágenes y contenedores individuales, mientras que Kubernetes sirve para gestionar pods de contenedores. Docker proporcionó un estándar abierto para empaquetar y distribuir aplicaciones en contenedores, pero no resolvió el problema de la orquestación de contenedores (intercomunicación, escalado, etc.). Los competidores de Kubernetes en este espacio son Mesos y Docker Swarm, pero estamos viendo que la industria converge hacia Kubernetes como el estándar para la orquestación de contenedores.

Con Kubernetes también tenemos la capacidad de escalar dinámicamente las aplicaciones en un clúster. Con opciones instalables como Kubernetes Horizontal Pod Autoscaler, también tenemos la capacidad de escalar los propios clústeres.

Kubernetes permite a las aplicaciones escalar horizontalmente en el ámbito de los nodos y contenedores (pods), al tiempo que proporciona tolerancia a fallos y una infraestructura autorregenerativa que mejora la fiabilidad. Kubernetes también proporciona un uso eficiente de los recursos para las aplicaciones desplegadas en las instalaciones o en la nube. También se esfuerza por que todas las aplicaciones desplegadas estén disponibles 24 horas al día, 7 días a la semana, al tiempo que permite a los desarrolladores desplegar aplicaciones o actualizaciones varias veces al día sin tiempo de inactividad.

Kubernetes es, además, una gran opción para las cargas de trabajo de aprendizaje automático porque ya tiene soporte para GPUs y TPUs como recursos, con FPGAs en desarrollo. En la Figura 1-2 podemos ver cómo tener abstracciones clave con contenedores y otras capas es significativo para ejecutar un trabajo de entrenamiento de aprendizaje automático en GPUs de forma similar a como podrías ejecutar el mismo trabajo en FPGAs.

Figura 1-2. Contenedores y abstracción del hardware

Destacamos las abstracciones de la Figura 1-2 porque todas ellas son componentes de los retos que plantea la portabilidad del flujo de trabajo. Un ejemplo de ello es cómo nuestro código puede funcionar localmente en nuestro propio ordenador portátil, pero no ejecutarse remotamente en una máquina virtual de Google Cloud con GPUs.

Kubernetes también dispone ya de controladores para tareas como los trabajos por lotes y la implementación de servicios de larga duración para el alojamiento de modelos, lo que nos proporciona muchos componentes fundamentales para nuestra infraestructura de aprendizaje automático. Además, como gestor de recursos, Kubernetes proporciona tres ventajas principales :

  • Gestión unificada
  • Aislamiento laboral
  • Infraestructuras resistentes

La gestión unificada nos permite utilizar una única interfaz de gestión para varios clústeres de Kubernetes. El aislamiento de trabajos en Kubernetes nos ofrece la posibilidad de trasladar modelos y canalizaciones de extracción, transformación y carga (ETL) del desarrollo a la producción con menos problemas de dependencia. La infraestructura resistente implica cómo Kubernetes gestiona los nodos del clúster por nosotros, y se asegura de que tengamos suficientes máquinas y recursos para realizar nuestras tareas.

Kubernetes como plataforma se ha escalado en la práctica hasta los miles de nodos. Aunque muchas organizaciones no alcanzarán ese orden de magnitud de nodos, pone de relieve el hecho de que Kubernetes (la plataforma en sí) no tendrá problemas de escala desde el punto de vista de un sistema distribuido como plataforma.

Kubernetes no es magia

Toda aplicación de sistemas distribuidos requiere un diseño meditado. No caigas en la idea de que Kubernetes escalará mágicamente cualquier aplicación sólo porque alguien la haya metido en un contenedor y la haya enviado a un clúster.

Aunque podemos resolver los problemas relacionados con el traslado de contenedores y pilas de flujos de trabajo de aprendizaje automático, no estamos totalmente libres. Todavía tenemos otras consideraciones, como

  • El coste de utilizar la nube frente al coste local
  • Normas organizativas sobre dónde pueden vivir los datos
  • Consideraciones de seguridad como la integración de Active Directory y Kerberos

Estos son sólo algunos ejemplos. La infraestructura moderna del centro de datos tiene muchas variables en juego, y puede hacer la vida difícil a un equipo de TI o DevOps. En este libro pretendemos, al menos, armarte con un plan de ataque sobre la mejor forma de planificar y satisfacer las necesidades de tus componentes de ciencia de datos, todo ello manteniéndote en línea con las políticas de la organización.

Kubernetes resuelve muchos problemas de infraestructura en un mundo de infraestructuras progresivamente complejo, pero no se diseñó específicamente para los flujos de trabajo del aprendizaje automático.

Para profundizar en Kubernetes

Consulta el Apéndice B de este libro, o alguno de los otros libros de O'Reilly sobre Kubernetes, como Kubernetes: Up and Running, de Brendan Burns et al.

Echemos ahora un vistazo a cómo Kubeflow entra en escena para ayudar a habilitar los flujos de trabajo de aprendizaje automático.

Entra: Kubeflow

Kubeflow se concibió como una forma de ejecutar flujos de trabajo de aprendizaje automático en Kubernetes y se suele utilizar por las siguientes razones:

  • Quieres entrenar/servir modelos de aprendizaje automático en distintos entornos (por ejemplo, local, local y en la nube).
  • Quieres utilizar Jupyter Notebooks para gestionar trabajos de entrenamiento de aprendizaje automático (no sólo trabajos de TensorFlow).
  • Quieres lanzar trabajos de entrenamiento que utilizan recursos (como CPUs o GPUs adicionales, que no están disponibles en tu ordenador personal).
  • Quieres combinar código de aprendizaje automático de distintas bibliotecas.

A veces, como describe el último ejemplo, queremos combinar nuestro código TensorFlow con otros procesos. En este ejemplo, podríamos querer utilizar TensorFlow/agentes para ejecutar simulaciones que generen datos para entrenar modelos de aprendizaje por refuerzo (RL). Con Kubeflow Pipelines podríamos encadenar estas dos partes distintas de un flujo de trabajo de aprendizaje automático.

Con nuestra plataforma de aprendizaje automático, normalmente, nos gustaría un patrón operativo similar al del "laboratorio y la fábrica". De este modo, queremos que nuestros científicos de datos puedan explorar nuevas ideas de datos en "el laboratorio", y una vez que encuentren una configuración que les guste, trasladarla a "la fábrica" para que el flujo de trabajo de modelado pueda ejecutarse de forma coherente y reproducible. En la Figura 1-3 podemos ver una representación generalizada de un flujo de trabajo común de aprendizaje automático.

Figura 1-3. El flujo de trabajo generalizado del aprendizaje automático

Kubeflow se diseñó para operar flujos de trabajo de aprendizaje automático, como el representado en la Figura 1-3, a través de las muchas limitaciones diferentes que hemos señalado hasta ahora en este capítulo. Dos sistemas clave (cubiertos en detalle arquitectónico en el Capítulo 2) que son grandes ejemplos del valor que Kubeflow proporciona más allá de Kubernetes son el sistema de cuadernos en Kubeflow, y Kubeflow Pipelines. Volveremos a referirnos a este diagrama varias veces en el libro para contextualizar cómo las partes de Kubeflow interactúan como un todo para lograr los objetivos de los equipos de DevOps y ciencia de datos.

Kubeflow es una gran opción para la infraestructura de Fortune 500, porque permite que un sistema de modelado basado en cuadernos se integre fácilmente con las operaciones ETL del lago de datos en un lago de datos local o en la nube de forma similar. También admite la multitenencia a través de hardware diferente mediante la gestión del aspecto de orquestación de contenedores de la infraestructura. Kubeflow nos ofrece grandes opciones para un entorno de "laboratorio" multiinquilino, a la vez que proporciona infraestructura para programar y mantener flujos de trabajo de producción de aprendizaje automático coherentes en "la fábrica".

Aunque hoy en día los equipos pueden compartir potencialmente un servidor, cuando intentamos gestionar 5 ó 10 servidores, cada uno con varias GPUs, creamos rápidamente una situación en la que la multitenencia puede volverse engorrosa. Los usuarios acaban teniendo que esperar por los recursos, y también pueden estar luchando contra dependencias o bibliotecas que otros usuarios dejaron atrás de trabajos anteriores. También está la dificultad de aislar a los usuarios entre sí, para que no puedan ver los datos de los demás.

Si tenemos alguna esperanza de mantener una práctica sólida de ciencia de datos en un clúster de hardware heterogéneo, necesitaremos utilizar un sistema como Kubeflow y Kubernetes. Más allá de los obstáculos que mencionamos aquí, los flujos de trabajo del aprendizaje automático tienden a tener mucha deuda técnica justo debajo de la superficie visible.

¿Qué problemas resuelve Kubeflow?

El objetivo de Kubeflow es simplificar la implementación de flujos de trabajo de aprendizaje automático en Kubernetes. El problema de utilizar directamente la API de Kubernetes es que tiene un nivel demasiado bajo para la mayoría de los científicos de datos. Un científico de datos ya tiene que conocer una serie de técnicas y tecnologías sin necesidad de añadir a la lista las complejidades de la API de Kubernetes.

Envolver los modelos de aprendizaje automático de Python en contenedores es la forma en que mucha gente empieza a poner en producción los modelos iniciales. A partir de ahí, la implementación del contenedor en un pod en Kubernetes es el siguiente paso natural (como podemos ver en las tendencias del mercado). A medida que se despliegan más aplicaciones de aprendizaje automático en Kubernetes, este efecto de gravedad tiende a atraer también más trabajo de aprendizaje automático. Sin embargo, desde el punto de vista de DevOps, pronto estarás implementando una plataforma completa de ciencia de datos multiusuario en Kubernetes desde cero.

Hay muchos detalles adicionales de los que preocuparse, con todo el código "pegamento" implicado en hacer que cosas como los servidores de cuadernos y las canalizaciones funcionen de forma coherente y segura como un sistema distribuido. Muchas veces, el trabajo de la ciencia de datos consiste en gran medida en secuencias de comandos, en lugar de aplicaciones completas, y esto hace que su implementación como flujo de trabajo de producción desde cero sea mucho más difícil. Más allá de la API de Kubernetes, también tendrías que escribir código personalizado para integrar diferentes componentes en ejecución y también orquestar los componentes para cosas como la orquestación del flujo de trabajo.

Añadir nodos en Kubernetes y esperar que funcionen como una plataforma cohesionada no siempre es tan fácil. Es habitual que las organizaciones elaboren scripts de automatización que configuren rápidamente un usuario en un entorno en la nube, ejecuten el conjunto de trabajo o trabajos y, a continuación, desmantelen el entorno. Sin embargo, esto se vuelve engorroso, ya que puede haber problemas de integración no triviales en torno a Active Directory (gestión de usuarios) o Kerberos, por ejemplo.

Quieres que un científico de datos se centre en el trabajo de desarrollar, entrenar, probar e implementar modelos y menos en cómo conseguir que la API de Kubernetes funcione de tal manera que haga posible su trabajo principal. Los problemas que Kubeflow resuelve más allá del núcleo de la API de Kubernetes son:

  • Implementaciones más rápidas y coherentes
  • Mejor control de los puertos y del acceso a los componentes para una seguridad más estricta
  • Protección contra el sobreaprovisionamiento de recursos, ahorrando costes
  • Protección para que las tareas no se desasignen una vez finalizadas, ahorrando costes
  • Orquestación del flujo de trabajo y recopilación de metadatos
  • Monitoreo y registro centralizados
  • Infraestructura para pasar modelos a producción, de forma segura y a escala

El nombre Kubeflow es un portmanteau de Kubernetes y TensorFlow. Los tres proyectos surgieron de equipos de Google como proyectos de código abierto. Sin embargo, aunque Kubeflow comenzó como una forma de poner en producción los flujos de trabajo y modelos de TensorFlow, ha evolucionado más allá de su estado inicial.

Kubeflow no te encierra en TensorFlow

Tus usuarios pueden elegir el marco de aprendizaje automático para sus cuadernos o flujos de trabajo según les convenga.

Hoy en día, Kubeflow puede orquestar flujos de trabajo para contenedores que ejecutan muchos tipos diferentes de marcos de aprendizaje automático (XGBoost, PyTorch, etc.). En algunos casos, un equipo puede querer utilizar Kubeflow para gestionar servidores de portátiles para un entorno multiusuario que puede que ni siquiera se centre en el aprendizaje automático.

Un trabajo en Kubeflow puede ser un Jupyter Notebook o puede ser un script de Python en una serie de trabajos conectados por tuberías. Un trabajo en Kubeflow también puede ser tan sencillo como ejecutar un script de Python en un contenedor en un pod en Kubernetes a través de kubectl. Utilizamos cuadernos, la CLI o pipelines para configurar flujos de trabajo de aprendizaje automático que ejecutan un trabajo o una serie de trabajos para construir modelos de aprendizaje automático.

Para cualquiera de estos flujos de trabajo, utilizamos Kubeflow como infraestructura más allá de la API de bajo nivel de Kubernetes para orquestar de forma segura flujos de trabajo heterogéneos de aprendizaje automático sobre hardware heterogéneo gestionado y programado por Kubernetes. Kubeflow es la capa entre el usuario y la API de Kubernetes que hace posible operar esto de forma consistente como una plataforma escalable de aprendizaje automático multiusuario.

En el Capítulo 2 examinaremos más detenidamente la arquitectura de Kubeflow y sus subsistemas. Veremos cómo la arquitectura resuelve problemas específicos en este espacio, y cómo los componentes encajan entre sí para formar la solución de plataforma de aprendizaje automático que es Kubeflow.

Origen de Kubeflow

En Google Next de 2016, Google anunció Cloud Machine Learning (Cloud ML) en Google Cloud Platform (GCP). Cloud ML utiliza GKE, un precursor de lo que hoy conocemos como Kubeflow. En diciembre de 2017, en la KubeCon, David Aronchick y Jeremy Lewi anunciaron y presentaron la versión inicial de Kubeflow. Esta versión incluía:

  • JupyterHub
  • TFJob v1alfa1
  • TFServicio
  • GPUs trabajando en Kubernetes

En enero de 2018, se publicó la Propuesta de Gobernanza de Kubeflow para ayudar a dirigir cómo trabajaría la comunidad en torno al proyecto. En junio de 2018, se presentó la versión 0.1 de Kubeflow, que contiene un conjunto ampliado de componentes, entre los que se incluyen:

  • JupyterHub
  • TFJob con soporte de formación distribuido
  • TFServicio
  • Argo
  • Núcleo Seldon
  • Embajador
  • Mejor soporte para Kubernetes

La versión 0.2 de Kubeflow se anunció sólo dos meses después, en agosto de 2018, con avances como:

  • TFJob v1alfa2
  • Operadores PyTorch y Caffe
  • IU Central

El proyecto sigue (en el momento de escribir este libro) creciendo, y Kubeflow sigue evolucionando. En la actualidad, el proyecto se ha ampliado hasta el punto de que más de 100 ingenieros trabajan en él (frente a los 3 del principio), con la participación de 22 organizaciones miembro.

¿Quién utiliza Kubeflow?

Algunas de las personas clave de la empresa que más interés tienen en Kubeflow son:

  • Ingenieros DevOps
  • Arquitectos de plataforma
  • Científicos de datos
  • Ingenieros de datos

Los arquitectos de DevOps y plataformas deben apoyar a todos con la infraestructura adecuada en los lugares adecuados, en la nube o en las instalaciones, respaldando los esfuerzos de ingesta, ETL, almacén de datos y modelado de otros equipos. Los ingenieros de datos utilizan esta infraestructura para preparar a los científicos de datos con los mejores conjuntos de datos desnormalizados para la vectorización y el modelado de aprendizaje automático. Todos estos equipos necesitan trabajar juntos para operar en el almacén de datos moderno, y Kubernetes les da mucha flexibilidad en cómo hacerlo.

Alineación de equipos para la línea de negocio, DevOps, ingeniería de datos y ciencia de datos

Otro reto para las organizaciones en el espacio de la infraestructura del aprendizaje automático es lo polifacéticos que son los esfuerzos para construir y dar soporte a estas canalizaciones. Como vimos en la Figura 1-4, hay mucha "deuda técnica oculta" en la mayoría de los flujos de trabajo de aprendizaje automático, y los componentes de estos flujos de trabajo son propiedad de múltiples equipos. Estos equipos incluyen :

Sector de actividad
La parte de la empresa que pretende utilizar los resultados del modelo de aprendizaje automático para producir ingresos para la organización
DevOps
El grupo responsable de garantizar que la plataforma sea operativa y segura
Ingeniería de datos
El grupo responsable de obtener los datos del sistema de registro (o almacén de datos) y convertirlos en un formato que pueda utilizar el equipo de ciencia de datos
Ciencia de datos
El equipo responsable de construir y probar el modelo de aprendizaje automático

Cada uno de estos equipos tiene que trabajar en concierto o la empresa probablemente no encontrará ningún valor en sus esfuerzos individuales. Echemos ahora un vistazo a algunos escenarios concretos en los que podríamos ver utilizado Kubeflow para los equipos mencionados.

Casos de uso comunes de Kubeflow

Los escenarios específicos sobre cómo utilizaríamos una tecnología son siempre fundamentales porque, de lo contrario, no es más que "más infraestructura que gestionar". En esta sección veremos algunos casos de uso específicos sobre cómo puede utilizarse Kubeflow, y cómo podría participar cada uno de los equipos de la sección anterior.

Ejecutar portátiles en GPU

Los usuarios suelen empezar en plataformas locales como Anaconda y diseñar casos de uso iniciales. A medida que sus casos de uso necesitan más datos, un procesamiento más potente o datos que no pueden copiarse en su portátil local, tienden a toparse con obstáculos para avanzar en sus actividades de modelización.

También observamos que ejecutar Jupyter localmente proporciona al usuario la misma experiencia que ejecutarlo remotamente en Kubeflow, porque una instalación local es una instalación de servidor que sólo se ejecuta en el escritorio. Desde esa perspectiva, los usuarios disfrutan de la misma experiencia de uso de Jupyter Notebooks en su escritorio que en la plataforma de cuadernos Kubeflow.

Ventajas de los portátiles con GPU

Dado que muchos usuarios de portátiles se inician localmente en su portátil, esto nos lleva naturalmente a la pregunta: "¿por qué utilizar Kubeflow para la infraestructura de portátiles alojados?" El aprendizaje automático, y especialmente los algoritmos de entrenamiento de aprendizaje profundo, están notoriamente hambrientos de potencia de procesamiento para sus rutinas de álgebra lineal. Las GPU se han convertido en el estándar del sector para acelerar el procesamiento del álgebra lineal en el aprendizaje automático. La mayoría de los portátiles no tienen GPU a bordo, por lo que los usuarios buscan lugares donde ejecutar eventualmente su código de modelado. Una pila de plataformas común en la que han convergido los usuarios es ésta:

  • Cuaderno Jupyter
  • Código Python
  • Gestión de dependencias con contenedores, típicamente Docker

Estos desarrolladores son buenos consiguiendo esta pila justo como la quieren en su portátil. Sin embargo, operar así en una empresa Fortune 500 tiene efectos secundarios como:

  • Seguridad
  • Acceso a los datos
  • Gestión de conductores
  • Integración de modelos

Las organizaciones de TI de la mayoría de las empresas de Fortune 500 se toman muy en serio la seguridad y el acceso a los datos. La idea de que los doctores experimenten con datos corporativos sensibles en sus portátiles locales entra en conflicto directo con la mayoría de las políticas de seguridad de la información de TI, y esto crea una contención natural en una organización. Esta contención gira en torno a la necesidad de la línea de negocio de obtener más valor de sus datos, frente al mandato de la seguridad de la información informática de mantener a salvo la información clave.

Dado que las empresas no van a renunciar a sus requisitos de seguridad, tenemos que encontrar formas de servir mejor a los científicos de datos y a cómo quieren operar, manteniendo intactas las políticas de seguridad. Kubeflow es una gran opción para este escenario porque permite a un científico de datos mantener su entorno de trabajo preferido, construido en un contenedor, para ejecutar en un entorno bendecido por la seguridad corporativa de TI.

Esta infraestructura interna puede asegurarse con Active Directory y Kerberos, al tiempo que proporciona GPUs (por ejemplo, DGX-1 de Nvidia) y grandes matrices de almacenamiento con almacenes de objetos, almacenamiento propietario (por ejemplo, FlashBlade de Pure, almacenamiento de NetApp) o HDFS.

Alineación de equipos para portátiles en GPUs

En este escenario, el equipo de DevOps puede permitir a los científicos de datos construir modelos más rápidamente con Kubeflow. Esto permite a los científicos de datos explorar más rápidamente más conceptos para la línea de negocio, y esto les permite eliminar más rápidamente los casos de uso malos candidatos.

Si la línea de negocio puede validar los casos de uso más rápidamente con el equipo de ciencia de datos, podrán encontrar los mejores ajustes para que la empresa saque el máximo provecho de sus datos.

Entorno compartido de aprendizaje automático multiusuario

Muchas veces, una organización tendrá múltiples científicos de datos que necesitan compartir un clúster de recursos de alto valor (por ejemplo, GPUs) o tendrá múltiples equipos de científicos de datos que necesitan el mismo acceso a recursos compartidos. En este caso, una organización necesita construir una plataforma de aprendizaje automático multiusuario, y Kubeflow es un candidato sólido para este escenario.

A menudo veremos que las organizaciones compran máquinas con una o más GPU conectadas a hardware especializado, como una Nvidia DGX-1 o DGX-2 (por ejemplo, ocho GPU por máquina). Este hardware es considerablemente más costoso que un servidor tradicional, por lo que queremos que el mayor número posible de científicos de datos lo aprovechen para el entrenamiento de modelos.

Ventajas del entorno multiusuario local

Cada científico de datos tendrá su propio modelo de flujo de trabajo y dependencias de código, como se ha descrito anteriormente en este capítulo. Necesitamos un sistema como Kubeflow que pueda ejecutar el flujo de trabajo de cada usuario manteniendo las dependencias del flujo de trabajo y los datos separados del trabajo de otros usuarios en el mismo conjunto de recursos (por ejemplo, aislamiento).

Kubeflow y Kubernetes gestionan estos requisitos por nosotros con sus funciones de programación y gestión de contenedores. Un gran ejemplo es cómo podemos tener tres científicos de datos diferentes que necesitan ejecutar cada uno su propio cuaderno en una única GPU. Kubernetes con Kubeflow gestiona el seguimiento de quién está ejecutando qué código en qué máquina y qué GPU se están utilizando en ese momento. Kubernetes también realiza un seguimiento de los trabajos que están esperando en la cola de trabajos, y programará los trabajos en espera una vez que finalice un trabajo en proceso.

Alineación del equipo

Los sistemas multiinquilino simplifican mucho la vida de los equipos de DevOps, porque manejan gran parte de la complejidad de la infraestructura por nosotros. DevOps puede centrarse en mantener operativos el clúster Kubernetes y la aplicación Kubeflow, lo que nos permite aprovechar todas las ventajas de la programación, la programación de contenedores y la gestión de recursos en Kubernetes.

Cuando los científicos de datos tienen un acceso más flexible a los recursos que necesitan (por ejemplo, GPUs), pueden construir modelos más rápidamente. Esto, a su vez, permite a la línea de negocio evaluar más rápidamente un producto de datos para ver si puede ser lo suficientemente eficaz como para ser viable para la organización.

Construir un proceso de aprendizaje por transferencia

Utilicemos un escenario de visión por ordenador para comprender mejor cómo podría implementarse Kubeflow para resolver un problema real. Un ejemplo realista sería el de un equipo que quisiera poner en funcionamiento un canal de aprendizaje por transferencia de visión por ordenador para poder crear un modelo de visión por ordenador personalizado para detectar artículos concretos en una tienda.

El plan básico del equipo consiste en

  • Conseguir que funcione un modelo básico de visión por ordenador a partir del zoo de modelos TensorFlow
  • Actualizar el modelo con un conjunto de datos de ejemplo para comprender el aprendizaje por transferencia
  • Trasladar el código de entrenamiento del modelo a Kubeflow para aprovechar las GPU locales

El equipo comienza experimentando con el cuaderno de ejemplo de detección de objetos proporcionado en el tutorial de detección de objetos de TensorFlow. Una vez que tengan este cuaderno ejecutándose localmente, sabrán que pueden producir inferencias para objetos en una imagen con un modelo de visión por ordenador TensorFlow preconstruido.

A continuación, el equipo quiere personalizar un modelo de visión por ordenador a partir del modelo zoo con su propio conjunto de datos, pero primero necesita hacerse una idea de cómo funciona el aprendizaje por transferencia en la práctica. El equipo consulta la documentación de TensorFlow sobre aprendizaje por transferencia para obtener más información sobre la creación de un modelo de visión por ordenador personalizado.

Una vez que tengan el ejemplo de aprendizaje por transferencia funcionando con el conjunto de datos personalizado, no debería ser difícil etiquetar algunos de sus propios datos de producto para crear las anotaciones necesarias para seguir entrenando su propio modelo personalizado de visión por ordenador.

El ejemplo de la flor original muestra cómo utilizar el cuaderno en Google Cloud como un cuaderno de Google Colab, pero el equipo quiere aprovechar un clúster de GPUs que tienen en su propio centro de datos. En este punto, el equipo configura Kubeflow en su clúster interno de Kubernetes y ejecuta el cuaderno de aprendizaje por transferencia como un cuaderno Jupyter en Kubeflow. El equipo había creado previamente su propio conjunto de datos anotados personalizados, que ahora pueden utilizar para crear modelos en su propio clúster interno de Kubeflow.

Ventajas de ejecutar el pipeline de visión artificial en Kubeflow

Las principales razones por las que el equipo traslada su pipeline a Kubeflow son:

  • Acceso seguro a datos sensibles para varios usuarios (datos que no pueden permanecer en los portátiles de los usuarios)
  • Ahorro de costes mediante el uso de GPU locales
  • Posibilidad de que varios usuarios compartan el mismo cluster de GPUs

El equipo considera que, en algunos escenarios de entrenamiento, Kubeflow en las instalaciones puede ser más rentable por hora de GPU que las GPU en la nube. También quieren controlar de forma segura dónde se aloja el conjunto de datos de entrenamiento central, y quieren tener la capacidad de permitir que varios científicos de datos compartan el mismo conjunto de datos de entrenamiento consistente mientras prueban diferentes variaciones de modelos.

Alineación de equipos para el pipeline de visión por ordenador

Este escenario de aprendizaje por transferencia en Kubeflow permite al equipo de DevOps controlar más estrictamente quién tiene una copia de los datos de entrenamiento sensibles. La línea de negocio ha encargado al equipo de ciencia de datos que construya un modelo que tenga una puntuación mAP de un nivel mínimo para que sea económicamente viable para la unidad de negocio.

Para lograr este objetivo de modelado, el equipo de ciencia de datos necesita probar muchas variaciones de hiperparámetros y pases de selección de características (en colaboración con el equipo de ingeniería de datos) para aumentar la eficacia de su modelo. Cuanto más rápido pueda entrenar modelos el equipo de ciencia de datos, más variaciones de pasadas de entrenamiento podrá probar. En el caso del aprendizaje profundo y la visión por ordenador, las GPU hacen que las ejecuciones de entrenamiento lleven mucho menos tiempo, por lo que son un recurso clave para el equipo de ciencia de datos.

La unidad de negocio quiere alcanzar su objetivo de eficacia mínima del modelo, pero tiene que hacerlo dentro de un presupuesto. Utilizar Kubeflow on-premise con GPU es una forma más barata de construir modelos para el equipo de ciencia de datos, por lo que los costes acaban siendo menores. La unidad de negocio prevé que el coste es más barato porque el equipo de ciencia de datos prevé que necesitará modelizar muchas veces a la semana durante un largo periodo de tiempo.

GPUs en la nube

Las GPU en la nube nos dan más flexibilidad que las GPU locales, porque podemos ponerlas en marcha ad hoc, bajo demanda, lo que hace más cómodo probar nuevas ideas.

Sin embargo, esta comodidad puede costar más que si compramos una GPU y la utilizamos localmente todo el tiempo.

El equilibrio entre coste y flexibilidad es algo que debemos tener siempre presente al decidir dónde realizar nuestros trabajos.

El uso de Kubeflow on-premise con GPUs también permite al equipo de ciencia de datos modelar más rápido, a la vez que ejecuta múltiples trabajos de visión computerizada en el cluster al mismo tiempo, bajo la naturaleza multitenant del sistema .

Implementación de modelos en producción para la integración de aplicaciones

Una vez entrenado un modelo, suele existir como un único archivo en un ordenador portátil o en un servidor. Entonces tenemos que hacer una de las siguientes cosas:

  • Copia el archivo en la máquina con la aplicación para su integración.
  • Carga el modelo en un proceso servidor que pueda aceptar peticiones de red para la inferencia del modelo.

Si optamos por copiar el archivo del modelo en un único host de aplicación, esto es manejable. Sin embargo, cuando tenemos muchas aplicaciones que quieren obtener resultados de la inferencia de un modelo, esto se vuelve más complejo.

Uno de los principales problemas es la actualización del modelo una vez que se ha implementado en producción. Esto supone más trabajo, ya que tenemos que hacer un seguimiento de la versión del modelo en más máquinas y recordar cuáles deben actualizarse.

Otro problema es revertir un modelo una vez implementado. Si hemos desplegado un modelo y luego nos damos cuenta de que necesitamos volver a la versión anterior del modelo, esto supone mucho trabajo cuando tenemos un montón de copias del modelo flotando por ahí en diferentes hosts. Veamos ahora algunas ventajas si utilizamos un patrón de alojamiento de modelos para desplegar un modelo en producción con Kubeflow.

Ventajas de la implementación de modelos en producción en Kubeflow

Una gran ventaja de tener un modelo de aprendizaje automático cargado en un servidor de modelos en Kubeflow es que podemos hacer actualizaciones y retrocesos desde un único punto (por ejemplo, el proceso del servidor). Esto nos permite tratar un modelo más como una tabla de base de datos, en el sentido de que podemos aplicar operaciones al modelo, y luego todas las aplicaciones cliente consumidoras obtienen las actualizaciones en cuanto se completa la transacción de actualización y realizan su siguiente solicitud de inferencia.

Alineación del equipo para la implementación del modelo

El patrón del servidor de modelos facilita considerablemente la vida al equipo de DevOps, ya que no tiene que hacer un seguimiento manual de muchas copias del modelo. El equipo de ingeniería de aplicaciones puede centrarse en consumir el modelo como un recurso REST interno en la red, y menos en escribir código API específico de aprendizaje automático para integrar un modelo.

Una vez que el equipo de ciencia de datos ha desarrollado modelos que la línea de negocio desea poner en producción, el patrón del servidor de modelos les permite entregar el modelo al equipo de DevOps para que lo ponga en producción en el servidor de modelos. Esto permite al equipo de ciencia de datos no tener que dar soporte a modelos individuales en producción y centrarse en construir la siguiente ronda de modelos con las líneas de negocio.

Componentes de Kubeflow

Las agrupaciones de componentes lógicos de Kubeflow son:

  • Herramientas ML
  • Aplicaciones y andamiaje
  • Plataformas/nubes

Las relaciones entre los grupos de componentes pueden verse en la Figura 1-5.

Figura 1-5. Visión general de la plataforma Kubeflow (fuente: documentación de Kubeflow)

Estos componentes trabajan juntos para proporcionar un sistema escalable y seguro para ejecutar trabajos de aprendizaje automático (trabajos basados en cuadernos y también trabajos fuera de los cuadernos).

Dado el auge de Kubernetes como sistema de gestión de plataformas empresariales, tiene mucho sentido disponer de una forma de gestionar nuestras cargas de trabajo de aprendizaje automático de manera similar. En el resto de esta sección echaremos un vistazo a cada uno de los grupos de componentes, a algunos de sus componentes y a cómo se utilizan dentro de la plataforma Kubeflow.

Herramientas de aprendizaje automático

Kubeflow admite muchos marcos de aprendizaje automático. En teoría, un usuario podría simplemente contenerizar un marco arbitrario y enviarlo a un clúster de Kubernetes para su ejecución. Sin embargo, Kubeflow hace que los clústeres Kubernetes sean conscientes de los matices de ejecución que cada biblioteca de aprendizaje automático espera o necesita hacer, como el entrenamiento paralelo en múltiples nodos Kubernetes, o el uso de GPU en nodos específicos.

Los marcos de formación actuales compatibles con Kubeflow son :

  • TensorFlow
  • XGBoost
  • Keras
  • scikit-learn
  • PyTorch
  • MXNet
  • MPI
  • Encadenador

A continuación, daremos una breve visión general sobre algunos frameworks y cómo se utilizan.

Entrenamiento TensorFlow y TFJob

TensorFlow es compatible con Kubeflow y es la biblioteca de aprendizaje automático más popular del mundo en la actualidad. Dado que TensorFlow, Kubernetes y Kubeflow se crearon originalmente en Google, tiene sentido que fuera la biblioteca original soportada por Kubeflow.

Como hemos mencionado, TFJob es un componente personalizado para Kubeflow que contiene un descriptor de recursos personalizado de Kubernetes (CRD) y un controlador asociado(tf-operator). El CRD de TFJob es lo que permite a Kubernetes ejecutar trabajos TensorFlow distribuidos. El controlador TFJob (tf-operator) forma parte de las aplicaciones y andamiaje de apoyo incluidos en Kubeflow para habilitar bibliotecas de aprendizaje automático en Kubernetes.

Consulta la página de documentación de Kubeflow sobre TensorFlow.

Keras

Keras es compatible con el proyecto Kubeflow y puede utilizarse de varias formas :

  • Trabajo de proceso único ejecutado como una definición de recurso personalizada (CRD)
  • Trabajo GPU de un solo proceso ejecutado como CRD
  • TFJob como trabajo unipersonal
  • TFJob como trabajo distribuido (a través de la API del Estimador)
  • Jupyter Notebook (CPU o GPU)
  • Trabajo configurado para Kubeflow Pipelines

Muchas veces, un usuario puede querer simplemente entender cómo conseguir rápidamente un trabajo en el clúster. En el Ejemplo 1-1, mostramos la forma más sencilla de ejecutar un trabajo de Keras en Kubernetes como un trabajo desde la línea de comandos con kubectl .

Ejemplo 1-1. Ejemplo de trabajo YAML para ejecutar un script Keras Python
apiVersion: batch/v1
kind: Job
metadata:
  name: keras-job
spec:
  template:
    spec:
      containers:
      - name: tf-keras-gpu-job
        image: emsixteeen/basic_python_job:v1.0-gpu
        imagePullPolicy: Always
      volumes:
      - name: home
        persistentVolumeClaim:
          claimName: working-directory
      restartPolicy: Never
  backoffLimit: 1

En el ejemplo anterior, Kubernetes extraería la imagen del contenedor del repositorio de contenedores por defecto y luego la ejecutaría como un pod en el clúster Kubernetes.

En este ejemplo, nos saltamos todas las demás formas más complejas de utilizar Kubeflow y ejecutamos el script de Keras como un pod de Kubernetes simple y directo. Sin embargo, cuando hacemos esto, perdemos las ventajas de Kubeflow en torno a la orquestación del flujo de trabajo y la recopilación de metadatos.

El caso de Kubeflow sobre sólo Kubernetes

Sin la orquestación del flujo de trabajo y el seguimiento de los metadatos, perdemos la capacidad de ejecutar de forma fiable y coherente los flujos de trabajo de aprendizaje automático y de comprender su rendimiento a medida que cambiamos nuestro código de entrenamiento.

El Ejemplo 1-1 muestra que, aunque puedes ejecutar fácilmente scripts sencillos de aprendizaje automático en Kubernetes, Kubeflow proporciona un valor añadido a Kubernetes que puede que no se reconozca inmediatamented.

Aplicaciones y andamiaje

Gestionar la infraestructura de aprendizaje automático con todas las limitaciones y objetivos que hemos descrito en este capítulo es una alta montaña que escalar. Kubeflow proporciona muchas subaplicaciones y componentes de andamiaje para ayudar a soportar la experiencia completa del flujo de trabajo del aprendizaje automático.

Algunos de los componentes del "andamiaje" que están "bajo el capó", desde la perspectiva de la mayoría de los usuarios, incluyen :

  • Operadores del marco de aprendizaje automático
  • Metadatos
  • PyTorch al servicio de
  • Núcleo Seldon
  • TensorFlow Sirviendo
  • Istio
  • Argo
  • Prometeo
  • Spartakus

Muchos de los componentes anteriores nunca son utilizados directamente por un usuario normal, sino que dan soporte a la funcionalidad central de Kubeflow. Por ejemplo, Istio da soporte a las operaciones de la arquitectura de microservicios distribuidos Kubeflow proporcionando funcionalidades como el control de acceso basado en roles (RBAC) para puntos finales y recursos de red. Argo proporciona integración continua y funcionalidad de implementación para Kubeflow. Prometheus proporciona a los sistemas en Kubeflow el monitoreo de componentes, y la capacidad de consultar eventos pasados en los datos de monitoreo.

En las siguientes subsecciones examinaremos más de cerca algunas de las aplicaciones y componentes clave de Kubeflow.

Interfaz de usuario de Kubeflow

La interfaz de usuario de Kubeflow es el eje central de la actividad de un usuario en la plataforma Kubeflow. Podemos ver la pantalla principal de Kubeflow en la Figura 1-6.

Figura 1-6. La interfaz de usuario de Kubeflow

Desde la interfaz de usuario de Kubeflow podemos realizar visualmente tareas como crear Pipelines, ejecutar trabajos de optimización de hiperparámetros con Katib y lanzar servidores Jupyter Notebook.

Cuadernos Jupyter

Los Cuadernos Jupyter se incluyen en la plataforma Kubeflow como componente básico. Estos cuadernos son populares debido a su facilidad de uso y se asocian habitualmente (en el aprendizaje automático especialmente) con el lenguaje de programación Python. Los cuadernos suelen contener código (por ejemplo, Python, Java) y otros elementos visuales de texto enriquecido que imitan una página web o un libro de texto.

Un aspecto novedoso de los cuadernos es que combinan el concepto de programa informático con las notas que solemos asociar a la lógica compleja de nuestros programas. Esta propiedad de documentación en línea permite al usuario de un cuaderno no sólo documentar mejor lo que está haciendo, sino comunicarlo mejor a otros usuarios que puedan querer ejecutar nuestro código. Dada la complejidad del código de aprendizaje automático, esta propiedad ha sido parte de la razón por la que vemos su popularidad explosiva en el espacio del aprendizaje automático.

Integración de Jupyter Notebook con Kubeflow

La implementación de la aplicación Kubeflow incluye soporte para generar y utilizar Jupyter Notebooks. Las ventajas de tener Jupyter Notebooks integrados en la plataforma Kubeflow incluyen:

  • Buena integración con el resto de la infraestructura Kubeflow desde el punto de vista de la autenticación y el control de acceso
  • Posibilidad de compartir cuadernos entre usuarios

Cuadernos y Carenado

Los cuadernos Jupyter en Kubeflow también tienen acceso a la biblioteca Fairing, lo que permite a los cuadernos enviar trabajos de formación a Kubernetes desde el cuaderno. Esto es convincente, porque el código en un cuaderno Jupyter sólo utiliza el modo de ejecución de proceso único por defecto. La capacidad de enviar trabajos a Kubernetes desde el cuaderno nos permite aprovechar TFJob para ejecutar trabajos de formación distribuidos.

A veces queremos servidores de blocs de notas distintos para cada usuario o para un equipo. Kubeflow nos permite configurar varios servidores de blocs de notas para una determinada implementación de Kubeflow. Cada servidor de blocs de notas pertenece a un espacio de nombres, y puede servir y ejecutar varios blocs de notas. Los espacios de nombres en Kubeflow también nos proporcionan aislamiento multiusuario. Esto significa que podemos tener varios conjuntos de usuarios que no pueden ver los recursos de los demás para que no saturen los espacios de trabajo de los demás en la infraestructura compartida multiusuario.

Kubeflow lanzará una imagen de contenedor en Kubernetes para cada servidor de cuaderno. La imagen del cuaderno contiene dependencias como las bibliotecas para ML y el soporte de CPU o GPU en el cuaderno.

Operadores para marcos de aprendizaje automático

Cada marco de aprendizaje automático soportado en Kubeflow tiene un controlador asociado (Ej, tf-operator). Por ejemplo, el CRD TFJob es lo que hace que Kubernetes pueda ejecutar trabajos TensorFlow distribuidos. El controlador TFJob (tf-operator) forma parte de las aplicaciones de apoyo y del andamiaje que Kubeflow incluye para habilitar bibliotecas de aprendizaje automático en Kubernetes.

Metadatos y artefactos

El componente de metadatos de Kubeflow ayuda a los usuarios a rastrear y gestionar sus flujos de trabajo de ML recopilando y almacenando los metadatos producidos por los flujos de trabajo. La información recogida sobre un flujo de trabajo por el sistema de metadatos de Kubeflow incluye ejecuciones, modelos, conjuntos de datos y otros artefactos. En este contexto, Kubeflow define los artefactos como los objetos y archivos que forman las entradas y salidas de los componentes de un flujo de trabajo de aprendizaje automático, de los que hablamos con más detalle en el Capítulo 2.

Una vez ejecutado el código que tiene la API kubeflow-metadata recopilando metadatos para un flujo de trabajo, puedes ir a la pestaña Artefactos de tu interfaz de usuario de Kubeflow y ver los metadatos recopilados por ejecución, como se ve en la Figura 1-7.

Figura 1-7. La etiqueta Artefacto en la interfaz de usuario de Kubeflow

Ajuste de hiperparámetros

El ajuste de hiperparámetros consiste en explorar el espacio de búsqueda de hiperparámetros para encontrar un conjunto óptimo (o casi óptimo) de hiperparámetros para entrenar un modelo de aprendizaje automático. Los científicos de datos pasan una cantidad de tiempo no trivial probando combinaciones de hiperparámetros, y viendo cuánto más preciso puede ser su modelo como resultado.

La aplicación de búsqueda de hiperparámetros incluida con Kubeflow se llama Katib. Katib, inspirada originalmente en un sistema interno de Google llamado Vizier, se centró en ser agnóstica al marco de aprendizaje automático. Nos permite crear una serie de experimentos para probar ensayos de evaluación de hiperparámetros. Actualmente, Katib admite algoritmos de exploración como la búsqueda aleatoria, la búsqueda en cuadrícula y otros.

Tuberías

Kubeflow Pipelines nos permite construir flujos de trabajo de aprendizaje automático y desplegarlos como una unidad lógica en Kubeflow para que se ejecuten como contenedores en Kubernetes. Aunque muchas veces vemos ejemplos de aprendizaje automático en un único Jupyter Notebook o script de Python, los flujos de trabajo de aprendizaje automático no suelen ser un único script o trabajo.

Anteriormente en este capítulo presentamos la Figura 1-8, de "La deuda técnica oculta en el aprendizaje automático".

Figura 1-8. Diagrama del documento "Deuda técnica oculta en el aprendizaje automático"

Muchas de las casillas de este diagrama acaban siendo sus propios subflujos de trabajo en la práctica en un sistema de aprendizaje automático de producción. Ejemplos de esto se pueden ver en cómo la recopilación de datos y la ingeniería de características pueden ser sus propios flujos de trabajo construidos por equipos separados del equipo de ciencia de datos. La evaluación del modelo es otro componente que a menudo vemos realizado como su propio flujo de trabajo una vez finalizada la fase de entrenamiento.

Los conductos Kubeflow (véase la Figura 1-9) simplifican la orquestación de estos conductos como contenedores en la infraestructura Kubernetes. Esto da a nuestros equipos la capacidad de reconfigurar y desplegar complejas canalizaciones de aprendizaje automático de forma modular para acelerar la implementación de modelos y el tiempo de producción.

Figura 1-9. Interfaz de usuario de la tubería

Conceptos básicos de Kubeflow Pipeline

Una canalización Kubeflow es un grafo acíclico dirigido (DAG) que representa todos los componentes del flujo de trabajo. Los pipelines definen las ranuras de los parámetros de entrada necesarios para ejecutar el pipeline, y luego cómo se cablea la salida de cada componente como entrada a la siguiente etapa del grafo.

Un componente de canalización se define como una imagen Docker que contiene el código de usuario y las dependencias para ejecutarse en Kubernetes. En el Ejemplo 1-2 podemos ver un ejemplo de definición de pipeline en Python.

Ejemplo 1-2. Canalización Kubeflow definida en Python
@dsl.pipeline(
  name='XGBoost Trainer',
  description='A trainer that does end-to-end distributed training for XGBoost models.'
)
def xgb_train_pipeline(
    output,
    project,
    region='us-central1',
    train_data='gs://ml-pipeline-playground/sfpd/train.csv',
    eval_data='gs://ml-pipeline-playground/sfpd/eval.csv',
    schema='gs://ml-pipeline-playground/sfpd/schema.json',
    target='resolution',
    rounds=200,
    workers=2,
    true_label='ACTION',
):
    delete_cluster_op = DeleteClusterOp('delete-cluster', 
      project, region).apply(gcp.use_gcp_secret('user-gcp-sa'))
    with dsl.ExitHandler(exit_op=delete_cluster_op):
    create_cluster_op = CreateClusterOp('create-cluster', project, region, 
      output).apply(gcp.use_gcp_secret('user-gcp-sa'))

    analyze_op = AnalyzeOp('analyze', project, region, create_cluster_op.output, \ 
       schema,
      train_data, '%s/{{workflow.name}}/analysis' % \ 
         output).apply(gcp.use_gcp_secret('user-gcp-sa'))

    transform_op = TransformOp('transform', project, region, create_cluster_op.output,
      train_data, eval_data, target, analyze_op.output,
      '%s/{{workflow.name}}/transform' %  \ 
         output).apply(gcp.use_gcp_secret('user-gcp-sa'))

    train_op = TrainerOp('train', project, region, create_cluster_op.output, \ 
       transform_op.outputs['train'],
      transform_op.outputs['eval'], target, analyze_op.output, workers,
      rounds, '%s/{{workflow.name}}/model' % \ 
         output).apply(gcp.use_gcp_secret('user-gcp-sa'))
...

Si miramos este gráfico en la IU de Pipelines en Kubeflow, tendría un aspecto similar al de la Figura 1-10.

Figura 1-10. Visualización en Kubeflow de un pipeline

La interfaz de usuario de Kubeflow Pipelines nos permite además definir los parámetros de entrada por ejecución y luego lanzar el trabajo. Los resultados guardados de la tubería incluyen gráficos como una matriz de confusión y curvas de características operativas del receptor (ROC).

Los Kubeflow Pipelines producen y almacenan tanto metadatos como artefactos de cada ejecución. Los metadatos de las ejecuciones de los pipelines se almacenan en una base de datos MySQL, y los artefactos en un almacén de artefactos como el servidor MinIO o un sistema de almacenamiento en la nube. Tanto MinIO como MySQL están respaldados por PersistentVolumes (PV) en Kubernetes.

Los metadatos guardados permiten a Kubeflow rastrear experimentos y trabajos específicos ejecutados en el clúster. Los artefactos guardan información para que podamos investigar el rendimiento de la ejecución de un trabajo individual .

Inferencia de Modelos de Aprendizaje Automático Sirviendo con KFServing

Una vez que hemos construido un modelo, necesitamos integrar el modelo guardado con nuestras aplicaciones. Kubeflow ofrece múltiples formas de cargar modelos guardados en un proceso para servir inferencia de modelos en vivo a aplicaciones externas. Estas opciones incluyen :

  • KFServing
  • Núcleo Seldon Sirviendo
  • BentoML
  • Servidor de inferencia Nvidia Triton
  • TensorFlow Sirviendo
  • Predicción por lotes TensorFlow

Las distintas opciones anteriores admiten diferentes bibliotecas de aprendizaje automático, y tienen sus propios conjuntos de características específicas. Normalmente, cada una tiene una imagen Docker que puedes ejecutar como recurso de Kubernetes y luego cargar un modelo guardado de un repositorio de modelos.

KFServing se diseñó para que el servicio de modelos pudiera funcionar de forma estandarizada en todos los marcos de trabajo nada más sacarlo de la caja. Se necesitaba un sistema de servicio de modelos que pudiera ejecutarse fácilmente en las pilas existentes de Kubernetes e Istio, y que también proporcionara capacidad de explicación de modelos, operaciones de gráficos de inferencia y otras funciones de gestión de modelos. Kubeflow tenía que permitir tanto a los científicos de datos como a los equipos de DevOps/MLOps colaborar desde la producción de modelos hasta la implementación de modelos de producción modernos.

El valor fundamental de KFServing puede expresarse así:

  • Ayudar a estandarizar el servicio de modelos en todas las organizaciones con un plano de datos unificado y servidores de modelos preconstruidos.
  • Una única forma de implementar, monitorizar los servicios/servidores de inferencia y escalar la carga de trabajo de inferencia
  • Acorta drásticamente el tiempo que tarda el científico de datos en implementar el modelo en producción

En algunos casos, un servidor de inferencia específico de un marco (por ejemplo, TensorFlow Serving) puede tener características especializadas para un marco asociado.

Muchos equipos, sin embargo, utilizarán marcos diferentes y necesitarán más flexibilidad para su infraestructura de servicio de inferencia de modelos. En este caso, deberías considerar KFServing o Seldon Core, como se ha descrito anteriormente. En el capítulo 8 tratamos KFServing en detalle, desde los conceptos básicos que intervienen en la implementación de un modelo básico en KFServing, hasta la creación de servidores de modelos personalizados para la implementación de modelos en KFServing.

Plataformas y nubes

Kubeflow tiene la flexibilidad de desplegarse en cualquier lugar en el que pueda desplegarse Kubernetes, desde una gran nube pública hasta un clúster Kubernetes local, y también una implementación local de Kubernetes de un solo nodo en una sola máquina.

Nubes públicas

Dado que los tres principales proveedores de nubes admiten tanto Kubernetes gestionado como la posibilidad de implementar Kubernetes manualmente en máquinas virtuales, Kubeflow puede implementarse en cualquiera de las principales nubes, incluida :

  • Plataforma en la nube de Google (GCP)
  • Servicios web de Amazon (AWS)
  • Plataforma en la nube Azure

En capítulos posteriores profundizaremos en los detalles de la instalación y configuración de cada una de estas nubes. También te informaremos sobre lo que ofrece cada nube principal y cómo se integra con la oferta de Kubernetes gestionado para la nube. Esto te dará una visión sólida de lo apropiada que es tu nube preferida para ejecutar su infraestructura de Kubernetes y Kubeflow.

Instalar Kubeflow en una nube pública requiere algunas cosas, entre ellas:

  • Comprender cómo se integra el proveedor de la nube con tu propia infraestructura
  • Asegúrate de que es la versión correcta de Kubernetes (y otros subcomponentes) para tu organización
  • Temas de integración de seguridad

Más allá de los temas dogmáticos de los vendedores, una narrativa dominante en infraestructura es cómo un sistema puede integrarse como impulso heredado en la infraestructura de la empresa. Cuando se ejecuta bien, esta narrativa produce un valor consistente para cualquier empresa.

Kubernetes gestionados en la nube

Como se ha mencionado anteriormente en este capítulo, las tres principales nubes ofrecen una versión compatible con el código abierto de Kubernetes gestionado :

  • Motor Google Kubernetes (GKE)
  • Servicios Azure Kubernetes (AKS)
  • Motor Amazon Kubernetes (AKE)

Cada sistema tiene similitudes y diferencias en la forma de instalar e integrar Kubeflow. Hay, por supuesto, variaciones en cómo hacer una instalación de Kubeflow para cada nube, como por ejemplo:

  • Tipos y estrategias de almacenamiento
  • Configuración y gestión de identidades
  • Estrategias de gestión de contenedores
  • Integración de ETL pipeline
  • Planificación de infraestructuras y modelización de costes

A lo largo de este libro te presentaremos los conceptos básicos de cada oferta en la nube y, a continuación, te mostraremos cómo instalar Kubeflow específicamente para cada una de las plataformas en la nube.

En las instalaciones

Kubeflow es compatible con la implementación en un clúster Kubernetes local. La principal diferencia entre Kubeflow en un clúster local y Kubeflow en una nube importante es que un clúster local tendrá más limitaciones en cuanto a la escalabilidad dinámica de los recursos. Sin embargo, un clúster local no se factura por horas, por lo que cada organización debe hacer una compensación.

Como veremos a lo largo de este libro, también hay diferentes estrategias de integración de identidades para Kubernetes en las instalaciones y para Kubernetes en la nube.

Local

En algunos casos -principalmente pruebas, desarrollo y evaluación- un usuario puede querer ejecutar Kubeflow en una máquina local o VM. En este caso, puedes utilizar máquinas virtuales para configurar localmente un pequeño clúster de Kubernetes, o puedes probar un sistema Kubernetes de un solo nodo ya construido, como Minikube.

Ejecutar Kubeflow localmente puede requerir muchos recursos

Normalmente, una implementación de Kubeflow en Minikube necesita al menos 12 GB de memoria y 4 CPU asignadas a Minikube. También debes considerar cuántos recursos necesitará tu ordenador, además de estos requisitos, para funcionar normalmente.

En el capítulo 8 te mostramos un ejercicio de despliegue de KFServing autónomo en Minikube localmente para probar la implementación del modelo.

Resumen

En este capítulo introductorio hemos tratado el impulso de Kubeflow como plataforma de aprendizaje automático. A medida que avancemos en este libro, comprenderemos cómo planificar, instalar, mantener y desarrollar en la plataforma Kubeflow como piedra angular de nuestra infraestructura de aprendizaje automático. En el próximo capítulo, te llevaremos a través de los fundamentos de seguridad y la arquitectura de Kubeflow para establecer el contenido de operaciones para el resto del libro.

Get Guía de operaciones de Kubeflow now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial