Let me be honest with you — I often feel being a Luddite. Not that I am against progress or trying to stop the hype train, no. But I often think that every new and shiny framework or tool is just redesigned and overengineered, and it will be replaced in a year or two by some other tool… And this clearly shows my relationship with Kubernetes.
Don’t get me wrong, Kubernetes is incredible. So are AWS ECS, DC/OS (Apache Mesos on steroids), and Hashicorp Nomad.
My problem with Kubernetes was that our paths never intersected. My “first” orchestration system was DC/OS. Afterward, I ran everything I have touched on ECS as it is deeper integrated with AWS than others.
When K8s and I finally met, K8s was 1.16 years old, and I was just a Solution Architect who often speaks a language of abstractions. For me, it is just another task scheduler.
Kubernetes dragged my attention after a panel discussion at DevOpsConf 2020, where Andrei Kvapil asked: “Is there a point to use AWS’ managed services if I can run my own using Kubernetes Operators?”
Of course! If Kubernetes is a Cloud Application Orchestration Framework Platform And Other Buzzwords (whatever you call it, lol), it makes perfect sense to build your own cloud service inside of it!
Achieving multitenancy using host constraints and namespaces, controlling resources using limits, integrating entities using labels and annotations is pretty cool. But for me as a novice to K8s — believe it or not, I have never worked with Kubernetes as an engineer in my whole career — it will take a ton of time to get everything up and running so I can play around… This is what I thought before I found out about this repo from MadDevs.
Introducing the mighty AWS EKS Base repo!
Boilerplate your way out
aws-eks-base is a repo containing a set of infrastructure and system configuration files. It uses Terraform to provision resources, deploys to AWS (EKS is a managed Kubernetes), and runs several supporting systems in K8s, such as Loki, Prometheus, build system, and so on.
The exciting bit of this setup is that you provision a network for the different types of resources, which is aligned with the networking best practices for AWS.
You have a network for a storage layer (database subnet), intranet subnet for internal systems with no access to the internet. You store parameters in SSM Parameter Store and images in ECR. It leverages a mix of Spots and On-Demands instances to achieve the best pricing in the AWS region you run your infrastructure.
This said, all the building blocks in AWS are in place, and the same is with Kubernetes: the namespaces, ingress controllers, and even node termination handlers are provisioned right away as soon as a foundational infrastructure is in place.
The best bit — how you run it. Once you have the remote storage set up, you do the following:
And that’s it. On top of that, there are other pros of using this boilerplate!
It is customizable
Why would you need a codebase while you have eksctl, which does roughly the same?
Well, eksctl only delivers the cluster itself. The rest of the infrastructure needs to be in place. Add to that, you can not change the internals of eksctl, only the parameters it’ll use.
It is not the same with the base repo. If you want to remove, change or add extra resources to the whole stack, you can fork the repo and add your code.
And that’s it. On top of that, there are other pros of using this boilerplate!
It is educational
If you are new to K8s or running modern applications in the Cloud and you don’t want to slack around “Hello, World” applications, aws-eks-base is a great starting point!
It contains all the popular tools for managing AWS and Kubernetes along with useful VS Code plugins.
It is built around well-architected infrastructure.
This makes it a great hands-on guide!
It is a boilerplate
Speaks for itself, aws-eks-base is a boilerplate code, so you don’t have to spend precious time writing from scratch the same infrastructure code over and over again! It uses well-known Terraform modules and is frequently updated, so you can be sure it won’t contain outdated configuration or software.
What to do next
If you are looking into running Kubernetes workloads on AWS and have been waiting for a seamless way to begin — the wait is over!
If you, like me, have not gotten your hands dirty for a long while, then definitely reserve some time to look into aws-eks-base. This will help you quickly learn the latest engineering and DevOps tooling trends.
Fork it, run it, break it, make an issue on GitHub, or even better — a Pull Request! I am sure, MadDevs welcome every feedback!
Previously published on the Karen Tovmasyan blog.
Top comments (0)