Kubernetes. Un orquestador de contenedores que debes poner en tu vida

Un cluster de Kubernetes está formado por dos tipos de recursos (referidos a máquinas, ya sean físicas o virtuales):

Al desplegar una aplicación en Kubernetes el Master inicia los contenedores de la aplicación. El máster organiza los contenedores para que se ejecuten en los nodos (worker) del cluster. Los nodos se comunican con el master usando la API de Kubernetes. La API es expuesta a través del nodo Master y es posible usarla directamente para intectuar con el cluster.

Los clusters de Kubernetes se pueden desplegar sobre máquinas físicas o virtuales. Para comenzar a practicar con Kubernetes o para tareas de desarrollo, Minikube es una buena opción. En la sección Minikube se presenta más información sobre esta plataforma. Minikube está disponible para Windows, Linux y MacOS.

Tal y como hemos introducido en el apartado anterior, un cluster de Kubernetes está formado por dos tipos de unidades, el nodo Master y los nodos Worker (o siemplemente Nodos).

La figura siguiente ilustra estas dos unidades, así como algunos de los componentes más importantes en su interior.

Kubernetes ofrece una serie de objetos básicos y una serie de abstracciones de nivel superior llamadas Controladores.

Los objetos básicos de Kubernetes son:

Los objetos de nivel superior o Controladores se basan en los objetos básicos y ofrecen funcionalidades adicionales sobre los objetos básicos:

Una configuración de Deployment pide a Kubernetes que cree y actualice las instancias de una aplicación. Tras crear el Deployment, el Master organiza las instancias de aplicación en los nodos disponibles del cluster.

Una vez creadas las instancias de aplicación, el Controlador de Deployment de Kubernetes monitoriza continuamente las instancias. Si un nodo en el que está una instancia cae o es eliminado, el Controlador de Deployment de Kubernetes sustituye la instancia por otra instancia en otro nodo disponible del cluster.

Esta funcionalidad de autocuración de las aplicaciones supone un cambio radical en la gestión de las aplicaciones. Esta característica de recuperación de fallos mediante la creación de nuevas instancias que reemplazan a las defectuosas o desaparecidas no existía antes de los orquestadores.

Al crear un Deployment se especifica la imagen del contenedor que usará la aplicación y el número de réplicas que se quieren mantener en ejecución. El número de réplicas se puede modificar en cualquier momento actualizando el Deployment.

Al crear el Deployment anterior, Kubernetes creó un Pod para ejecutar una instancia de la aplicación. Un Pod es una abstracción de Kubernetes que representa un grupo de uno o más contenedores de una aplicación y algunos recursos compartidos de esos contenedores (p.e. volúmenes, redes)

Los contenedores de un pod comparten una IP y un espacio de puertos, y siempre van juntos y se despliegan juntos en un nodo. La figura siguiente ilustra varias configuraciones de pods:

Los pods son la unidad atómica de Kubernetes. Al crear un despliegue en Kubernetes, el Deployment crea Pods con contenedores en su interior. Cada pod queda ligado a un nodo y sigue allí hasta que se finalice o se elimine. En caso de fallo del nodo se planifica la creación de sus pods en otros nodos disponibles del cluster.

Se dice que en Kubernetes los pods son mortales o efímeros. Cuando un nodo desaparece (bien por un error o por una desconexión), los contenedores que están en el nodo también se pierden. En ese momento, un ReplicaSet se encarga de devolver el cluster al estado deseado y organiza la creación de nuevos pods en otros nodos disponibles para mantener funcionando la aplicación. Las réplicas de los pods han de ser intercambiables y aunque cada pod en el cluster tenga su propia IP única, Kubernetes reconcialiará los cambios entre los pods para que las aplicaciones sigan funcionando.

Los servicios en Kubernetes son una abstracción que definen un conjunto lógico de pods y una política de acceso a ellos estableciendo un nombre para acceder a ellos. Esto permite que haya un acoplamiento débil entre pods dependientes. El acceso puede ser interno o externo al cluster. De esta forma, las aplicaciones sólo usarán los nombres de los servicios y no las IP de los pods, ya que éstas nunca son fijas debido a que, por un lado, los pods se crean y se destruyen para mantener el número de réplicas deseado; y por otro lado, un pod puede ser sustituido por otro ante un problema y el nuevo pod tendrá una IP diferente.

Cada pod tiene una dirección IP única, pero esa IP no se expone fuera del cluster sin lo que se denomina un Servicio. Los servicios pemiten que las aplicaciones reciban tráfico.

Básicamente, un volumen es un directorio para datos que es accesible a los contenedores de un Pod y que persiste a los reinicios de un Pod. El medio que se use para el almacenamiento y cómo se comporte ante una eliminación del Pod depende del tipo de volumen que se use.

Para usar un volumen, un Pod especifica el volumen que proporciona al Pod (el campo .spec.volumes) y donde montarlo en los contenedores (el campo .spec.containers.volumeMounts). Dejamos por ahora el tema de los volúmenes para volver a ellos más adelante cuando usemos archivos de despliegue.

Los objetos ConfigMap permiten almacenar datos en forma de pares clave-valor para que puedan usarse posteriormente en despliegues parametrizados y hacerlos más portables.

Usaremos los ConfigMap para almacenar datos no sensibles sobre la configuración. Deben ser datos no sensibles porque los datos se guardan tal cual.

Los objetos Secret se usan para almacenar información sensible, como contraseñas, tokens OAuth y claves ssh. Colocar esta información en objetos Secret es más seguro que colocarla en texto plano y legible.

No obstante, los datos de los objetos Secret no están cifrados. Están codificados en base64 y pueden hacerse visibles fácilmente. Sistemas como Vault son usados de forma complementaria para aumentar la seguridad de la información que contienen los Secret.

Hasta ahora, todos los objetos que hemos creado (pods, deployments, replicasets, services, configmaps y secrets) están en el mismo lugar, en el mismo espacio. Concretamente en el espacio default. Es lo que se conoce como namespace. Los namespaces se usan para organizar objetos en un cluster, proporcionando una forma de mantener separados los recursos en el cluster. De cara a dar nombres a los recursos, los nombres sólo tienen que ser únicos a nivel de namespace, pero no a nivel de cluster.

En primer lugar veremos cuáles eran las condiciones del despliegue de ejemplo que estamos usando.

El comando siguiente escala a 4 réplicas el despliegue de ejemplo (jsonproducer)

Unos instantes después podremos comprobar que el Deployment ya ha alcanzado el estado deseado.

La aplicación sigue disponible sin ningún cambio para el usuario final. Sin embargo, ahora hay 4 réplicas cuyo tráfico es gestionado por un balanceador de carga asociado al servicio.

La información de las réplicas la podemos obtener consultando el número de pods con el comando siguiente:

Si ahora por cualquier motivo dejase de estar disponible alguno de los nodos en los que se encuentra desplegados los pods de la apliación, o bien dejase de funcionar alguno de los pods, el Controlador de Deployment de Kubernetes se encargaría de organizar la creación de nuevos pods para volver a alcanzar el estado deseado, en nuestro caso 4 réplicas.

Probemos esta funcionalidad eliminando el último pod y comprobando como Kubernetes organiza inmediatamente la creación de otro pod que lo sustituya.

Por último, si ahora queremos reducir el número de réplicas a 2 bastará con volver a indicarlo al Deployment en el parámetro replicas y este será el nuevo estado a alcanzar.

Veamos cómo crear un archivo de manifiesto para desplegar un pod mediante un archivo de manifiesto YAML. El ejemplo despliega una web de contenido estático.

Archivo pod-dotnet2019.yaml

Desplegaremos el pod con kubectl con este comando:

Si contamos con una URL para el manifiesto también lo podemos desplegar haciendo referencia a la URL:

Esto creará un pod denominado dotnet2019 en el namespace default de nuestro cluster Kubernetes.

Para ver la aplicación de forma provisional haremos un port forward entre el pod y nuestro equipo local con

Al abrir un navegador en nuestro equipo en localhost:83 accederemos a la web desplegada.

Si ahora queremos actualizar el pod con una nueva versión de la aplicación, basta con modificar el manifiesto YAML con la nueva imagen y volver a aplicar los cambios. Para ilustrar esto, modifiquemos la versión del manifiesto anterior a la imagen ualmtorres/dotnet2019web:v1 en lugar de la version v0. La nueva versión tiene los botones en verde.

La nueva versión del manifiesto quuedaría así:

Una vez guardados los cambios en el archivo de manifiesto, aplicaríamos los cambios con

Esto hará que se descargue la nueva imagen, se cree un nuevo pod con la nueva imagen y se elimine el pod que estaba sirviendo. Una vez finalizado ese proceso ya estará disponible la nueva versión de la aplicación en la misma URL:

Normalmente no desplegaremos Pods. En su lugar desplegaremos Deployments. En ellos podremos incluir contenedores con imágenes diferentes para que puedan trabajar de forma coordinada. Un ejemplo habitual es el de frontend y backend. En la espeficación de los contenedores indicaremos además de la imagen de partida, número de réplicas, recursos solicitados (p.e. cantidad de RAM, porcentaje de CPU, …​). Esto, además de desacoplar frontend y backend, desde el punto de vista de la escalabilidad, permite escalar frontend y backend de forma independiente.

Para ilustrar el despliegue de una aplicación mediante archivos YAML vamos a desplegar una aplicación de ejemplo que consuma del servicio jsonproducer creado anteriormente. Se trata de un ejemplo muy sencillo de un entorno frontend-backend con un funcionamiento independiente.

Vamos a crear un archivo de Deployment denominado json-reader-deployment.yaml. Este archivo básicamente contiene entre otros, el nombre de despliegue, el selector que usa el despliegue para seleccionar los pods que forman parte del despliegue, la etiqueta que usan los pods para ser agrupados y formar parte del mismo Deployment, número de réplicas y la imagen usada para crear el contenedor de cada pod.

El despliegue se realiza con kubectl con el comando siguiente

Al crear el despliegue, se procederá a descargar la imagen y se pasarán a crear los dos pods indicados para este despliegue. Podemos ver los pods creados con el comando siguiente comprobando que efectivamente se creado los dos pods jsonreader que exigía el despliegue.

Podemos ver el despliegue con el comando siguiente

También podemos ver los ReplicaSets creados por los despliegues

Los pods los podemos ver junto con sus etiquetas con el parámetro --show-labels

Ahora podríamos ver a cualquiera de los pods de jsonreader haciendo port forward a nuestro equipo.

Este sería su resultado en un navegador

Puedes encontrar un ejemplo más completo de Deployment con un front-end más elaborado que consume de una API que proporciona calificaciones de estudiantes.

Sin embargo, vemos que el frontend no puede recuperar los datos del backend. Esto se debe a que aún no hay definido un servicio. En la siguiente sección encontraremos la solución a ese problema.

Un Service es una abstracción que define una agrupación de Pods y una política de acceso a ellos. El conjunto de Pods al que se dirige un Servicio están determinados por un selector.

En la sección Ejemplo de escalado de una aplicación habíamos creado un servicio directamente al hacer kubectl expose deployment jsonproducer --type=NodePort. A continuación vamos a ver cómo podemos crear ese servicio mediante un manifiesto YAML.

Vamos a crear un archivo de Servicio denominado json-reader-service.yaml. Este archivo básicamente contiene entre otros el nombre de servicio, el tipo del servicio (ClusterIP, NodePort, …​), el puerto de acceso a los pods del despliegue y el selector que identifica al despliegue con el que se corresponde el servicio creado.

El despliegue se realiza con kubectl con el comando siguiente

El despliegue nos permitirá acceder a la aplicación en un puerto en el rango 30000-32767. En este caso ha tocado el 31976

Para poder acceder al servicio pediremos a Minikube que nos lo muestre.

Esto hará que se abra un navegador con la aplicación jsonreader que simplemente lee el JSON y presenta un saludo sencillo.

También podemos usar el Kubernetes Dashboard para mostrar información de interés sobre este despliegue, viendo como el Deployment de jsonreader se ha incorporado a la lista de despliegues disponibles en el cluster, así como los Pods, ReplicaSets y Services, como muestran las figuras siguientes.

Puedes encontrar un ejemplo más completo de Service que completa el Deployment de la sección anterior. Recordemos que el frontend no podía obtener la lista de calificaciones que ofrecía la API. Esto se debía a que se había desplegado el Deployment de la API, pero no se había desplegado su Service, que es lo que le da visibilidad.

Al desplegar el servicio del backend ya podremos ver que el frontend ya sí puede acceder a los datos que genera la API.

Tal y como comentamos anteriormente en la sección ConfigMaps, los objetos ConfigMap permiten almacenar datos no sensibles en forma de clave valor. Un uso habitual de los ConfigMap es para inicialización de variables de entorno.

Antes de comenzar a usar ConfigMaps con variables de entorno, veamos cómo establecer variables de entorno. El ejemplo siguiente muestra un manifiesto YAML que crea un pod e inicializa dos variables de entorno (NOMBRE y APELLIDOS)

El código siguiente muestra cómo lanzamos el manifiesto YAML para configurar las variables de entorno:

Una vez que el pod esté en ejecución podremos abrir una sesión interactiva en él con

Una vez dentro del contenedor del pod podremos mostrar las variables de entorno

Una vez hecho esto haremos el mismo ejemplo pero configurando los valores a través de un ConfigMap. Una vez creado el ConfigMap, habrá que acceder a sus pares clave-valor para asignarlo a las variables del entorno en el contenedor de destino.

El manifiesto YAML siguiente crea un objeto ConfigMap con dos pares clave-valor y un objeto Pod que accede al ConfigMap para inicializar dos variables de entorno.

El código siguiente muestra cómo lanzamos el manifiesto YAML para configurar las variables de entorno:

Una vez que el pod esté en ejecución podremos abrir una sesión interactiva en él con

Una vez dentro del contenedor del pod podremos mostrar las variables de entorno

Como comentamos anteriormente en la sección Secrets, los objetos Secret se usan para almacenar información sensible, como contraseñas, tokens OAuth y claves ssh. No obstante, los datos de los objetos Secret no están cifrados. Están codificados en base64 y pueden hacerse visibles fácilmente.

Para ilustrar el uso de Secrets veamos el manifiesto de creación de un pod con MySQL sin y con secretos.

El manifiesto siguiente crea un pod MySQL al que se le pasa la variable de entorno MYSQL_ROOT_PASSWORD durante su inicialización para la contraseña del root. En este ejemplo, el valor de la variable de entorno de la contraseña del root es pasada en el propio manifiesto

El manifiesto anterior lo lanzamos con

A continuación vamos a modificar el manifiesto anterior para hacer uso de objetos Secret.

Kubernetes guarda los secretos en base64. Por tanto, los valores que vayamos a almacenar en los pares clave-valor de un secreto tendrán que estar en base64.

Para codificar en base64 el valor password que utilizamos en el ejemplo anterior para contraseña del root, ejecutaremos el comnando siguiente desde la línea de comandos:

Esto devolverá la cadena cGFzc3dvcmQ=, que corresponde a la cadena password en base64. Este valor codificado será el que usaremos para la creación del Secret.

A continuación crearemos el manifiesto YAML secret-password.yaml que inicializa un objeto Secret.

Lanzamos la creación del Secret con kubectl:

Por último, creamos el manifiesto YAML que inicializa un pod MySQL que lee del Secret creado la contraseña del usuario root para inicializar el pod correctamente.

Este manifiesto lo lanzaremos con kubectl:

Apache Benchmark es una herramienta útil para realizar pruebas de carga. A continuación se muestra cómo hacer una prueba de carga con

La figura siguiente ilustra varias capturas de cómo ha ido adaptándose el número de pods a la demanda a lo largo de la prueba de carga. Hemos usado colores naranja, rojo y azul para ilustrar el estado de stress y la respuesta elástica con el número de pods en distintos estados que hemos ido capturando durante la prueba de carga.

La figura siguiente ilustra el estado del objeto HPA con el comando

Se trata de volúmenes que se crean al asignar un pod a un nodo. Su contenido se mantiene en el nodo hasta que el contenedor sea eliminado. Su contenido se mantiene aunque el contenedor sea destruido o eliminado.

De forma predeterminada, los volúmenes emptyDir son almacenados en el medio de almacenamiento prederminado del nodo (HD, SSD, NAS, …​). No obstante, se puede definir este tipo de volúmenes como volátiles configurando la propiedad emptyDir.medium como Memory y Kubernetes lo montará como un sistema de archivos RAM, lo que puede ser muy útiles para cachés.

Este tipo de contenedores se suele usar para situaciones en las que queremos compartir datos entre varios contenedores en un pod o cachés.

El manifiesto siguiente crea un pod con Redis usando un volumen emptyDir. El volumen se monta en el directorio /data del contenedor, que es el directorio predeterminado de almacenamiento de la imagen de Redis.

A continuación ya podremos desplegar este pod con un volumen emptyDir usando kubectl

Un volumen hostPath monta en el contenedor un archivo o un directorio del sistema de archivos del nodo en el que está ejecutándose el pod.

El ejemplo siguiente muestra un manifiesto para la creación de un pod con un contenedor Apache que monta un volumen hostPath. El contenedor monta ese volumen en la carpeta de publicación del contenedor Apache (/usr/local/apache2/htdocs/).

Podemos montar volúmenes OpenStack Cinder en pods Kubernetes. Previamente tendremos que haber configurado el cluster Kubernetes con OpenStack como proveedor cloud. Los volúmenes Cinder son volúmenes externos al cluster Kubernetes y son persistentes, de forma que su contenido se mantiene después de la eliminación de los pods que lo tengan montado.

Para este ejemplo partimos de un cluster Kubernetes gestionado con Rancher. En la configuración del archivo YAML del cluster añadiremos lo siguiente:

Kubernetes permite montar shares NFS existentes en un pod. Los volúmenes NFS son volúmenes externos al cluster Kubernetes y son persistentes, de forma que su contenido se mantiene después de la eliminación de los pods que lo tengan montado.

Para este ejemplo usaremos Openstack Manila como servidor NFS. Para los ejemplos ya tenemos creado un share,. disponible en en la ruta /var/lib/manila/mnt/share-2e653a46-bc6a-4fc3-83d3-d144554113e1 del servidor 192.168.64.17

cloud_provider: name: "openstack" openstackCloudProvider: block_storage: ignore-volume-az: true trust-device-path: false global: auth-url: "http://192.168.64.12:5000/v3/" domain-name: "default" tenant-name: "mtorres" username: "mtorres" password: "xxx" load_balancer: create-monitor: false manage-security-groups: false monitor-max-retries: 0 use-octavia: false metadata: request-timeout: 0

El archivo de contextos

Disponible en ~/.kube/config

Obtener los contextos

Añadir un contexto nuevo

Obtener los datos de conexión a Rancher desde

Ahí aparecen los datos de conexión al cluster. Ahí se encuentran los datos que tenemos que copiar en el archivo ~/.kube/config

Editamos el archivo el archivo ~/.kube/config y debería quedar algo así

Usar un contexto

Si ahora consultamos los contextos, veremos que el contexto activo es produccion-ci. Por tanto, todas las operaciones que hagamos con kubectl a partir de ahora se dirigirán contra ese contexto (cluster-usuario-namespace).

Istio viene a incorporarse al vocabulario marinero y ballenero del ecosistema de Docker y Kubernetes. Istio es una palabra griega que significa navegar.

La figura siguiente ilustra una aplicación sin Istio. En ella, cada microservicio es el responsable de implementar la funcionalidad de discovery, balanceo, resilencia, métricas y trazado.

La figura siguiente ilustra cómo en las aplicaciones basadas en Istio los pods están formados por dos contenedores: el contenedor propio del microservicio y el del sidecar. Al sidecar se le delegan las tareas de discovery, balanceo, resilencia, métricas y trazado, lo que facilita el desarrollo de los microservicios.

Istio ofrece una forma declarativa, mediante la creación de manifiestos YAML, de gestión del tráfico, enrutado selectivo de peticiones (en lugar del round robin que ofrece Kubernetes), diferentes tipos de despliegue (canary, A/B, blue/green), resilencia a nivel de red (con opciones de retry, timeout), control de acceso, observación de microservicios distribuidos comprendiendo los flujos y trazas y pudiendo ver las métricas importantes de forma inmediata, inyección de caos para poner a prueba la resilencia de aplicaciones y servicios, por citar algunas de sus funcionalidades destacadas.

Para activar el uso de Istio en un namespace (p.e. default) se haría con

Istio consta de un plano de control y un plano de datos. El plano de datos está formado por proxies que se integran en los pods de la aplicación. Usando el patrón del sidecar, cada instancia de la aplicación tendrá su proxy dedicado a través del cual pasa todo el tráfico antes de llegar a la aplicación. Estos proxies individuales son gestionados individualmente por Istio para enrutar, filtrar y aumentar el tráfico según sea necesario.

Además, Istio permite realizar deciciones de enrutado en función de las cabeceras HTTP (p.e. tipo de navegador, usuario, …​)

Sin embargo, toda esta funcionalidad tiene un coste sobre la infraestructura. Cuando mayor sea el cluster, mayor será la carga añadida al sistema. Cada sidecar consume bastante RAM (unos 350Mb). Además, añade una latencia de unos 10 ms a cada petición.

Para no perdernos en los detalles usaremos un ejemplo muy sencillo con dos servicios: uno que produce datos y otro que los presenta. Podríamos ver este ejemplo como un ejemplo muy reducido de backend y frontend.

El servicio que genera datos se denomina jsonproducer y genera un documento JSON con un único elemento nombre y un valor asociado (p.e. {"nombre": "manolo"}). De este servicio se cuenta con dos versiones, cada una con su imagen Docker correspondiente. La primera versión (v0) devuelve el elemento JSON {"nombre": "manolo"}. La segunda versión (v1) devuelve el elemento JSON {"nombre": "Manuel Torres"}

El servicio que consume datos se denomina jsonreader y usará los datos leídos de jsonproducer para presentarlos al usuario en forma de saludo, mostrando Hola seguido del nombre leído del JSON devuelto por la versión de jsonproducer usada (Hola manolo cuando use v0 y Hola Manuel Torres cuando use v1).