 Buen día y bienvenidos a esta charla de dando tus primeros pasos en Kubernetes. Bueno, buen día o una noche dependiendo desde dónde o a qué hora estén viendo este vídeo. Esta conferencia va a ser un tanto teórica con una pequeña demostración del funcionamiento de Kubernetes al final, que es para las personas que están iniciándose completamente en lo maravilloso que es Kubernetes. Vamos a abarcar a grandes rasgos algunos de los aspectos más importantes de esta herramienta. Bueno, nosotros podríamos pasar días completos hablando de Kubernetes que aún el tiempo sería poco, así que vamos a empezar. Primero, pues voy a hablar un poco sobre mí. Mi nombre es Josy Castillo, soy estudiante ingeniería en ciencias y sistemas o al menos lo ver hasta hace un par de días antes de esta charla. Soy full stack developer actualmente. Trabajo con lo que es .NET, JavaScript y cosas similares. Soy entusiasta cloud native. Me encanta probar diferentes herramientas cloud native, experimentar con cobernetes y diferentes herramientas con las que nosotros lo podemos utilizar. También soy colaborador de la comunidad cloud native de Guatemala. Ahora bien, vamos a hablar un poco del origen de cobernetes. ¿Por qué se dio la necesidad de crear esta herramienta? Bueno, inicialmente, su desarrollo se llevó a cabo durante una investigación de cómo realizar despliegues en entornos en la nube por el año 2013. Ya los contenedores y Docker específicamente tenían bastante popularidad para este tipo de implementaciones, arquitecturas contenderizadas, pero cada vez la demanda de esto era mucho más grande. Y conforme esta demanda crecía, la escala de mantenimiento de estos contenedores también, lo que hacía mucho más difícil mantener, administrar y observar estas arquitecturas en nuestros entornos en la nube. Fue entonces cuando BrainGrant y TeamHawking, junto con otros ingenieros de Google, trabajaron en un sistema que ellos querían que fuera de código libre para automatizar despliegues masivos de contenedores, ajustar las escalas de esto conforme fuera necesario y, por supuesto, manejar las aplicaciones contenderizadas para facilitaros este trabajo, hacerlo más óptimo, más sencillo y, por supuesto, hacer mucho más sencilla la administración. Por lo cual fue hasta el año 2014, donde junto con Google se presentó la primer versión de gubernetes, es decir, hace ocho años. Ahora bien, ¿qué es gubernetes en sí? La descripción oficial que ellos nos dan en su sitio dice que es una plataforma portable, extensible, de código abierto para administrar cargas de trabajo y servicios. A nosotros nos facilita la automatización y configuración declarativa. Más adelante, vamos a ver por qué es esta configuración declarativa. Esta herramienta soporta muy altas cargas de trabajo. Nos permite orquestar contenedores en cluster, correr diferentes réplicas en nuestros pods. Ya dentro de un momento vamos a ver algunos de estos conceptos para que no se nos pierdan. Nos permite, de una forma más fácil, observar el estado de nuestra arquitectura y también exponer nuestros servicios hacia el exterior, que es lo que nosotros nos interesa, ya sea por medio de balanceadores de carga, diferentes formas de enrutamiento. También nos permite realizar rollbacks en caso de que se genere algún despliegue fallido de la arquitectura. Esto es bastante normal. Todos somos humanos y obviamente nos podemos equivocar. Pero el gobierno nos da las herramientas para corregirlo rápidamente. También se puede realizar ciertas políticas de escalado conforme sea necesario, junto con muchas otras características que nosotros podemos realizar. Ahora bien, antes de entrar de lleno a la demostración en sí, vamos a ver un poco de los conceptos importantes de Kubernetes. Primero, los pods. Los pods dentro de Kubernetes van a ser la unidad de despliegue más pequeño que podemos tener. Este puede tener uno o más contenedores con su propio almacenamiento, red compartidos y las mismas especificaciones para el despliegue. Es decir, si nosotros en un pod tenemos cinco contenedores, cada uno con una determinada aplicación y queremos diferentes réplicas, cada réplica, es decir, cada pod va a tener estas mismas características que nosotros desplieguamos en uno. Los cluster, este va a ser un conjunto de máquinas o de nodos que ejecutan nuestras aplicaciones. Esto tiene como mínimo un plano de control. Estos conceptos ahorita, este concepto ahorita no es muy importante y una o varias computadoras no. Ya en la demostración vamos a ver un poco más de esto. En el caso del plano de control, va a ser el que se encarga de mantener el estado que nosotros queremos que tenga la arquitectura. Es decir, va a ser el que va a estar monitoreando constantemente nuestra arquitectura para verificar que esté con nosotros definimos si se presenta alguna falla, algún error. Este va a ser el encargado de verificar e intentar recuperarlo. Los réplicas sets. Eso nos da la capacidad de mantener de forma estable un grupo de réplicas de pods que se van a estar ejecutando en todo momento. También nos permite definir un cierto número de réplicas, como lo vamos a ver en el ejemplo, indicando cuántos pods debemos gestionar. Los deployments son una parte fundamental de cobernetes. Esta es la forma que nosotros vamos a utilizar para decirle a cobernetes cómo vamos a crear, modificar, eliminar nuestras instancias de los pods, nuestra arquitectura, cómo vamos a escalar, exponer nuestros servicios, actualizar o realizar rollbacks. Los daemon set nos van a garantizar que nuestros nodes estén ejecutando una copia de un pod conforme más nodes creamos en un cluster. Se van a ir agregando, obviamente, más pods en los mismos. Si nosotros los eliminamos, pues estos van a ser destruidos. Pero cuando nosotros eliminamos un daemon set, estos se van a limpiar de todos los pods que nosotros habíamos creado. Los labels o como su nombre lo dice, son etiquetas que normalmente van como una clave valor como lo vamos a ver en el archivo de definición, en el cual nosotros vamos a asociar diferentes objetos de cobernetes, como por ejemplo los pods, a características que nosotros queremos que vaya a tener un display o una exposición de servicio o la arquitectura en sí. Los namespace van a ser los diferentes cluster que cobernetes nos permiten utilizar nosotros. Van a ser los cluster virtuales, aparte de los cluster físicos. Estos van a poseer diferentes recursos que van a ser únicos dentro de cada namespace y también lo podríamos ver con una forma sencilla de separar recursos de una forma lógica. Y por último, los servicios. Estos van a ser objetos de la API de cobernetes que van a describir la forma en que nosotros vamos a acceder a nuestras aplicaciones. Es decir, van a ser la forma en la que vamos a permitir el descubrimiento de los servicios. Ahora bien, para la parte de la exposición de los servicios, cobernetes nos brinda cuatro formas principales. La primera es el port forward. Este funciona como un NAT, es decir, redirige una dirección IP y un número de puerto de un sistema a otro. Esto es bastante útil cuando nosotros trabajamos con pods individuales, no con servicios y únicamente necesitamos el comando qctl por forward para poder utilizarlo. El segundo es no port. Este es un puerto abierto que cada que se le va a dar a cada cluster y de forma transparente cobernetes lo vean rutar hacia el tráfico, hacia este puerto. Si la aplicación está corriendo en uno instinto, también funciona. Por defecto, todos los clusters de cobernetes soportan no port, pero si estamos trabajando con algún proveedor en la nube, ya sea Google Cloud, Microsoft Azure, AWS, sí puede ser necesario que nosotros vayamos con las reglas de seguridad de cada servicio para habilitar el puerto que nosotros estamos perunciendo con cobernetes. El tercero, load balancer, tal vez uno de los más útiles. Este también es un servicio de cobernetes que nos permite evitar downtimes. Dado que si en algún caso, algún de los nuevos falla, load balancer, aparte de lendarnos una IP hacia el exterior, se va a encargar de enrutar los diferentes paquetes hacia los pods activos. Este balanceador de carga lo va a generar de forma externa, es decir, sobre el servicio en la nube en el cual estamos trabajando. Y el último, de Zingress. Esta es una fracción de un nivel un poco más alto que nos permite exponer rutas HTTP o HTTPS según las reglas que nosotros definamos desde el exterior de nuestros clusters hacia los servicios internos que nosotros ya hemos definido. También, obviamente, podemos definir muchas otras reglas. Ahora bien, ¿de qué forma nosotros podemos utilizar cobernetes? Personalmente, ahí me gusta manejarlo a través de una línea de comandos. Ya sea que estén en un sistema Linux, en Windows utilizando CMD o PowerShell desde la terminal de Mac, ustedes pueden utilizar cobernetes, únicamente necesario instalar el cliente de cobernetes y podemos acceder a todos sus comandos hacia el cluster que nosotros estemos utilizando. Esta es la forma consideraría yo más rápida. No les voy a mentir, son bastantes comandos, pero no es imposible aprender los. Todos los comandos nos van a brindar mucha información sobre el estado de nuestra arquitectura, de nuestros pods, de nuestros servicios, pero así como se puede manejar desde la línea de comandos, también lo podemos manejar desde un dashboard. Únicamente que este dashboard se tiene que implementar al igual que la arquitectura, decir que hay un cierto archivo manifiesto que nosotros podemos desplegar con nuestros namespace, que nos va a generar un dashboard similar al que nosotros estamos viendo de esta forma. Únicamente que para esto ya es necesario para nosotros ciertos recursos adicionales para poderlo visualizar, ciertas configuraciones, permisos, generación de usuarios para acceder a esto, pero también se puede utilizar de esta forma, de la misma forma crear despliegues, agregar pods y en este caso es de la forma que prefieran utilizarlo. ¿Ahora bien? ¿Dónde se utiliza actualmente cubernetes? Bueno, estas son sólo algunas de las empresas que actualmente utilizan cubernetes para sus despliegas. Estoy seguro que podrán reconocer de la imagen algunas de las empresas, todas estas que aparecen en la página oficial de cubernetes. En caso que deseen ingresar a la página, yo las voy a dejar finales las referencias para que puedan ingresar y ver qué otras empresas lo están utilizando, ¿Verdad? Ahora bien, vamos a pasar rápidamente a la parte de la demostración que estoy seguro que están esperando. Todo lo que vamos a mostrar ahorita lo van a poder replicar. Yo se los voy a dejar todo en el repositorio de la aplicación que voy a utilizar junto con las instrucciones de cómo utilizarlo en Google Cloud, que es el que el proveedor que me gusta para cubernetes. Esto no quiere decir que no se puede utilizar en una computadora local, también es posible. Hay herramientas como Minikube que nosotros podemos instalar. Este únicamente necesitará algún hipervisor para virtualizar el cluster únicamente que con Minikube únicamente podemos utilizar un cluster para nuestras pruebas, ya sea por medio de Docker, VMware o VirtualBox. Hay que realizar ciertas configuraciones adicionales. En el caso de que deseen probar toda la potencia de cubernetes, yo les recomendaría utilizar en algún proveedor en la nube, ya que van a poder crear máquinas con más capacidad de diversos clusters. En mi caso, yo ya tengo creado acá el cluster. Lo creé con anticipación, dado que si tarda algunos minutos en realizar todas las configuraciones, creé un único cluster que va a tener dos nuevos asignados. En las relas de entrada, yo asigné dado que es un ejemplo, permitir todo el tráfico de entrada y salida y el tipo de máquina. En el caso de Google Cloud, podemos ver rápidamente que la opción de cubernets Engine ya aparece el cluster creado. Yo lo nombré OSSL, OSSL, Open Source Summit Latin America. Y como habíamos hablado en los clusters virtual de las máquinas virtuales y físicas, en este caso el cluster está utilizando dos máquinas físicas para su funcionamiento dentro de un solo cluster. Ahora bien, al descargar o clonar el repositorio, para ver a tus archivos, el archivo Rhythmic va a tener las instrucciones de cómo implementar este entorno en sus computadoras. Yo lo hice basándome en un entorno Linux, con el que les estoy presentando. Y va a estar también el archivo de la arquitectura, con el nombre de cubernetes, el example Jam. Vamos a ver rápidamente este archivo. Muy bien. De primero, le estoy indicando acá que el tipo de arquitectura, lo que la implementación que voy a realizar es un deployment, es decir, un display que va a tener el nombre webtest. Y en este caso voy a implementar cinco réplicas, es decir, se van a implementar cinco plugs con mi aplicación. Pero esto lo vamos a cambiar. Digamos que vamos a utilizar ocho en este caso. El contenedor que vamos a utilizar está dentro de mi repositorio, y yo sí. Y la imagen se llama OSS-LATAM-22. Esta también les voy a dejar el enlace en el repositorio para que ustedes puedan entrar a verificarla. Este es lo único que tiene, es un servidor Apache con un sitio web que dice Hello World. El puerto que el contenedor está utilizando por defecto, pues era Apache, va a ser el puerto 80. Y ahora, después de haber definido nosotros nuestro display, vamos a definir el servicio. Es decir, vamos a definir la forma en la que vamos a acceder a la aplicación obtenerizada. En este caso, el tipo de implementación va a ser un servicio para webtest. Then, ambas van a estar implementados dentro del namespace default para no crear un namespace distinto. Y aquí está la parte del mapeo de puertos. Voy a utilizar el puerto 80 que va a estar apuntando al puerto 80 del contenedor. Y el puerto que quiero que mapee del node va a ser el 30,004. Y esto quiero que lo exponga a través de un load balancer. En caso de nosotros querramos utilizar ingress, en esta parte sería donde nosotros lo debemos definir. Yo por facilidad y gusto voy a utilizar el load balancer. Y esto me va a generar un load balancer físico sobre Google Cloud sobre el cual voy a poder yo acceder en línea la aplicación. Ahora bien, vamos a acceder rápidamente y vamos a verificar. Actualmente, y existe el cluster, vamos a ingresar el primero de los comandos. Todos los comandos que yo voy a utilizar se los voy a dejar en el repositorio, en la parte final. Y el primero que voy a utilizar será qctl getBuds. Y ahorita me tiene que dar un pequeño error. Dice que no encontró ningún recurso dentro de nuestro namespace. Esto porque no he desplegado ninguna arquitectura. Vamos a intentar con qctl getNamespaces. Y actualmente aquí está el namespace default que es el que voy a utilizar para la aplicación. Y otros namespaces que Kubernetes genera para su funcionamiento. Ahora bien, vamos a desplegar nuestra arquitectura para eso utilizaremos el comando qctl apply-f. Este minusf significa que nosotros vamos a utilizar un archivo manifiesto para el display, que en este caso es example.jammable. Kubernetes example.jammable. Impresionamos enter y empezará a crear el display. Decían cuenta que dice que el deployment se ha creado y que también se ha creado el servicio. Ahora vamos a verificar un qctl getBuds. Y aquí nos dice que ya están desplegadas y las 8 réplicas que definimos. Cada uno tiene ahorita un contenedor dado que no definimos más contenedores dentro de cada pod y que el status just running es decir que ya están activos y funcionando. En este caso lo hizo, hizo todo el proceso muy rápido. En el caso de que sea más lento y tenga una oportunidad de probar, pueden correr este comando y darse cuenta que al principio no va a ser esto a running, sino que va a estar intentando primero dar un pull en la imagen que se encuentra en el hub, en el Docker hub para obtener la imagen. Si la logra obtener exitosamente, le implementa y el status cambia a running. También hay otros comandos. Por ejemplo, qctl getServices. En este caso nosotros implementamos un servicio que era de tipo load balancer, que es la exposición del servicio. Si se dan cuenta, este servicio que aparece aquí, este es el servicio por defecto de Kubernetes del no manestro que utiliza, que es el que se encarga de estar verificando el estado de nuestro arquitectura. Y el segundo, aquí aparece webtest, es el que creamos con un tipo load balancer, la IP interna que va a utilizar con Kubernetes y una IP externa. También el mapeo del puerto 80 que está utilizando mi cluster hacia el puerto 30,004 por medio de TCP. En esta dirección IP externa es donde nosotros podemos conectarnos a nuestro servicio, es decir, consumirlo como tal. Vamos a intentar, espero que no genje ningún error. O sea, ir al navegador. Y sí, todo funcionó correctamente. Este es el hello world que les haría mencionado, que tiene la aplicación contenerizada. En el caso de que ustedes deseen implementar sus propias aplicaciones contenerizadas si es necesario hacerlo con Docker, verdad? Y hacer el push de su imagen al Docker Hub, en el cual ustedes lo van a poder utilizar. En este caso, estoy utilizando hola mundo, open source in Latin America 2022. Es decir, funcionó correctamente, pero también hay otras formas en las que nosotros podemos ver diferente información de lo que Kubernetes está ejecutando. Por ejemplo, que CdL, get nodes, esta vez vamos a obtener los nodes, no los pods. Y si se encuentran tenemos dos nodes. Son los dos nodes que nosotros definimos en el comando inicial para crear el cluster. Pero de igual forma, siempre podemos ver más información. En este caso, el comando menos o wide, me voy a volver datos más específicos de lo que tiene el node. Por ejemplo, parte del nombre, su estado, aquí me da una dirección IP que está utilizando cada una de los clusters. Si se dan cuenta, ambos tienen una dirección IP distinta, dado que los objetos dentro de uno van a compartir cierta información similar para su interconexión. Ahora bien, todo lo que nosotros acabamos de hacer fue a través de un archivo manifiesto. Yo considero que es bastante más sencillo. Si se dan cuenta, únicamente definimos las características que queremos que tenga y lo podemos desplegar. Pero no es la única forma de realizarlo. Esto nosotros también lo podemos realizar por medio de comandos, es decir, la creación del cluster, la creación de nuestro deployment, de los pods, del servicio. Únicamente que esto ya lleva un poco más de pasos, ¿verdad? Es estar metiendo cada comando uno por uno por uno para llegar a lo que nosotros tenemos. En el caso de que estemos haciendo muchas pruebas, sería crear, eliminar la arquitectura. Esto puede hacer mucho tiempo. Cambio con el archivo, únicamente guardamos el cambio, eliminamos y volvemos a desplegar, haciéndolo más sencillo. Ahora bien, si se dan cuenta, esta ventana aún no la habíamos visto, no tenía nada. Y dentro de Kubernetes Engine, aquí se muestran los ingress y servicios. Si se dan cuenta, aquí está la misma IP por medio de la cual yo me conecté a la aplicación con su load balancer. Esta es la IP del balanceador de cargas externo que por medio de Kubernetes se creó directamente, es decir, físicamente, con Google. Y al igual, las instancias que Kubernetes generó para su cluster continuan funcionando. Y si se dan cuenta, es bastante sencillamente una arquitectura. En este caso, vamos a mostrarlo otra vez. Tener esto es como que nosotros tengamos actualmente cinco servidores, bueno, ocho servidores, perdón, con nuestra aplicación web corriendo, todos los servidores conectados a través de un balanceador de carga para que se pueda acceder desde el exterior. Tomó alrededor de 30 segundos, tal vez el despliegue toda la arquitectura con su balanceador de carga. Si se dan cuenta, es bastante más rápido. En este caso, ahorita no tenemos como nosotros probar o generar alguna falla dentro de alguno de los bots para poder verificar el estado. Dado que Kubernetes se encarga de que se mantenga de la mejor manera el estado deseado en nuestra arquitectura. Es decir, si por alguna razón estos dos bots fallaron, la arquitectura deseada era de ocho bots ejecutándose. Ahorita van a haber seis. El control plane de Kubernetes al estar verificando constantemente, detectar que no está el estado deseado, es decir, dos servidores, se podría decir que fallaron, va a intentar recuperar. Es decir, lo primero que va a hacer es apagar estos dos pod, eliminarlos y activar dos nuevos. Esto lo hace con la verificación de los health checks que Kubernetes maneja y lo hace constantemente. Kubernetes maneja dos tipos de errores, los que puede recuperar y los no. En el caso de un error que puede recuperar, únicamente apaga el pod y crea uno nuevo. En el caso de los que no, va a ser este proceso, hasta que nosotros de forma manual, podamos corregir la situación y cuando el pod nuevamente se active, ya llegue a su estado estable nuevamente. Ahora bien, si nosotros quisiéramos eliminar esta configuración o esta arquitectura, eliminar el despliegue, lo podemos realizar con el comando qcpl, bilit-f y el nombre del archivo manifiesto que utilizamos. Vamos a verificar. Si se cuenta que ya nos dice que el deployment web test fue eliminado y el servicio web test fue eliminado, ahorita está haciendo las últimas verificaciones, entonces de indicarnos que ya terminó, mostrará nuevamente la línea de mi terminal. Esto puede tomar algunos segundos o minutos, dependiendo de qué tan grande sea la arquitectura. En este caso, dado que era una arquitectura relativamente pequeña, no va a ser muy tardado. Y se cuenta, ahorita terminó y veamos nuevamente. Nosotros queremos ver los posts. Nos dice que ya no hay ningún recurso dentro de nuestro namespace nuevamente. Vamos a venir y verificar, por ejemplo, con el servicio que era una de las cosas que creó el deployment y ya parece vacío. Únicamente nos da el mensaje de bienvenida de la página para crear servicios, pero este ya no existe. Igual forma, aquí dentro del repositorio, les dejo todos los pasos para replicarlo junto con algunos comandos que pueden resultarse muy útiles. Incluso ahorita, dado que el servicio ya no existe, si yo ven y recargo la página, si se me cuenta ahorita ya se tardó en la respuesta. Lo más probable es que de algún error 404 donde lo encuentra o un error 500. Aunque eso puede que tome un poco más de tiempo. Vamos a regresar ahora rápidamente a nuestra a nuestra presentación y nos vamos a adelantar nuevamente hasta donde estábamos. Muy bien. Ahora bien, ahora que ya vimos a grandes rasgos cómo empezar a utilizar cobernetes, algunas de sus grandes ventajas, con qué más podemos utilizar nosotros cobernetes. Bueno, esta es un área bastante extensa. Lo que yo les estoy poniendo aquí es solo un pincelazo de todas las herramientas que nosotros podemos combinar. En el caso de la parte de administración, nosotros podemos gestionar tal vez de una forma un poco más sencilla. Nuestros despliegue, esas arquitecturas, nuestros contenedores y orquestadores por medio de helm como herramienta para la administración. En la parte de service mesh, usted es un tema, tal vez un poco más avanzado, una maya de servicios para nuestras aplicaciones en masa. Podríamos utilizar linker, DSTO. Cada uno de estos también nos da un dashboard específico en el que nosotros podemos monitorear el estado de la arquitectura. Para los que les gusta la parte de integración continua, de plumen continuo, tenemos lo que es Jenkins, GitLab, Travis, también está Argos, CD, que es una herramienta bastante potente. En la parte ingeniería de caos para simular errores, sobre todas las arquitecturas con cobernetes. Esto se lo recomiendo mucho. En el caso de que quieran experimentar, alterar las métricas de cobernetes, utilizar chaos mesh y lignos. Ambos son bastante potentes. Cada uno tiene sus experimentos, por así decirles. Bastante interesante. Podemos generar files and pods en las máquinas virtuales, en la red. Y, por supuesto, las plataformas en la nube. Actualmente, nosotros podemos implementar cobernetes en la mayoría de plataformas en la nube, es decir, Microsoft Azure, Google Cloud, IBM, Digital Ocean. Todos nos dan ya herramientas con las cuales nosotros podemos implementar fácilmente cobernetes. Incluso, si es de forma educativa que nosotros queremos aprender, entran muchas de estas características en las capas gratuitas. Para bien, todas las herramientas que yo aquí he listado, por ejemplo, Hell, Ninkerd, Istio, Chaos Mesh y Litmus se instalan directamente sobre los terrenes cobernetes para realizar sus funciones. En el caso de Jenkins, posiblemente muchos las conocen, igual que Geed, Laby, Travis, son herramientas externas mediante las cuales nosotros podemos incluso gestionar los display de nuestros orquestadores. Por ejemplo, el archivo que nosotros utilizamos en nuestro ejemplo, podemos realizar modificaciones y únicamente con estas herramientas, redesplegar el deployment de nuestro cluster. Ahora bien, sé que a muchos también les interesa esta parte. Yo quiero aprender cobernetes, quiero saber manejarlo, pero también quiero demostrar que lo se manejar. Bueno, cobernetes también tiene certificaciones oficiales. Todas estas las pueden incorporar en el sitio del Linux Foundation, en el cual al final de la presentación también les deja el enlace. Y actualmente cobernetes tiene tres certificaciones. Certify, Kubernetes Administrator, Application Developer y Security Specialist. Cada una para diferentes gustos. La parte administrativa es como nosotros acabamos de ver mantener la arquitectura y Application Developer, el despliegue de diferentes aplicaciones orquestadas. Y por supuesto algo muy importante ahora, la parte de la seguridad en estos contenedores. No únicamente ver la seguridad del firewall en el cual nosotros lo estamos implementando, sino que la seguridad interna del orquestador, la comunicación y la red que se utiliza de form interna es muy importante. Pueden verificar cualquiera de estas tres certificaciones en caso les llame la atención. Las tres son muy buenas, se las recomiendo. Y ya casi llegando al final, las referencias en el caso de CEN indagar un poco más dado que cobernetes es un tema sumamente extenso, pero es sumamente interesante. Yo aquí les dejo algunos enlaces de los sitios oficiales de cobernetes, unos casos de estudio, la documentación oficial donde van a poder ver ejemplos de cada uno de los comandos, funcionamiento, la arquitectura de cobernetes para saber cómo realmente funciona cobernetes de forma interna, dado que ese es un tema muy extenso. Y el segundo enlace que es el de training de LinuxFundation.org, que es donde está el catálogo de las certificaciones de LinuxFundation, donde van a encontrar las de cobernetes. También en caso tengan alguna duda sin contactarme, les dejo mi Twitter y también el enlace de repositorio donde van a poder encontrar el archivo manifiesto que utilizamos, las instrucciones para poder implementar este ejemplo en este caso con Google Cloud y Linux, algún sistema Linux host, en mi caso me gusta utilizar Ubuntu como sistema WESPE, todo va a estar aquí en el repositorio, al igual que el enlace de la presentación que se los voy a subir. Y bueno, de mi parte eso sería todo, espero les haya gustado y vamos a pasar rápidamente ahora a la sección de preguntas, en caso tengan alguna. Si hay alguien que nos esté viendo que se le dificulta un poco el español, no hay problema, pueden hacer la pregunta en inglés, yo la voy a procurar traducir lo mejor posible y se las voy a responder tanto en inglés como en español. Nos vemos.