AWS, Kubernetes

"We can hardly contain ourselves."

With this epic email tagline Amazon announced that Elastic Kubernetes Services, their managed Kubernetes offering, is generally available for public use! 

In this article, I'll explore what EKS is and what this announcement means for your digital transformation efforts.

What is Kubernetes?

Kubernetes is a clustered, open-source system for managing containerized applications at scale. It is inspired by Borg, Google's container orchestration system, which is used to host almost all of the Google applications that you use on a daily basis. Like Borg, Kubernetes is designed for massive scalability: companies such as OpenAI and Huawei are using over 2,000 Kubernetes nodes to manage tens of thousands of containers per day! Kubernetes is also flexible enough to support several use-cases, from stateful, long-lived databases to extremely-ephemeral serverless workloads.

What is Elastic Kubernetes Service?

Amazon's Elastic Kubernetes Service is a managed Containers-as-a-Service offering that significantly simplifies the deployment of Kubernetes on AWS. With EKS, you simply create your own Kubernetes workers through the EKS Wizard. Creating the Kubernetes master cluster and configuring networking, service discovery and other Kubernetes primitives is done for you.

EKS is meant to be a turnkey drop in for custom Kubernetes clusters. Most existing tooling works with EKS with little to no modifications. What's more, HashiCorp just released a Terraform resource to make creating and managing EKS clusters even simpler.

How does this compare to running my own Kubernetes cluster?

Many organizations have invested significant amounts of time in developing their own on-premise or cloud-based Kubernetes clusters. The usual advantages of rolling-your-own-cluster are ubiquitous: you can configure your Kubernetes masters as you wish and use whatever version of Kubernetes your organization needs (EKS supports Kubernetes 1.10.3 and above), etc. Depending on the amount of prior investment spent and/or organizational requirements, some companies might stand to benefit from the knowledge and skills gained from this experience.

However, those that have not yet managed or are just starting to manage their own Kubernetes might come to find that doing so is difficult and time-consuming. While Kubernetes does come with its own management UI, many of its internals are configured via YAML files and command line tools. Furthermore, Kubernetes is made up of many small services, such as etcd for service discovery and cluster management, networking overlays to manage how traffic goes from and to containers and internal Kubernetes services for general cluster management. Many things can (and do) break, and time spent on troubleshooting those issues is time spent away from making operations more accessible to development teams.

Organizations just getting started with Kubernetes will likely see faster uplift by using EKS to manage their first Kubernetes clusters, pushing its limits to see how adaptable the service is for their use cases and provisioning their own clusters when those limits are reached. Organizations that are not at all interested in maintaining their own container infrastructure will see even bigger wins by using ECS Fargate instead.

Moving to the cloud?

What is a cloud operating model and why do you need one?

Find out how to design and operate a cloud operating model with Ben Wootton, Contino CTO and Co-Founder

Read More

While this service will certainly help many organizations onboard core workloads into the cloud more quickly than before, there are several ways to get to Kubernetes that might better fit your needs.

So let's compare EKS to Amazon Fargate and other container orchestrators. 

ECS Fargate and Kubernetes are both excellent solutions for providing turnkey, self-service container orchestration on AWS. However, there are notable differences between the two that are worth understanding before embarking on your journey.

The biggest difference is in the additional infrastructure required to get going. While EKS still requires creating and managing additional EC2 instances, ECS Fargate is completely standalone and requires no additional infrastructure. Developers simply create their task definitions, specify that they want to use Fargate, create the Fargate clusters with Terraform or similar and deploy --- no infrastructure management required.

However, what EKS lacks in simplicity on this front is reclaimed by the vast library of Kubernetes-specific tooling, automation and support communities it inherits. Kubernetes is one of the most popular open-source projects in the world at the moment. Almost every Fortune 500 organization is experimenting with or using it for live workloads. Most importantly, EKS offers a (thin) migration strategy for customers who might want to consider distributing their Kubernetes clusters across clouds or create a hybrid with their on-premise clusters.

Another big difference between the two services is cost. EKS costs $0.20/hour to run, consumption of other AWS services (ELB, Route53, S3, etc.) notwithstanding. This price also does not include the cost of the worker nodes themselves; consequently, you will need to factor EC2 and EBS costs into your cost projections for your EKS projects. (Note: While this is currently in debate, Kubernetes best practice recommends using an EC2 instance size of t2.large or greater. If you would prefer to not worry about CPU credits, consider using a m4.large instead.) However, those prices allow you to run as many containers as your cluster can fit. As well, there exist many strategies for optimizing EC2 and EBS spend, which can bring that auxillary spend down further.

On the other hand, ECS Fargate, as discussed in another blog post, costs a flat rate of $0.0506/hour/vCPU and $0.0127/hour/memory consumed, AWS service consumption costs notwithstanding. No other infrastructure is required to use ECS Fargate. Consequently, the operational cost of using Fargate scales linearly in proportion to the number of Fargate containers, or tasks, you create. Fargate can become expensive quite rapidly.

How does this compare against other container orchestrators?

While Kubernetes is extremely popular in the container orchestration space, there are several other orchestrators worth discussing.

"Classic" Amazon ECS, or EC2 Container Service, is Amazon's initial clustered Container-as-a-Service offering. It leverages EC2, Docker and a home-grown, Python-based client for moving containers from node to node. While ECS is slightly cheaper in that you only pay for the AWS resources that you use, EKS subsumes most of its feature set while providing more flexibility around the application-container relationship, a more widely-supported solution and maintaining its relationship with other AWS services. We recommend that organizations strongly consider EKS for their container platform before looking into classic ECS.

Docker Datacenter is Docker's enterprise offering for a Docker-native container orchestrator. Its biggest advantages over Kubernetes and EKS lie in its simple setup process and tight tie-ins with the Docker command line tool and Docker Compose deployment format. However, it does not offer any native tie-ins with AWS services, lacks flexibility around networking and service discovery configurations and has fewer case studies backing its use within the enterprise. Additionally, Docker is a smaller organization than AWS and AWS Professional Services, which can make obtaining support more difficult. Lastly, Kubernetes has several years of experience in high-scalability container management backing it and is the more mature product.

HashiCorp Nomad is HashiCorp's container orchestrator. Unlike Kubernetes and Docker Datacenter, Nomad focuses solely on container placement. It works closely with its other products (Consul for service discovery and Vault for secrets management) to fill in the gaps. Installing Nomad is as simple as downloading the binary onto nodes that will manage containers and telling it where its configuration file lives. Furthermore, HashiCorp offers an enterprise variant that provides additional features such as a UI, role-based access control and enhanced auditing.

(If you're interested in the pros and cons of different container management tools, you might benefit from having a look at the various Container Management Debates that Contino has held across the world in London, Sydney and Melbourne. Across these debates we pitch Kubernetes, Rancher, AWS ECS, HashiCorp Nomad, Mesosphere and Docker Swarm against each other!) 

While its setup simplicity is quite lucrative, Kubernetes provides significantly more flexibility around how containers and applications relate to each other and how those containers should be accessed. As well, it has a significantly larger working community behind it.

I use Cloud Foundry? How does this affect me?

Cloud Foundry is designed to allow developers to deploy applications onto any platform supported by BOSH. Additionally, BOSH has had native support for Kubernetes since last year, so it is expected that the work required to use EKS in its place is minimal. We anticipate that using EKS in conjunction with Cloud Foundry will make it even easier for engineering teams to spend less time worrying about their infrastructure and more time shipping software faster.

Conclusion

EKS is an exciting new service offering by Amazon that aims to make running containerized workloads in Kubernetes easy, quick and relatively cost-conscious. While you still bring some of your own infrastructure to make it work, the hardest parts of managing a Kubernetes cluster on AWS are managed for you without sacrificing its power and flexibility. What's more, you can use your existing Kubernetes-focused tools to manage your EKS clusters with little to no modification.

If you've long wanted to try Kubernetes on AWS without worrying about the operational overhead involved, your time has come! Get started here!

  • Carlos Nunez

    Technical Principal

    Carlos Nunez is an Amazon Web Services certified Technical Principal with over 10 years of technology experience across the Financial, Insurance, and IT verticals. For the last five years, Carlos's mission has been to help transition every company into a software company through highly automated infrastructure, bridging the gap between software and systems, and enabling enterprises to drive their decision making through fast, data-driven feedback. He has executed on this through migrating enterprises onto public cloud providers and private clouds, using continuous delivery and infrastructure as code to test and deploy physical and virtual infrastructure just like any other software project and evangelizing the DevOps culture and Site Reliability Engineering principles through blog posts and talks.

    More Articles by Carlos