Kops vs. EKS: A Comparison Guide

This post was originally published here.

It is fairly safe to say that Kubernetes is now the go-to solution when it comes to deploying containerized apps. EKS simplifies the creation of a secure and capable K8s environment on the Amazon Web Services platform and makes deploying clusters there that much easier. We’ve covered EKS on several occasions previously here and here to read more. As discussed previously, EKS does have its limitations, but the service is very easy to use, even when you are not a server administrator. 

However, EKS and similar services are not the only way you can set up a production-grade K8s environment. Kops, or Kubernetes Operations, has been around for a while, offering CLI tools that make creating and managing Kubernetes installations easy. Kops is designed for those who want complete control over their Kubernetes environment but without the usual headaches.

So, should you use EKS for your next deployment? Or is kops the way to go? One major difference between the two is that EKS is an AWS product so you need an AWS account but kops allows you to run Kubernetes in AWS but also “with GCE in beta support, and VMware vSphere in alpha, and other platforms planned.” 

Outside of this significant platform compatibility distinction, choosing between the two is a matter of finding a deployment solution that suits your specific requirements, but these next few points we are going to discuss in this article will also help you make a better decision.

Initial Setup

Both EKS and kops make setting up a production environment easy. EKS automates most of the steps and allows you to get an EKS instance up and running in minutes by bringing up the Kubernetes control plane (masters), assuming you already have your AWS IAM permissions and users configured correctly.

EKS does not create nodes automatically when you create an instance, so you have to do that manually. After defining cluster names and setting up endpoints for public and private access, you can continue to map users to the EKS instance as the last step once you have workers up and running. AWS has developed a couple of CloudFormation templates for automating this process, however it’s not a ‘push button’ process yet. The AWS CLI tool is easier and more straightforward than its GUI, so you might want to use command line instead, at least during the initial setup process. This is not the standard AWS CLI by the way. Weaveworks created a CLI called eksctl for bringing up the control plane (EKS) and the workers with just one single line command. This solution has been adopted by AWS as an alternate method for deploying an EKS cluster.

Kops, on the other hand, lets you actually configure masters and nodes yourself. Yes, it works with AWS, but master nodes are created as EC2 instances instead. The tool also supports automation during the setup process.

You can update the kops templates at any time and it will take care of making the proper changes in AWS. The kube infrastructure with kops is described through templates, so, you simply describe the desired state and kops will work to match the kube environment to that.

Since kops work natively with AWS, you can create even the most complex containerized environment faster. In fact, many developers find kops to be more useful when setting up cloud environments from scratch, particularly when there are specific requirements to meet.

Configuration and Access

One of the first—and biggest—differences between EKS and kops is in how control and access are handled. With EKS, things such as managing the master node and configuring the cloud environment are handled by Amazon, leaving you with little to no control over them.

Kops, on the other hand, lets you configure your cloud environments the way you like them, including configuring them to meet specific needs. In the long run, the level of control provided by kops will enable better control over the efficiency of the cloud environment.

That said, kops’s manual approach means you are completely responsible for making sure that the cluster is configured correctly and running properly. It is also up to you to make sure that the master node services are working properly, including critical services like API server and scheduler. Not only this, but you are also responsible for keeping the master nodes up to date and working properly.

In terms of control and access, the Amazon EKS may suit developers more. kops, on the other hand, is more for server administrators who appreciate more control over the entire environment.

Speaking of control and access management, by default, kops uses a secret (API bearer token) to authenticate users but it has also added support for configuring authentication systems. Since Kops 1.10, the tool also supports AWS IAM Authenticator (which is the way EKS authenticates). As mentioned before, EKS relies on IAM for authenticating users and the authorization is done by Kubernetes RBAC in the standard way. Visit our Amazon EKS Authentication & Authorization Process article for more details.

Cluster Management

There are reasons why EKS is a bit more difficult to configure initially, and that reason is meticulous management of your cluster in the long run. With EKS, you don’t even have to worry about having to bring the entire cluster down for substantial updates and upgrades.

EKS is also considered to be more scalable in most situations. It runs a highly available control plane at its core, making the entire service more dependable. Your continuous testing and integration workflows can surely benefit from up-to-date K8s.

EKS is also incredibly detailed when it comes to internal pods management. You can dig deep into IP assignments, how pods communicate with each other, and even how pods interact with VPC as a whole, all without worrying about the technical side of things. By default, EKS uses the VPC CNI (network plugin) which gives each pod a VPC IP address and enables any pod to be able to communicate with other AWS services without issues.

Kops doesn’t have these advantages natively. To fully benefit from your use of kops, you need additional tools that offer these functionalities. Also, kops uses private networking for pods by default and supports several CNIs for pod networking, but AWS VPC CNI is not listed there. 

Since kops uses EC2 instances for nodes, you maintain control over networking and resource allocation. Once again, you can choose to use kops commands to manage these resources or simply go back to the AWS control panel for more refined control.

Yes, it is more complicated than using the native tools offered by EKS, but kops has a secret trick up its sleeve: version compatibility. Kops let you to deploy any kube version—including the latest, 1.14—while EKS is still a couple of versions behind (as of today the latest version available in EKS is 1.12).

Both of these methods of running Kubernetes on AWS are handy for their own reasons. Cluster maintenance is pretty similar. EKS involves more configuration to align IAM, manage worker nodes, and setup a VPC still. But in terms of security, it’s difficult for the open source nature of kops to match the security expertise of the EKS team and AWS support despite being backed by an amazing Kube community. At the end of the day it may come down to platform compatibility to help you decide because both offer great functionality.

Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our DevOps-as-a-Service offering.