Is Google Kubernetes Engine (GKE) the right fit?

Nowadays every IT organization widely uses the concept of Containers to deploy the applications. Containers have changed the entire virtualization theory by allowing you to run multiple isolated applications on a single hardware, or you can say on the same machine, which in turn helps you use your hardware resources wisely.

Yogesh Golande, Head of Engineering, Sela - Cloud better

When Docker was first introduced in the year 2013 it brought a revolution in the field of using microservices, because it allows us to use the server’s base Operating System to control all the running applications inside the containers and hence make all the containers light-weighted. So when people started using containers in production environments to deploy their applications the result was very good, but providing zero downtime when a container went down was still a headache, as we need to manually spin up a new container to handle this. In such critical situations, you can’t afford an extended downtime because it will cost you a good loss in your business and hence people started thinking about solutions like having a managed containerized platform that can take care of scaling, failover as well and down-scaling when required. And in 2014, Google Engineers came up with the solution that is, Kubernetes (K8s).

Kubernetes is an open-source platform that helps in everything, starting from deploying the application, managing the application, as well as scaling-in and scaling out your application. In simple words, K8s helps in controlling the containerized clusters used for application deployment.

In recent times I guess there are very few technologies that have gained so much success as Kubernetes has, and at the same time is popular among all the IT geeks. But it doesn’t mean that learning K8s is like a piece of cake. There are so many things that you need to be aware of before getting your hands dirty with K8s.

Real-time Benefits of Kubernetes

Let’s see some of the real-time benefits you will get from K8s:

High availability of your applications. You will not even notice a small fluctuation in your containerized infrastructure if some of the nodes go offline.
Consider if your website/application receives high traffic, then the auto-scaling feature of K8s will spin up more nodes or containers to match the traffic.
Using the concept of ‘namespaces’ you can deploy and also separate the services with different teams and their test/dev/prod environments.
K8s can self-heal the cluster. This means if a container stops, then K8s will try to restart it, kill it if the container doesn’t respond, plus don’t expose your application to any user request unless and until the container is up & running to take the incoming requests.

I have often seen people get confused between Google Compute Engine (GCE) Managed Instances & Google Kubernetes Engine (GKE) and consider them the same. But in reality, it’s not. In the coming section, I will brief you about both and also put some use cases to understand them completely.

Google Compute Engine MIGs vs. Google Kubernetes Engine

GCE MIGs

Google Compute Engine is a service in the Google Cloud Platform that allows you to create any number of virtual machines with the option of choosing the hardware resources (CPU, RAM, Hard Disk, etc.) as per your need. You can simply consider it as an Infrastructure-as-a-Service (IaaS) provided by Google.

Using GCE, you can create 3 types of instance groups: Managed stateless Instance Groups (MIGs), the second is Managed stateful Instance Groups and the other is Un-managed Instance Groups. The key difference among both of these is MIGs provide features like autoscaling, auto-healing, multiple zone deployments, etc. since all instances in the managed instance groups run the same image. Unmanaged instance Groups only help you load-balance the requests across multiple VMs since the instances in an unmanaged instance group could have different images. For this blog’s sake, we will focus only on MIG’s.

When to choose MIGs?

Following are some of the topmost use cases of using MIGs,

If your website or application is frequently receiving high traffic then you don’t have to worry about that, as MIGs can auto-scale your infrastructure when a certain metric condition is met. Like for example, in the below screenshot, you can see when the CPU usage goes above 60% then MIGs will auto-scale as per the configuration.

Screenshot A

MIGs can be best suited for applications where containerization and subsequent running-in GKE is not an option, however, auto-scaling is desirable. This could happen if the application is a legacy application and the time needed to modernize it is not available. In the case of legacy applications, based on whether the application is stateful or stateless, various deployment options are available.
Compared with security, GKE security namespaces do not provide more isolated security features like GCE instances because GKE uses the same kernel and that’s the reason the root has access to any namespace.

Google Kubernetes Engine (GKE)

Google Kubernetes Engine is a managed Kubernetes service where your Kubernetes components are provided out of the box. GKE also provides services such as centralized logging and monitoring with Google Cloud’s Operations suite, automatic upgrade of cluster nodes software, and node pools for additional flexibility

GKE provides horizontal and vertical scaling that dynamically adds and removes nodes to

A pool which it calls the cluster auto-scaler. The cluster auto-scaler is going to add or remove nodes as needed based on the resource requests that we have for our pods.

The screenshot below gives us some parameters that are used to configure the auto-scaling of a cluster.

When to use GKE?

Below are some of the reasons to go with GKE,

GKE is the go-to option for a microservices-based application since it gives fine-grained control over scaling. The most frequently used services can scale faster and be given more resources than services that are not as popular.
A complex application with numerous smaller parts that need to communicate with each other, and need to scale differently. GKE is best suited as GKE Pods contain one or more containers When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod’s resources. Pods also contain shared networking and storage resources for their containers.

Cost Comparison Between GCE and GKE

GCE Pricing

Calculating or getting an estimated cost of running VMs on a Google Compute Engine depends upon many aspects. Like,

The machine type that includes some CPU and size of memory you require to create your VMs
Price also varies if you are using sole tenant nodes instead of Multi-tenant hosts.
Premium OS images will also incur some additional costs.
The size and type of disks attached to VMs will also add to your cost.
If you are using Custom Images to create your VMs then it will incur a storage cost to you.

So, depending upon all the above, the cost of GCE will vary.

GKE Pricing

Cost for GKE also depends upon many aspects like,

A cluster consists of worker nodes, which are priced at regular machine instance prices. The machine type includes the number of CPUs and the size of the memory.
The number of clusters you are using for your deployments. Google charges $0.10 per cluster/hour and makes it a cluster management fee, which means they will give you almost 100 % assurance for the availability of your clusters.
Also Few other things like networking and resource location.

You can also calculate your cost estimation for GCE & GKE from here.

Given that there is a cost overhead with GKE, should GKE be a choice for choosing a scalable platform?

As mentioned above, GKE allows for fine-grained control over scaling pods. If nodes are under-utilized, and all Pods could be scheduled even with fewer nodes in the node pool, Cluster auto-scaler removes nodes, down to the minimum size of the node pool. This brings in far more efficient use of resources and thus in the long run makes GKE cost-effective.

Performance Comparison

When it comes to performance, Google Kubernetes Engine (GKE) is far better than Google Compute Engine (GCE) to deploy the applications.

GCE VM security and updates are up to you. On the other hand, if there are any updates or patches for GKE it will automatically get pushed to the cluster.
GKE comes with more automation and management baked in.
Running each microservice on a separate virtual machine (VM) on Compute Engine could make the operating system overhead a significant part of your cost.
Google Kubernetes Engine lets you deploy multiple containers and groups of containers for each VM instance, which can allocate host VM resources more efficiently to microservices with a smaller footprint.
GKE Sandbox provides a second layer of defense between containerized workloads on GKE for enhanced workload security. GKE clusters natively support Kubernetes Network Policy to restrict traffic with pod-level firewall rules.
Scaling / down-scaling of application containers works faster automatically handled by Kubernetes Engine. This feature is not there in GCE.
GKE provides managed DNS for resolving service names and for resolving external names.

Deploying New Features

New feature deployment is one of the plus points of GKE, as this feature is missed in GCE. Because GKE has the ability to roll out the new changes with zero downtime and hence it gives IT geeks the freedom to add new features/functionalities to their applications/websites on the go.

GKE will allow you to roll out new updates without impacting the running deployment. It will first spin a container of new deployment (rollout update) and if all goes well then it will spin up more containers and gradually destroy the containers of the previous deployment. Similarly, after the rollout of a new deployment if you see bugs in your website/app, then GKE also has the ability to roll back to the previous release of deployment in the blink of an eye.

Applications Suitable for K8s Deployment

Below are some of the suggestions where we can take the benefit from K8s,

K8s is mostly useful for microservices applications where the application is built as a suite of modular services. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services.
The applications such as E-commerce apps and websites consist of several modules. Define each module as a separate loosely coupled service depending on the requirement, which may collaborate based on the scenario.
Applications that provide Online streaming and online gaming platforms can also make use of K8s.

The above three points are showing where K8s is best suited. But I will also share a few moments where K8s could be overkill.

K8s is expensive for small applications to host. To take advantage of GKE resiliency you need additional nodes above the minimum amount required to run your application. If a node is down, the requested pods will be relocated to the available nodes. For production workloads, at least three nodes are recommended for resiliency.
K8s is complex to start with, so if you are planning to move your applications on a containerized platform then make sure to hire the right resource to work with K8s, as migrating from a traditional setup to K8s is very challenging.

Endnotes

Containerized applications are one of the hottest topics in the current market, so is the Kubernetes and its managing platforms like Google Kubernetes Service (GKE), AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS).

It’s easy to start with K8s, but having the ability to provide real-world solutions becomes a bit tricky. Building a strategy to use the K8s and any of its managing platforms as per your needs requires extensive knowledge of K8s, which you will only get by deep diving.