Despliegue, escalado y monitorización de videojuegos multijugador en la nube

Despliegue, escalado y monitorización de videojuegos multijugador en la nube Memoria del proyecto Especialización en Tecnologías de la Información Blai Ortuño Seron Director: Ruben Tous Liesa Tutor de GEP: Fernando Barrabes Naval Fecha: 16/01/2022 I Resumen Hoy en día, el mundo de los videojuegos está creciendo exponencialmente, aprovechándose de un componente esencial, la nube. Aun así, todavía no se ha creado una solución open source para el despliegue de servidores de videojuegos multijugador en la nube. Este proyecto pretende crear justo eso, una solución open source de referencia para el despliegue, escalado y monitorización de servidores de videojuegos multijugador en la nube. Resum Avui dia, el món dels videojocs està creixent exponencialment, aprofitant-se d'un component essencial, el núvol. Així i tot, encara no s'ha creat una solució open source per al desplegament de servidors de videojocs multijugador en el núvol. Aquest projecte pretén crear just això, una solució open source de referència per al desplegament, escalat i monitoratge de servidors de videojocs multijugador en el núvol. Abstract Today, the world of video games is growing exponentially, taking advantage of an essential component, the cloud. However, an open source solution has not yet been created for the deployment of multiplayer video game servers in the cloud. This project aims to create just that, an open source reference solution for the deployment, scaling and monitoring of multiplayer servers in the cloud. II Agradecimientos Primero de todo, agradecer la ayuda prestada durante todo el trabajo al profesor Ruben Tous, el tutor de este proyecto. Las ideas y consejos que ha ido aportando durante la realización de dicho proyecto han sido esenciales para conseguir el resultado final. También agradecer todo el apoyo que me han dado mis padres y mi hermano, al aguantarme, escucharme y aconsejarme durante todo el proyecto, sobre todo este año de pandemia donde hemos convivido muchas más horas en casa. Por último, pero no por ello menos importante, agradecer de corazón a mis amigos, sin los cuales este proyecto no sería lo mismo. Todas las horas y noches virtuales que hemos pasado durante esta pandemia me han ayudado muchísimo a mantener el ánimo arriba. III Índice de contenidos 1. Introducción y contextualización .............................................................................. 4 1.1 Contexto ................................................................................................................. 4 1.2 Conceptos .............................................................................................................. 5 1.2.1 Servidor de videojuegos ................................................................................. 5 1.2.2 La nube ............................................................................................................ 5 1.2.3 Clúster de contenedores ................................................................................ 6 1.3 Problema a resolver ............................................................................................... 7 1.4 Stakeholders ........................................................................................................... 7 2. Justificación ............................................................................................................... 8 2.1 Estado del arte ....................................................................................................... 8 2.2 Estudios previos ..................................................................................................... 9 2.3 Justificación ........................................................................................................... 9 3. Alcance del proyecto ............................................................................................... 10 3.1 Objetivo principal ................................................................................................. 10 3.2 Subobjetivos ......................................................................................................... 10 3.2.1 Despliegue del servidor ................................................................................ 10 3.2.2 Monitorización .............................................................................................. 11 3.2.3 Escalabilidad................................................................................................. 11 3.2.4 Automatización ............................................................................................ 11 3.2.5 Demo del servidor ........................................................................................ 11 3.3 Requerimientos .................................................................................................... 11 3.4 Potenciales problemas y riesgos ........................................................................ 12 4. Metodología y rigor .................................................................................................. 12 4.1 Metodología de trabajo ....................................................................................... 12 4.2 Herramientas de seguimiento y desarrollo ........................................................ 13 5. Descripción de las tareas ........................................................................................ 13 IV 5.1 Tareas de gestión y documentación .................................................................. 13 5.2 Tareas de desarrollo ............................................................................................ 14 5.2.1 SPRINT 1: Clúster Y Agones ........................................................................ 14 5.2.2 SPRINT 2: Flota de contenedores y servidor .............................................. 15 5.2.3 SPRINT 3: Monitorización ............................................................................ 15 5.2.4 SPRINT 4: Despliegue final .......................................................................... 16 5.3 Recursos ............................................................................................................... 17 5.3.1 Recursos humanos ...................................................................................... 17 5.3.2 Hardware ....................................................................................................... 17 5.3.3 Software ........................................................................................................ 17 5.4 Resumen de las tareas ........................................................................................ 17 6. Diagrama de Gant .................................................................................................... 20 7. Gestión de riesgos ................................................................................................... 21 7.1 Fecha límite del proyecto .................................................................................... 21 7.2 Inexperiencia en el sector ................................................................................... 21 7.3 Posibles errores y callejones sin salida ............................................................. 22 8. Presupuesto ............................................................................................................. 22 8.1 Identificación de los costes ................................................................................ 22 8.1.1 Recursos humanos ...................................................................................... 22 8.1.2 Hardware ....................................................................................................... 25 8.1.3 Software ........................................................................................................ 25 8.1.4 Gastos generales ......................................................................................... 26 8.1.5 Contingencia ................................................................................................. 26 8.1.6 Imprevistos ................................................................................................... 27 8.2 Costes totales ...................................................................................................... 27 8.3 Control de gestión ................................................................................................ 28 9. Sostenibilidad .......................................................................................................... 28 9.1 Autoevaluación .................................................................................................... 28 V 9.2 Dimensión económica ......................................................................................... 29 9.3 Dimensión ambiental ........................................................................................... 30 9.4 Dimensión social .................................................................................................. 31 10. Desarrollo ................................................................................................................. 32 10.1 Tecnologías utilizadas ..................................................................................... 32 10.1.1 Docker .......................................................................................................... 32 10.1.2 Kubernetes ................................................................................................... 34 10.1.3 Agones ......................................................................................................... 40 10.1.4 Prometheus ................................................................................................. 44 10.1.5 Grafana ......................................................................................................... 46 10.2 Arquitectura .......................................................................................................... 47 10.3 Implementación ................................................................................................... 48 10.3.1 Clúster de Kubernetes y GKE ....................................................................... 48 10.3.2 Agones .......................................................................................................... 50 10.3.3 Monitorización .............................................................................................. 52 10.4 Pruebas y resultados ........................................................................................... 55 10.4.1 Estadísticas con Grafana ............................................................................. 55 10.4.2 Conexión al servidor por parte de jugador ................................................. 56 10.4.3 Fleet Autoscaler ............................................................................................ 58 10.4.4 Pérdida de un pod en tiempo real ............................................................... 61 10.4.5 Actualización del servidor en tiempo real .................................................. 62 11. Conclusiones............................................................................................................ 65 12. Bibliografía ............................................................................................................... 66 13. Anexo ....................................................................................................................... 70 13.1 Anexo A: Ejemplos de la monitorización con Grafana ...................................... 71 13.2 Anexo B: Especificaciones de los servidores y la flota ..................................... 75 13.3 Anexo C: Especificaciones del autoscaler ......................................................... 77 4 1. Introducción y contextualización Ya hace unos años que el sector de los videojuegos está creciendo a un ritmo muy elevado, siendo dicho crecimiento respecto al año pasado de un 18% en España, generando 1747 millones de euros con una base de 16 millones de usuarios aproximadamente [1]. Debido a este hecho, muchas empresas buscan como integrar estos videojuegos con nuevas tecnologías o algunas ya existentes para generar beneficios. Una de estas tecnologías es la nube, que está empezando a ser un componente vital en la evolución de los videojuegos actuales. A parte de otros usos (e.g. juego bajo demanda), uno de los usos de la nube en los videojuegos actuales consiste en alojar servidores de videojuegos multijugador. En un videojuego multijugador en línea cada jugador opera sobre un programa cliente. Los programas clientes de todos los jugadores envían las acciones realizadas por estos a un servidor de videojuegos, que actualiza el estado del juego e informa a los clientes de los cambios. En la actualidad, la mayoría de juegos multijugador son gestionados por un proveedor y hacen uso de servidores dedicados, que permiten controlar la calidad del servicio y la conexión de un número elevado de jugadores. Con el paso del tiempo y el incremento del número de usuarios, la creación y gestión estos servidores de manera eficiente se ha vuelto una tarea compleja y costosa. La gestión simultánea de múltiples servidores dedicados involucra clústeres de computadoras, en muchos casos, alojados por un proveedor de servicios en la nube. La implementación de soluciones para el despliegue y monitorización de estos clústeres de servidores de videojuegos es un trabajo añadido que tienen las empresas de desarrollo de videojuegos actuales. Aunque la mayoría de tareas necesarias son comunes a la mayoría de juegos, muchas empresas optan por soluciones propietarias, y todavía no se ha consolidado una solución de referencia, a pesar de que existen herramientas de código abierto que lo permiten, como Kubernetes. Este proyecto abordará ese problema, y estudiará una posible solución. 1.1 Contexto El proyecto “Despliegue, escalado y monitorización de videojuegos multijugador en la nube” es un trabajo de fin de grado de modalidad A realizado para la Facultad de 5 Informática de Barcelona (FIB), concretamente para el grado de ingeniería informática y la especialidad de tecnologías de la información. 1.2 Conceptos A continuación, se tratarán los elementos imprescindibles para comprender este trabajo. 1.2.1 Servidor de videojuegos Un servidor es una máquina que proporciona alguna funcionalidad o servicio para otras máquinas o dispositivos llamados clientes, formando así lo que se conoce como una arquitectura cliente-servidor [2]. En esta arquitectura, el cliente hará diferentes peticiones al servidor, y el servidor le responderá de una manera u otra dependiendo de la petición del cliente. En algunos casos será el servidor quien haga la petición inicial, aunque lo más habitual es que sea el cliente quien lo haga. Un servidor puede realizar diferentes funciones, desde actuar como una base de datos que el cliente puede consultar hasta funcionar como un servidor de aplicaciones que ejecuta algunos programas. El caso que nos interesa en este trabajo es el del servidor de videojuegos, en el que podemos diferenciar entre el servidor de escucha y el servidor dedicado. Tradicionalmente se usaba el servidor de escucha, que funcionaba en el mismo proceso que el cliente, permitiéndole alojar y jugar en esa partida al mismo tiempo. Sin embargo, cuando el cliente se desconectaba el servidor también lo hacía. Es por eso que apareció el modelo más usado actualmente, el servidor dedicado. En este modelo el servidor es alojado por una máquina idealmente dedicada exclusivamente a esa tarea, y por tanto es independiente al jugador, estando activo esté o no conectado el cliente. Se encarga de recolectar y procesar datos de los diferentes jugadores que usan dicho servidor y distribuir las respuestas pertinentes a estos participantes. Este será el modelo que se intentará correr en la nube en este trabajo. 1.2.2 La nube Se podría definir la nube como una red a nivel mundial de servidores que realizan todo tipo de tareas, como por ejemplo almacenamiento de datos o ejecución de aplicaciones, formando un ecosistema remoto al cual un cliente se puede conectar desde cualquier parte del mundo [3]. Esta tecnología pretende eliminar la gran limitación física que había 6 hasta hace unos años, donde para poder acceder a un servicio online a una latencia asumible había que hacerlo accediendo a un servidor cercano. Este avance es de vital importancia para los videojuegos, ya que en estos la latencia es imprescindible para una buena experiencia multijugador, donde el jugador nunca debería sentir un retardo cuando realiza alguna acción dentro del juego. Es por eso que hoy en día la nube va tan ligada con los videojuegos y se le va a dar tanta importancia en este trabajo. 1.2.3 Clúster de contenedores Para poder entender qué es un clúster de contenedores, primero es necesario saber qué es un contenedor. Un contenedor es un conjunto de uno o más procesos que están separados del resto del sistema [4]. Para poder ejecutarlos, se usarán archivos que procederán de una imagen diferente, de manera que estos contenedores son portátiles. Es decir, aunque se construya un contenedor en una máquina con una determinada configuración, el contenedor ya tiene por sí mismo todo lo necesario para funcionar. Por tanto, cuando se mueva dicho contenedor a otra máquina, este seguirá funcionando igualmente. Antes de la aparición de los contenedores, la manera de separar distintos entornos y aislarlos era ponerlos en distintas máquinas, ya fuesen físicas o virtuales. Con los contenedores, se pueden tener corriendo cinco a la vez en una sola máquina, todos ellos independientes entre ellos, protegiendo así el sistema de posibles ataques externos. Además, no solo proporcionan este aislamiento y por tanto seguridad, sino que también proporcionan más escalabilidad, ya que donde antes había un entorno aislado de unas determinadas características, ahora hay cinco totalmente flexibles. Dicho esto, un clúster es un conjunto de máquinas que ejecutan aplicaciones en contenedores [5]. Contiene como mínimo un plano de control y una o más máquinas. El plano de control es algo similar a una sala de control, ya que se encarga de mantener el estado que se quiere en el clúster, así como también de controlar lo que pasa en él, como por ejemplo que aplicaciones se ejecutan y que imagen se usa para los contenedores. Para la realización de este trabajo, se usará un clúster que usará Kubernetes [6], una plataforma open source que actúa como un orquestador de contenedores, facilitando la automatización y eliminando muchos de los procesos manuales que había en la 13 4.2 Herramientas de seguimiento y desarrollo Como método de seguimiento se realizarán reuniones cada dos semanas con el tutor del proyecto, con tal de comprobar el estado del sprint en el que se está trabajando actualmente. De esta manera, en caso de haber algún problema con dicho sprint, se podría aumentar el tiempo destinado a él o tomar alguna medida para evitar que este fallo en la planificación hunda otras etapas. Para poder compartir el desarrollo con el tutor, tener siempre una copia de seguridad actualizada, y tener toda la parte práctica del trabajo en un mismo sitio, se usará GitHub [13]. Se tendrá una rama master donde se encontrará el código funcional del proyecto, y una rama development donde estará el código sin finalizar o en fase de testing. 5. Descripción de las tareas Al comenzar un proyecto es imprescindible tener una planificación temporal y de las distintas tareas que se van a realizar. Dicha planificación es esencial para saber en todo momento qué se debe hacer, y si se está haciendo a tiempo. En el caso de este trabajo, el inicio del mismo es el día 20 de septiembre de 2021 con la presentación de la asignatura GEP (Gestión de Proyectos), y debe estar finalizado para su defensa para mediados de enero. Teniendo en cuenta que se pretende dedicar entre unas 4 o 5 horas diarias a este trabajo y que se tiene unos 4 meses para su realización, se estiman unas 580 horas de trabajo. Estas horas se van a dividir entre tareas de documentación y gestión del proyecto, y tareas de desarrollo e investigación para dicho desarrollo. 5.1 Tareas de gestión y documentación • TGD1 (30 h). Alcance del proyecto y contextualización. Confección de la primera entrega de GEP, donde se incluye el contexto, justificación, alcance y metodología a utilizar del proyecto. • TGD2 (15 h). Planificación temporal. Segunda entrega del GEP que especifica las tareas que se van a realizar y su planificación en el tiempo. Dependencias: TGD1. • TGD3 (20 h). Presupuesto y sostenibilidad. Tercera entrega del GEP que pretende estimar los costes económicos del proyecto, así como también el 14 impacto de este en las dimensiones ecológica, social y económica. Dependencias: TGD2. • TGD4 (10 h). Creación del documento final. Cuarta y última entrega del GEP. Está destinada a la confección del documento final del GEP que engloba las otras tres entregas. Este será la versión definitiva, corrigiendo todos los errores que haya a partir del feedback de los profesores. Dependencias: TGD3. • TGD5 (100 h). Redacción de la memoria. Elaboración de la memoria del proyecto en su versión final. Esta debe ser acabada y entregada la semana del 14 de enero. Dependencias: TGD4. • TGD6 (15 h). Elaboración de la presentación. Construcción de la presentación del proyecto para la lectura ante el tribunal. Dependencias: TGD5. • TGD7 (20 h). Reuniones de control. Para garantizar que el proyecto salga adelante, se realizarán reuniones entre el alumno y el tutor del proyecto cada dos semanas. Estas reuniones tendrán una duración variada dependiendo de cómo haya ido el sprint correspondiente a esas dos semanas. Además, a parte de estas reuniones programadas, se podría dar el caso de que sea necesario concertar alguna reunión extra, ya sea por problemas que surjan o por posibles cambios en alguna parte ya programada. 5.2 Tareas de desarrollo Para planificar correctamente estas tareas, se hará por sprints o etapas. 5.2.1 SPRINT 1: Clúster Y Agones • CA1 (20 h). Introducción a los contenedores y Kubernetes. Aunque previamente ya se había trabajado con contenedores, se hizo a un nivel muy básico. Por tanto, es necesario profundizar en esta materia para la realización del proyecto. • CA2 (25 h). Introducción a Agones. Ya que Agones es una herramienta creada hace poco tiempo y que el autor no ha usado nunca, se requiere tiempo para investigar todo lo que puede ofrecer al proyecto y cómo hacerlo en la práctica. • CA3 (20 h). Primer despliegue del clúster. Con la ayuda de la documentación provista por los developers de Agones [14], se hará el primer intento de despliegue del clúster con las opciones predeterminadas recomendadas. Dependencias: CA1, CA2. • CA4 (20 h). Instalación de Agones. Se instalará Agones dentro del clúster que se ha desplegado. Dependencias: CA2, CA3. 15 • CA5 (20h). Creación e integración en el clúster del servidor de videojuegos. Siguiendo la documentación mencionada en SP3, se creará la primera versión del servidor de videojuegos. Esta versión será la más básica, ya que simplemente se pretende probar que funciona dentro del clúster que se ha montado previamente. Dependencias: CA3, CA4. • ML1 (10 h). Entorno básico creado y testing. Al acabar el Sprint 1, se llega al primer hito, donde se puede encontrar el entorno básico acabado. Esto dará pie a completar dicho entorno con la creación de la flota en el siguiente apartado, y es un hito esencial para este proyecto, ya que es el esqueleto que sostendrá todo lo demás. 5.2.2 SPRINT 2: Flota de contenedores y servidor • FCS1 (30 h). Creación de la flota de contenedores. Para mejorar la escalabilidad del proyecto y poder tener más de un servidor activo a la vez, se creará una flota de contenedores en vez de uno solo como había hasta este momento. Para poder lograrlo, también habrá que integrarla con Agones para poder funcionar correctamente con el servidor. Dependencias: CA3, CA4 • ML2 (5 h). Clúster finalizado y testing. Se ha acabado el clúster de contenedores, y ahora se pasará a probar que todo funcione correctamente. • FCS2 (40 h). Construcción del servidor de videojuegos para monitorización. Primero se aprenderá lo necesario del lenguaje de programación Go. Este lenguaje es nuevo para el autor, y ya que los servidores están escritos en dicho lenguaje, es necesario aprender una base para poder entenderlos. Una vez se tenga la base suficiente, se modificarán para conseguir los parámetros óptimos para el proyecto. Dependencias: FCS1, CA5. • ML3 (5h). Servidor finalizado y pruebas por consola. Se ha construido el servidor de videojuegos de una manera más avanzada y personalizada, y se procede a hacer algunas pruebas para verificar que las ordenes enviadas funcionen como deberían. 5.2.3 SPRINT 3: Monitorización • M1 (20 h). Documentación previa sobre Prometheus [15] y Grafana [16]. Para tener una correcta monitorización, se usarán estas dos herramientas. El autor nunca ha trabajado con ellas, así que se requiere un tiempo previo de estudio para usarlas como corresponde. 16 • M2 (20 h). Instalación e integración de Prometheus en el entorno. Además de la instalación, se tendrá que integrar este software con el entorno ya existente. Dependencias: M1. • M3 (20 h). Instalación e integración de Grafana en el entorno. Al igual que con la tarea anterior, además de la instalación también habrá que integrar esta herramienta. En este caso, también incluiremos Prometheus en el entorno existente, ya que Grafana se encargará de mostrar sus estadísticas. Dependencias: M1, M2. • M4 (25 h). Personalización y parametrización de las herramientas de monitorización. Una vez instaladas e integradas, se ajustarán y personalizarán ambas herramientas para garantizar que su funcionamiento es el que se desea, tanto para enseñar las estadísticas que se necesiten como para ganar calidad de vida para el autor. Dependencias: M2, M3. • ML4 (10 h). Monitorización finalizada y pruebas con ella. Las herramientas de monitorización han sido instaladas y personalizadas. Se procede a hacer pruebas con ellas. • M5 (20 h). Cambios en el servidor de videojuegos. Ya que ahora ya se tiene el entorno de monitorización, se harán algunos cambios en el servidor de videojuegos para poder visualizar algunas estadísticas concretas al realizar algunas acciones. Dependencias: M4, FCS2. 5.2.4 SPRINT 4: Despliegue final • DF1 (30 h). Debugging y posible demo. Primero, se realizarán tareas de debug en todo el entorno, de manera que se arregle cualquier problema que pueda quedar para poder realizar correctamente la siguiente tarea. En caso de sobrar tiempo, se intentaría hacer una demo para la presentación del videojuego escogido para el servidor. Dependencias: M5. • DF2 (40 h). Pruebas usando todo el entorno. Se realizarán pruebas usando el entorno construido hasta ahora. Con estas pruebas, conseguiremos los datos necesarios para argumentar una conclusión a este proyecto. Dependencias: DF1. 17 5.3 Recursos 5.3.1 Recursos humanos El principal recurso humano será el autor de este trabajo, encargado de su desarrollo y documentación. Sin embargo, el tutor del proyecto (Ruben Tous) y el tutor del GEP (Fernando Barrabes), también tendrán un papel relevante, ya que serán los encargados de guiar el proyecto hacía el buen camino. 5.3.2 Hardware Las etapas de desarrollo se realizarán en un ordenador de sobremesa con las siguientes características: • CPU: AMD Ryzen 5 3600 (6 núcleos, 12 hilos) a 3.6 GHz. • RAM: 16 GB. • GPU: NVIDIA GTX 2060 Super de 8GB GDDR6. • SO: Windows 10 Pro con Linux Ubuntu 20.04 en máquina virtual para el desarrollo. 5.3.3 Software En un proyecto de estas características se usará un conjunto extenso de herramientas y programas. Para trabajar con Linux, en este caso Ubuntu, necesario para este proyecto, se usará VMware (VM) [17]. Para tener el proyecto en la nube y así tener una copia de seguridad, se usará GitHub (GH). Para la comunicación con los tutores, se usará Gmail y Google Meet. Por último, para el desarrollo del código necesario, se usará VScode (VS) [18]. 5.4 Resumen de las tareas ID TAREA HORA S DEPENDENCIAS RIESGO RECURSOS GESTIÓN Y DOCUMENTACIÓN TGD1 Alcance y contextualización 30 - Bajo PC, Gmail TGD2 Planificación temporal 15 TGD1 Alto PC, Gmail TGD3 Presupuesto y sostenibilidad 20 TGD2 Bajo PC, Gmail 18 TGD4 Documento final 10 TGD3 Bajo PC, Gmail TGD5 Redacción de la memoria 100 TGD4 Bajo PC TGD6 Presentación 15 TGD5 Medio PC TGD7 Reuniones de control 20 - Bajo PC, GMeet SPRINT 1: CLÚSTER Y AGONES CA1 Introducción a contenedores y Kubernetes 20 - Bajo PC, VM, GH, VS CA2 Introducción a Agones 25 - Bajo PC, VM, GH, VS CA3 Primer despliegue del clúster 20 CA1 Alto PC, VM, GH, VS CA4 Instalación de Agones 20 CA2 Alto PC, VM, GH, VS CA5 Creación e integración del servidor de videojuegos básico 20 CA3, CA4 Medio PC, VM, GH, VS ML1 Entorno básico creado y testing 10 CA5 Medio PC, VM, GH, VS SPRINT 2: FLOTA DE CONTENEDORES Y SERVIDOR FCS1 Flota de contenedores 30 CA3, CA4 Alto PC, VM, GH, VS ML2 Clúster finalizado y testing 5 CA5 Medio PC, VM, GH, VS FCS2 Servidor de videojuegos para monitorización 30 FCS1, CA5 Bajo PC, VM, GH, VS ML3 Servidor finalizado y pruebas por consola 5 FCS1, CA5 Bajo PC, VM, GH, VS SPRINT 3: MONITORIZACIÓN M1 Documentación Prometheus y Grafana 20 - Bajo PC, VM, GH, VS M2 Instalación Prometheus 20 M1 Medio PC, VM, GH, VS M3 Instalación Grafana 20 M1, M2 Medio PC, VM, GH, VS M4 Personalización y parametrización 25 M2, M3 Bajo PC, VM, GH, VS 19 ML4 Monitorización finalizada y pruebas con ella 10 M4 Bajo PC, VM, GH, VS M5 Cambios en el servidor de videojuegos 20 M4, FCS2 Bajo PC, VM, GH, VS SPRINT 4: DESPLIEGUE FINAL DF1 Debugging y posible demo 30 M5 Medio PC, VM, GH, VS DF2 Pruebas finales 40 DF1 Medio PC, VM, GH, VS TOTAL 580 horas Tabla 1: Resumen de las tareas [Elaboración propia] 20 6. Diagrama de Gant Figura 1: Diagrama de Gant [Elaboración propia a partir de Gantt Project] 21 7. Gestión de riesgos 7.1 Fecha límite del proyecto Este proyecto abarca muchas herramientas y tecnologías, y es muy sencillo expandir cualquiera de los ámbitos que se tratan. Esto a priori podría parecer algo a favor, pero a la hora de decidir que se quiere hacer en el proyecto puede llegar a ser un problema. Esto se debe a que es muy fácil añadir más cosas de las que se pueden hacer a tiempo, provocando no llegar a la fecha límite y dejar de realizar otros aspectos importantes del trabajo. Es por eso que, a la hora de pensar el proyecto, se ha ido con mucho cuidado al fijar los objetivos, ya que un objetivo demasiado ambicioso podría suponer el fracaso del trabajo. Asimismo, también se ha puesto especial interés en cómo se distribuyen las tareas en el tiempo, ya que con una fecha fijada se trabaja con un número determinado de horas que se ha de dividir entre dichas tareas. Esta división se ha hecho intentando recompensar a las que son más importantes con más horas, para que así la parte esencial del trabajo salga adelante pase lo que pase. 7.2 Inexperiencia en el sector El autor es inexperto en casi todas las tecnologías que se mencionan, así como en las herramientas que se usan en la realización del proyecto. Por tanto, se necesita un período de documentación e investigación antes de realizar la mayoría de las tareas, cosa que requerirá bastante tiempo que podrá ser invertido en el desarrollo o cualquier otra parte del trabajo. Para solventar este problema, se le ha destinado las horas que se creen necesarias a todo el apartado de investigación. Así se espera que el autor obtenga todos los conocimientos necesarios para realizar el proyecto sin problemas, eso sí, sin consumir demasiado tiempo que se tendría que destinar a otros apartados. Asimismo, se ha hecho un estudio previo al trabajo en el mes de septiembre de algunas de las tecnologías que se creía que podían dar más problemas. De esta forma, se espera que haya el menor número de altercados posibles. 22 7.3 Posibles errores y callejones sin salida Ya que el autor realiza el proyecto en base a nuevas tecnologías con poca documentación disponible, es muy probable que haya problemas en el camino que no estén resueltos en Internet. Por tanto, habrá que destinar tiempo a solucionar dichos imprevistos, poniendo más tiempo en la planificación de tareas en algunas tareas en específico que probablemente den algún problema. Además, también debido a la poca documentación que hay sobre estas nuevas tecnologías, se puede dar el caso en que un objetivo propuesto no se pueda cumplir, ya sea por errores al intentarlo o por problemas externos. Por consiguiente, se ha pensado un plan B para los campos que más problemas puedan dar, como por ejemplo usar otra herramienta de monitorización que no sean Prometheus y Grafana, o cambiar Minikube por Google Cloud en el clúster. 8. Presupuesto 8.1 Identificación de los costes Para poder identificar correctamente los costes que va a tener este proyecto, se debe tener en cuenta algunos factores. Entre ellos, se destacarán los recursos humanos, hardware y software que se necesitan para poder realizar este trabajo, así como también los gastos generales como luz, Internet, etc. Por último, pero no por ello menos importante, también se tendrán que contar los impuestos, ya que no son precisamente bajos, junto a las contingencias y un fondo de emergencia reservado a posibles imprevistos. 8.1.1 Recursos humanos Cuando se habla de recursos humanos, se hace referencia a los diferentes empleados que se necesitan para llevar a cabo un proyecto. En este caso, se valorará que roles y que empleados para llenar dichos roles se necesitan, así como también cuál es su coste económico aproximado por hora trabajada. Se empezará por definir quién debe participar en el proyecto, ordenados de mayor a menor responsabilidad: • Director de proyecto: Principal responsable del proyecto, encargado de dirigir, planificar y asegurarse de que el trabajo va por el buen camino en todo momento. 29 Además, no solo son un problema los residuos, sino que para que este mundo funcione necesita muchísima electricidad, ya sea para ordenadores, mantenimiento de servidores, conexión a Internet y móvil en cualquier parte el mundo, etc. Es por eso que con este trabajo me gustaría conseguir realizar el objetivo propuesto, y de esta manera, aunque solo esté destinado a los servidores de videojuegos, reducir el número de máquinas que se usan para ello, y mejorar poco a poco la vida de nuestro planeta. Sin embargo, aunque esta dimensión ambiental me parecía muy relevante y a priori no quería interesarme por ninguna más, al realizar este trabajo, me encontré con otras dos dimensiones que me sorprendieron. La primera es la social, para mí también muy importante, ya que vivimos en un mundo donde la exclusión social está muy presente, teniendo en cuenta que no todo el mundo tiene acceso a un buen ordenador, o directamente a un ordenador. Por esa razón, este trabajo también pretende abaratar el coste de jugar a videojuegos, ya que, si hacen falta menos ordenadores para levantar un servidor, no hay porque seguir cobrando precios excesivos por servicios multijugador con la excusa de que se usan muchas máquinas dedicadas [25]. Por último, en cuanto al ámbito económico, es el que menos conozco, y el que más he tenido que profundizar al realizar este proyecto. Al comenzar, no sabía prácticamente nada ni de gestión económica ni de las decisiones que hay que tomar al comenzar un proyecto. Aunque después de realizar el apartado de presupuesto tampoco tengo grandes conocimientos, al menos me he dado cuenta de lo complicado que es armar unos presupuestos coherentes y que permitan realizar el proyecto deseado. 9.2 Dimensión económica ¿Has estimado el coste de la realización del proyecto (recursos humanos y materiales)? Previamente al comienzo de este proyecto, se ha completado un estudio de los costes que conlleva su realización. Se ha hecho tanto por costes en recursos humanos (sueldos y precio por tareas derivados de dichos sueldos), como también por materiales usados (hardware, software, gastos generales, etc.). Además, también se ha tenido en cuenta gastos por imprevistos y contingencia. ¿Cómo se resuelve actualmente el problema que quieres abordar (estado del arte)? ¿En qué mejorará económicamente tu solución a las existentes? 30 Actualmente, se revuelve mediante el uso de servidores operando en máquinas dedicadas exclusivamente a ello. Con la solución propuesta en este proyecto, se mantendría el uso de estas máquinas, pero ahora se añadiría el uso de contenedores y la nube, pudiendo tener por ejemplo cinco servidores donde antes había uno, reduciendo el coste producido al comprar y mantener las máquinas. Y, en caso de ya usar contenedores como en el caso de algunas grandes empresas, este proyecto propone una solución viable open source. De esta forma, tanto empresas como usuarios podrían no pagar a estas grandes empresas por este servicio y montar su propio entorno con la solución propuesta en el proyecto. 9.3 Dimensión ambiental ¿Has estimado el impacto ambiental que tendrá la realización de este proyecto? ¿Te has planteado minimizar el impacto, por ejemplo, reutilizando recursos? En este proyecto, hay que tener en cuenta no solo las máquinas que se usan para alojar el servidor, sino las usadas para jugar al videojuego y las necesarias para el almacenamiento en la nube. Por tanto, aunque el proyecto pretende reducir los recursos usados mediante el uso de contenedores, el consumo sigue siendo alto, ya que son muchas máquinas que fabricar y que alimentar de corriente. En cuanto a reutilizar, ya que en este caso para realizar el proyecto prácticamente solo se usará mi ordenador para todas las tareas, es una manera de reducir el consumo. Es un buen paso hacía el camino a seguir, pero como en toda la industria de la informática no es suficiente y se debería poder hacer más, como usar energías renovables para el consumo tan grande que provoca este sector. ¿Cómo se resuelve actualmente el problema que quieres abordar (estado del arte)? ¿En qué mejorará ambientalmente tu solución a las existentes? Actualmente, aunque duela decirlo, se revuelve dando pequeños pasos y poniendo excusas, alargando la discusión existente sobre el gran problema medioambiental que supone el sector de la informática. En el caso de mi proyecto, con el uso de contenedores se reduciría mucho el número de máquinas necesarias para alojar servidores, y por tanto el consumo eléctrico. Aun así, no es suficiente, y se debería hacer mucho más, empezando en mi opinión, por el uso en un futuro exclusivamente de energías renovables. 31 9.4 Dimensión social ¿Qué crees que te va a aportar a nivel personal la realización de este proyecto? Primeramente, conocimientos generales de algunos campos que siempre había querido explorar y profundizar, como contenedores o monitorización. También me ayudará a pensar en algo más que en la tecnología a la hora de planear el desarrollo de un proyecto, como por ejemplo sus costes económicos o su impacto social y ambiental. ¿Cómo se resuelve actualmente el problema que quieres abordar (estado del arte)? ¿En que mejorará socialmente (calidad de vida) tu solución a las existentes? Socialmente hablando, el problema actual se resuelve pagando a compañías como Amazon por sus servicios en la nube, de manera que estas grandes empresas tienen el monopolio. La idea de este proyecto es hacer este servicio open source, y por tanto disponible para todo el mundo. De esta forma, cualquier persona o empresa lo podrá usar y montar su flota de servidores en la nube, sin necesidad de pagar a estas grandes empresas si no se quiere. ¿Existe una necesidad real del proyecto? Aun hoy en día con todo el crecimiento que ha experimentado el mundo de los videojuegos, hay mucha gente escéptica con ellos y que no los ve como algo serio. Por tanto, para mucha gente pensará que este trabajo no será necesario. Dicho esto, para mí si lo es, ya que este proyecto pretende posibilitar la creación de servidores en contenedores en la nube de manera open source. Esto podría posibilitar como ya he mencionado anteriormente que cualquier persona con acceso a un ordenador con capacidad de correr un contenedor pueda tener su propio servidor de videojuegos, sin tener la limitación económica que producen las grandes empresas al tener que contratar sus servicios. 32 10. Desarrollo 10.1 Tecnologías utilizadas Para construir todo el entorno para poder realizar las pruebas pertinentes, primero es necesario saber qué funcionalidades se quieren obtener, qué herramientas se usarán para realizarlas, y cómo funcionan estas herramientas. Es por eso que a continuación, se explica en detalle que tecnologías se ha decidido utilizar y porqué, así como también en el siguiente apartado que funcionalidades deben estar acabadas y funcionando para poder realizar los test deseados. 10.1.1 Docker Docker [26] es una plataforma de software de código abierto que permite correr software a la vez que facilita su proceso de desarrollo y distribución. Esto se consigue porque en el momento de empaquetar dicho software en Docker, este es provisto de todas las librerías, bibliotecas y dependencias necesarias para realizar una ejecución de forma autónoma en cualquier sistema operativo. Este software empaquetado se conoce como contenedores, y aunque ya existían antes de la aparición de Docker, no tenían la tecnología ni las ventajas que este aporta. Gracias a Docker, se pueden crear, probar e implementar aplicaciones rápidamente, ya que, al poderse ejecutar en cualquier sistema operativo, ya no hace falta crear una aplicación en particular para cada uno de ellos, sino empaquetarla en un contenedor y usarlo en todos los sistemas deseados. De esta forma, se puede gastar más tiempo en la creación y el testeo de dicha aplicación. Además, tal y como está pensado y creado Docker, empaqueta el software en un contenedor de manera que este es un entorno aislado del resto. Esto quiere decir, que se puede ejecutar uno o más contenedores a la vez sin miedo a tener problemas de seguridad fuera del contenedor, permitiendo por ejemplo usarlo como un entorno de pruebas si se desea. Docker entre otras cosas, facilita la automatización del software cuando es desplegado en los contenedores. En el entorno del contenedor, donde se virtualizan y ejecutan las aplicaciones, Docker añade una capa extra de motor de despliegue por encima. La forma en que se ha diseñado, proporciona un entorno rápido y liviano donde el código es ejecutado de forma eficiente, eso sí perdiendo un pequeño porcentaje de efectividad 33 respecto a su ejecución fuera de contenedores. Asimismo, también permite probar el código antes de ser puesto en producción, una gran ventaja para los programadores. Para poder acabar de entender cómo está creado Docker, y como este funciona, se van a explicar sus cuatro componentes principales. Servidor y cliente Docker tiene una arquitectura de tipo cliente y servidor, donde el cliente enviará una petición al servidor (Daemon) para que este la procese. Este Daemon también será el encargado de crear y administrar los contenedores. Cabe mencionar que la conexión mediante cliente y Daemon se realiza a través de una API, y por tanto el cliente y el servidor pueden ser ejecutados tanto en la misma máquina física como también en distintas, teniendo una conexión remota entre ellos. Imágenes Una imagen de Docker es una plantilla que contiene las instrucciones para la creación de un contenedor. Todas las imágenes tienen como inicio una imagen base, que suelen ser las imágenes de sistemas operativos, como por ejemplo Ubuntu o Fedora. Estas imágenes base tienen la capacidad de crear un contenedor capaz de correr un sistema operativo con todas sus funcionalidades. Cabe decir que también se les puede añadir aplicaciones para modificar dichas imágenes base y tener algo más que el sistema operativo. Dicho esto, la mejor manera para crear una imagen de Docker es usar un fichero llamado Dockerfile. Este fichero contiene todas las instrucciones necesarias para crear una imagen de manera automatizada, simplemente usando el comando docker build en el Dockerfile que se ha creado. Ahora, se mostrará un ejemplo de un Dockerfile muy sencillo en la Figura 2. Este crea una imagen de Docker a partir de una imagen de un sistema operativo, en este caso Ubuntu 18.04. Además del sistema operativo, también se añadirá una aplicación en Python y se ejecutará más adelante. Para concluir, se ejecutará un comando que borrará un directorio en caché. 34 Figura 2: Ejemplo de Dockerfile. Fuente: [27] Repositorios Las imágenes de Docker se almacenan en repositorios, ya que estos permiten descargar o subir las imágenes desde una única fuente. Se distinguen dos tipos, los privados y los públicos. En el caso de los privados, serán repositorios que un particular o empresa ha montado por su cuenta. En ellos se podrán subir imágenes propias para así usarlas desde cualquier parte. Esto es muy útil a la hora de trabajar, sobre todo para las empresas, ya que no siempre es de su interés que las imágenes que usan sean de carácter público. Por otro lado, los repositorios públicos permiten el acceso a cualquier usuario, de manera que todo el mundo tiene permiso para subir y descargar imágenes. Un ejemplo es Docker Hub [28], el repositorio más grande de Docker que fue creado por la propia empresa. Contenedores Un contenedor se podría definir como una imagen en ejecución. Estos contienen toda la información necesaria para que el software que se ha empaquetado sea ejecutado de manera correcta y aislada. Por ejemplo, suponiendo que se tiene una imagen con Ubuntu 18.04 y una base de datos MongoDB. Cuando esta imagen se ejecute, se creará un contenedor donde una base de datos Mongo DB correrá en Ubuntu 18.04. 10.1.2 Kubernetes Kubernetes [29] es un sistema de código abierto para el despliegue, escalado y orquestación de contenedores. Se podría ver a Kubernetes como un conjunto de nodos organizados que corren aplicaciones empaquetadas en contenedores, donde un nodo es una máquina ya sea virtual o física. Esto permite a Kubernetes desarrollar, mover y gestionar aplicaciones de una manera más fácil. 35 Sus principales características que hacen que sea una de las tecnologías más usadas hoy en día son: • La posibilidad de correr Kubernetes en cualquier parte, debido a el uso de contenedores. Por ejemplo, desde un centro de datos hasta cualquier lugar en la nube, permitiendo una flexibilidad enorme. • La distribución de carga automática entre nodos, permitiendo al programador distribuir la carga como deseé según el sistema en que se encuentre, o dejar al propio Kubernetes hacer una repartición equilibrada. • La capacidad de mantener los contenedores con una alta disponibilidad, ya que Kubernetes puede monitorizarlos y así saber si se deben reiniciar o arreglar. • Es auto escalable, es decir, se puede empezar con un solo nodo y después pasar a tener ciento cincuenta más sin ningún problema aparente. Una vez se ha visto como es Kubernetes, se pasará a explicar algunas herramientas que se usan junto a él en este proyecto: Minikube Minikube [30] es una herramienta de código abierto, que permite obtener un entorno de Kubernetes con prácticamente todas sus funcionalidades a partir de la creación de una máquina virtual, por defecto Virtual Box de Oracle. Se podría decir que Minikube presenta una versión reducida de Kubernetes de manera sencilla, ligera y local. Una de sus mayores ventajas es que para funcionar solo necesita un clúster con un solo nodo. Esto hace que para un proyecto privado como éste sea perfecto, ya que se puede montar un clúster muy ligero rápidamente, permitiendo hacer pruebas y después eliminar el clúster si el resultado no es el esperado. Además, como Minikube trabaja localmente, no se depende de ningún servicio de pago para acceder a la nube. Google Kubernetes Engine Google Kubernetes Engine (GKE) [31], es una plataforma que proporciona un entorno para implementar, administrar y escalar aplicaciones automáticamente mediante Kubernetes. Esto permite que se pueda interactuar con el clúster de contenedores tal y como se hace en Kubernetes, mediante comunicación directa con una API. Sin embargo, en este caso se puede ver de manera gráfica y no solo por terminal si accedemos mediante un navegador al panel de control, cosa que facilita mucho su uso al autor. 36 Figura 3: Panel de control de GKE. Fuente: https://cloud.google.com/. Antes de continuar con GKE, es necesario entrar en detalle en algunos conceptos usados en Kubernetes que son vitales para este proyecto, como son el concepto de pod, nodo e instancia [32]. Un nodo es una máquina trabajadora en Kubernetes, y puede ser tanto física como virtual. Estas máquinas son instancias de máquinas virtuales de Compute Engine, otra plataforma de Google. Una instancia es una máquina virtual alojada en la infraestructura de Google. Estas instancias son creadas automáticamente por GKE cuando se crea un clúster, pudiendo crear más o eliminar algunas de ellas si se escala dicho clúster. Cada nodo es controlado por el plano de control, el encargado de “gobernar” Kubernetes, que mantiene un registro de todos los objetos de Kubernetes en el sistema para poder controlarlos y gestionarlos correctamente. Todos los nodos deben correr como mínimo un software que pueda correr contenedores (en este proyecto Docker), así como también Kubelet. Kubelet es el proceso responsable de la comunicación entre el plano de control y el nodo. Este se encarga de gestionar los pods y los contenedores que se ejecuten en una máquina. Un pod es una abstracción en Kubernetes que representa un grupo de uno o más contenedores, que tienen almacenamiento/red compartidos y unas especificaciones de 37 cómo deben ejecutar dichos contenedores. Al compartir red, todos los procesos dentro de dicho pod comparten IP y puerto, facilitando así su acceso. Además, también tienen almacenamiento compartido como volúmenes de datos, pudiendo así compartir datos en tiempo real entre ellos. Esto puede ser muy beneficioso para determinadas aplicaciones, donde por ejemplo se quiera montar un servidor y una base de datos donde guardar la información que el servidor necesite escribir, ya que ambas estructuras pueden estar dentro del mismo pod y compartir datos en tiempo real sin tener que irlos a buscar a otro pod/nodo. A continuación, se muestra una imagen representativa de la estructura nodo/pod. Figura 4: Nodo/Pod en Kubernetes. Fuente: [32]. La principal ventaja de GKE para este proyecto es su capacidad para crear un clúster totalmente escalable de manera automática. Es decir, aunque inicialmente se cree el clúster con dos nodos, en cualquier momento se puede escalar hasta tener por ejemplo mil nodos, siempre y cuando el usuario tenga el crédito suficiente para poder escalar y mantener dicho clúster. Es por esta razón, que en este proyecto solo se usarán dos nodos con dos pods cada uno. Se ha usado la opción gratuita de GKE que proporciona un crédito de 300$ durante 90 días. Aunque ha sido suficiente para la mayoría de las pruebas que se querían realizar, es cierto que ha limitado algunas de ellas, ya uno de estos dos nodos se tiene que dedicar a las métricas, y por tanto queda solo un nodo para correr Agones y los servidores. 38 Esto deja poco espacio para las pruebas con más de un nodo a la vez corriendo servidores, y así poder visualizar su comportamiento ante una caída, actualización, balanceo de carga cuando uno está lleno, etc. Kubectl Kubectl [33] es una línea de comandos que Kubernetes utiliza para desplegar y gestionar aplicaciones en el clúster. A través de kubectl, se pueden inspeccionar recursos del clúster, así como también crear, eliminar y actualizar componentes. Algunos de los comandos básicos y más usados se muestran a continuación: Figura 5: Comandos más usados de kubectl. Fuente: [33] Helm Helm [34] es un gestor de paquetes para Kubernetes. Aunque existen otros como apt o npm, se ha decidido usar este para el proyecto ya que es el recomendado por Agones. Para la construcción del entorno de Kubernetes y Agones, es necesaria la modificación y creación de muchos archivos YAML, que normalmente son archivos de configuración usados para diferentes fines, como por ejemplo crear aplicaciones o para su personalización y configuración. A continuación, se puede ver un ejemplo de un fichero YAML extraído de la instalación de Agones de este proyecto: 45 En cuanto a las métricas, se podrían definir como medidas numéricas que varían dependiendo de las necesidades del cliente. Es decir, una métrica puede ser desde tiempos de solicitud para un servidor web, hasta el número de consultas realizadas a una base de datos en un determinado tiempo. Son imprescindibles para entender y controlar el comportamiento de cualquier aplicación, ya que sin una monitorización adecuada es mucho más complicado detectar cuando dicha aplicación deja de funcionar de una manera adecuada, y más importante aún, porqué ha dejado de actuar como debería y así poder arreglarla. Antes de continuar con la arquitectura de Prometheus, cabe mencionar que este usa un lenguaje de consulta flexible llamado PromQL. En resumen, este lenguaje permite al usuario seleccionar y agregar datos en tiempo real. El resultado es una expresión que puede ser mostrada como un gráfico, como una estructura con forma de tabla, etc. En general, consigue mostrar los datos de forma agradable para el usuario, de forma que se asimilan mejor. Para acabar, se va a explicar por encima la arquitectura de Prometheus. Como se puede ver en la figura 9, consta de seis elementos principales: • Servidor principal de Prometheus, que extrae y almacena datos de las métricas generadas. • Librerías de cliente para completar el código de la aplicación. • Una entrada llamada Pushgateway que permite a los trabajos efímeros y por lotes expongan sus métricas a Prometheus antes de ser eliminados. • Exportadores de propósito especial para servicios particulares como HAProxy, Graphite, etc. • Un administrador de alertas para manejar dichas alertas. • Herramientas varias de apoyo, como, por ejemplo, Grafana. Primeramente, Prometheus buscará un objetivo para comenzar a trabajar con él. Esto lo hará con el Service Discovery, que detectará determinados softwares, como por ejemplo Kubernetes. Si no detecta ningún software de esta manera, lo puede hacer de otra forma, mediante los exportadores de propósito especial, que detectarán un software en particular. Una vez tiene un objetivo, puede comenzar a extraer las métricas. Esto lo puede hacer directamente o mediante la Pushgateway para trabajos de corta duración. Acto seguido, almacenará todas las muestras extraídas localmente, y aplicará las etiquetas 46 correspondientes para agregar y registrar las nuevas series de tiempo. Durante este proceso también se podrán generar las alertas, a gusto del cliente dependiendo de sus necesidades. En el caso de este proyecto, también se usará una herramienta adicional, Grafana, que se encargará de mostrar los datos recopilados por pantalla de manera amigable para el usuario. Figura 11: Arquitectura de Prometheus. Fuente: [40]. 10.1.5 Grafana Grafana [42] es una herramienta que permite consultar, visualizar, alertar y comprender métricas independientemente de donde estén almacenadas. En el caso de este proyecto, se va a utilizar Grafana para facilitar la comprensión y la lectura de las métricas extraídas por Prometheus, ya que, aunque estas son muy completas, además de ser poco visuales, también son complejas para leer y entender para el usuario. Grafana también ofrece posibilidades muy potentes en cuanto a monitorización y alertas para su control. Un ejemplo son las alertas en la nube, donde a partir de una sola alerta se pueden llegar a generar múltiples notificaciones. Además, estás se pueden filtrar por tipos y prioridades para evitar un posible spam, quedándose solo con las que interesan al cliente. 47 Aunque Grafana tiene otras herramientas muy potentes, como por ejemplo un sistema basado en Machine Learning que aprende de la monitorización realizada, adaptándose a las situaciones generadas por el software y prediciendo posibles problemas antes de que estos surjan, no se planea utilizarlas. Esto se debe a que no se cree necesario usarlas para lograr obtener los datos requeridos para cumplir los objetivos fijados, sino que con las funcionalidades básicas debería ser más que suficiente. 10.2 Arquitectura Antes de comenzar con el desarrollo del proyecto, se cree conveniente mostrar la arquitectura de este de una forma compacta y unificada. De esta manera, se puede ver el conjunto “desde arriba” y tener una imagen clara de qué tecnologías lo forman, así como también de cómo se complementan e interactúan entre ellas. Figura 12: Arquitectura del proyecto. Fuente: Elaboración propia Como se puede apreciar en la Figura 10, Kubernetes es una herramienta imprescindible en este proyecto, al igual que Docker y Agones, ya que juntos forman el esqueleto del trabajo. Kubernetes actúa de orquestador de los contenedores Docker, siendo un gestor para ellos. En los contenedores se alojan los servidores de videojuegos, y estos se comunican con Kubernetes gracias a Agones. A continuación, una vez todo se ha puesto en marcha, las herramientas de monitorización entran en escena. Prometheus será en el encargado de recoger los datos 48 generados por todo este software. Con estos datos se generarán las estadísticas apropiadas, para que Grafana las muestre de una manera agradable para el usuario. De esta forma, no solo se obtiene un entorno que monta el servidor en la nube, sino que también se consiguen estadísticas con las que poder discutir si es una opción viable hoy en día, o aún queda camino por recorrer. 10.3 Implementación Una vez vista la arquitectura del proyecto, sus componentes y como estos funcionan, es el turno de la implementación. Esta se ha realizado siguiendo la planificación de las tareas establecida al comienzo del trabajo, acabando de pulir un apartado antes de pasar al siguiente para evitar posibles errores en el futuro. Sin embargo, estos errores y problemas derivados del desarrollo son inevitables, ya sean provocados por errores en la programación, instalaciones mal realizadas, bugs relacionados con la interacción entre las herramientas utilizadas o simplemente errores que no dependen del autor, sino de alguna tecnología utilizada como es el caso de Agones, la cual debido a su poco tiempo de desarrollo tiene aún mucho que mejorar. Estos errores, aun siendo considerados desde el día uno en la planificación, han consumido una cantidad considerable de horas que no se ha podido dedicar a conseguir otros subobjetivos. Por tanto, se ha considerado relevante explicar mínimamente el proceso que se ha seguido para detectar dichos errores, encontrar dónde se encontraba el problema y solucionarlos mientras que se entra en detalle en la implementación. 10.3.1 Clúster de Kubernetes y GKE Primeramente, es necesaria la creación del clúster de Kubernetes para poder continuar con el resto de tecnologías, por tanto, se empezará por ahí. Aunque originalmente se comenzó trabajando de manera local con Minikube, una vez el proyecto ya era funcional, se decidió cambiar a Google Kubernetes Engine (GKE) para poder trabajar en la nube, ya que era el objetivo inicial. Por tanto, toda la instalación se realizará usando el clúster creado en GKE y no el de Minikube. Para ello, previamente se ha creado un proyecto en Google Cloud y se ha habilitado la API para él. Una vez creado dicho proyecto, se ha de configurar el entorno que se usará durante toda la instalación, comenzando por la consola de comandos. Se presentan dos opciones, usarla de manera local mediante la consola de Ubuntu, o directamente en la nube a 49 través de la plataforma de Google Cloud. En este caso se ha elegido hacerlo localmente, ya que era más cómodo para el autor. Al haber realizado esta elección, se deben instalar y configurar algunos elementos más que en su variante en la nube. Primero, se necesita instalar el SDK de Google Cloud, que se encarga de permitir al usuario usar los comandos gcloud desde su máquina, haciendo que ahora la consola de Ubuntu sepa hablar con Google Cloud. 1. echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] http://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list 2. curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add - 3. sudo apt-get update && sudo apt-get install google-cloud-sdk Ahora, se tiene que configurar el entorno, donde también se tendrá que seleccionar la zona horaria. Además, también es necesario instalar kubectl, ya que por defecto no está en Ubuntu. 1. gcloud init 2. gcloud components install kubectl Cabe mencionar, que al realizar la instalación de kubectl surgió un problema. Aunque al principio se pensó que se debía a un error en las credenciales de Google Cloud, resultó ser culpa de un conflicto entre dos gestores de paquetes. Más concretamente, entre apt y snap, al haber instalado el SDK de Google Cloud con apt y kubectl con snap. La solución fue instalar tanto el SDK como kubectl con el mismo gestor, en este caso apt. A continuación, se muestra la captura del error: Figura 13. Error al usar gcloud para instalar componentes en la nube. Fuente: Elaboración propia Para acabar lo necesario antes de crear el clúster, se necesita un firewall para permitir el tráfico UDP en los puertos 7000-8000 para los nodos que tengan la etiqueta gameserver, sino el servidor no será capaz de comunicarse. 50 1. gcloud compute firewall-rules create game-server-firewall \ 2. --allow udp:7000-8000 \ 3. --target-tags game-server \ 4. --description "Firewall to allow game server udp traffic" Ahora, ya se tiene lo necesario para crear el clúster, por lo que se procede a ello. Como ya se ha mencionado anteriormente, debido a la situación económica y la cantidad de nodos disponibles en la prueba gratuita de GKE, solo se pueden crear dos nodos. Uno de estos nodos estará dedicado a la monitorización y se creará una vez esté el clúster operativo. Por tanto, esto deja un nodo disponible para los servidores, y será con el que creemos el clúster. A continuación, se procede a la construcción del clúster con un solo nodo de inicio. 1. gcloud container clusters create agonestfg --cluster-version=1.21 \ 2. --tags=game-server \ 3. --scopes=gke-default \ 4. --num-nodes=1 \ 5. --no-enable-autoupgrade \ 6. --machine-type=e2-standard-4 Ahora, se ha de crear el segundo nodo dedicado a las métricas. 1. gcloud container node-pools create agones-metrics \ 2. --cluster=agonestfg \ 3. --no-enable-autoupgrade \ 4. --node-taints agones.dev/agones-metrics=true:NoExecute \ 5. --node-labels agones.dev/agones-metrics=true \ 6. --num-nodes=1 Por último, para finalizar con el clúster por el momento, es necesario decirle a gcloud que se está hablando con este clúster, y pedir las credenciales para poder usar kubectl sobre él. 1. gcloud config set container/cluster agonestfg 2. gcloud container clusters get-credentials agonestfg 10.3.2 Agones La instalación de Agones se pretendía hacer mediante un chart de Helm, pero debido a problemas que no se consiguieron resolver al configurar algunos parámetros esenciales de Agones, se decidió realizar mediante un archivo yaml. Estos parámetros, como por ejemplo el RBAC que permite tener un sistema de roles en Kubernetes, son imprescindibles para que Agones funcione correctamente. 51 Cabe decir, que antes de realizar dicha instalación, se crea un namespace llamado agones-system para hacerla allí. Esto se debe a que, aunque en este proyecto no se pueda tener más de dos nodos, idealmente se tendrían separados por namespace los nodos dedicados a servidores, Agones, métricas, etc. y se ha querido mantener la estructura. 1. kubectl create namespace agones-system 2. kubectl apply -f https://raw.githubusercontent.com/googleforgames/agones/release1.19.0/install/yaml/install.yaml Para comprobar que todo haya ido correctamente, se puede visualizar el estado de los pods en el namespace que se acaba de crear. 1. kubectl describe --namespace agones-system pods 2. kubectl get pods --namespace agones-system Seguidamente, se muestra el resultado de ambos comandos. Cabe decir que, debido a la gran longitud del primer comando, solo se muestra un fragmento donde se puede ver el estado de uno de los pods que se acaban de crear, el cual siempre tendría que tener todas las condiciones a true si está en buen estado. Figura 14. Comprobación de la instalación de Agones. Fuente: Elaboración propia En el caso del segundo comando, para comprobar que el estado de los pods es correcto, símplemente hay que verificar que todos los pods están en estado Running y Ready. A continuación, se muestran dos capturas del resultado del comando, una al instalar Agones, y la otra tras un error al comprobar el estado de los pods una vez ya estaba Agones en marcha. Este error se produjo al asignar un servidor, y fue provocado al intentar asignar un servidor en un pod que estaba en estado Shutdown, es decir, un pod que estaba en proceso de terminio. Como se puede apreciar en la segunda imagen, el estado es CrashLoopBackOff y no está Ready, pudiendo ver claramente que el pod no funciona como debería. 52 Figura 15. Comprobación de la instalación de Agones parte 2. Fuente: Elaboración propia Figura 16: Error al asignar los pods. Fuente: Elaboración propia Asimismo, para poder comunicarse con los servidores se necesita Netcat. 1. sudo apt update 2. sudo apt install Netcat Por último, se ha clonado el repositorio de GitHub de Agones, de forma que se tiene acceso a todos los archivos necesarios para hacer las pruebas en un futuro. 1. git clone https://github.com/googleforgames/agones.git 10.3.3 Monitorización Para la instalación de Prometheus, se usará Helm. Por tanto, se debe instalar primero. 1. curl https://baltocdn.com/helm/signing.asc | sudo apt-key add - 2. sudo apt-get install apt-transport-https --yes 3. echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list 4. sudo apt-get update 5. sudo apt-get install helm Ahora sí, es el turno de Prometheus. Al trabajar con Helm, primero se añadirá al repositorio del usuario el chart de Prometheus, en este caso prometheus-community. Después, se realizará la instalación del contenido de dicho chart en el namespace metrics que se ha creado anteriormente. 53 1. helm repo add prometheus-community https://prometheus-community.github.io/helmcharts 2. helm repo update 3. helm upgrade --install prom prometheus-community/prometheus --version 11.16.2 -- namespace metrics \ 4. --set server.global.scrape_interval=30s \ 5. --set server.persistentVolume.enabled=true \ 6. --set server.persistentVolume.size=64Gi \ 7. -f ./build/prometheus.yaml Cabe señalar que este helm upgrade puede dar un error al no encontrar el archivo de configuración de la instalación prometheus.yaml. Si esto ocurre, simplemente es necesario crear un fichero prometheus.yaml con el siguiente formato, pudiendo cambiar el valor de alguno de los parámetros si le conviene al usuario. Para comprobar que Prometheus está funcionando correctamente, se puede utilizar la utilidad de kubectl port-forward, que expone el pod al mundo exterior y permite conectarse a él. Es decir, redirige el tráfico del pod a un puerto local, para así poder visualizarlo de una manera más sencilla mediante el navegador. En este caso, se redirige el tráfico del pod encargado de las métricas al puerto 9090 de la máquina, accesible a través de http://localhost:9090 . 1. kubectl port-forward deployments/prom-prometheus-server 9090 -n metrics Seguidamente, se muestra una captura de Prometheus en marcha. Figura 17: Ejemplo de Prometheus. Fuente: Elaboración propia 54 Ahora bien, como ya se ha mencionado anteriormente, las métricas generadas por Prometheus son poco visuales, así como también algo difíciles de comprender y leer para el usuario. Por tanto, aunque Prometheus esté en funcionamiento, lo que el usuario vea será Grafana. Aunque para eso, primero es necesaria su instalación y configuración. Primeramente, se ha de instalar el paquete de dashboard de Agones para Grafana. Este paquete contiene todo lo necesario para poder visualizar las métricas más relevantes de Agones desde Grafana. 1. kubectl apply -f ./build/grafana/ A continuación, tal y como se ha hecho con Prometheus, se instalará Grafana mediante Helm, usando el chart Grafana Community Kubernetes. Cabe decir que en el comando se pide una contraseña. Esta será la utilizada por el usuario para entrar a Grafana, así que es importante tener esto en cuenta para no perderla o poner una equivocada. 1. helm repo add grafana https://grafana.github.io/helm-charts 2. helm repo update 3. helm upgrade --install --wait grafana grafana/grafana --version=5.7.10 --namespace metrics \ 4. --set adminPassword=123456 -f ./build/grafana.yaml Para acceder a las métricas mediante Grafana, se seguirá el mismo proceso que con Prometheus usando port-forward, en este caso en el puerto 3000. 1. kubectl port-forward deployments/grafana 3000 -n metrics La conexión se realizará accediendo a http://localhost:3000 a través del navegador. Seguidamente, se muestra una captura de Grafana en funcionamiento. 61 Figura 26: Autoscaler en funcionamiento en la tercera prueba. Fuente: Elaboración propia Tal y como se puede observar en la Figura 26, al eliminar todos los servidores, el autoscaler ha escalado la flota de tres a dos servidores. Además, se han creado dos servidores nuevos. Este comportamiento se debe a los parámetros establecidos que se han visto anteriormente, ya que, una vez eliminados todos los servidores, el autoscaler ha escalado la flota al estado deseado que el autor había introducido, en este caso dos servidores, pasando de cero a dos servidores. Por tanto, se puede apreciar como el servidor en estado alocado ha desaparecido, y se ha creado dos servidores nuevos para cumplir el estado deseado establecido por el autor, probando así que el funcionamiento del autoscaler es el que se quería, y, por consiguiente, una prueba con éxito. 10.4.4 Pérdida de un pod en tiempo real En el anterior apartado, se ha comprobado como en caso de eliminar o perder un servidor, el clúster es capaz de volver al estado en el que estaba la flota de manera automática. En la siguiente prueba, se quiere comprobar si el resultado es el mismo si se pierde directamente el pod y no el servidor. Para ello, se empezará el experimento con una flota que contiene dos servidores en estado Ready. Cada uno de estos servidores está formado por un pod, que a su vez está formado por dos contenedores. 62 El primero de estos corresponde al contenedor creado con la imagen preparada para el servidor, y, por ende, actuará como tal. El segundo, en cambio, es un contenedor inyectado por Agones, llamado SDK sidecar. Este sidecar, permite al otro contenedor realizar todas las acciones disponibles para el SDK, como comprobar la salud o la disponibilidad del servidor. La gracia de esta interacción está en que todo esto será en tiempo real, ya que ambos contenedores pertenecen al mismo pod, y por tanto tienen recursos compartidos. Por esa razón, un contenedor actúa como servidor y el otro como apoyo de Agones, pudiendo pasarse información en tiempo real y comprobar continuamente el estado del servidor, para así ofrecer la mejor experiencia al jugador. En la Figura 27, se encuentra el resultado de esta prueba. Figura 27: Resultado de la cuarta prueba. Fuente: Elaboración propia Tal y como se puede observar en la Figura 27, se partía de dos servidores con un pod cada uno. De estos dos pods, se decidió eliminar uno, en este caso el acabado en 7vp. Después, se volvió a comprobar el estado de los servidores y los pods, y como se puede ver, un nuevo servidor con un nuevo pod fue creado (el acabado en psv), substituyendo de manera automática al que había sido eliminado (el acabado en 7vp). Este resultado es el deseado, por lo que se considera que la prueba ha sido exitosa. 10.4.5 Actualización del servidor en tiempo real Por último, se desea comprobar el comportamiento del clúster al actualizar los servidores en tiempo real. En este caso, se probará a cambiar el número de puerto asignado a los servidores, todo esto con un servidor alocado en marcha, y otros en estado Ready sin trabajo actualmente. En la Figura 28, se encuentra el estado inicial de la flota. 63 Figura 28: Estado inicial de la flota en la quinta prueba. Fuente: Elaboración propia Como se puede ver en la Figura 28, se parte de una flota con cinco servidores en marcha, uno alocado y cuatro en estado Ready. Además, todos estos servidores tienen como puerto asignado al contenedor el 6060, que será el dato que se modificará para actualizar dichos servidores. Ahora, se modificará el código del servidor para que el puerto utilizado sea el 8080 en vez del 6060 que se usa actualmente. De esta manera, una actualización del servidor sería necesaria, y, por ende, la propia flota debería hacer dichos cambios. Los resultados de dicha prueba se encuentran en la Figura 29. Figura 29: Resultados de la quinta prueba. Fuente: Elaboración propia Tal y como se puede apreciar en la Figura 29, se empezó la prueba por cambiar el archivo de configuración de los servidores, modificando el puerto usado por los contenedores que conforman dichos servidores. A continuación, se fue comprobando el estado del 64 campo que contiene el puerto de los contenedores usado por los servidores, y como se puede ver, poco a poco, va cambiando de manera automática de 6060 a 8080, que es el nuevo puerto establecido. Sin embargo, hay un servidor que ha mantenido el mismo puerto que ya había antes, que es el servidor alocado previamente. Si se observa la parte baja de la Figura 29, se puede comprobar como todos los servidores excepto el alocado han sido creados de nuevo usando el nuevo código, cambiando también su puerto de acceso. Cuando el servidor alocado deje de tener jugadores y por tanto vuelva al estado Ready, siguiendo del camino de los otros servidores, será eliminado para dejar paso a un nuevo servidor, creado a partir de la nueva versión del código. Ya que todos los servidores que no estaban alocados han sido actualizados a la nueva versión, y el servidor alocado ha podido seguir funcionando sin problemas con la versión que ya existía, se considera que la prueba ha sido un éxito. 65 11. Conclusiones Una vez finalizado el proyecto, es momento de comprobar si el resultado obtenido ha sido satisfactorio. Para ello, primero recordar que el objetivo principal del proyecto consistía en el estudio de una solución de referencia para el despliegue de servidores de videojuegos multijugador en la nube. Dicho objetivo principal se considera logrado, ya que, al final, se ha podido realizar un estudio en profundidad sobre el tema en cuestión, además de montar un entorno capaz de hacer funcionar un servidor de videojuegos multijugador en la nube. Sin embargo, también se establecieron unos objetivos secundarios, siendo algunos necesarios para poder obtener el principal, y otros opcionales para ampliar el proyecto. Estos objetivos secundarios obligatorios, que son lograr el despliegue del servidor de videojuegos, montar la monitorización del sistema y conseguir que el entorno sea escalable han sido conseguidos y superados con éxito, tal y como se puede ver en el apartado 10.4. En cuanto a los objetivos secundarios opcionales, de los dos propuestos, que eran la automatización del proyecto y una demo del servidor de videojuegos en vivo, se ha conseguido el segundo. De esta forma, se ha podido probar el servidor de videojuegos alojado en la nube en una partida real entre jugadores e inteligencias artificiales, como se puede observar en las Figuras 21 y 22. En conclusión, ya que tanto el objetivo principal como los objetivos secundarios esenciales han sido conseguidos, se considera que el objetivo del proyecto ha sido logrado, obteniendo un entorno totalmente capaz de alojar servidores de videojuegos en la nube de manera open source. No obstante, aunque la mayoría de objetivos se hayan completado con éxito, aún quedan campos que ampliar y explorar para este proyecto. Un ejemplo es la automatización, ya que facilitaría mucho la construcción del entorno y los servidores, haciendo esta idea mucho más atractiva de cara a los usuarios, que lo tendrían mucho más fácil a la hora de montar su propio servidor en la nube. 66 12. Bibliografía [1] AEVI. La industria del videojuego en España. España: AEVI, 2020. [Última consulta: 22 de septiembre de 2021]. Disponible en: http://www.aevi.org.es/web/wpcontent/uploads/2021/04/AEVI_Anuario_2020.pdf. [2] Servidor. En: Wikipedia [en línea]. Wikimedia Foundation, 2019. [Última consulta: 23 de septiembre de 2021]. Disponible en: https://es.wikipedia.org/wiki/Servidor. [3] ¿Qué es la nube? En: Azure [en línea]. Microsoft Azure, 2021. [Última consulta: 23 de septiembre de 2021]. Disponible en: https://azure.microsoft.com/es-es/overview/whatis-the-cloud/. [4] ¿Qué son los contenedores Linux (LXC)? En: Red Hat [en línea]. Red Hat, 2021. [Última consulta: 24 de septiembre de 2021]. Disponible en: https://www.redhat.com/es/topics/containers/whats-a-linux-container. [5] ¿Qué es un clúster de Kubernetes? En: Red Hat [en línea]. Red Hat, 2021. [Última consulta: 24 de septiembre de 2021]. Disponible en: https://www.redhat.com/es/topics/containers/what-is-a-kubernetes-cluster. [6] ¿Qué es Kubernetes? En: Kubernetes [en línea]. Kubernetes, 2021. [Última consulta: 24 de septiembre de 2021]. Disponible en: https://kubernetes.io/es/docs/concepts/overview/what-is-kubernetes/. [7] Amazon. En: Amazon Game Lift [en línea]. Amazon, 2021. [Última consulta: 16 de octubre de 2021]. Disponible en: https://aws.amazon.com/es/gamelift/. [8] Google Stadia. En: Stadia, un único lugar para todas las formas de jugar [en línea]. Stadia, 2021. [Última consulta: 16 de octubre de 2021]. Disponible en: https://stadia.google.com/?hl=es. [9] Agones. En: Google Agones [en línea]. Google, 2021. [Última consulta: 2 de enero de 2022]. Disponible en: https://agones.dev/site/. [10] Qué es la inteligencia artificial – IA? En: Oracle [en línea]. Oracle, 2021. [Última consulta: 27 de septiembre de 2021]. Disponible en: https://www.oracle.com/es/artificial-intelligence/what-is-ai/. [11] The Go programming Language. En: Golang [en línea]. Golang, 2021. [Última consulta: 27 de septiembre de 2021]. Disponible en: https://golang.org/. 67 [12] ¿Cuál es la metodología más adecuada para tu proyecto? En: Deloitte [en línea]. Deloitte, 2021. [Última consulta: 25 de septiembre de 2021]. Disponible en: https://www2.deloitte.com/es/es/pages/technology/articles/waterfall-vs-agile.html. [13] GitHub. En: Github [en línea]. GitHub, 2021. [Última consulta: 25 de septiembre de 2021]. Disponible en: https://github.com/. [14] Agones. En: Create Kubernetes Cluster [en línea]. Google, 2021. [Última consulta: 24 de septiembre de 2021]. Disponible en: https://agones.dev/site/docs/installation/creating-cluster/. [15] Prometheus. En: Prometheus: From metrics to insight [en línea]. Prometheus, 2021. [Última consulta: 2 de octubre de 2021]. Disponible en: https://prometheus.io/. [16] Grafana. En: Grafana: The open observability platform [en línea]. Grafana, 2021. [Última consulta: 2 de octubre de 2021]. Disponible en: https://grafana.com/. [17] VMware. En: VMware [en línea]. VMware, 2021. [Última consulta: 2 de octubre de 2021]. Disponible en: https://www.vmware.com/es.html. [18] VScode. En: VScode: code editing redefined [en línea]. Microsoft, 2021. [Última consulta: 2 de octubre de 2021]. Disponible en: https://code.visualstudio.com/. [19] Glassdoor. En: Glassdoor: Encuentra el empleo perfecto para ti [en línea]. Glassdoor, 2021. [Última consulta: 5 de octubre de 2021]. Disponible en: de. [20] PCComponentes. En: PCComponentes: Encuentra tu PC de 10 [en línea]. PCcomponentes, 2021. [Última consulta: 7 de octubre de 2021]. Disponible en: www.pccomponentes.com/configurador/5cFc49Dd6. [21] Microsoft. En: Windows: Compra Windows 10 para empresas [en línea]. Microsoft, 2021. [Última consulta: 7 de octubre de 2021]. Disponible en: https://www.microsoft.com/es-es/d/windows-10pro/df77x4d43rkt?rtc=1&activetab=pivot:overviewtab. [22] VMware. En: VMware: VMware Workstation 16 Pro [en línea]. VMware, 2021. [Última consulta: 7 de octubre de 2021]. Disponible en: https://store-es.vmware.com/vmwareworkstation-16-pro-5434558400.html. [23] CoWorking Space. En: Monday Tibidabo [en línea]. CoWorking Space, 2021. [Última consulta: 7 de octubre de 2021]. Disponible en: https://coworkingspain.es/espacios/coworking/barcelona/monday-tibidabo. 68 [24] Greenpeace. En: Envenenando la pobreza [en línea]. Greenpeace, 2021. [Última consulta: 10 de octubre de 2021]. Disponible en: http://archivoes.greenpeace.org/espana/Global/espana/report/contaminacion/envenenando-lapobreza.pdf. [25] Microsoft. En: Xbox Live Gold [en línea]. Microsoft, 2021. [Última consulta: 10 de octubre de 2021]. Disponible en: https://www.xbox.com/es-ES/live/gold. [26] Babak Bashari Rad, Harrison John Bhatti and Mohammad Ahmadi. An Introduction to Docker and Analysis of its Performance. IJCSNS International Journal of Computer Science and Network Security. Marzo de 2017, VOL.17 No.3. Disponible en: http://paper.ijcsns.org/07_book/201703/20170327.pdf. [27] Docker. En: Best practices for writing Dockerfiles [en línea]. Docker, 2021. [Última consulta: 29 de octubre de 2021]. Disponible en: https://docs.docker.com/storage/storagedriver/. [28] Docker. En: Build and Ship any Application Anywhere [en línea]. Docker, 2021. [Última consulta: 29 de octubre de 2021]. Disponible en: https://hub.docker.com/. [29] Baró Cayetano, L. Creation of a Kubernetes Infrastructure [en línea]. Degree Thesis, UPC, Escola Tècnica d’Enginyeria de Telecomunicació de Barcelona, 2021 [Última consulta: 30 de octubre de 2021]. Disponible en: https://upcommons.upc.edu/bitstream/handle/2117/344394/Creation%20of%20a%20K ubernetes%20Infrastructure.pdf?sequence=2&isAllowed=y. [30] Minikube. En: Minikube, Documentation [en línea]. Minikube, 2021. [Última consulta: 2 de noviembre de 2021]. Disponible en: https://minikube.sigs.k8s.io/docs/. [31] Google. En: Google Kubernetes Engine [en línea]. Google, 2021. [Última consulta: 2 de enero de 2022]. Disponible en: https://cloud.google.com/kubernetes-engine/. [32]Kubernetes. En: Viewing Pods and Nodes [en línea]. Kubernetes, 2021. [Última consulta: 2 de enero de 2022]. Disponible en: https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/. [33] Kubernetes. En: Overview of kubectl [en línea]. Kubernetes, 2021. [Última consulta: 30 de octubre de 2021]. Disponible en: https://kubernetes.io/docs/reference/kubectl/overview/. 69 [34] Helm. En: Helm, the package manager for Kubernetes [en línea]. Helm, 2021. [Última consulta: 30 de octubre de 2021]. Disponible en: https://helm.sh/. [35] Helm. En: Charts [en línea]. Helm, 2021. [Última consulta: 30 de octubre de 2021]. Disponible en: https://helm.sh/es/docs/topics/charts/. [36] Ionos. En: ¿Qué es Netcat y cómo funciona? [en línea]. Ionos, 2021. [Última consulta: 31 de octubre de 2021]. Disponible en: https://www.ionos.es/digitalguide/servidores/herramientas/netcat/. [37] Agones. En: Quickstart: Create a Game Server [en línea]. Agones, 2021. [Última consulta: 2 de enero de 2022]. Disponible en: https://agones.dev/site/docs/gettingstarted/create-gameserver/. [38] Agones: En: Visión General [en línea]. Agones, 2021. [Última consulta: 1 de noviembre de 2021]. Disponible en: https://agones.dev/site/docs/overview/. [39] Agones. En: SDK de cliente de Agones Game Server [en línea]. Agones, 2021. [Última consulta: 1 de noviembre de 2021]. Disponible en: https://agones.dev/site/docs/guides/client-sdks/. [40] Agones. En: Game Server Specification [en línea]. Agones, 2021. [Última consulta: 2 de enero de 2022]. Disponible en: https://agones.dev/site/docs/reference/gameserver/. [41] Prometheus. En: OVERVIEW: What is Prometheus [en línea]. Prometheus, 2021. [Última consulta: 20 de diciembre de 2021]. Disponible en: https://prometheus.io/docs/introduction/overview/. [42] Grafana. En: The open observability platform [en línea]. Grafana, 2021. [Última consulta: 20 de diciembre de 2021]. Disponible en: https://grafana.com/. 70 13. Anexo 77 13.3 Anexo C: Especificaciones del autoscaler Figura 37: Especificación del autoscaler. Fuente: Elaboración propia