Tag Archive Google Cloud

Quilkin, el nuevo proxy UDP Open Source para servidores de juegos

En una colaboración entre Embark Studios y Google Cloud crean Quilkin, un proxy UDP Open Source para servidores de juegos.

Quilkin es un proxy UDP de código abierto diseñado específicamente para su uso con despliegues de servidores de juegos dedicados multijugador a gran escala, para garantizar la seguridad, el control de acceso, los datos de telemetría, las métricas y mucho más.

Está diseñado para ser utilizado detrás de los clientes de juegos, así como delante de los servidores de juegos dedicados, y ofrece los siguientes beneficios: Proxy de datos UDP no transparente, Métricas fuera de la caja, Visibilidad, Flexibilidad, Compatibilidad e Integración.

Luna Duclos, Tech Lead, Embark Studios, mencionó:

Hasta ahora, este tipo de capacidades sólo están al alcance de los grandes estudios de juegos con recursos para construir su propia tecnología.

Creemos que igualar las condiciones para todo el mundo en la industria de los juegos es un esfuerzo importante y digno. Por eso hemos colaborado con Google Cloud y hemos iniciado este proyecto juntos.

En Embark, creemos que el código abierto es el futuro de la industria de los juegos y que la colaboración abierta entre empresas es el camino a seguir, para que todos los estudios, independientemente de su tamaño, puedan alcanzar el mismo nivel de capacidades técnicas.

Y, Rob Martin, Chief Architect, Google Cloud for Games, dijo:

Google Cloud se complace en anunciar Quilkin como la última incorporación a nuestra cartera de soluciones de código abierto para juegos. Quilkin complementa nuestras soluciones OSS existentes, como Agones para los servidores de juegos, Open Match para el matchmaking y Open Saves para la persistencia. Están diseñadas para trabajar juntas como un ecosistema abierto e integrado para el juego. Estamos orgullosos de incluir a Embark Studios como nuestro último colaborador de código abierto para juegos, junto con Ubisoft, Unity y 2K Games. Google Cloud seguirá colaborando estrechamente con nuestros socios de la industria y la comunidad para ofrecer soluciones a escala planetaria que impulsen los juegos más grandes del mundo.

Más información en Embark Studios Blog, Google Cloud.

 

Tags, , , ,

Construir una plataforma con KRM: Parte 5 – Gestionar recursos alojados desde Kubernetes

Este es la 5to. resume y último parte de una serie de varias posts sobre el modelo de recursos de Kubernetes. Consulte lresúmenes 1, 2, 3 y 4 para obtener más información.

En la parte 2 de esta serie, se aprendió cómo funciona el modelo de recursos de Kubernetes y cómo el plano de control de Kubernetes actúa para garantizar que el estado deseado de los recursos coincida con el estado de ejecución. Con este post cierran el círculo explorando cómo utilizar el modelo de recursos de Kubernetes para configurar y aprovisionar recursos alojados en Google Cloud.

 

 

Hay 3 razones para utilizar KRM para los recursos alojados. La primera es la consistencia. La segunda es la reconciliación continua (continuous reconciliation). La tercera es la capacidad de integrar herramientas como kustomize en sus especificaciones de recursos alojados.

Estas ventajas han dado lugar a un nuevo ecosistema de herramientas de KRM diseñadas para gestionar recursos alojados en la nube, incluido el proyecto Crossplane, así como herramientas de primera mano de AWS, Azure y Google Cloud.

En este ejercicio que el equipo de Google ha estado explicando, se utilizó Config Connector, se hizo la integración de Config Connector con Policy Controller y se gestionó los recursos existentes de GCP con Config Connector.

Este post concluye la serie «Construir una plataforma con KRM».

Más información en Google Cloud Blog.

 

 

 

Tags,

Construir una plataforma con KRM: Parte 4 – Administrar un entorno multi-cluster

Esta es la 4to. resumen de una serie de varios posts sobre el modelo de recursos de Kubernetes. Consulte los resúmenes 1, 2 y 3 para obtener más información.

Los clústeres de Kubernetes pueden escalar, admiten hasta 5.000 nodos, y GKE admite hasta 15.000 nodos. Pero escalar un  solo clúster puede llegar hasta cierto punto, si el plano de control del clúster se cae, toda la plataforma se cae; si la región de la nube que ejecuta el clúster tiene una interrupción del servicio, también lo hace su aplicación.

Es por eso que se recomienda operar a través de varios clústers Kubernetes. O al menos es lo que la mayoría de las organizaciones optan por hacer.

Existen varias razones para considerar un multi-cluster, la división de las cargas de trabajo entre la nube y en las instalaciones, la asignación de un clúster a cada equipo de desarrollo, o la capacidad de ráfaga para los picos de tráfico, entre otras.

 

 

En este post presentan Config Sync y Policy Controller que son los que proporcionan una potente cadena de herramientas para estandarizar la configuración y administrar de manera más fácil la capa base en un entorno Kubernetes multi-cluster.

Más información en Google Cloud Blog.

Tags,

Construir una plataforma con KRM: Parte 3 – Simplificar el desarrollo de aplicaciones Kubernetes

Esta es la 3er. resumen de una serie de varios posts sobre el modelo de recursos de Kubernetes. Consulte los resúmenes 1 y 2 para obtener más información.

En el último post, se explica cómo Kubernetes puede proporcionar una base sólida de la plataforma. Pero si bien el modelo de recursos de Kubernetes es poderoso, también puede ser abrumador para aprender porque hay docenas de recursos principales de la API, desde Deployments y StatefulSets, hasta ConfigMaps y Services. Y cada uno tiene su propia funcionalidad, campos y sintaxis.

Es posible que algunos equipos de la organización necesiten conocer toda la superficie de desarrollo de Kubernetes, como los equipos que construyen integraciones de plataformas. Pero otros equipos, como los desarrolladores de aplicaciones, probablemente no necesiten aprender todo sobre Kubernetes para ser productivos. Con las abstracciones adecuadas, los desarrolladores pueden interactuar con una plataforma Kubernetes con mayor facilidad, lo que se traduce en menos trabajo y un desarrollo más rápido de las funciones.

¿Qué es una abstracción de plataforma? Es una forma de ocultar los detalles, dejando sólo la funcionalidad necesaria. Al eliminar ciertos detalles, las abstracciones abren nuevas posibilidades, permitiéndole crear conceptos y objetos que tienen sentido para la organización. Por ejemplo, es posible querer combinar todos los recursos de Kubernetes para un servicio en un concepto de «aplicación», o combinar varios clústeres de Kubernetes en un «entorno».

Existen muchas maneras de abstraer una plataforma Kubernetes, desde interfaces de usuario personalizadas, herramientas de línea de comandos e integraciones IDE. Todo va depender de la cantidad de Kubernetes a las que se desee exponer a los desarrolladores.

 

En el blog presentan una demostración  de un flujo de trabajo de desarrollo de extremo a extremo utilizando un conjunto de herramientas amigables de Kubernetes para que lo vayas probando tú mismo.

Más información en Google Cloud Blog.

 

Tags,

Construir una plataforma con KRM: Parte 2 – Cómo funciona el modelo de recursos de Kubernetes

Esta es la 2do. resumen de una serie de varios posts sobre el modelo de recursos de Kubernetes. Consulte el resumen 1 para más información.

En la 1er. resumen se mencionaron algunas características de una buena plataforma para desarrolladores. En este post se presentará el modelo de recursos de Kubernetes (KRM) y analizará cómo el diseño declarativo puede proporcionar una capa base estable para una plataforma de desarrolladores.

Para entender cómo funciona el KRM, es necesario aprender un poco sobre cómo funciona Kubernetes.

Kubernetes es un sistema de código abierto para la automatización del despliegue, ajuste de escala y manejo de aplicaciones en contenedores y permite tratar varios servidores (Nodos) como un gran ordenador, o Cluster. Entre otras cosas auto-programa sus contenedores para que se ejecuten en cualquier nodo que tenga espacio. Todos los Nodos Kubernetes reciben sus instrucciones del plano de control de Kubernetes. Y el plano de control de Kubernetes recibe las instrucciones del usuario.

Google Kubernetes Engine (GKE) es el producto Kubernetes gestionado por Google, y se muestra a continuación su arquitectura.

En el área azul del «plano de control zonal», se puede ver que el plano de control de GKE está formado por varias cargas de trabajo -controladores de recursos, un planificador y almacenamiento backend- y todas las flechas apuntan al servidor de la API.

También mencionan todo sobre la importancia de la API, dan una explicación de la vida de un recurso Kubernetes y muestran un ejemplo de KRM y GitOps trabajando juntos.

Más información en Google Cloud Blog.

Tags,

Anuncian Ubuntu Pro en Google Cloud

En conjunto con Canonical, Google Cloud anuncia Ubuntu Pro en Google Cloud. Es una nueva oferta de Ubuntu para todos los usuarios de Google Cloud. Ubuntu Pro en Google Cloud permite el acceso instantáneo a los parches de seguridad que cubren miles de aplicaciones de código abierto durante un máximo de 10 años y a las características de cumplimiento críticas esenciales para ejecutar cargas de trabajo en entornos regulados.

Google Cloud se ha asociado desde hace tiempo con Canonical para ofrecer soluciones innovadoras para desarrolladores, desde el escritorio hasta Kubernetes y AI/ML. En la línea de esta colaboración, Google Cloud y Canonical han creado un entorno devops más seguro, reforzado y rentable: Ubuntu Pro en Google Cloud para que todas las empresas aceleren su adopción de la nube.

Más información en Phoronix, Google Cloub Blog, Cannonical Blog.

Tags, ,

Construir una plataforma con KRM: Parte 1 – ¿Qué hay en una plataforma?

Esta es la 1er. resumen de una serie de varios posts sobre la construcción de plataformas para desarrolladores con KRM  (Modelo de Recursos Kubernetes).

Se empieza por definir ¿Qué es una plataforma?. Son las capas de tecnología que hacen posible la entrega de software, desde los repositorios Git y los servidores de prueba, pasando por las reglas del firewall y los CI/CD pipelines, hasta las herramientas especializadas de análisis y supervisión, y la infraestructura de producción que ejecuta el propio software.

Pero una plataforma no es sólo una combinación de productos. Son las API, las interfaces de usuario y las herramientas de línea de comandos que se utilizan para interactuar con esos productos, las integraciones y el pegamento entre ellos, y la configuración que permite crear entornos de forma repetible.

Una plataforma debe ser fácil de usar, con abstracciones que dependen del usuario. Debe ser escalable: los recursos adicionales deben poder ser «estampados» de forma automatizada y repetible. Debe ser extensible, lo que permite a una organización añadir nuevos productos a ese diagrama a medida que evolucionan sus necesidades empresariales y tecnológicas. Por último, una plataforma debe ser segura y debe cumplir con la normativa específica del sector y de la zona.

El modelo de recursos de Kubernetes (KRM) es el formato declarativo que se utiliza para hablar con la API de Kubernetes. A menudo, el KRM se expresa como YAML. Kubernetes no es solo el bloque de «computación» en un diagrama de plataforma, sino que también puede ser el potente plano de control declarativo que gestiona grandes franjas de su plataforma. En última instancia, KRM puede acercarle a una plataforma para desarrolladores que le ayude a entregar software de forma rápida y segura.

Más información en Google Cloud Blog.

Tags,