Capítulo 4. Instalación de Kubeflow On-Premise

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

En este capítulo echaremos un vistazo a los aspectos básicos de la instalación de Kubeflow en un clúster Kubernetes local existente. En este capítulo se asume que ya tienes algunos conocimientos previos sobre Kubernetes y que también tienes acceso a un clúster de Kubernetes existente, ya sea local o gestionado en la nube. También existen opciones para entornos de aprendizaje como Minikube, kubeadm-dind.

También asumimos que te sientes cómodo con los procesos de instalación de infraestructuras de software y que puedes trabajar desde una interfaz de línea de comandos. Si necesitas un repaso rápido, en la siguiente sección revisamos algunos comandos básicos para Kubernetes.

Operaciones de Kubernetes desde la línea de comandos

Dado que Kubeflow está estrechamente integrado con Kubernetes, necesitamos conocer algunos comandos básicos de Kubernetes para realizar cualquier tipo de instalación. En esta sección repasamos los comandos:

  • kubectl
  • docker

Este capítulo te dará los detalles sobre las partes de Kubernetes de las que debemos preocuparnos para una instalación local. Empecemos por instalar algunas de nuestras herramientas básicas de línea de comandos.

Instalación de kubectl

kubectl controla el gestor de clusters Kubernetes y es una interfaz de línea de comandos para ejecutar comandos contra clusters Kubernetes. Utilizamos para implementar y gestionar aplicaciones en Kubernetes. Utilizando , podemos: kubectl kubectl

  • Inspeccionar los recursos del clúster
  • Crear componentes
  • Eliminar componentes
  • Actualizar componentes

Para una lista más completa de funciones en kubectl, consulta esta hoja de trucos.

kubectl es una herramienta fundamental para las operaciones en Kubernetes y Kubeflow, y la utilizaremos mucho durante la implementación de componentes y la ejecución de trabajos en Kubeflow.

Instalar kubectl en macOS

Una forma sencilla de instalar kubectl en macOS es utilizar el comandobrew:

brew install kubernetes-cli

Una vez que tenemos kubectl, necesitamos permiso para que pueda hablar con nuestro clúster Kubernetes.

Comprender kubectl y los contextos

kubectl sabe cómo hablar con clusters remotos basándose en un archivo de contexto local almacenado en el disco. Definimos un contexto kubectl como una entrada en un archivo kubectl utilizada para identificar un grupo de parámetros de acceso bajo un ID común. Cada uno de estos grupos de parámetros de acceso, o contextos, tiene tres parámetros :

  • Grupo
  • Espacio de nombres
  • Usuario

La ubicación por defecto del archivo local kubeconfig es ~/.kube/config (o $HOME/.kube/config). También podemos establecer esta ubicación con la variable de entorno KUBECONFIG o activando la opción --kubeconfig bandera.

También podemos utilizar varios archivos de configuración, pero por ahora consideraremos el caso del archivo de configuración por defecto. En algunos casos, trabajarás con varios clusters, y su información de contexto también se almacenará en este archivo.

Para ver la configuración actual de kubectl, utiliza el comando

kubectl config view

El resultado debería ser algo parecido a esto:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/ec2-user/.minikube/ca.crt
    server: https://172.17.0.3:8443
  name: kubeflow
contexts:
- context:
    cluster: kubeflow
    user: kubeflow
  name: kubeflow
current-context: kubeflow
kind: Config
preferences: {}
users:
- name: kubeflow
  user:
    client-certificate: /home/ec2-user/.minikube/profiles/kubeflow/client.crt
    client-key: /home/ec2-user/.minikube/profiles/kubeflow/client.key

La salida puede variar dependiendo de cuántos contextos haya actualmente en tu archivo local, pero nos dice cosas como qué clusters tenemos adjuntos y cuál es la configuración del contexto actual. Para más información sobre las operaciones que podemos realizar en el sistema de contextos de kubectl, consulta el recurso en línea.

Utilizamos kubectl archivos de contexto para organizar la información sobre:

  • Agrupaciones
  • Usuarios
  • Espacios de nombres
  • Mecanismos de autenticación

Veamos ahora algunas formas concretas de utilizar el archivo contextual y kubectl.

Obtener el contexto actual

Si queremos saber cuál es el contexto actual, utilizaríamos el comando

kubectl config current-context

La salida debe ser similar a la siguiente salida de registro de la consola:

kubeflow

Esto nos da el ID del grupo de contexto en nuestro archivo de contexto; kubectl actualmente enviará comandos de Kubernetes al clúster representado por ese ID.

Añadir clusters a nuestro archivo de contexto

Para añadir un nuevo clúster de Kubernetes a nuestro archivo de contexto local utilizamos los comandos set-cluster, set-credentials, y set-context, como se ve en el siguiente ejemplo:

kubectl config \
set-cluster NAME \
[--server=server] \
[--certificate-authority=path/to/certificate/authority] \
[--insecure-skip-tls-verify=true]

kubectl config \
set-credentials NAME \
[--client-certificate=path/to/certfile] \
[--client-key=path/to/keyfile] \
[--token=bearer_token] \
[--username=basic_user] \
[--password=basic_password] \
[--auth-provider=provider_name] \
[--auth-provider-arg=key=value] \
[--exec-command=exec_command] \
[--exec-api-version=exec_api_version] \
[--exec-arg=arg][--exec-env=key=value] \
[options]

kubectl config \
set-context [NAME | --current] \
[--cluster=cluster_nickname] \
[--user=user_nickname] \
[--namespace=namespace] \
[options]

Ten en cuenta que en el comando set-context, el parámetro NAME es el nombre de la credencial establecida mediante el comando set-credentials.

En el próximo capítulo veremos cómo obtener las credenciales de una nube pública y añadir automáticamente el contexto de Kubernetes a nuestro archivo de contexto local.

Cambiar de contexto

Para cambiar el contexto predeterminado para que apunte a otro clúster de Kubernetes, utiliza el comando

kubectl config use-context [my-cluster-name]

Todos los comandos emitidos a través de kubectl deberían dirigirse ahora al clúster que añadimos previamente con el ID [my-cluster-name].

Uso de kubectl

Acostumbrémonos a utilizar kubectl probando algunos comandos para obtener información del clúster, como los siguientes:

  • Los servicios actuales en funcionamiento
  • La información de la agrupación
  • Los trabajos en ejecución actuales

Poner en marcha los servicios

Para confirmar que nuestro clúster está operativo y que los componentes se están ejecutando, prueba con el siguiente comando:

kubectl -n kubeflow get services

Deberíamos ver una lista de componentes en ejecución que coinciden con los componentes que acabamos de instalar en nuestro clúster (ver Ejemplo 4-1).

Ejemplo 4-1. Lista de servicios desde la línea de comandos
NAME                                          TYPE        PORT(S)             AGE
admission-webhook-service                     ClusterIP   443/TCP             2d6h
application-controller-service                ClusterIP   443/TCP             2d6h
argo-ui                                       NodePort    80:30643/TCP        2d6h
centraldashboard                              ClusterIP   80/TCP              2d6h
jupyter-web-app-service                       ClusterIP   80/TCP              2d6h
katib-controller                              ClusterIP   443/TCP,8080/TCP    2d6h
katib-db-manager                              ClusterIP   6789/TCP            2d6h
katib-mysql                                   ClusterIP   3306/TCP            2d6h
katib-ui                                      ClusterIP   80/TCP              2d6h
kfserving-controller-manager-metrics-service  ClusterIP   8443/TCP            2d6h
kfserving-controller-manager-service          ClusterIP   443/TCP             2d6h
kfserving-webhook-server-service              ClusterIP   443/TCP             2d6h
metadata-db                                   ClusterIP   3306/TCP            2d6h
metadata-envoy-service                        ClusterIP   9090/TCP            2d6h
metadata-grpc-service                         ClusterIP   8080/TCP            2d6h
metadata-service                              ClusterIP   8080/TCP            2d6h
metadata-ui                                   ClusterIP   80/TCP              2d6h
minio-service                                 ClusterIP   9000/TCP            2d6h
ml-pipeline                                   ClusterIP   8888/TCP,8887/TCP   2d6h
ml-pipeline-ml-pipeline-visualizationserver   ClusterIP   8888/TCP            2d6h
ml-pipeline-tensorboard-ui                    ClusterIP   80/TCP              2d6h
ml-pipeline-ui                                ClusterIP   80/TCP              2d6h
mysql                                         ClusterIP   3306/TCP            2d6h
notebook-controller-service                   ClusterIP   443/TCP             2d6h
profiles-kfam                                 ClusterIP   8081/TCP            2d6h
pytorch-operator                              ClusterIP   8443/TCP            2d6h
seldon-webhook-service                        ClusterIP   443/TCP             2d6h
tensorboard                                   ClusterIP   9000/TCP            2d6h
tf-job-operator                               ClusterIP   8443/TCP            2d6h

Esto nos permite confirmar qué servicios que hemos implementado se están ejecutando actualmente.

Obtener información del clúster

Podemos comprobar el estado del clúster en ejecución con el comando

kubectl cluster-info

Deberíamos ver una salida similar a la del Ejemplo 4-2.

Ejemplo 4-2. Salida kubectl cluster-info
Kubernetes master is running at https://172.17.0.3:8443
KubeDNS is running at https://172.17.0.3:8443/api/v1/namespaces/kube-system...

To further debug and diagnose cluster problems, use kubectl cluster-info dump.

Obtener los trabajos actualmente en ejecución

Normalmente, ejecutaríamos un trabajo basado en un archivo YAML con el comando kubectl:

kubectl apply -f https://github.com/pattersonconsulting/tf_mnist_kubflow_3_5...

Ahora deberíamos tener el trabajo ejecutándose en el clúster de Kubeflow. No veremos el trabajo ejecutándose y escribiendo en la pantalla de nuestra consola porque se está ejecutando en un clúster remoto. Podemos comprobar el estado del trabajo con el comando

kubectl -n kubeflow get pod

La salida de nuestra consola debería parecerse al Ejemplo 4-3.

Ejemplo 4-3. Salida de kubectl para los trabajos que se están ejecutando actualmente
NAME                                              READY  STATUS     RESTARTS  AGE
admission-webhook-deployment-f9789b796-95rfz      1/1    Running    0         2d6h
application-controller-stateful-set-0             1/1    Running    0         2d6h
argo-ui-59f8d49b9-52kn8                           1/1    Running    0         2d6h
centraldashboard-6c548fc6dc-pzskh                 1/1    Running    0         2d6h
jupyter-web-app-deployment-657bf476db-v2xgl       1/1    Running    0         2d6h
katib-controller-5c976769d8-fcxng                 1/1    Running    1         2d6h
katib-db-manager-bf77df6d6-dgml5                  1/1    Running    0         2d6h
katib-mysql-7db488768f-cgcnj                      1/1    Running    0         2d6h
katib-ui-6d7fbfffcb-t84xl                         1/1    Running    0         2d6h
kfserving-controller-manager-0                    2/2    Running    1         2d6h
metadata-db-5d56786648-ldlzq                      1/1    Running    0         2d6h
metadata-deployment-5c7df888b9-gdm5n              1/1    Running    0         2d6h
metadata-envoy-deployment-7cc78946c9-kcmt4        1/1    Running    0         2d6h
metadata-grpc-deployment-5c8545f76f-7q47f         1/1    Running    0         2d6h
metadata-ui-665dff6f55-pbvdp                      1/1    Running    0         2d6h
minio-657c66cd9-mgxcd                             1/1    Running    0         2d6h
ml-pipeline-669cdb6bdf-vwglc                      1/1    Running    0         2d6h
ml-pipeline-ml-pipeline-visualizationserver...    1/1    Running    0         2d6h
ml-pipeline-persistenceagent-56467f8856-zllpd     1/1    Running    0         2d6h
ml-pipeline-scheduledworkflow-548b96d5fc-xkxdn    1/1    Running    0         2d6h
ml-pipeline-ui-6bd4778958-bdf2x                   1/1    Running    0         2d6h
ml-pipeline-viewer-controller-deployment...       1/1    Running    0         2d6h
mysql-8558d86476-xq2js                            1/1    Running    0         2d6h
notebook-controller-deployment-64b85fbc84...      1/1    Running    0         2d6h
profiles-deployment-647448c7dd-9gnz4              2/2    Running    0         2d6h
pytorch-operator-6bc9c99c5-gn7wm                  1/1    Running    30        2d6h
seldon-controller-manager-786775d4d9-frq9l        1/1    Running    0         2d6h
spark-operatorcrd-cleanup-xq8zb                   0/2    Completed  0         2d6h
spark-operatorsparkoperator-9c559c997-mplrh       1/1    Running    0         2d6h
spartakus-volunteer-5978bf56f-jftnh               1/1    Running    0         2d6h
tensorboard-9b4c44f45-frr76                       0/1    Pending    0         2d6h
tf-job-operator-5d7cc587c5-tvxqk                  1/1    Running    33        2d6h
workflow-controller-59ff5f7874-8w9kd              1/1    Running    0         2d6h

Dado que un trabajo TensorFlow se ejecuta como una extensión del operador TensorFlow, aparece como un pod junto a los demás componentes de Kubeflow.

Utilizar Docker

Docker es el sistema de contenedores más utilizado en sistemas de orquestación de contenedores como Kubernetes. Para lanzar un contenedor ejecutamos una imagen. Una imagen incluye todo lo necesario para ejecutar una aplicación (código, tiempo de ejecución, bibliotecas, etc.) como una imagen ejecutable. En el caso de nuestro trabajo TensorFlow, incluye cosas como las dependencias de la biblioteca TensorFlow y nuestro código de entrenamiento Python para ejecutarlo en cada contenedor.

Docker Hub proporciona un repositorio para almacenar, buscar y recuperar imágenes de contenedores. Otros repositorios incluyen el Registro de Contenedores de Google y las instalaciones locales de Artifactory.

Instalación básica de Docker

Para obtener información sobre cómo instalar Docker, consulta su página de documentación sobre el proceso.

Para el resto de este capítulo supondremos que tienes instalado Docker. Pasemos ahora a algunos comandos básicos de Docker que necesitarás conocer.

Comandos básicos de Docker

Para más detalles sobre el uso del comando build, consulta la página de documentación de Docker.

El comando que sigue construye la imagen a partir de la dockerfile contenida en el directorio local y le da la etiqueta [account]/[repository]:[tag]:

docker build -t "[account]/[repository]:[tag]" .

Para empujar el contenedor que hemos construido con este comando Docker, utilizaremos un comando de la siguiente forma:

docker push [account]/[repository]:[tag]

El siguiente comando toma la imagen del contenedor que construimos en el paso anterior y la envía a la cuenta mike en Artifactory bajo el repositorio de Kubeflow. También añade la etiqueta dist_tf_estimator.

docker push mike/kubeflow:dist_tf_estimator

Ahora pasemos a construir contenedores TensorFlow con Docker.

Utilizar Docker para construir contenedores TensorFlow

Cuando construyas imágenes de contenedor Docker basadas en imágenes de contenedor TensorFlow existentes, ten en cuenta:

  • La versión de TensorFlow deseada
  • Si la imagen contenedora estará basada en Python2 o Python3
  • Si la imagen contenedora tendrá enlaces de CPU o GPU

Suponemos que construirás tu propio contenedor TensorFlow de base o extraerás uno existente de gcr.io o Docker Hub. Echa un vistazo al repositorio de TensorFlow en Docker Hub para ver algunos buenos ejemplos de imágenes de contenedores TensorFlow existentes.

Contenedores, GPU y versión de Python

Comprueba en cada repositorio de contenedores las reglas de nomenclatura de Python 2 frente a Python 3, ya que pueden ser diferentes en cada repositorio. Para los enlaces GPU dentro de la imagen contenedora, asegúrate de utilizar la imagen base correcta con la etiqueta -gpu.

Ahora pasemos al proceso de instalación de Kubeflow desde la línea de comandos .

Proceso básico de instalación

El proceso básico de instalación de Kubeflow es:

  1. Inicializa los artefactos Kubeflow.
  2. Personaliza cualquier artefacto.
  3. Implementa artefactos Kubeflow en el clúster.

Desglosamos cada uno de ellos en los siguientes apartados.

Instalación in situ

Para instalar Kubeflow in situ, debemos tener en cuenta los siguientes aspectos:

  • Consideraciones para construir clusters Kubernetes
  • Acceso del host pasarela al clúster
  • Integración de Active Directory y gestión de usuarios
  • Integración de Kerberos
  • Entornos de aprendizaje frente a entornos de producción
  • Integración del almacenamiento

Empezaremos viendo distintas formas de configurar clusters de Kubernetes.

Consideraciones para construir clusters de Kubernetes

Para enmarcar nuestro debate sobre cómo queremos configurar nuestra instalación de Kubeflow in situ, volveremos a ver el diagrama de cómo se dividen los clústeres en capas lógicas(Figura 4-1).

Figura 4-1. Opciones del entorno de producción para clústeres Kubernetes (fuente: documentación de Kubernetes)

Kubeflow vive en la capa de aplicación de nuestro clúster, y lo instalaremos como un conjunto de pods y servicios de larga duración.

Glosario Kubernetes

Kubernetes tiene muchos términos y conceptos que debes conocer. Si alguna vez te confundes, consulta el glosario normalizado de Kubernetes en la documentación del sitio web del proyecto Kubernetes.

Dado este contexto, entendemos que necesitamos instalar Kubeflow en un clúster Kubernetes existente. La ubicación de elementos como el plano de control y la infraestructura del clúster puede influir en gran medida en las decisiones de diseño de la instalación, por ejemplo:

  • Topologías de red
  • Integración con Active Directory
  • Integración de Kerberos

Veamos con más detalle qué implica configurar un host de puerta de enlace para acceder a nuestro clúster.

Acceso del host de puerta de enlace al clúster de Kubernetes

En la mayoría de los sistemas empresariales multiempresa compartidos, tenemos un host de puerta de enlace que se utiliza para acceder al clúster. Para instalar Kubeflow en un sistema Kubernetes, es probable que tu clúster necesite la misma configuración de patrón.

Normalmente, la máquina anfitriona de la pasarela necesita los siguientes recursos:

  • Acceso de red al clúster Kubernetes
  • kubectl instalado y configurado localmente

Se requiere acceso de red al clúster de Kubernetes donde reside Kubeflow, ya que necesitamos acceso para que kubectl envíe comandos a través de la red. Hay variaciones en las que la construcción de contenedores se realiza en una máquina que no es el host de la pasarela, pero normalmente depende de cómo lo configure tu departamento de TI.

Está perfectamente bien que el host de la pasarela sea una máquina local que cumpla estos requisitos.

Integración del Directorio Activo y Gestión de Usuarios

En la mayoría de las organizaciones, los usuarios se gestionan mediante una instalación de Directorio Activo. La mayoría de los sistemas de software empresarial tendrán que integrarse con esta instalación de Directorio Activo para que los usuarios puedan utilizar sistemas como Kubernetes o Kubeflow.

Empecemos analizando la experiencia de usuario típica en una organización para acceder a un clúster de Kubernetes integrado con Active Directory.

Kubernetes, kubectl y Active Directory

Para acceder a un clúster Kubernetes, los usuarios normalmente tendrán que solicitar formalmente el acceso al clúster al equipo de TI de su empresa. Una vez superado con éxito el proceso de aprobación, los usuarios se añadirán al grupo de Active Directory adecuado para acceder al clúster.

Los usuarios acceden al host de la pasarela (que, de nuevo, puede ser su máquina local) utilizando un conjunto de credenciales, e inmediatamente después de iniciar sesión con las credenciales genéricas, se les concederá un ticket Kerberos. Ese ticket puede utilizarse posteriormente para autenticarse en el clúster Kubernetes.

Los usuarios tendrán que configurar los binarios necesarios (kubectl, y plug-ins -como mencionamos en el texto siguiente-), así como la kubeconfig requerida (configuración de Kubernetes). Una vez configurado el kubeconfig, los usuarios sólo tendrán que preocuparse de ejecutar los comandos kubectl adecuados.

Integración de Kerberos

Los equipos informáticos de las empresas suelen utilizar Kerberos como protocolo de autenticación de red, ya que está diseñado para ser utilizado por aplicaciones cliente/servidor (como los nodos de Kubernetes) para proporcionar una autenticación sólida mediante criptografía de clave secreta. Como se describe en el sitio web de Kerberos:

Kerberos fue creado por el MIT como solución a estos problemas de seguridad en la red. El protocolo Kerberos utiliza una potente criptografía para que un cliente pueda demostrar su identidad a un servidor (y viceversa) a través de una conexión de red insegura. Después de que un cliente y un servidor hayan utilizado Kerberos para demostrar su identidad, también pueden cifrar todas sus comunicaciones para garantizar la privacidad y la integridad de los datos mientras realizan sus actividades.

Por defecto, Kubernetes no proporciona un método para integrarse con Kerberos directamente, porque se basa en un enfoque más moderno: OpenID Connect, o OIDC para abreviar.

Un método de utilizar Kerberos con Kubernetes es intercambiar un ticket Kerberos existente por un token OIDC, y presentar ese token a Kubernetes en el momento de la autenticación. Esto funciona autenticando primero a un proveedor de tokens OIDC utilizando una credencial Kerberos existente, y obteniendo un token OIDC a cambio de la autenticación Kerberos. Esto puede lograrse utilizando un complemento de kubectl, con un ejemplo aquí.

Integración del almacenamiento

Por defecto, Kubeflow no tiene noción de un almacén de datos específico y deja que el clúster Kubernetes subyacente defina las opciones de almacenamiento disponibles.

Al configurar nuestra instalación de Kubeflow y ejecutar trabajos, debemos tener en cuenta:

  • De qué tipo de almacenamiento dispone nuestro clúster
  • Patrones de acceso a los datos más adecuados para nuestro trabajo
  • Consideraciones de seguridad en torno al almacén de datos

La forma en que almacenamos los datos está estrechamente relacionada con la forma en que accedemos a ellos, por lo que debemos asegurarnos de pensar en cómo vamos a acceder a los datos cuando diseñemos nuestro almacenamiento. Los tipos de trabajo que tendremos en cuenta en relación con nuestros patrones de acceso a los datos son:

  • Código Python (u otro) en un único contenedor ejecutado en Kubernetes
  • Un contenedor se ejecuta en un operador Kubeflow específico (por ejemplo, TFOperator, o PyTorchOperator) en ejecución normal de nodo único o en modo distribuido
  • Código Python ejecutado desde un Jupyter Notebook

Hay dos facetas a considerar en estas tres variantes de empleo:

  • ¿Estamos proporcionando suficiente ancho de banda al trabajo para no privar de potencia de modelado al código que se está ejecutando?
  • ¿Nos integramos con la capa de almacenamiento mediante la semántica del sistema de archivos o mediante llamadas de red?

Empecemos examinando el ancho de banda y el almacenamiento de los trabajos de Kubeflow.

Pensando en el ancho de banda de trabajo de Kubeflow

Si recuerdas, en el Capítulo 2 hablamos de cómo las GPU pueden afectar a los trabajos, desde las GPU individuales hasta las multi-GPU e incluso las GPU distribuidas. Las GPUs pueden estar hambrientas de datos, por lo que tener un subsistema de almacenamiento extremadamente rápido es fundamental. No queremos que las GPUs esperen datos.

Si un trabajo determinado va a entrenarse con muchos datos, podemos pensar que ese trabajo requiere una solución de almacenamiento de gran ancho de banda que pueda saciar las necesidades de las GPU. Por otro lado, si un trabajo estuviera muy ligado al cálculo, sin un conjunto de datos más pequeño, la velocidad a la que los datos iniciales son recibidos por las GPU puede no ser tan importante. En este último escenario, podemos considerarlo como un trabajo de menor ancho de banda.

Patrones comunes de almacenamiento de acceso con trabajos Kubeflow

Hay dos formas principales en que las tareas de Kubeflow acceden al almacenamiento:

  • Utilizar llamadas de red a través de la red o de Internet
  • Utilizar la semántica del sistema de archivos

Si la tarea va a extraer datos a través de la red/Internet con las propias credenciales del usuario (que no nos importa poner en la configuración/código en alguna parte), entonces no tenemos que preocuparnos de la semántica del sistema de archivos y los puntos de montaje para Kubernetes a nivel de Kubernetes.

En este caso, el código gestiona todas las llamadas de red para obtener los datos localmente, pero los hosts de nuestro clúster necesitan conectividad de red externa. Estos ejemplos podrían ser el acceso al almacenamiento desde S3, SFTP, sistemas de terceros, etc.

Si quieres utilizar un punto de montaje local para acceder a una partición de los datos (por ejemplo, de forma similar a como se utilizará un sistema de archivos local por Python y los blocs de notas en un portátil local), entonces tendrás que aprovisionar el almacenamiento utilizando reclamaciones de volumen persistente (PVC) en el nivel de pods y contenedores de Kubernetes.

Opciones para el almacenamiento de Kubeflow

El propio Kubernetes proporciona una plétora de mecanismos de almacenamiento, de los que puedes encontrar más información aquí. En el nivel más básico, se puede considerar que el almacenamiento es un almacenamiento conectado localmente en un nodo trabajador de Kubernetes concreto (por ejemplo, un volumen conectado localmente y efímero), o una capa de almacenamiento persistente, normalmente proporcionada por un subsistema de almacenamiento.

En el contexto de Kubeflow, es preferible un subsistema de almacenamiento de alta velocidad, como una matriz de almacenamiento conectada por fibra. Esto proporciona un medio de almacenamiento consistente de gran ancho de banda que puede saciar las necesidades de la GPU.

Algunos ejemplos de estos sistemas de gran ancho de banda son :

  • AFFA800 de NetApp
  • Cisco FlexPod
  • FlashBlade

En los Capítulos 5 a 7 ofrecemos más detalles sobre cada uno de los sistemas de almacenamiento básicos para Kubernetes gestionado para las nubes públicas.

Reclamaciones de volumen persistente y almacenamiento Kubeflow

Kubeflow, por defecto, utilizará volúmenes persist entes (PV) y reclamaciones de volúmenes persistentes (PVC) para sus necesidades de almacenamiento. Por ejemplo, cuando un usuario implemente un servidor de portátiles, tendrá la opción de asignar almacenamiento dinámicamente (a partir de una clase de almacenamiento) o de utilizar una reclamación de volumen persistente existente.

La distinción clave que hay que entender entre los PV y los PVC es que un PV es simplemente una representación de almacenamiento "en algún lugar", como un "1 GB de espacio" asignado. Para utilizar realmente ese espacio de almacenamiento, debe hacerse una reclamación contra ese almacenamiento. Una vez realizada la solicitud, Kubernetes ofrece ciertas garantías de que, mientras dure la solicitud, no se liberará el almacenamiento subyacente. Por lo tanto, en el contexto de Kubernetes, no basta con tener un PV, sino que también debe adquirirse un PVC contra ese almacenamiento.

Si un usuario aprovisiona almacenamiento de forma dinámica, Kubeflow creará automáticamente una PVC contra el almacenamiento recién asignado, que más tarde podrá utilizarse y reutilizarse para varios pods, cuadernos, etc. Si un usuario desea proporcionar un PVC existente al configurar un entorno Kubeflow, como Notebook, es el PVC el que se proporciona a Kubeflow (y no el propio PV).

Gestión de contenedores y repositorios de artefactos

La gestión de contenedores es clave para Kubeflow y Kubernetes (o cualquier sistema de orquestación de contenedores) porque tenemos que tener algún lugar para que vivan las imágenes de los contenedores.

Deberíamos dejar claro aquí en qué se diferencian las imágenes contenedoras de los archivos de configuración (por ejemplo, Dockerfiles) que definen las imágenes contenedoras. Podemos enviar nuestros archivos de configuración (Dockerfiles) a un repositorio de control de código fuente como github.com, pero necesitamos un repositorio diferente para gestionar los artefactos binarios de la aplicación (por ejemplo, las imágenes de contenedor).

En concreto, necesitamos un lugar donde almacenar y gestionar todas nuestras imágenes de aplicaciones en contenedores para su posterior implementación en Kubernetes.

Hay dos tipos de repositorios de artefactos para imágenes de contenedores:

  • Repositorios públicos de imágenes de contenedores (o registros)
  • Repositorios (o registros) de imágenes de contenedores privados (y quizás locales)

Normalmente se accede a los repositorios/registros públicos a través de Internet y permiten que todo el mundo vea tus contenedores (al menos en el nivel gratuito). El repositorio público de artefactos más popular es hub.docker.com, también conocido como Docker Hub.

Los repositorios/registros privados también pueden alojarse en Internet, o en las propias instalaciones. Los detalles y la implementación de la creación y gestión de repositorios y registros privados son específicos de cada implementación.

La clave importante para Kubeflow es entender que todas las imágenes de contenedores deben extraerse de un repositorio de contenedores en algún lugar. Por defecto, Kubeflow está preconfigurado para extraer todas las imágenes de contenedores del Registro de Contenedores de Google (gcr.io). Kubeflow proporciona un mecanismo para establecer la ubicación del registro de contenedores.

Configurar un repositorio interno de contenedores

JFrog Artifactory OSS es una opción de código abierto para un registro de aplicaciones en contenedor local (también hay actualizaciones comerciales sobre la versión de código abierto).

Para descargar Artifactory (u obtener una imagen Docker), consulta su sitio web. Para instalar Artifactory in situ, consulta su documentación sobre Confluence. Artifactory es compatible con:

  • Solaris
  • MacOS
  • Windows
  • Linux

Las dependencias de Artifactory incluyen una base de datos local (por defecto es una base de datos Derby incrustada), un almacén de archivos (el FS local es el predeterminado) y la integración con un servidor HTTP.

Acceder e interactuar con Kubeflow

Hay dos formas principales de trabajar con Kubeflow:

  • La CLI, utilizando principalmente la herramienta kubectl, así como la herramienta kfctl
  • Con un navegador web, utilizando la interfaz de usuario web de Kubeflow

En las siguientes subsecciones veremos los detalles de cada uno de ellos.

Es importante tener en cuenta que las operaciones de gestión de Kubeflow -como la implementación de una instalación de Kubeflow, la actualización de componentes de Kubeflow, etc.- se realizan mediante la herramienta kfctl, mientras que para ver lo que está "haciendo" actualmente el clúster se utiliza la herramienta kubectl.

Operaciones comunes de la línea de comandos

kubectl es la herramienta fundamental que nos interesa para las opciones de la línea de comandos en Kubeflow. En una sección anterior de este capítulo revisamos algunas de las cosas clave que podemos hacer en un clúster basado en Kubernetes con . Las operaciones relevantes sobre Kubeflow que nos interesan con son: kubectl kubectl

  • Ejecutar un contenedor básico con algo de código, típicamente Python, en nuestro clúster
  • Ejecutar un grupo de contenedores en un operador especial de Kubernetes como TFJob

En el primer caso, muchas veces nuestros profesionales tienen algún código Python que les gustaría ejecutar en GPUs. En estos casos, creamos un contenedor con las dependencias adecuadas y lo ejecutamos en nuestro clúster Kubernetes con Kubeflow.

En el segundo caso, tenemos que configurar nuestro archivo YAML de trabajo para especificar un operador de cliente de Kubernetes específico, como TFJob, de modo que podamos aprovechar modos especiales de coordinación de contenedores, como el entrenamiento distribuido de TensorFlow.

Interfaces de usuario web accesibles

El recurso web clave que proporciona Kubeflow es la interfaz de usuario del Cuadro de Mando de Kubeflow, que tiene enlaces a todos los demás recursos accesibles desde la web que proporciona Kubeflow. En la Figura 4-2, podemos ver el aspecto del panel de control.

Como ya se comentó en el Capítulo 1, este panel de control es en realidad una tabla rápida de los demás recursos relevantes disponibles a través de un navegador web para los usuarios de Kubeflow.

Figura 4-2. Interfaz de usuario de Kubeflow

Instalar Kubeflow

En esta sección, hablaremos de los pasos necesarios para instalar Kubeflow.

Requisitos del sistema

En el momento de redactar este documento, el clúster Kubernetes debe cumplir los siguientes requisitos mínimos:

  • 4 CPUs
  • 50 GB de almacenamiento
  • 12 GB de memoria

La versión de Kubernetes recomendada es la 1.14. Kubeflow ha sido validado y probado en Kubernetes 1.14. Tu clúster debe ejecutar al menos la versión 1.11 de Kubernetes, y Kubeflow no funciona en Kubernetes 1.16.

Configuración e Implementación

La instalación de Kubeflow requiere estos pasos:

  1. Descarga la herramienta kfctl.
  2. Prepara los artefactos Kubeflow.
  3. Implementa los artefactos en un clúster.

Si utilizas un sistema compatible (como Linux o macOS), adquiere la herramienta kfctl descargándola de las páginas de versiones de Kubeflow en GitHub. Consulta el Ejemplo 4-4.

Ejemplo 4-4. Descarga y desempaqueta el binario kfctl1
$ cd ~/bin
$ curl -LOJ https://github.com/.../kfctl_v1.0.2-0-ga476281_linux.tar.gz
$ tar zxvf kfctl_v1.0.2-0-ga476281_linux.tar.gz

Una vez descargada la herramienta, se crea un directorio de trabajo que contendrá los artefactos y cualquier personalización realizada para Kubeflow. En el Ejemplo 4-5, utilizaremos el directorio kf en el directorio personal del usuario (~/kf).

Ejemplo 4-5. Crear directorio de trabajo
$ mkdir ~/kf
$ cd ~/kf

No estamos preparados para preparar la instalación de Kubeflow. Esto se hace especificando un manifiesto inicial desde el que descargar y preparar, como en el Ejemplo 4-6.

Ejemplo 4-6. Preparar la instalación de Kubeflow2
$ cd ~/kf
$ ~/bin/kfctl build -V -f "https://raw.githubusercontent.com/..."

Esto creará un directorio kustomize, que contendrá todas las plantillas que Kubeflow desplegará. En esta fase, se puede realizar cualquier personalización adicional.

Como ejemplo, para establecer un registro de contenedores personalizado a utilizar, podemos utilizar la herramienta kfctl. El comando del Ejemplo 4-7 cambiará el registro de contenedores por defecto de gcr.io a hub.docker.com.

Ejemplo 4-7. Establecer un registro de contenedores personalizado
$ ~/bin/kfctl alpha set-image-name hub.docker.com

Una vez que estemos listos, Kubeflow puede desplegarse utilizando el comando kfctl apply, como se ve en el Ejemplo 4-8.

Ejemplo 4-8. Implementación de Kubeflow
$ ~/bin/kfctl apply -V -f kfctl_istio_dex.v1.0.2.yaml

Contexto Kubernetes

Ten en cuenta que Kubeflow utilizará el contexto de Kubernetes por defecto, y esto dictará en qué clúster de Kubernetes se instalará Kubeflow .

Resumen

En este capítulo hemos visto los pasos prácticos para la implementación de Kubeflow in situ. Aunque muchos usuarios querrán saltar a la nube (como haremos en los próximos capítulos), las instalaciones locales siguen siendo relevantes para muchas situaciones empresariales. Cuando pasemos al siguiente capítulo, veremos cómo empezamos a basarnos en muchos de los conceptos introducidos en este capítulo, a la vez que evolucionamos la instalación para una implementación en la nube.

1 La URL se ha acortado por razones de espacio; la URL completa es https://github.com/kubeflow/kfctl/releases/download/v1.0.2/kfctl_v1.0.2-0-ga476281_linux.tar.gz.

2 La URL se ha acortado por razones de espacio; la URL completa es https://raw.githubusercontent.com/kubeflow/manifests/v1.0-branch/kfdef/kfctl_istio_dex.v1.0.2.yaml.

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