Autoscaling an Instance Group with Custom Cloud Monitoring Metrics
Theory
Application architecture
The autoscaling application uses a Node.js script installed on Compute Engine instances
The script reports a numeric value to a Cloud monitoring metric
In response to the value of the metric, the application autoscales the Compute Engine instance group up or down as needed
The application includes the following components
Compute Engine instance template -=> A template used to create each instance in the instance group
Cloud Storage -=> A bucket used to host the startup script and other script files
Compute Engine startup script -=> A startup script that installs the necessary code components on each instance
Compute Engine instance group -=> An instance group that autoscales based on the Cloud monitoring metric values
Compute Engine instances -=> A variable number of Compute Engine instances
Custom Cloud Monitoring metric -=> A custom monitoring metric used as the input value for Compute Engine instance group autoscaling
Creating the application
Uploading the script files to Cloud Storage
Create a bucket
Creating an instance template
Creating the instance group
Verifying that the instance group has been created
Verifying that the Node.js script is running
Configure autoscaling for the instance group
Watching the instance group perform autoscaling
Setting up Jenkins on Kubernetes Engine
Prepare the Environment
Creating a Kubernetes cluster
Configure Helm
Configure and Install Jenkins
Connect to Jenkins
Deploying a Fault-Tolerant Microsoft Active Directory Environment
Theory
Google Cloud with Microsoft Active Directory (AD), SQL Server, and Internet Information Services (IIS)
Set up a redundant pair of Windows Domain Controllers (DC) with AD using a new Virtual Private Cloud (VPC) network and multiple subnets
Creating the network infrastructure
Creating the first domain controller
RDP into your instance
Copy and paste with the RDP client
Navigation menu > Compute Engine > VM Instances
RDP
Creating the second domain controller
Testing the installation
Deploying Memcached on Kubernetes Engines
Theory
Memcached is one of the most popular open source, multi-purpose caching systems, It usually serves as a temporary store for frequently used data to speed up web applications and lighten database loads
Memcached has two main design goals
Simplicity: Memcached functions like a large hash table and offers a simple API to store and retrieve arbitrarily shaped objects by key
Speed: Memcached holds cache data exclusively in random-access memory (RAM), making data access extremely fast
Memcached is a distributed system that allows its hash table capacity to scale horizontally across a pool of servers
Each Memcached server operates in complete isolation from the other servers in the pool
Scheme guarantees the following conditions
The same server is always selected for the same key
Memory usage is evenly balanced between the servers
A minimum number of keys are relocated when the pool of servers is reduced or expanded
Deploying a Memcached service
Configure Helm
Discovering Memcached service endpoints
Implementing the service discovery logic
Enabling connection pooling
Deploy Mcrouter
Reducing latency
Colocating proxy pods
Configure Application Pods to Expose the Kubernetes Node Name as an Environment Variable
Connecting the pods
Running Dedicated Game Servers in Google Kubernetes Engine
Theory
Containerizing the dedicated game server
Creating a dedicated game server binaries container image
Create a VM instance
Install kubectl and docker on your VM
Download the Game Server Demo
Creating a dedicated game server binaries container image
Prepare the working environment
Generate a new container image
Generate an assets disk
In most games binaries are orders of magnitude smaller than assets
It makes sense to create a container image that only contains binaries; assets can be put on a persistent disk and attached to multiple VM instances that run the DGS container
Connect to the Asset Builder VM Instance using SSH
Format and Configure the Assets Disk
Setting up a Kubernetes cluster
Creating a Kubernetes cluster on Container Engine
The number of vCPUs you'll run on each machine is largely influenced by two factors
The largest number of concurrent DGS pods you plan to run
Your VM instance granularity
Configuring the assets disk in Kubernetes
Configuring the DGS pod
Managing the dedicated game server process
Setting up the scaling manager
Configure the Openarena Scaling Manager Deployment File
Scaling nodes
Testing the setup
Requesting a new DGS instance
Connecting to the DGS
Testing the scaling manager
Distributed Load Testing Using Kubernetes
Theory
System under test
The application exposes basic REST-style endpoints to capture incoming HTTP POST requests (incoming data is not persisted)
Example workloads
Devices first register with the service and then begin reporting metrics or sensor readings, while also periodically re-registering with the service
Container-based computing
A container cluster consists of at least one cluster master and multiple worker machines called nodes
These master and node machines run the Kubernetes cluster orchestration system
A pod is one or more containers deployed together on one host, and the smallest compute unit that can be defined, deployed, and managed
A Deployment controller provides declarative updates for Pods and ReplicaSets
Get the sample code and build a Docker image for the application
Deploy Web Application
Deploy Kubernetes Cluster
Load testing master
Deploy locust-master
Load testing workers
The Locust workers are deployed by a single deployment that creates multiple pods
Deploy locust-worker
Scaling up the number of simulated users will require an increase in the number of Locust worker pods
