Offloading K8s

16. December 2018 2018 0

Container Origins

Container is, by no means, a new concept. While Docker should and gets credit for popularizing it, the concept dates all the way back to the 1970s through the birth of the chroot system call. chroot is a way to isolate a process (and its children processes) from the rest of the system. Through this approach a program (process) can be run in a modified environment that is confined (sandboxed). A few decades later, in the 2000s, BSD jails, Solaris zones and Linux Containers (LXC) served as the manifestation of progress. Containers provide virtualization at the operating system level. Since containers share the kernel, aka operating system, container start times are rapid, in seconds, with a small footprint, in megabytes. Virtual machines (VM), an alternate virtualization construct require the full operating system. This contrast is exactly what makes containers so light weight compared to VMs. Consequently, this is one of the fundamental reasons why containers became the evolutionary successor to VMs.

Container Fascination

When an application is packaged into a container, it includes the application and its dependencies. Therefore, such a containerized application essentially becomes portable and resource efficient. This also makes the sandboxed application consistent regardless of where it is deployed, one of the hallmark benefits. With monoliths giving way to microservices in the cloud era, this transition played neatly into the hands of containers where developers could package small microservices based cloud native applications.

Container Orchestration

As containers became popular, it led to the next question of managing them efficiently. Managing containers at scale became a challenge that different groups strived to solve. Until last year, there were different products wanting to become the coveted industry darling. The battle was mainly among Docker Swarm, Apache Mesos and Kubernetes. Even though there was separation emerging in adoption numbers, the debate had not really been won. 2017 finally settled the debate with Kubernetes (K8s) winning the Container Orchestration Battle. One of the salient reasons for the win was the community support behind Kubernetes. The trigger was Google relinquishing control by donating [2] it to the open source community’s Cloud Native Computing Foundation (CNCF). The evidence of victory lies in the announcements made by various cloud vendors last year.

  1. Azure Kubernetes Service (AKS) became GA in October 2017.
  2. Pivotal Container Service (PKS) announced at 2017 VMWorld.
  3. Amazon Elastic Container Service for Kubernetes (EKS) announced at 2017 ReInvent.

Amazon EKS

After much anticipation, Amazon Elastic Container Service for Kubernetes (EKS) was announced at re:Invent 2017. While it could be argued that this Managed Kubernetes Service will end up cannibalizing AWS’s native Elastic Container service (ECS), it speaks to Amazon’s commitment to customer obsession [3].

EKS is currently available in the following regions with Ohio being the fourth and latest addition as of last month [4].

  1. North Virginia
  2. Oregon
  3. Ohio
  4. Ireland

The value proposition of EKS is to offload management of the Kubernetes cluster. With the Kubernetes masters deployed across multi AZ environment, it provides the requisite resiliency. As the underlying masters’ infrastructure is managed by AWS, version upgrades and patching are automatically managed by AWS. Secondly, this allows integration of Kubernetes clusters with the rich AWS ecosystem.

EKS pricing model has two components.

  1. Cost of EC2 servers by the minute.
  2. Cost of Control Plane by the hour.

EKS introduces a concept of platform that is meant to easily identify enabled features of the cluster. While EKS currently supports Kubernetes 1.10, it should be noted that 1.12 is the latest Kubernetes version and 1.13 is expected to be released [5] around this year’s KubeCon (Dec 10-13).

AWS Fargate

While EKS announcement at last year’s reInvent wasn’t particularly a surprise, there was another service that came out of the blue. The unexpected announcement was Fargate; a managed container service married to the serverless paradigm. In this service, AWS abstracts away the infrastructure, thereby entirely relieving customers from having to manage the underlying infrastructure.

Interestingly, Fargate only supports ECS at this point but it is a given that running Kubernetes without managing infrastructure is on the road map. This will allow AWS to offer a complete Container as a Service offering (CaaS).

Container as a Service

CaaS, through Fargate, serves another huge goal of AWS that ties back to Lambda. Back in 2014 reInvent, when Lambda was announced it generated fervor with a radical paradigm of, though poorly named, Serverless. This paradigm is meant to not only abstract away the infrastructure, provisioning is only needed when the code is invoked.

With the term Serverless being a misnomer, there is a better alternate name of Function as a Service (FaaS). I recall at one of the Conferences a Panelist sharing a far eloquent description of Serverless.

  1. Invisible infrastructure
  2. Micro-billing
  3. Event based programming

With AWS focused on taking on more and more of the undifferentiated heavy lifting, this is the logical progress where after managing the control plane, the next iteration takes over management of the servers as well.

2018 re:Invent

Unlike last year, this year’s reInvent wasn’t heavy on container technology. Following are couple of high level enhancements.

  1. AWS CodeDeploy supports blue/green deployments to AWS ECS and Fargate.
  2. AWS CodePipeline supports Elastic Container Registry (ECR) as a source provider.







About the Author

Atif Siddiqui is a returning author having participated in 2016 AWS Advent. He is passionate about Cloud technologies and is a Cloud Infrastructure Architect at Citigroup. He currently holds all three AWS Associate certifications and remains committed to expanding his knowledge in Cloud Solutions.

About the Editor

John Varghese is a Cloud Steward at Intuit responsible for the AWS infrastructure of Intuit’s Futures Group. He runs the AWS Bay Area meetup in the San Francisco Peninsula Area for both beginners and intermediate AWS users. He has also organized multiple AWS Community Day events in the Bay Area. He runs a Slack channel just for AWS users. You can contact him there directly via Slack. He has a deep understanding of AWS solutions from both strategic and tactical perspectives. An avid AWS user since 2012, he evangelizes AWS and DevOps every chance he gets.