Developer’s Guide to operate game servers on Kubernetes – Part 2

TutoSartup excerpt from this article:
Game server infrastructure has reached a critical inflection point… Open-source game servers using Amazon Elastic Kubernetes Service: Agones and Open Match Open-source game server technologies like Agones and Open Match are revolutionizing the way developers manage and scale their game infrastru…

Game server infrastructure has reached a critical inflection point. Traditional virtual machine deployments are no longer sufficient for today’s dynamic gaming environments that require live operations with fast, frequent, and efficient updates. Modern technologies, like Kubernetes, are empowering game operations teams to be efficient.

Part 1 of this blog series explored how containerization and Kubernetes on Amazon Web Services (AWS) revolutionizes game operations with scalable solutions. Part 2 of this series extends the containers theme to describe two technology solutions leveraging Kubernetes to provide powerful and practical solutions for today’s game developers. Enter Agones and Open Match: open-source frameworks offering infrastructure abstraction, cost optimization, and accelerated development cycles while permitting teams to have complete control of their architecture.

Open-source game servers using Amazon Elastic Kubernetes Service: Agones and Open Match

Open-source game server technologies like Agones and Open Match are revolutionizing the way developers manage and scale their game infrastructure.

Agones abstracts game servers as Kubernetes objects, simplifying management and scaling processes. This is a game-changer for developers who are DevOps and GitOps enthusiasts. Agones offers an out-of-the-box game server orchestration system to enable live operations for games—a key advantage to developers.

Whether a tool like Argo CD or Spinnaker is being used to roll out game server patches, blue/green deployments, or canary deployments, Agones makes these processes smoother by extending Kubernetes for game server management. This extension includes centralized fleet control, container lifecycle management, and game servers SDK integration.

Open Match complements Agones by providing an open-source matchmaking framework that integrates with the game server management system. Developers looking to build custom matchmaking strategies can do so with Open Match using Go to define matchmaking functions and orchestrate custom scenarios with ease. The ability of Open Match to scale proportionally with the Kubernetes cluster ensures it can handle large player volumes.

When used in tandem, Agones and Open Match unlock the potential for sophisticated multi-region architectures and player-game server allocation strategies. This combination enables game operation teams to route players to the optimal-performing game server locations. This is based on the players’ geographical positions or other gaming characteristics, such as skills level, latency, and gaming preferences. While there are infrastructure costs associated with deployment and operation, the open-source nature of both Agones and Open Match translate to substantial cost savings for game developers and publishers.

It is crucial to note that leveraging these technologies effectively requires a solid foundation in container technologies. Game developers should be comfortable with how game server containers work, how they are built, and the intricacies of their deployment. A good understanding of Kubernetes is essential, including how Amazon Elastic Kubernetes Service (Amazon EKS) clusters should be designed to host game servers.

How to get started

The Guidance for Game Server Hosting Using Agones and Open Match on Amazon EKS document states how to streamline the deployment and management of game server infrastructure. Through this Solutions Guidance, developers can create a robust, scalable game server hosting environment on Amazon EKS that incorporates best practices with key AWS services.

The diagram following describes the solution architecture.

Diagram illustrating game server allocation and matchmaking process using AWS services: 1.Players connect to AWS Global Accelerator endpoint for match allocation. AWS Shield mitigates threats. 2.Request is routed through Network Load Balancer to Frontend container. 3.Director container processes match requests. Amazon CloudWatch monitors this process. 4.Match Making Function groups player tickets and returns a match ticket. 5.Match allocation is requested from Agones Allocator Service, potentially specifying different regions. 6.If Region 1 has the lowest latency, a game server is allocated there. 7.Otherwise, request is routed to Region 2 via VPC Peering and Classic Load Balancer. 8.Internal IP and port of game server are returned to Director container. 9.	IP and port are translated to AWS Global Accelerator address and port and sent to Frontend. 10.	Connection details are sent back to players. 11.	Players connect to game server. Amazon GuardDuty monitors EKS for suspicious activity. 12.	Connection is routed to allocated game server container. This Process showcases AWS global infrastructure for gaming, including matchmaking, cross-region allocation, and security measures.

Figure 1: Agones and Open Match deployment on Amazon EKS.

To deploy the solution, clone its GitHub repository and follow the README instructions. It leverages Infrastructure as Code (IaC) through HashiCorp Terraform and enables version control, automation, and consistent multi-environment deployments. The Terraform templates will deploy two Amazon EKS clusters in two regions.

Figure 2 shows the Terraform code used for in The Guidance for Game Server Hosting Using Agones and Open Match on Amazon EKS. The code begins by defining environment variables for the Amazon EKS clusters. Then it initializes terraform and deploys the terraform templates with the provided environment variables to create two Amazon EKS clusters each in us-east-1 and us-east-2 regions.

Figure 2: Terminal commands setting environment variables, initializing Terraform, and launching a Terraform template to create multiple clusters in separate AWS Regions.

This pattern is necessary for the creation of a highly available game server infrastructure that can serve players globally, reduce latency and enhance player experience.

The Terraform code provided in the solution is based on the Amazon EKS Blueprints for Terraform. This was introduced in Part 1 of our blog series. The Amazon EKS Blueprints provide production grade templates for clusters creation, extensibility, and team-based access controls.

Agones, for game server orchestration, and Open Match, for matchmaking, are managed with Helm Charts to facilitate customization and upgrades. The multi-Region architecture is based on AWS Global Accelerator acting as edge entry point to the solution, AWS Shield for Distributed denial of service (DDoS) protection, AWS Key Management Service (AWS KMS) for encryption, Amazon CloudWatch for monitoring, and Amazon GuardDuty for security.

The solution can be used with services like AWS CodeBuild or AWS CodePipeline to improve the developer experience on AWS. DevOps frameworks like Spinnaker and Argo CD can also be used to enable advanced deployment techniques.

Optimize Amazon EKS hosting costs with AWS Graviton Processors

To further reduce costs, consider running certain workloads on AWS Graviton processors. With Graviton, workloads can achieve up to 40 percent better price-performance compared to traditional x86-based EC2 instances. The Solutions Guidance offers support for deploying the Agones system and Agones game servers on arm64-based instances. A Terraform variable can be set at the command line to choose the compute architecture to use for Amazon EKS managed node groups.

Disclaimer: Running Agones and Open Match on arm64 processors is currently in Alpha. The Agones project has an official arm64-based image, and the Open Match project has the resources necessary to build an arm64-based image.

Best practices

Running a production-grade Amazon EKS cluster requires expertise in many areas (security, observability, cluster upgrades), all of which cannot be covered in this blog. The Solutions Guidance is designed to incorporate AWS Best Practices and Well-architected Framework Pillars into an architecture for hosting containerized game servers. In addition to the general Amazon EKS Best Practices, Best Practices of Running Agones, and the Best Practices of Running Open Match, there are a few additional best practices related to the Solutions Guidance.

First, as recommended in the Amazon EKS Observability Best Practices Guide, decrease the unnecessary noise by using the right logging level. Limit the generation of verbose logs to monitor the health of the application. Containerized applications go through lifecycle activities that can lead to increased log outputs, creation, and deletion of resources. These activities can lead to higher costs for security services like Amazon GuardDuty (when monitoring for threat protection) and AWS Config (when evaluating resource configurations).

Second, implement a node autoscaling solution to dynamically adjust game server node size based on fluctuating demand. Amazon EKS offers Cluster Autoscaler or Karpenter for this purpose. The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in your cluster when pods fail or are rescheduled, confirming optimal resource utilization. Karpenter is a high-performance autoscaler that launches right-sized compute resources in response to changing application load in under a minute. It creates new nodes when existing ones can’t accommodate pods, consolidates workloads for efficiency, and removes unnecessary nodes. Currently, the Solutions Guidance deploys Cluster Autoscaler, with future plans to provide options for Karpenter.

Third, benchmark resource reservation for specific workloads. Different workloads have different resource requirements. Kubernetes allocates the requested resource reservation amounts to pods, and if those resource requests don’t match actual utilization, Kubernetes will either under or over-allocate resources. Matching resource reservations close to what applications need will improve overall node utilization.

Fourth, protect active game sessions from unexpected disruptions. Agones offers a powerful feature to control pod eviction at the GameServer object level, verifying that live game sessions aren’t abruptly terminated. By setting the eviction.safe parameter to “Always” or “Never” in the Fleet manifest, game server pods can be fine-tuned in how they behave during cluster events. This works well in harmony with Kubernetes taint-based eviction, providing a robust defense against unwanted pod terminations and node scale-downs.

Fifth, protect the game infrastructure running on Kubernetes against layer three and four DDoS. The Guidance deploys AWS Global Accelerator to create a performant and secure infrastructure. Global Accelerator reduces the latency for player connections while providing fine-grained control over traffic flows. In addition, it benefits from AWS Shield Standard protection to mitigate distributed denial-of-service attempts. It does this while allowing valid traffic from safe game clients to flow through the accelerator and reach game servers or matchmaking functions running in private subnets. Advanced attack patterns can be prevented by adding accelerators created through Global Accelerator as protected resources in AWS Shield Advanced.

It is always helpful to stay up-to-date on any best practices.

Conclusion

Agones and Open Match offer a flexible approach for game studios seeking to leverage Kubernetes’ agility while minimizing infrastructure costs. To harness the power of these tools, organizations should foster a culture that advocates for the use of cloud-focused and open-source frameworks. This approach encourages the effective use of containers and promotes innovation and frugality in game server management. By embracing these technologies, game developers can create more robust, scalable, and cost-effective multiplayer experiences for their players.

This blog only covers the steps to get started. In the next publication we will explore how you can implement observability, build games analytics, enhance security measures, and integrate additional built for the cloud frameworks to evolve the solution.

If you are interested in running game servers as containers on AWS with Kubernetes, contact us through our games landing page.

Further reading

Developer’s Guide to operate game servers on Kubernetes – Part 2
Author: Serge Poueme