More than a year ago, setting up a Kubernetes cluster on AWS wasn’t an easy task.
Here’s a quick recap of the things you needed to set up an HA Kubernetes cluster on AWS:
This is only a partial list off the top of my head, but I hope you get the overall picture — setting up a Kubernetes cluster would allocate a big chunk out of your overall Kubernetes migration project.
Today, there are tools like kops that automate most of the tasks mentioned above and can help you spin HA Kubernetes clusters on AWS. Kops specifically is pretty mature and seems like it has been getting a lot of development attention recently.
If you want to avoid setting up your own Kubernetes cluster on AWS, there are a few commercial options available like Stackpoint.
Toward the end of last year, AWS announced that it accepts beta testers for its own managed Kubernetes service, called EKS.
I’m not a cloud analyst, so I won’t even try to dive into the strategic implications of this announcement. However, I’ll ask another question, which is much more relevant to the job we’ve been doing with clients: “Will EKS dramatically reduce the time needed to migrate a company to Kubernetes running on AWS?”
During the past two years I’ve done multiple Kubernetes migration projects in which we took a working production environment and migrated it to run on a Kubernetes cluster.
To answer the question I’ve mentioned above, let’s take a look at the tasks we usually need to perform to migrate an existing environment to Kubernetes:
As I mentioned, with tools like kops it’s relatively an easy job now, especially if you already know Kubernetes internals to a good extent which will help you make the right decisions early on, like which networking driver to use.
If you aren’t using Docker already and deploying your applications in some other way, it may take a few days to create appropriate Docker images for all your services.
To be honest, I would say that this part takes roughly a half of the project’s time!
Why? Because usually you uncover a lot hacks or assumptions about the deployment environment that you need to overcome first.
There could be some hard-coded Jenkins jobs that do some parts of a deployment or are triggered to do specific post-deployment tasks.
Also, Jenkins can be one hell of a mess that you don’t even want to touch. So it might make more sense to start a separate Jenkins instance that will take care of the new Kubernetes environment.
If Jenkins isn’t involved, there can be a set of deployment scripts, let’s say in Python, that accumulated so much unused legacy code that even the people who use it daily don’t fully understand what it does!
Eventually we need to map the existing deployment process and translate it to the way things will be done in the Kubernetes world.
Usually creating these manifests is done as part of the previous step, but I wanted to separate it to its own category.
Most of the time this process is pretty easy, but it can become increasingly complicated depending on the number of services you want to deploy and how well they map to the 12-factor app manifesto.
If you have a bunch of stateless services, a simple template with envsub could be enough.
However, if you have dozens of services with complex relationships that affect the deployment, we might need to use the heavy guns of Kubernetes deployment: Helm.
The complexity of this stage depends on the tools you currently use and the breadth of monitoring coverage you have.
If you use CloudWatch to monitor and graph a few built-in AWS metrics, you might need to implement and switch to a new set of monitoring tools that integrate with Kubernetes.
Other monitoring tools like Datadog might need fewer adjustments, but you still need to perform several steps to forward the new metrics.
If after the migration to Kubernetes your development team can’t operate the day-to-day tasks themselves, you’re missing out on one of the core benefits of Kubernetes.
Unfortunately, despite Kubernetes’ growing popularity these days, it takes time to teach its main concepts. The documentation isn’t the best, and it takes time for the team to learn how to work with Kubernetes efficiently. I’ve written before about what’s difficult for beginners to learn in Kubernetes, so you may want to take a look to get a fuller picture.
Does EKS really simplify migration to Kubernetes if you’re running on AWS? From all the tasks I’ve mentioned above, setting up a Kubernetes cluster on AWS will take approximately 10% of the migration project.
That doesn’t include maintenance, which also depends on the cluster’s size and environment’s complexity.
But to answer the question I’ve asked at the beginning of this article — EKS will probably reduce some time related to cluster setup, and maybe even related to monitoring and logging in the future. Since much of the migration project’s complexity is related to existing infrastructure, I feel that migrating to Kubernetes on AWS will continue to be challengingall the way through 2018!
Scaling a cloud-enabled startup requires DevOps expertise. We partner with your engineering team to help you build and scale your cloud infrastructure.
Contact us
