{{announcement.body}}
{{announcement.title}}

Kubernetes Accelerator Helps in All Phases of Kubernetes Adoption

DZone 's Guide to

Kubernetes Accelerator Helps in All Phases of Kubernetes Adoption

In this article, we discuss how a Kubernetes accelerator can help in all phases of Kubernetes adoption, as it significantly decreases complexity.

· Cloud Zone ·
Free Resource

A Kubernetes accelerator tames a lot of the Kubernetes' complexity. Complexity is one of the biggest barriers to organizations using Kubernetes in general.  Even if tech groups like what Kubernetes can do, the inherent complexity in Kubernetes puts off a lot of organizations. When more engineers and organizations can smooth out a lot of those pain points, there will be even greater adoption of Kubernetes.

Kubernetes modules are configured both to run individual nodes as well as clusters of nodes, allowing users to choose which arrangement they want. Kubernetes will orchestrate all of them just fine.

Here is an example: We bought a bunch of instances. We bought a bunch of compute on AWS, and we wanted to instantiate those by creating nodes, each with their own characteristics on where to get data, which database to use, etc. Kubernetes clusters also have their own individual control software that we used. We could have also used Helm. 

We configured resource utilization, so that if we got above a 50% of CPU utilization, we automatically spun up another node to offload some of the workload so that no individual instance gets too bogged down. That can be configured automatically, whether it's CPU usage, RAM usage, or other services. 

There are lots of different metrics you can configure with an accelerator. It allows us to just look at the console and see whether we’ve got 25 nodes because of a bunch of applications, or one big application. When we use Docker, that is where Kubernetes really shines because we have Docker images and can easily load the Docker images into the cluster.

Now the thing with EKS as opposed to something like Fargate, is that the biggest difference there is with EKS, is that you must specify various things using YAML configuration files. It's called a ConfigMap file, which basically tells EKS how you want to do various things. But with Fargate, a lot of that is managed for you. So you could just give a Fargate a Docker image, and it will automatically run it. The use case really depends on how much individual level of control you want. 

EKS is more suited for organizations that have dedicated ops teams and that know how to manage all the complexity of Kubernetes. Because it can be very quickly not be simple depending on what you are doing. So, if you are not careful, you will really have to put a leash on it.

Depending on whether you want to run multiple clusters or not, it depends on which sort of modules you enable. An accelerator automatically provisions Kubernetes nodes in EKS, and then once those are provisioned, you get a ConfigMap file that you could use to automatically configure many things. So you can get up to speed with Kubernetes in 15 minutes.

We use a lot of Terraform, and most people using EKS to have a lot of control over what nodes are doing. Out of the box, if you spin up a cluster through the AWS console, you just get a cluster, but you don't really get a whole lot of knowledge about what to do with it.

But, with a Kubernetes accelerator, a lot of those questions are solved for you because we've done a lot of the work to specify how many CPUs are needed per cluster, how much RAM, etc. It's configurable so whatever resource usage typically fits your application, you can configure that. It does not come out of the box with just a normal EKS filter because it has the groundwork for that configuration for you.

An accelerator should help install and implement Kubernetes because it provisions a cluster, and you can configure it automatically to your liking. It spins up a cluster and because you can specify resource usage, you can configure automatically as you're deploying the cluster, rather than just deploying kind of a blank cluster and having to do a lot of configuration after the fact.

A Kubernetes accelerator should help you when you first decide to use Kubernetes, to set up Kubernetes, when you are using Kubernetes. It should save substantial time.

Since writing good YAML files can take a day or two, by using the defaults in the accelerator, instead of taking a day, you can be up and running in 20 minutes. It's a good reason to want to use Kubernetes because now it's super easy.  Here’s a specific example of why.

Example cluster config: resource "aws_eks_cluster" 

Properties files


 Example ConfigMap YAML:

YAML

 

Look for integration with ECR, which is the Elastic Container Registry. If your application is already running inside of it, is already containerized. You can do a pretty impressive automatically loaded Kubernetes because all you have to do is load your image into ECR, and then once it does that, it'll give you a URL. It will give you a container URL that you can plug into EKS, and that will automatically have everything running as you deploy your stuff.

If you have the usual Kubernetes kind of dashboard or control panel and managing clusters, and you are already good at fine-tuning, an accelerator should also help you. If you know you need to expand, it will help you expand faster, and if you know you need more than one cluster, it should definitely help you as well.

If you are already managing existing clusters, you can specify a lot of the configuration options through the YAML file, and it will automatically manage that for you in code rather than you as the DevOps person having to manually go into the AWS console and do various things. One issue that engineers will have to be aware of is that provisioning a cluster, while easy, if using Terraform, can take a long time to provision successfully by AWS. It has been our experience that provisioning often takes 15-20 minutes so engineers should be aware of this. This is an AWS limitation and not the result of having used Terraform.

All the options that you would typically specify in the console are configurable in the YAML file. So whatever options are supported in the console are supported in that YAML file. This means you do not have to leave Kubernetes and go to AWS in order to specify some things.

And you also simplify your version control because it is easier to manage changes. You can make a change and then commit it to a repository, and then have it so that all your team knows how to manage all of that from one place. Because an accelerator leverages infrastructure as code, it is much easier to centralize and manage all the different options that DevOps people need to manage various things. 

The biggest barrier to organizations using Kubernetes in general is the time cost. Even if they like the idea of what Kubernetes does, the inherent complexity that can arise in Kubernetes, puts off a lot of organizations. And the more people, the more organizations like us can smooth out a lot of those pain points, I think will really drive greater adoption of Kubernetes both now and in the future.

Please contact us for access to the repository which you can find at: https://github.com/xOpsOSS/terraform-accelarators.git 

Topics:
devops and cloud ,devops complexity ,infrastructure as code ,kubernetes ,kubernetes and azure ,open source ,open source automation ,sre tools

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}