Brendan Burns - Guía práctica de Kubernetes

A Brendan le gustaría dar las gracias a su maravillosa familia, Robin, Julia y Ethan, por el amor y el apoyo que le brindan en todo lo que hace; a la comunidad de Kubernetes, sin la cual nada de esto sería posible; y a sus fabulosos coautores, sin los cuales este libro no existiría.

A Dave le gustaría agradecer a su bella esposa, Jen, y a sus tres hijos, Max, Maddie y Mason, todo su apoyo. Agradece también a la comunidad de Kubernetes todos los consejos y la ayuda que ha brindado a lo largo de los años. Finalmente, le gustaría dar las gracias a sus coautores por hacer realidad esta aventura.

A Lachlan le gustaría agradecer a su esposa y a sus tres hijos su amor y su apoyo. También le gustaría dar las gracias a todos los componentes de la comunidad de Kubernetes, incluidas las maravillosas personas que han dedicado su tiempo a enseñarle a lo largo de los años. Quisiera enviar un agradecimiento especial a Joseph Sandoval por su tutoría. Y, finalmente, querría dar las gracias a sus fantásticos coautores por hacer posible este libro.

A Eddie le gustaría agradecer a su esposa, Sandra, su apoyo moral y que lo dejara desaparecer durante horas para escribir mientras ella estaba en el último trimestre de su primer embarazo. También le gustaría agradecer a su nueva hija, Giavanna, el impulso que le ha dado para seguir adelante. Finalmente, querría dar las gracias a la comunidad de Kubernetes y a sus coautores, que siempre han sido guías en su viaje para convertirse en un nativo de la nube.

A todos nos gustaría agradecer a Virginia Wilson su trabajo en el desarrollo del manuscrito y su ayuda a la hora de reunir todas nuestras ideas; y a Bridget Kromhout, Bilgin Ibryam, Roland Huß y Justin Domingus, por cuidar los detalles finales.

En este capítulo se describen las prácticas para configurar una sencilla aplicación multinivel en Kubernetes. La aplicación consta de una aplicación web básica y de una base de datos. Aunque seguramente no se trata de la aplicación más complicada, es un buen ejemplo para comenzar a orientarnos en la administración de una aplicación en Kubernetes.

La aplicación que usaremos para nuestro ejemplo no es particularmente compleja. Es un sencillo servicio de publicaciones que almacena sus datos en un backend de Redis. Tiene un servidor de archivos estáticos independiente que usa NGINX. Presenta dos rutas web en una sola URL. Una de ellas es para la interfaz de programación de aplicaciones (API) RESTful de la publicación, https://my-host.io/api , y la otra es un servidor de archivos en la URL principal, https://my-host.io . Utiliza el servicio Let’s Encrypt para administrar certificados de la capa de conexión segura (Secure Sockets Layer) (SSL). La Figura 1-1presenta el diagrama de la aplicación. A lo largo de este capítulo vamos a ir creando esta aplicación, usando en primer lugar archivos de configuración YAML y después diagramas de Helm.

Figura 1-1 Diagrama de la aplicación.

Antes de exponer en detalle cómo crear esta aplicación en Kubernetes, vale la pena discutir cómo vamos a gestionar las propias configuraciones. Con Kubernetes, todo se representa de forma declarativa . Esto significa que escribimos los estados deseados de la aplicación en el clúster (generalmente en archivos YAML o JSON) y estos estados deseados que se han declarado definen todas las partes de la aplicación. Este enfoque declarativo es mucho más conveniente que un enfoque imperativo , en el que el estado del clúster es la suma de una serie de cambios en el mismo. Si un clúster está configurado de forma imperativa, es muy complicado replicar y entender cómo el clúster ha llegado a estar en ese estado. Esto hace que sea muy difícil comprender la aplicación o recuperarse de los problemas que esta pueda tener.

Cuando se declara el estado de la aplicación, los programadores suelen preferir YAML a JSON, aunque Kubernetes soporta ambos tipos de archivo. Esto se debe a que YAML es algo menos prolijo y más editable que JSON. Sin embargo, vale la pena señalar que YAML es sensible al sangrado. A menudo, los errores en las configuraciones de Kubernetes se deben a un sangrado incorrecto en YAML. Si algo no se comporta como se espera, es aconsejable comprobar el sangrado.

Debido a que el estado declarativo contenido en estos archivos YAML sirve como fuente de verdad para la aplicación, la gestión correcta de este estado es fundamental para lograr nuestros objetivos. Cuando modifiquemos la aplicación para llevarla al estado deseado, nos interesará poder gestionar los cambios, validar que sean correctos, auditar quién realizó esos cambios y, posiblemente, si las cosas fallan poder volver al punto de partida. Afortunadamente, en el contexto de la ingeniería de software, ya hemos desarrollado las herramientas necesarias para gestionar tanto los cambios en el estado declarativo como la auditoría y el proceso de reversión. Es decir, las mejores prácticas se aplican directamente a la tarea de administrar el estado declarativo de la aplicación, en relación tanto con el control de versiones como con la revisión de código.

En la actualidad, la mayoría de los desarrolladores almacenan sus configuraciones de Kubernetes en Git. Aunque los detalles específicos del sistema de control de versiones no son importantes, en el ecosistema de Kubernetes muchas herramientas esperan archivos en un repositorio Git. Para la revisión de código hay mucha más heterogeneidad; aunque claramente GitHub es bastante popular, otros usan herramientas o servicios locales de revisión de código. Independientemente de cómo implementemos la revisión del código para la configuración de la aplicación, debemos tratarla con la misma diligencia y atención que aplicamos al control del código fuente.

Cuando se trata de diseñar el sistema de archivos de la aplicación para organizar los componentes, generalmente vale la pena usar la organización de carpetas que viene con el sistema de archivos. Por lo general, se utiliza un único directorio para incluir Application Service (servicio de la aplicación), cualquiera que sea la definición de Application Service que sea útil para el equipo de trabajo. Dentro de ese directorio, los subdirectorios se utilizan para los subcomponentes de la aplicación.

Para nuestra aplicación, presentamos los archivos de la siguiente manera:

journal/ frontend/ redis/ fileserver/

Dentro de cada directorio se encuentran los archivos YAML específicos que se necesitan para definir el servicio. Como veremos más adelante, a medida que vayamos desplegando nuestra aplicación en varias regiones o clústeres diferentes, la disposición de archivos se irá complicando.

Para describir nuestra aplicación, comenzaremos por el frontend y trabajaremos hacia abajo. La aplicación frontend para la publicación es una aplicación Node.js implementada en TypeScript. La aplicación completa ocupa demasiado espacio para incluirla en el libro. Presenta un servicio HTTP en el puerto 8080 que atiende peticiones de la ruta / api / * y usa el backend de Redis para añadir, eliminar o devolver las entradas habituales de la publicación. Esta aplicación se puede compilar en una imagen de contenedor utilizando el Dockerfile incluido y se puede enviar a nuestro repositorio de imágenes. Después, sustituimos el nombre de esta imagen en los ejemplos de YAML que vendrán a continuación.