23
5 Razones de por qué aprender EKS practicando
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.
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.
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.
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 😎.
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!.
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.
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!.
23