Forem: mariomerco

5 Razones de por qué aprender EKS practicando

mariomerco — Mon, 14 Jun 2021 20:12:13 +0000

Alguna vez has estado en la posición de aprender alguna herramienta nueva sobre tecnología y piensas "esto es increíble!" pero cuando comienzas a aplicarla encuentras varios problemas que lo hacen realmente más difícil? Bueno, si has estado allí, definitivamente trabajas en TI!

No es un secreto que las tecnologías de la información evolucionan todo el tiempo y muy rápido, haciendo que las cosas sean mejores y más rápidas, pero también a veces un poco abrumadoras. E incluso más allá de eso, ¡este escenario podría suceder en muchos otros dominios del conocimiento y experiencias de vida!

Ahora, aterrizando más en nuestro tema, Kubernetes en AWS, hay muy buenos ejemplos, documentaciones, laboratorios y ejercicios que pueden ayudar a comenzar con nuevos conocimientos, por lo que esto le brinda las herramientas como piezas de Lego para construir su propia solución, ya sea desde cero o con alguna línea de base. Esto es genial y funciona así en la mayoría de las piezas de TI.

Pero hay veces en las que es necesario realmente mirar un proyecto (ya sea algo pequeño, incluso) y llevarlo de la mano con Kubernetes, porque en la teoría se pueden obviar cosas que en la práctica son necesarias y que solo es (la practica) la que podrá llenarlas. En otras palabras, no es lo mismo aprender a manejar una bicicleta por video tutoriales que montándote en una. Por eso les dejo aquí 5 razones por qué aprender EKS practicando.

1. Kubernetes es complicado: demasiadas piezas moviéndose

Si bien Kubernetes se está convirtiendo cada vez más en un estándar cuando se habla de orquestación de contenedores, también es cierto que el manejo de las cargas de trabajo de producción es un desafío. Kubernetes es un conjunto de múltiples componentes como línea de base, luego comienza a contar a medida que implementas pods, configmaps, secretos, servicios y un largo etc. (ni siquiera hablamos de CRDs ...), por lo que antes de comprometer algo en producción, requiere probar, no solo la aplicación en sí, sino su infraestructura implementada en Kubernetes.

2. Las redes necesitan atención

A medida que comience a implementar sus aplicaciones (especialmente si se comunican entre sí), inmediatamente se enfrentará con DNS, IP, equilibrio de carga, etc. Aunque la mayor parte de esto se maneja con conceptos simples de Kubernetes, su infraestructura subyacente requiere una infraestructura de red bien establecida.

3. Los permisos de IAM son muy detallados

Si los desarrolladores tienen un acceso amplio al espacio de AWS, codificarán sus aplicaciones usando el SDK de AWS probablemente sin preocuparse por los permisos ... ¡hasta que obtenga Kubernetes! Los contenedores intentarán solicitar acceso a la API de AWS y, si el rol de IAM que abarca la aplicación no está configurado con los permisos adecuados, simplemente fallará.

Hay varias soluciones para esto, como Kube2IAM, KIAM y IAM Roles for Service Accounts que, si estamos en AWS y EKS (ejecutándose en instancias EC2), esta es mi opción de preferencia 😎.

4. La automatización también requiere pruebas

La automatización está, en la mayoría de los casos, relacionada con la codificación, y la codificación también está relacionada con errores. Entonces, en este caso, tomaría la palabra "práctica" reemplazada por "prueba". Entonces, los flujos de trabajo de CICD que quizás desee crear son, al final, un código que se ejecuta en algún lugar y puede tener problemas. Es por eso que tener varios entornos (al menos un entorno de PRUEBA) antes del de producción es importante para probar realmente cómo se realizará el aprovisionamiento de sus recursos.

Kubernetes también se incluye en esta sección, porque automatiza la orquestación de contenedores según las configuraciones que proporciones. Pero si sus configuraciones son incorrectas, podrían llevarlo a un problema de implementación o un entorno mal configurado.

En resumen, siempre PRUEBA!.

5. Cuidado con el $orpri$e$ 💲💲💲

Esto es simple: Cuantos más nodos agregue, más dinero pagará. Por ejemplo, una de las ideas principales de tener contenedores y Kubernetes encima es Ajuste de escala automático, y hay varias formas, Ajuste de escala automático de clúster, Horizontal Pod Autoscaler y Vertical Pod Autoscaler. Lo mejor para configurar todo esto siempre depende del tipo de aplicación que esté creando. Tendrá que entender cómo se comporta, cuál es la mejor métrica para escalar, etc. y si esto no se toma con cuidado, podría escalar sin realmente necesitarlo y costarle mucho más. ** ¡O, incluso peor! **, podría reducirse de manera muy agresiva y dañar su disponibilidad y respuestas, ¡impactando directamente al usuario final! Así que es mejor estar preparado probando escenarios y desarrollando una estrategia de revisión de estas tareas a medida que su negocio aumente en usuarios finales.

Suena aterrador 🎃

Y puede que si lo sea 😅, pero realmente EKS ha ido creciendo y madurando en las herramientas que provee para hacer más fácil su aprendizaje y mantenimiento. Desde Managed Worker Nodes, add-ons y actualizaciones automáticas, hasta correr contenedores en Fargate (a lo Serverless) y miles de integraciones opensource por la comunidad de Kubernetes, de AWS y de ambos! Así que, aunque suene complejo, EKS brinda facilidades para hacerlo un servicio atractivo y una solución productiva, segura y efectiva en costo.

PD: Si tienes subscripción de A Cloud Guru, te invito a mi curso A Practical Guide To Amazon EKS, donde muchos de estos temas los cubrimos practicando!.

5 Reasons why to learn EKS practicing

mariomerco — Sun, 13 Jun 2021 19:06:29 +0000

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 you’ve been there, you definitely work on IT!

That’s 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.

But there are times when it is necessary to really look at a project (even be it something small) and take it by the hand with Kubernetes, because in theory you can ignore things that in practice are necessary and that is only (the practice) the one that will be able to fill them. In other words, it is not the same to learn to ride a bicycle through video tutorials rather than riding one. So here are 5 reasons why you should learn EKS by practicing.

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 it’s 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, they’ll 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.

Sounds scary 🎃

And it may be 😅, but really EKS has been growing and maturing in the tools it provides to make learning and maintenance easier. From Managed Worker Nodes, add-ons and automatic updates, to running containers in Fargate (the Serverless way) and thousands of opensource integrations by the Kubernetes community, AWS and both! So, although it sounds complex, EKS provides facilities to make it an attractive service and a productive, safe and cost-effective solution.

PD: If you have A Cloud Guru subscription, I invite you to my course A Practical Guide To Amazon EKS, where many of these topics we cover practicing!.