Kops vs EKS: what to choose?

Amet Umerov
Nov 9, 2019 · 5 min read

If you run your Kubernetes workloads, probably you use self-managed clusters managed by kops (supports k8s from version 1.4) or Amazon-managed Elastic Kubernetes Service (EKS) which generally available in the US since Jun 5, 2018.

In this article, I’ll describe the differences which I found while using them.

Image for post
Image for post
kops vs EKS: what to choose?

Pricing

In both cases, you use EC2 instances for running workloads (workers, load balancers, VPCs, etc), so AWS doesn’t charge you additionally for nodes. The only difference in pricing between kops and EKS — masters.

The master node in EKS calls Control Plane, it’s a fixed price of $0.2/hour ($144/month).

With kops, you should manage your master nodes yourself (also it’s better to have separate etcd nodes outside the master nodes). For example, you can use 3 t2.medium (or t3, they are cheaper) nodes for masters ($108/month) + etcd nodes (if you want) + small price for EBS volumes.

For running small or even temporary clusters it could be easy to use kops because you don’t have a huge load on master or you can even use spot instances for them. For large production clusters with a high load, it could be profitable to use EKS.

Release cycle

If you read it after October 2019, versions 1.15 and 1.16 could be already supported:

From this table, we can see that new version support comes to EKS earlier than kops.

The time gap between official k8s release and EKS support is ~6 months, kops comes ~7–8 months after k8s release. I don’t think that’s a very important parameter, but nevertheless, EKS is the winner here. Usually, kops beta releases are good, so people can usually live with kops beta releases which come earlier than the stable releases.

Cluster management

kops is excellent for the fast cluster creation in an imperative way, for example:

It creates a pool of resources for you include VPCs, subnets, autoscaling groups, etc.

BTW, there is a tool from Weaveworks called eksctl which also allows us to create a cluster so fast:

kops allows you to export the cluster state to terraform and then modify and deploy a cluster through it or even store cluster configuration in a declarative way.

It is also an available EKS-module for terraform.

Rolling updates

Masters

EKS cluster updates master nodes without downtime, it automatically manages the master state, rollbacks or unexpected things related to master’s rolling updates.

Image for post
Image for post
EKS’ s control plane

In the case of kops, you should check and monitoring the rolling update process and manually fix issues that come with this operation (for example kill stuck pods, etc).

Workers

In both cases, you should control the workers update. The flow is simple, just change the AMI for nodes and start the update (don’t forget to prepare deployments for pods eviction).

For me, EKS is better for master upgrades, you won’t worry about unexpected things during the rolling update.

Network

kops supports many different CNIs, so you can have full access to the corner case in your network infrastructure.

EKS uses VPC ENI networking, it means that you can integrate k8s cluster to the existing networks through the native AWS network, for example, to access to the EC2 instances in the same network. In this case, you have the plain network and you should plan the subnets because you can get the lack of IP addresses in your subnet. BTW, EKS supports Calico which allows us to isolate network segments.

Flexibility

EKS, as we don’t have access to the master we can’t control ApiServer, ControllerManager, etcd, Scheduler. It means that we can’t use such things as:

We still can add external policies to AWS resources, manage instance groups, modify the images for nodes, DNS, etc. Control Plane logging is available in EKS, but it sends logs to CloudWatch.

kops allows us to do what we want, that’s enough. Of course, Amazon is working on additional features, and we will see them in the future, here is a roadmap for it.

Image for post
Image for post

Subscribe to FAUN topics and get your weekly curated email of the must-read tech stories, news, and tutorials 🗞️

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

Image for post
Image for post

FAUN

The Must-Read Publication for Creative Developers & DevOps Enthusiasts

Sign up for FAUN

By FAUN

Medium’s largest and most followed independent DevOps publication. Join thousands of aspiring developers and DevOps enthusiasts Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Amet Umerov

Written by

DevOps Engineer — https://www.linkedin.com/in/amet13/

FAUN

FAUN

The Must-Read Publication for Creative Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

Amet Umerov

Written by

DevOps Engineer — https://www.linkedin.com/in/amet13/

FAUN

FAUN

The Must-Read Publication for Creative Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app