5 Reasons why to learn EKS practicing

Have you ever been in the position of learning some new tool on tech and think this is awesome! but when you start applying it find multiple issues that makes it actually harder? Well, if youve been there, you definitely work on IT!

Thats not a secret that information technologies evolve all the time and very quick, making things better and faster, but also some times a bit overwhelming. And even beyond that, this scenario could happen in multiple other domains of knowledge and live experiences!

Now, landing a more in our topic, Kubernetes in AWS, there are really good examples, documentations, labs and exercises out there that can get you started with some new knowledge, so this gives you the tools as lego pieces to build your own solution, whether from scratch or with some baseline. This is great and works just like that in most of IT pieces.

1. Kubernetes is complicated - too many moving pieces

While Kubernetes is getting more and more like a standard when talking about container orchestration, is also truth that handling for production workloads is challenging. Kubernetes is a set of multiple components as a baseline, then start counting as you deploy pods, configmaps, secrets, services, and a long etc (not even talking about CRDs), so before commiting something to production, it requires testing of, not only the app itself, but its infrastructure deployed in Kubernetes.

2. Networking needs attention

As you start deploying your apps (specially if they talk to each other) you immediately will face with DNS, IPs, load balancing, etc. Although most of this is handled with simple concepts by Kubernetes, your underlying infrastructure requires a well established networking infrastructure.

3. IAM permissions is very granular

If developers has a wide access to the AWS space, theyll code their apps using the AWS SDK probably without worrying about permissions until it gets Kubernetes! The containers will try to request access to the AWS API and, if the IAM role that is embracing the application is not setup with the proper permissions, will simply fail.

There are multiple solutions for this like Kube2IAM, KIAM, and IAM Roles for Service Accounts which, if we are in AWS and EKS (running in EC2 instances), this one is my go-to .

4. Automation also requires testing

Automation is, in most of the cases, related to coding, and coding is also related to bugs. So in this case, I would take the word "practice" replaced by "test". So the CICD workflows that you might want to create is, at the end, code running somewhere, and it can come with issues. That's why having multiple environments (at least a TEST environment) before the production one is important to actually test how the provisioning of your resources are going to happen.

Kubernetes also falls in this section, because it automates the orchestration of containers based on the configurations that you provide. But if your configs are wrong, they could lead you to a deployment issue or missconfigured environment.

In summary, always TEST!.

5. Watch out the $orpri$e$

This is simple: The more nodes you add, the more money you pay. For example, one of the main ideas of having containers and Kubernetes on top of them is Autoscaling, and there are multiple ways, Cluster Autoscaling, Horizontal Pod Autoscaler, and Vertical Pod Autoscaler. The best to set all of this up always depends on the type of application you are building. You'll have to understand how it behaves, what's the best metric to take for scaling, etc. and if this is not taken with care, could scale up without really needing it and costing you much more. Or, even worst! it could scale down very aggressively and damaging its availability and responses, impacting directly the end user! So better be prepared testing scenarios and developing a strategy of reviewing theses tasks as your business increase in end users.