Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
cómo estoy yo actualmente manejando, configurando los nodos en Kubernetes. Esto es como lo hago yo al día de hoy. Y es que tengo un node pool con un máximo de tres nodos. esos son tres nodos estáticos con instancias on demand. Cuando le digo estáticos es que no está autoescalando. Ni agrega más, ni quita nodos.
son tres instancias fijas, ahí corro esos servicios que no quiero que se estén interrumpiendo constantemente, ahí en esas instancias, en esa node pool fijo,
corre entre otras cosas el controller de Karpenter para esos tres nodos compro saving plans
para pagar lo menos posible con ellos. Y todo lo demás, configuro Karpenter para que me cree Spot Instances, que priorice Spot Instances y me las agregue de forma dinámica, analizando los patrones, la capacidad necesaria para que me pueda tolerar los flujos, y le agrego un fallback de que si no encuentro una instancia Spot,
que cargue con los recursos, que agregue una instancia on demand.
Douglas (01:13)
Hola a todos y bienvenidos a un nuevo episodio de Dev & Ops, su podcast favorito donde hablamos de temas de desarrollo, tecnología, DevOps y lo que es su cultura en general. El día de hoy con un nuevo episodio, un nuevo episodio que como siempre esperamos que les pueda traer mucho valor y temas de que hablar a ustedes en su día a día, en su semana. El día de hoy, lastimosamente, mi amigo y co-host Juan Ramos no me puede acompañar, no nos pudimos coordinar por diferentes aspectos.
y diferentes responsabilidades que ambos tenemos fuera de este espacio, de este podcast.
Sin embargo, aquí estoy yo para traerles a ustedes un episodio más, como mencionaba, un episodio más que esperamos que sea lleno de valor para ustedes. Y es que el tema que hoy quisiera tocar, el tema que hoy quisiera entretener delante de ustedes tiene que ver más con la parte de operaciones, con la parte de infraestructura, que es el área en la que yo me he especializado ya por varios años, y específicamente un tema con Kubernetes. Y lo que quiero tocar hoy es darles a ustedes
algunos consejos para optimizar costos corriendo Kubernetes en AWS. Y es que si estás en una situación en la que has hecho un análisis, un estudio, todo, has hecho tu tarea de analizar bien qué le conviene y has llegado a la conclusión de que Kubernetes es lo que necesita.
para correr tu aplicación web, tus sitios web, o hostear tu aplicación en general, o tal vez ya estás corriendo Kubernetes, específicamente en AWS. Yo creo que a este punto ya o has escuchado, dependiendo en qué etapa estás, o ya estás experimentando que Kubernetes...
es excelente, es en la actualidad, discutiblemente, el orquestador de contenedores más utilizado y por obvia razón en producción. Es muy bueno, Kubernetes. Si tu aplicación necesita ese tipo de orquestación que hoy en día la mayoría de aplicaciones para producción lo necesitan.
Sin embargo, robustez, esas bondades de Kubernetes vienen con un precio, no solo precio administrativo, precio de complejidad, sino que pues muchas veces es un precio literal. Las facturas de AWS comienzan a incrementarse cuando corremos Kubernetes en AWS y es que con EKS, así se llama el servicio de AWS de Kubernetes,
son en inglés, EKS, que son las siglas de Elastic Kubernetes Service en AWS. Con EKS no pagamos únicamente Kubernetes, por así decirlo. decir, estoy pagando Kubernetes en AWS, estoy pagando el servicio de EKS, sino que realmente con EKS estamos pagando el control plane, que es el que administra el cerebro de Kubernetes, por así decirlo.
estamos pagando los nodos que puede que sean easy to instances o fargate dependiendo como lo tengas configurado pagamos por load balancer volúmenes, pagamos por transferencia de datos, pagamos por logs, etcétera, etcétera. Son muchos los diferentes servicios que hay en Kubernetes alrededor de Kubernetes, detrás de Kubernetes que pagamos cuando trabajamos con EKS en AWS.
Y es por esta razón que si no hay una planificación apropiada, si no hay un control detallado, la factura podría llegar a ser altísima. Y esa es la razón, ese es el motivo por el cual hoy quiero traerles este tema a la mesa, hoy quisiera conversar esto y sobre todo darles estos consejos. Y como normalmente es costumbre aquí de nosotros hacer algunas cuantas aclaraciones, muchos de estos...
estos consejos aplican a Kubernetes en general, sin importar el proveedor, ⁓ Lo pueden aplicar sea donde sea que estén corriendo Kubernetes, o sea, donde sea que estén planeando correr Kubernetes, perdón, ¿verdad?
La mayoría de ellos van orientados específicamente para IKS de AWS, para el Kubernetes de AWS. ¿Por qué? Pues en general la razón es porque yo ahí es donde tengo la mayoría de mi experiencia trabajando con Kubernetes. Cuando digo mayoría es una gran mayoría, tal vez el 90 % de mi experiencia con Kubernetes está en AWS. He trabajado bastante con...
con el Kubernetes de Azure, que es el AKS, Azure Kubernetes Service, también el Kubernetes de DigitalOcean. he trabajado bastante, medio he usado el de Google Engine, escuchado a muchas personas de quienes respeto y valoro mucho su opinión en la comunidad DevOps, en la comunidad de sistemas que mencionan
que el Kubernetes de Google Engine es el mejor que existe y yo se los creo, respeto mucho su opinión. Sin embargo, mi experiencia va más alrededor de AWS y la realidad de las cosas es que también es el más utilizado. Hay muchas razones detrás de eso. AWS siendo el primer proveedor de nube a escala grandes, donde corporaciones enteras se emigraron de sus data centers propios a la nube, entre otras cosas. Pero esos son los motivos.
que quiero que quede claro, tal vez los primeros consejos que voy a ir dando son bien generales, pero a medida voy avanzando va a ser hacia EKS de Amazon Web Services. De nuevo.
lo he experimentado mucho y muchas de estas cosas vienen de errores y aciertos a lo largo de mi carrera. Y bueno, para no hacer ya más preámbulo, entremos de un solo al tema de lleno y es que voy a empezar de lleno con el primer consejo. Y el primer consejo es...
optimiza tu aplicación para que consuma la menor cantidad de recursos posibles. Y acá es un consejo muy repetido, muy trillado, muy obvio por mucha gente, ¿verdad? Pero este es un consejo que que darlo. Es parte del checklist que hay que seguir al momento que queremos ahorrar recursos. Normalmente no nos brincamos ciertos pasos de esos checklists porque a veces de nada
sirve brincar hacia otros pasos si tengo una aplicación que está consumiendo demasiado, demasiado recursos. Hay que asegurarse que la aplicación, que el código de tu aplicación y los algoritmos y la forma en que opera y trabaja y se interactúa, interconecta uno con otro, implementa buenas prácticas de desarrollo, buen manejo de recursos, etcétera. No quiero ahondar mucho en esta parte. Además, si sos alguien de
operaciones, sos alguien de sistemas, como tal no es tu responsabilidad codificar la aplicación, sin embargo nosotros en sistemas debemos de levantar la bandera roja y poner un alto cuando vemos que una aplicación no está siguiendo buenas prácticas, que no está optimizando bien los recursos, que no los está utilizando de la mejor manera, que está dejando memoria, que está creando memory leaks, etcétera, etcétera, nosotros deberíamos de detener eso.
a los developers y pedirles que lo mejoren. Pero, aunque es un tema, es un consejo repetido, se tiene que revisar entre las primeras cosas que hagamos al momento de querer optimizar Kubernetes en general, optimizarlo por rendimiento. Y en este caso, los consejos a los que estamos orientando el tema de hoy es optimizarlo para ahorrar recursos. Y aquí es sencillo, ¿no? Si tu aplicación consume más recursos, vas a pagar
más recursos. Si tu aplicación está optimizada para consumir menos, tu factura se va a reducir un poco. Ahora de nuevo, aquí no hay mucho que agregar pero quería mencionarlo como el primer consejo porque es necesario. Segundo consejo
siempre orientado a la arquitectura de la aplicación como tal y al desarrollo, pero nosotros de operaciones y sistemas tenemos que asegurarnos que esto simplemente es asegúrate de que tu aplicación sea cloud native, nativa para la nube. Cloud native, ¿qué significa que tu aplicación sea cloud native? No necesariamente que es que sea para servicios de nube como tal, sino que son una aplicación cloud native, son pensadas
desarrolladas, arquitectadas para aprovechar las bondades que ofrecen los servicios de nube, ya sea una nube privada que corre en tu propio data center o en el data center de la empresa en la que trabajas, no necesariamente tú eres el dueño del data center, pero que corran data centers privados, instalados, configurados con estos diferentes servicios que te permiten crear recursos, eliminar recursos por medio de APIs, script, automatización, etcétera.
o para aprovechar los beneficios de manera nativa de los servicios de proveedores de nube, de infraestructura de nube como en este caso AWS. ¿Qué tipo de servicios? Por ejemplo, trabajar de manera nativa que aprovechen almacenamiento compartido.
NFS, aunque NFS es súper antiguo y se usa desde antes, pero también almacenamiento tipo S3, que es Object Storage, herramientas de implementación de health check, por ejemplo, para que esté diciendo, que esté diciendo si la aplicación está corriendo bien o si tiene errores.
Que la aplicación tenga self-healing, que se pueda auto sanar, la aplicación pueda fallar con gracia, dar errores con gracia, se le dice eso, gracefully fail, se dice en inglés, que no vaya a ser que un error haga que todo el sistema crache y se detenga, ese tipo de cosas que aguante eso para que pueda en un evento de auto-scaling agregar nuevos...
o quitar nuevos nodos sin estar generando errores, ¿verdad? Eso es una aplicación Cloud Native. Esto no solo nos permite que la aplicación trabaje de manera más óptima, utilizando mejor los servicios más apropiados, o sea, eso de por sí solo en general va creando ahorros.
porque si tienes tu aplicación para que use, por ejemplo, almacenamiento en S3, en lugar de un gran disco inmenso compartido, en almacenamiento por si solo comienzas a ahorrar recursos, ¿verdad? Entonces, está esa parte de que si usas el servicio correcto para la necesidad que tienes de manera óptima, te va a generar ahorros, pero también va a permitir que tu aplicación soporte
ciertas técnicas o ciertas estrategias de ahorro que vamos a ir mencionando más adelante. Entonces aclaro un poco qué es Cloud Native para quienes no sepan y de nuevo un consejo en el cual no hay necesidad de ahondar muy a profundidad. Sin embargo, de nuevo, es parte del checklist para que una aplicación funcione. Si tienes un monolítico grande, inmenso que doquerizaste y si se cae un contenedor empieza a generar errores, entonces eso va a ser difícil.
que intente generar ahorro alrededor de ellos. Posiblemente incluso correrlo en contenedores o correrlo en docker como tal, perdón, en Kubernetes como tal, no sea la mejor idea. Tal vez si puedas ponerlo en contenedores, pero no necesariamente Kubernetes si tiene una aplicación que es muy monolítico, muy rígida, que no tiene partes movibles, que no tenga autosanación, self-healing, probablemente Kubernetes no sea la mejor opción. Entonces esa es la razón por la cual
está mencionada, entro los consejos si quieres ahorrar costos corriendo Kubernetes en AWS. Ahora un tercer consejo, de nuevo es muy repetido pero los quiero comenzar mencionando porque van agregando o escalando en base a lo que vamos a ir hablando hoy y es define límites a tus bots, al número de réplicas
o el número de nodos que tienes en Kubernetes. Consejo obvio, pero parte del checklist.
Acá es importante controlar mucho también los requests que entran a Kubernetes. Si no definimos límites, ejemplo, comencemos a los pods, límites en el uso de memoria o el uso de CPU, un bug en la aplicación pudiera generar que se consuma toda la memoria y entonces agarre todo un nodo y luego Kubernetes empieza a agregar más nodos y sigue escalando indefinidamente
hasta
que te consume medio recurso de AWS, medio datos entre AWS y te carga la factura. Uno por esa parte es importante hacerlo, definir esos límites de memoria, límites de CPU para que la aplicación se contenga y si hay un memory leak, si hay un bug, si hay un problema, no se extienda alocadamente. Igual.
definir un número máximo de réplicas de pod que se pueden agregar, puedes tener una aplicación con mucho tráfico que tal vez en horas bajas tenga 5 réplicas pero en horas altas tú le limites que puede llegar un máximo a 30 réplicas, luego de 30 réplicas tú quieres que si hay un error que te alerte, o que si sigue necesitando más recursos perdón que te alerte pero que no comience a agregar más réplicas y réplicas y réplicas entonces estamos viendo los diferentes niveles.
uno es evitar que consuma un solo pot, demasiados recursos, otro es evitar que se estén agregando pots o réplicas de manera indefinida, porque eso va a crear también que se sigan adquiriendo muchos recursos, y lo mismo es cuando Kubernetes, cuando llenó un nodo de pots, agrega un nuevo nodo para crear nuevos pots.
o almacenar nuevos pods en ese nodo, también pongamos un límite al número de nodos que se pueden agregar porque no queremos llegar a un escenario que nos vaya a agarrar todo y podemos pensar con ponerle límites a los pods que cada pod no agarre más de cierta cantidad de memoria o cierta cantidad de cpu es suficiente, no puede haber un escenario que no consideres que empieza a agregar pods indefinidamente entonces también puede decir
y si entonces le agrego límite a los bots la cantidad de réplicas que puede tener un servicio, ¿cómo eso va a ser suficiente? No, porque si hay otro servicio por allá que no configuraste vos, que comienza a crear réplicas indefinidas te va a agregar nodos indefinidos, entonces hay que ponerle límites a los nodos también ¿verdad? Y como mencioné también al inicio es bien importante también tratar de controlar los números de request.
porque los número, los requests son los que usa Kubernetes en manera general para definir si necesita más nodos, si necesita más pods, donde crear esos pods, entonces es importante controlar el número de requests con diferentes estrategias, si tiene sub front-end, en lugar de hacer tanto request al backend, puede haber una capa de cache para que el cache devuelva y eso genere menos requests o incluso a nivel más alto, a nivel de ledges, si puede escasar algo para que el request no
vaya hasta los nodos, hasta los pods, de nuevo eso te va a ayudar mucho, te va a ayudar mucho definitivamente. Entonces tratemos de controlar eso.
Ahora, entremos un poco más ahora a lo más profundo, a lo más ya orientado a AWS, a ya los consejos que donde el conocimiento empieza a incrementar, ya pasamos el primer checklist general de esos chequeos de rutina donde nos aseguramos que la aplicación esté bien. Básicamente es eso, comenzamos asegurándonos de manera general que la aplicación esté bien. Entonces ahora voy a enfocarme dentro de Kubernetes, dentro de AWS.
que puedo comenzar a ahorrar. Y quiero dar un par de consejos relacionados con lo que tiene que ver el tráfico y el ancho de banda. Porque en muchas ocasiones, en AWS en general, no solo en Kubernetes, pero en AWS en general, de repente un mes nos sale una factura
mucho más elevada que el mes anterior, 50 % más alto, 100%, 200 % más alto, en muchas ocasiones, no siempre, pero en muchas ocasiones es por el tráfico, el incremento en el ancho de banda, en el bandwidth, ya sea tráfico que viene del Internet o tráfico entre los availability zones.
los availability zones, verdad, para que no sepan, availability zones son data centers físicos en la misma región, en la región de North Virginia que es de las más utilizadas, es todo un estado, una gran región, esa es la región como tal, pero entonces hay una availability zone que es un data center físico en un lugar de North Virginia, luego tienen otra availability zone que es otro data center que está lo suficientemente recto.
del primero como para que si llega a haber un desastre ya sea de tipo natural o un apagón muy general o un problema grande que esté lo suficientemente separado como para que no se afecte, verdad, pero a la vez no tan separado como para hacer una región diferente entonces tienen ese balance, entonces esos son los availability zones y a veces
⁓ tenemos ese tráfico en travilabilización porque por buenas prácticas, cuando implementamos, cuando arquitectamos una aplicación, lo diseñamos de tal manera de que dentro de la misma región cree recursos.
en los diferentes data centers de esa región, los diferentes availability zones de esa región, lo hacemos por alta disponibilidad y lo hacemos por seguridad. De nuevo, porque si llegara a haber un incidente y todo un data center crashea, tenemos recursos separados en los otros dos, tres, cuatro data centers que hay en la misma región, dependiendo en cuál región estén.
Douglas (20:53)
Entonces, con eso, diciendo eso, el cuarto consejo que quiero dar es que utilices...
ingress con un application load balancer en tus servicios. Para quienes no saben, ingress en Kubernetes es el recurso que maneja el acceso externo a los servicios dentro de tu cluster vía HTTPS. Eso es ingress en esencia, maneja el recurso que maneja el acceso interno hacia los servicios, tus pods internos dentro de Kubernetes.
simplificada la definición pero es correcta sin embargo no verdad entonces AWS lanzó lo último que lanzó se llama AWS Load Balancer Controller el cual está pensado para reemplazar el antes se llamaba ALB Controller si no lo recuerdo si ALB ALB que son las ciclas de Application Load Balancer yo en lo personal como los clúster que estoy
están tan invertidos en lo que es el ALB Controller, todavía no he tenido la oportunidad de migrar al AWS Load Balancer Controller. Espero que esto no esté generando confusión a nadie. Es simplemente una versión mejorada, el cual AWS diseñó para que el mismo controlador te cree, ya sea Load Balancers de Application Load Balancers o que te cree Network Load Balancers, dependiendo de tu servicio. Entonces, yo estoy trabajando aún
mayormente con la versión anterior de ese controlador que se especifica únicamente para ALB, para Application Load Balancer. Pero de la manera que sea, aquí el consejo es que tengas un Application Load Balancer en tu ingres, ya sea con ALB ingres o con AWS Load Balancer Controller. ¿Por qué? Porque tener un ingres, un ALB perdón, me permite hacer cosas como agregar
un WAF a nivel de load balancer y agregando un WAF esto me ayuda a que se analice, a que se controle el tráfico antes de llegar a Kubernetes siquiera, se vea nivel de WAF, esto ayuda a evitar que tráfico malicioso, recueces necesarios lleguen a Kubernetes, lleguen a los bots, eso reduce carga en la aplicación, reduce consumo de recursos, reduce login,
dentro de Kubernetes, reduce procesamiento interno e incluso tráfico que llegue dentro de los contenedores de esa manera y eso dependiendo que tanto tráfico controle te comienza a generar ahorros. es una buena práctica y muchas de estas son buenas prácticas y son consejos que hay que implementar en Kubernetes de manera general.
porque traen mejor rendimiento, traen mejores analíticas, mejores formas de monitorear, ¿verdad? Pero a la vez, a la vez los estoy mencionando porque ayudan, la suma de estos consejos ayudan a reducir las facturas en AWS cuando trabajamos con Kubernetes. Ahora.
El quinto consejo, avanzando al quinto consejo, y esto es hablando de los availability zones que ya les mencioné, ¿verdad? Sería evitar la medida de lo posible el tráfico entre availability zones, ¿verdad? Porque ya les mencioné que están los diferentes data centers separados y que así arquitectamos las aplicaciones de manera intencional. Eso es muy bueno, lo vuelve robusto, lo vuelve seguro para nosotros.
pero el tráfico que hay de conexión entre un data center y otro cuesta dinero.
cuesta dinero, y a veces termina siendo una cantidad significativa de dinero lo que se paga en tráfico entre los diferentes data centers. ¿Por qué es así? Bueno, así funcionan los modelos de data centers, caro, el equipo de redes es caro, los diferentes circuitos que se pagan es caro. Mantener esa conexión requiere infraestructura externa a tu data center, requiere cableado subterráneo,
de línea, de cable, sea, requiere de muchos recursos y es por esa razón que el tráfico, el ancho de banda es uno de los recursos más caros en lo que tiene que ver con servicios de nube, Entonces, lo ideal es configurar la aplicación para que en la medida de lo posible haga llamados internos dentro del mismo availability zone, verdad.
porque en Kubernetes por defecto no garantiza que un servicio llame siempre POTS dentro del mismo availability zone. Kubernetes como tal no garantiza eso porque llama por medio del nombre de servicios internos y él balancea la carga, entonces no tiene algo que lo garantice. Pero nosotros tenemos que intentar tener un flujo en la medida de lo posible de nuevo, ¿no? Que...
que las conexiones se queden dentro del mismo data center. Voy a dar un ejemplo.
Digamos que llega el request al front end y llega al data center que es US East 1A, verdad que este es el data center en North Virginia, el A que es el, son US East 1A. Llega el request a ese data center al front end. El front end.
debería de llamar al API en ese mismo availability zone, en el US East 1A. El API va a buscar, va a hacer un read al cache, al redis que está en el mismo availability zone para ver si ahí está la información que requiere. No le encuentra, entonces el API hace el read a la base de datos.
para traer la información a él mismo en el mismo availability zone US East 1A Cuando la encuentra, la base de datos le da la respuesta del API, el API lo va guardar a Redis en el cache en el mismo availability zone US East 1A En ese momento Redis replica el cache a los demás nodos en los otros availability zones
Redis encarga de hacer eso. Luego el API que ya guardó en caché, manda la respuesta al front end que está ahí mismo en el US East 1A y este le responde al cliente. Entonces, si ustedes siguieron ese ejemplo y si alguien se perdió un poquito, vayan por favor, retrocedan los segundos atrás y vuelvan a escuchar. Si ustedes escuchan ese ejemplo a detalle.
solo hay un paso en ese ejemplo en el que existen conexiones entre data centers, entre availability zones y eso fue cuando el caché se replicó. De lo contrario, lo ideal, estoy poniendo un escenario ideal, estoy diciendo, recordemos, estoy diciendo que Kubernetes hace eso por defecto, estoy poniendo un escenario ideal de cómo debería de hacerse.
donde todo se mantuvo dentro del US East 1A y se replica a los demás. Y miren que interesante, en este ejemplo, si en otro request, un nuevo request de otro usuario llega al otro availability zone, US East 1B, ¿verdad? Al front end de esa misma región, al API de esa misma región y cuando llega el cache,
ya va a estar cachado que vino de la otra región y eso me vi ahí nomás se continúa se regresa el request al usuario todo por el mismo availability son perfecto estamos optimizando cuando arquitectamos intencionalmente las aplicaciones así estamos optimizando los request y eso nos va ayudar a reducir costos no hace que la aplicación sea mejor más rápida más estable por supuesto ese tiene que ser el uno de los objetivos principales es si no en realidad el principal queremos darle una
buena experiencia a los usuarios, pero al hacer eso normalmente también viene acompañado de reducción en los costos. Ahora
Como ya mencioné, Kubernetes no hace esto por defecto. ¿Cómo lo logro? Bueno, aquí es un reto bien interesante. Probablemente uno de los retos más complicados al momento de arquitectar soluciones, aplicaciones en AWS, en Kubernetes. Una de ellas puede ser creando la aplicación con diferentes topologías o conexiones para que se mantengan dentro de endpoints dentro del mismo availability zone. Pueden ser validaciones por medio de etiquetas en los bots, por ejemplo.
etiquetas que se agreguen por defecto en los pods donde digan qué región está, en qué availability zone está, perdón, y entonces por medio de eso que busque hacer llamados internos y que se generen endpoints internos por availability zone, que eso se monte como variable de entorno a los pods y trabajar de esa manera o buscar formas de arquitectar la aplicación de esa forma. De nuevo no es un reto simple, no estoy diciendo que es un reto simple, pero sí hay maneras de hacerlo y lograr
que la gran mayoría nunca se puede el 100 % porque existe replicación de nuevo si hago un write a la base de datos lo voy a buscar hacer en la misma región en la que estoy pero va a haber un escenario de replicación o igual si la base de datos donde yo estoy en mi región está caída
la aplicación debería de ir a escribir a otro lado o debería de ir a leer a la otra base de datos en la otra región porque vamos a priorizar que la aplicación está arriba, vamos a priorizar el usuario, ¿verdad? Entonces hay que tener mucho cuidado con eso. no es que el 100 % de los requests se van a mantener en el mismo availability zone, pero sí vamos a arquitectar de manera que la mayoría de los requests en lo que despeda a nosotros se mantenga dentro de la availability zone.
Otra alternativa es implementar Service Mesh. Service Mesh puede ayudar a controlar el tráfico y favorecer rutas locales, rutas en el mismo availability zone, aclarando que Service Mesh es bien complejo.
y ServiceMesh en sí también agrega consumo adicional en las conexiones porque es un contenedor adicional que se agrega a los pods y comienza a monitorear el tráfico, comienza a estar viendo y manda información. Entonces de por sí él agrega un poco más de información adicional, de datos adicionales. Yo a nivel personal no he tenido experiencia con Mesh en producción. Yo quiero dejar eso bien claro. Sin embargo, ya los
estamos trabajando, ya lo estamos considerando y lo estamos investigando para implementar en field, que es donde yo trabajo, justo con esta intención para buscar en la medida de lo posible de que las conexiones vayan dentro del mismo availability zone en todo lo que dependa de nosotros o en todo lo que podemos controlar.
Pero, siendo Service Mesh complejo y de por sí al agregarlo se le va a agregar él un poquito más o mucho más dependiendo del tráfico, porque aquí hay un gran depende siempre. Pero a pesar de que Service Mesh es muy complejo y de que le agrega también un tráfico adicional.
Hay muchos casos de uso en el cual es la solución que vas a necesitar y te va ahorrar mucho dinero. Entonces, de nuevo, no es la única, porque estoy mencionando las opciones. Recordemos, tratar de mantener el tráfico en el mismo availability zone en la medida de lo posible y dejar conexiones a los otros availability zones solo con objetivos de replicación de datos, replicación de caché, replicación
en almacenamiento, no se va a lograr al 100, pero intentemos hacerlo en la medida de lo posible.
Bueno, agreguemos ahora, avancemos perdón ahora con algunos consejos relacionados con hardware, verdad, ya mencioné que con EKS tenemos que pagar los nodos, Easy2 instances, verdad, a menos que alguien use Fargate, en ese caso no todos estos consejos van a aplicar si usas Fargate y no Easy2.
pero igual, nuevo, considerar el hardware es muy importante para reducir costos, siempre lo ha sido así históricamente, siempre ha sido así, considerar el hardware no es un consejo único para Kubernetes, sin embargo, voy a dar un poco de consejos orientados a Kubernetes o aplicables a Kubernetes a los cuales le puedan sacar algo práctico.
Y aquí voy con el consejo 6, que va relacionado con hardware y sería implementar saving plans. Saving plans. AWS tiene esto que se llama saving plans que funcionan, son un poco complicados de entender.
pero ya cuando se le entiende en la práctica resulta que sí es bien fácil. Solo toca hacer números y matemáticas complejas porque se hacen cálculos en base a uso de recursos por minuto. Es interesante. Yo lo voy a explicar de forma general y si esto es algo que no estás haciendo y que te interesa implementar, te aconsejo mucho que le dediques tu tiempo propio de investigación. ¿Verdad?
Porque de nuevo, suena un poco complicado y complejo de explicar y entender. Al final no lo es tanto, pero sí, requiere tener la mente bien concentrada al momento de querer entenderlo. Y para explicarlo de manera sencilla funciona como un compromiso de gastos que yo hago con AWS por hora. Un compromiso, me comprometo ya sea por uno o tres años.
no es de uno a tres años es o uno o tres que quede claro porque a veces suena como que pudiera entonces escoger, voy escoger dos años, no es o uno o tres años me comprometo a gastar cierta cantidad de dinero por hora verdad cierta cantidad de dólares para poder computacional para cierta cantidad de cómputo y el uso, el hardware que tenga corriendo
que use ese compromiso que yo hice de ese hardware va a tener un precio reducido.
y el hardware que yo tenga que exceda ese precio va a tener un cobro normal, un cobro de precio on demand y por si suena complicado porque yo sé que suena complicado de nuevo ya en la práctica no es tan fácil, básicamente decir ok yo me comprometo a pagar por decir algo 10 dólares por hora
es 10 dólares por hora, bastante recurso quiero aclarar, pero me comprometo pagar 10 dólares por hora de x cantidad de recurso computacional, entonces y eso me va a reducir ya sea porque me comprometo por un año o por tres años, yo voy a decidir, pero 10 dólares por hora, entonces eso me va dar un precio reducido de hardware, entonces
el hardware que yo tenga corriendo va a consumir primero esos 10 dólares que yo comprometí a un precio reducido, o sea que por esos 10 dólares voy a obtener más recursos de lo normal. Cuando me pase de ello, lo demás tiene un precio con demanda, un precio normal.
esos saving plans ofrecen hasta un 72 % de reducción de costos según la documentación de AWS, 72%, eso es fuerte, eso es bastante. Y de nuevo, si lo que expliqué suena confuso, esa es la manera más fácil que encontré de explicarlo, es que miren, aquí quiero aclarar algo, ¿no?
Inicialmente, lo había pensado explicar como decir, me comprometo a X instancias por X tiempo, correr X instancias por X tiempo, pero eso en realidad explica mejor otro modelo que se llama instancias reservadas, reserve instances.
que no es lo mismo que saving plans. Saving plans tienen un mejor ahorro normalmente, por eso no lo explico de esa manera y espero que al haber dicho esto no haya creado más confusión, yo lo que les quiero mencionar es si les interesa, que se lo recomiendo muchísimo para ahorrar costos, hagan la investigación. Savings plans en AWS tienen diferentes tipos, algunos aplican para firegate, otros aplican para lambda, otros aplican para easytube, pero
es
comprometer cierta cantidad de dinero, ya sea por uno o tres años, cierta cantidad de dinero por hora, ya sea por uno o tres años, y eso me genera hasta 72 % de reducción. Ya en la práctica, quiero aclarar, los costos van a andar dependiendo entre un 25 y en 30%, y es que entre más tiempo me comprometo, me genera más ahorro, pero también tengo la opción de dar
la mitad, si no me recuerdo, la mitad de entrada, como adelantar la mitad, digamos que me comprometo tres años y doy la mitad de entrada y eso me va a generar más ahorro. O puedo dar y comprometerme a un año y pagarlo todo de entrada. Si pago todo de entrada, me va a generar más ahorro. O puedo solamente comprometerme un año sin dar nada de entrada que me estén cobrando mes a mes. Entonces, entre más tiempo me comprometo y más doy por adelantado,
más ahorro recibo. Quiere decir que la manera de recibir el mayor ahorro posible es comprometerme por tres años y dar todo el dinero por adelantado. Eso me va a generar hasta un 72 % dependiendo del caso, lo cual de nuevo es muy poderoso. Si tenés ese dinero y si tenés ese compromiso, estás seguro de que vas a usar esos recursos, hay que hacerlo, hay que hacerlo. Porque eso sí, que quede bien claro algo.
si me comprometo, aunque no de anticipo, aunque no de nada de anticipo, si me comprometo al de tres años AWS me va a cobrar mes a mes a lo que yo me comprometí lo utilice o no lo utilice es así AWS lo va a utilizar, me lo va a estar cobrando lo utilice o no lo utilice entonces el consejo aplicado a EKS sería calcular el consumo mínimo y estable de los nodes on demand que tengo en mi cluster
y en base a eso comprar saving plans que cubran ese consumo base y en eso me comprometo cuando existan spikes y me creen más nodos pues esos nodos van a salir al precio normal verdad pero el tráfico mínimo que yo sé que mínimo va a haber siempre esa cantidad de nodos
ese tráfico lo tengo cubierto con saving plans. De esa manera me ahorro dinero y puedo ahorrarme mínimo un 25 % aproximadamente si adquiero un plan por un año y sin nada de dinero adelantado o puedo llevar esos ahorros hasta un 72 % como ya lo mencioné.
Ahora, continuando los ahorros de tipo hardware, quiero darles el consejo 7, que el consejo 7 ya es ir un poco más profundo, pero ocupamos que nuestros sistemas sean más tolerables al fallo y es implementar Spot Instances. Spot, así como lo escuchan, y si alguien no se ha topado con este concepto antes, los Spot Instances usan capacidad
no utilizada de EasyTool, o sea espacio vacío que va quedando entre los server físicos y según la documentación de AWS ahorran hasta un 90 % del precio de una instancia on demand. Aquellas personas que hemos trabajado con Data Center sabemos que cuando creamos nuestros clúster de VMs, VMware o
o el que sea que estés utilizando como hypervisor, ya tengo bastantes años de que no trabajo directo con VM si estaba olvidando los conceptos, hypervisor, cualquiera que sea que utilices, creas tus clusters de manera de en cada servidor físico utilizar entre un 75 a un 85 % de los recursos en cada servidor físico.
No utilizas el 100 % de cada servidor físico y una de las razones o la razón más importante de esto es porque querés tolerar al fallo. Querés que tu clúster soporte perder uno, dos o hasta tres nodos, dependiendo de tu aplicación, que los pierda y que las VM se engracen esos nodos, comiencen a reiniciarse en los huecos que van quedando en los demás servidores.
eso lo haces por alta disponibilidad vas a experimentar un fallo temporal aunque esperas tener otras VMs en otros nodos corriendo bien pero simplemente quieres tolerar de que se puedan dañar, caer varios nodos y las VMs en esos nodos comiencen a crearse en esos espacios vacíos que van quedando en los otros nodos si tuvieras el nodo por completo lleno todos los nodos a un 95 % de capacidad si perdés uno las VMs corriendo ahí no tienes manera de levantarlas de nuevo
de manera automática, Tienes que ir manualmente y reparar el nodo antes de continuar corriéndolas. Entonces, obviamente, AWS, con su servicio de EasyTool, hace algo similar. Pero ellos son inteligentes. Esos espacios vacíos que tienen ahí, en lugar de tenerlos ahí vacíos y pagando electricidad por ellos y pagando depreciación de hardware por nada.
te los ofrecen hasta por una reducción de un 90%, entonces ellos prefieren cargar el 10 % del costo a no cargar nada. Ahora, como es un espacio vacío, AWS no lo puede garantizar. Ese espacio lo tienen garantizado las instancias Sondeman, las instancias que pagan precio completo. Eso quiere decir de que si...
AWS lo necesita te va a quitar el instance, te da dos minutos de aviso, te manda un aviso en la instancia se va, te la vamos a quitar porque la necesitamos ese recurso y tener en dos minutos se va a caer, entonces esa es la contraparte por eso es que es tan barata, pero si tu aplicación
permite tolerar fallos y tiene self healing que se puede auto sanar que puede esperar a que la réplica se levante en otro lado puedes aprovechar los spot instances
correr tus nodos o muchos nodos o varios nodos o todos los nodos si tienes el valor para hacerlo. Honestamente, solo he escuchado un caso de uso que corren solo spot instances hace muchos años, muchos años antes de Kubernetes. De hecho, se trabajaba con VMs todavía. Un buscador famoso en Europa con esto de seguridad. Yo hablaba con él porque hablaba yo directamente con esta persona.
de el director de IT y mencionaba que el 100 % de su flujo eran spot instances y ellos se sentían muy orgullosos, trabajaban con Puppet en ese momento y tenían automatización.
que les permitía crear, cuando avisaba a AWS que iba a quitar la instancia, creaban otra y tenían self-healing y la aplicación lo permitían y ellos tenían 100 % sus flujos de trabajo con Spot Instances. Me cuenta, yo no lo vi directamente, pero no tengo ninguna razón de dudar de su palabra. En la actualidad, no se usa, yo no miro a nadie que tenga el 100 % en Spot Instances, sin embargo...
buscar mantener la mayoría de instances posibles si tu aplicación lo permite. Aquí el pro tip sería tener un node pool, así se llaman en EKS, node pools que te permiten agregar y quitar más nodos, tener un node pool con instancias donde man y correr la mayor cantidad de
nodos posibles fuera de él con spot instances. En el notepad con instances on demand vas a correr aquellos servicios que toleran menos el fallo, servicios que son indispensables y que querés...
que vas a evitar que estén fallando, estén haciendo self-healing, todo lo que correges en la nube debería de tolerar fallos, todo, porque nada te garantiza 100 % disponibilidad, pero si tenemos esos servicios que toleran menos el fallo o que queremos menos que fallen, eso lo ponemos en Notepools on Demand, la mayor, la menor cantidad de Notepools posibles, pero si eso para ti son 2, 3, 5, 10 Notepools, pues agregar los que necesites, pero que sea la menor cantidad posible.
Para esos node pools on demand adquirí saving plans para que pagues menos dinero por esos node pools on demand y el resto de nodos que sean spot instances. Ese sería el protip que te puedo dar si vas a trabajar con spot instances y con saving plans. Ahora...
El último consejo, el número 8, combina estos dos de una manera un poco más eficiente y menos estar pendiente de tantas cosas de nuestro lado y es que sería, el consejo número 8 sería implementar Karpenter. Karpenter con la letra K de Kubernetes. Yo he hablado ya en varias ocasiones de Karpenter en el pasado, ¿verdad? Pero en palabras sencillas, Karpenter es un cluster autoscaler de Kubernetes.
mejorado, mejorado. El clóset AuroScaler de Kubernetes usa AuroScaler Groups dentro de Kubernetes y va a agregar y va a quitar instancias de diferentes tipos de instancias que tú quieras agregar y quitar y te puede agregar Spot Instances en AWS se llaman FLITs, flotas en español, donde un FLIT tiene diferentes tipos de instancias de diferentes tamaños y puede tener instancias on demand e instancias Spot.
por defecto, ese funciona con AWS, pero Karpenter es mejorado, de hecho fue desarrollado por AWS y lo liberaron, lo pusieron open source, y también permite configurar instancias on demand y instancias spot, spot instances para tus node pools, pero lo hace más potente.
tiene esa habilidad que lo mejora, que le permite considerar otros aspectos para agregar las instancias y manejarlas de manera más eficiente. Con los node groups, por defecto de AWS, sigue dependiendo del auto scaling group de configuraciones un poco más estáticas, poco más estrictas que configuradas, mientras que Karpenter toma decisiones más dinámicas. Se basa en los pods pendientes.
por ser creados en restricciones, en request, en los tipos de instancias permitidos, en las capacidades disponibles, tiene estrategias de consolidación, consolidación que es que tengo nodos corriendo diferentes pods, pero si esos nodos, esos pods que están corriendo regados los puedo tener en menos nodos.
o en nodos más pequeños Karpenter se va a encargar de eso, verdad y Karpenter puede no solo crear Spot Instances, verdad, sino que también Spot Instances del tamaño apropiado y yo he puesto un poco este ejemplo en el pasado pero tenés un servicio que está corriendo y requiere un pod más, ese pod requiere digamos medio CPU y 1 GB de RAM, Karpenter se va a asegurar de agregar la instancia
lo más pequeña posible, sin comprometerle el servicio, lo más pequeña posible para correr ese nuevo pod.
y no dejarte tanto espacio de hardware sin utilizar pagando recursos sin necesidad, ¿verdad? pagando recursos sin necesidad. Entonces, es ahí donde Karpenter se vuelve inteligente y de nuevo la consolidación y eso me pasa es donde lo he visto más utilidad en lo personal a Karpenter. Tu cluster empieza a escalar por tráfico.
y empieza a agregar 2, 3, 4, 5 nodos más por tráfico, cuando el tráfico empieza a bajar entonces le quita 3, 4 pods al nodo 1, le quita 2, 3 pods al nodo 2, le quita 4, 5 pods al nodo 3 y así, entonces quedan luego todos los nodos con pocos pods, entonces Karpenter viendo el tráfico, analizando el tráfico y los diferentes patrones va a mover
los pods a pocas instancias y va a quitar las demás para ahorrar recursos porque había mucho espacio vacío y se encarga de consolidarlo para que tenga suficiente espacio para crecer en caso de un spike, de un incremento en tráfico, un incremento en recursos pero no mucho como para estar malgastando recursos entonces Karpenter definitivamente muy recomendado y
Cierro este consejo del Karpenter contándoles cómo estoy yo actualmente manejando, configurando los nodos en Kubernetes. Esto es como lo hago yo al día de hoy. Y es que tengo un node pool de momento con un máximo de tres nodos. Nunca, no he superado tres nodos hasta el momento. Un node pool, esos son tres nodos estáticos con instancias on demand. Cuando le digo estáticos es que no está autoescalando. Ni agrega más, ni quita nodos.
son tres instancias fijas, ahí corro esos servicios que no quiero que se estén interrumpiendo constantemente, que tal vez toleran menos fallos, o ahí corro incluso el controller de Karpenter, Karpenter tiene su controller, dentro de es un controller, al final es un pod o varios pods corriendo, ahí en esas instancias, en esa node pool fijo,
corre entre otras cosas el controller de Karpenter porque no quiero que esté corriendo un nuevo manejado por carper Karpenter que Karpenter lo saque del cluster y luego ya no está Karpenter corriendo y quedó todo caído no entonces la documentación incluso recomienda hacer algo como eso tengo sus tres nodos fijos para esos tres nodos compro saving plans
para pagar lo menos posible con ellos. Y todo lo demás, configuro Karpenter para que me cree Spot Instances, que priorice Spot Instances y me las agregue de forma dinámica, analizando los patrones, la capacidad necesaria para que me pueda tolerar los flujos, y le agrego un fallback de que si no encuentro una instancia Spot,
que cargue con los recursos, que agregue una instancia on demand.
En muy, muy rara ocasión, termina agregando instancia on demand y cuando lo hace, ocurre, no estoy mintiendo, al menos hasta el momento, ocurre dos o tres veces en un mes que me agrega instancia on demand y lo hace por un lapso de no sé, no más de unos 30 a 40 minutos. Luego de eso...
me agrega otra vez una instancia spot para reemplazarme una instancia on demand. Y de nuevo, me ocurre de dos a tres veces al mes. Y con eso, con esa configuración que les estoy comentando, hemos visto un ahorro significativo en lo que es hardware con respecto a los costos en AWS. Entonces, esos son los consejos que les quería compartir.
Hay más consejos, hay muchos más orientados siempre al ahorro de recursos, hay consejos alrededor del almacenamiento, alrededor del manejo de caché, etcétera, etcétera, pero esos son algunos prácticos que yo sé que si los comienzan a implementar, si comienzan a indagar, si comienzan a ver, les van a ir generando ahorro, la acumulación de estos consejos les van a ir generando un ahorro considerado. Espero que le hayan podido encontrar valor a estos consejos, a este tema.
compartan este vídeo, este episodio con alguien que ustedes consideren que le puede beneficiar esta información que tal vez está lidiando con problemas de costos en Kubernetes o que se ha topado con incrementos en factura recientemente, compartan esta información.
Si de alguno de los consejos o herramientas que mencioné hoy quisieran que que habláramos un poco más a profundidad, déjenoslo saber en los comentarios. De esa manera podemos elaborar un episodio un poco hablando un poco más al respecto y pues con suerte desarrollando el tema ya con Juan de regreso. Eso ha sido todo por hoy. Les agradezco muchísimo por la atención brindada. Nos veremos en el próximo episodio. Adiós.