Serie Híbrida EKS: Cambiando espacios de nombres de implementación sin servidor

En el post anterior de esta serie sobre cómo configurar un clúster EKS híbrido utilizando tanto máquinas EC2 tradicionales como opciones sin servidor usando Fargate, pudimos crear el clúster EKS con ambas modalidades de implementación disponibles. ¡Si aún no lo has visto, hazlo ahora! https://medium.com/@alexandrev/hybrid-aws-kubernetes-cluster-using-eks-ec2-and-fargate-13198d864baa En ese punto, tenemos un clúster vacío con todo listo para desplegar nuevas cargas de trabajo, pero aún necesitamos configurar algunas cosas antes de realizar el despliegue. Lo primero es decidir qué cargas de trabajo se van a desplegar usando la opción sin servidor y cuáles usarán la opción tradicional de EC2. Por defecto, todas las cargas de trabajo desplegadas en los espacios de nombres default y kube-system como puedes ver en la imagen a continuación desde la Consola de AWS:

Eso significa que todas las cargas de trabajo del espacio de nombres default y del espacio de nombres kube-system se desplegarán de manera sin servidor. Si eso es lo que deseas, perfecto. Pero a veces te gustaría comenzar con un conjunto delimitado de espacios de nombres donde te gustaría usar la opción sin servidor y confiar en el despliegue tradicional. Podemos verificar esa misma información usando eksctl y para hacerlo necesitamos escribir el siguiente comando:

eksctl get fargateprofile --cluster cluster-test-hybrid -o yaml

La salida de ese comando debería ser algo similar a la información que podemos ver en la Consola de AWS:

- name: fp-default
 podExecutionRoleARN: arn:aws:iam::938784100097:role/eksctl-cluster-test-hybrid-FargatePodExecutionRole-1S12LVS5S2L62
 selectors:
 — namespace: default
 — namespace: kube-system
 subnets:
 — subnet-022f9cc3fd1180bb8
 — subnet-0aaecd5250ebcb02e
 — subnet-01b0bae6fa66ecd31

NOTA: Si no recuerdas el nombre de tu clúster solo necesitas escribir el comando eksctl get clusters

Entonces, esto es lo que vamos a hacer y para hacerlo lo primero que necesitamos hacer es crear un nuevo espacio de nombres llamado “serverless” que va a contener nuestro despliegue sin servidor y para hacerlo usamos un comando kubectl de la siguiente manera:

kubectl create namespace serverless

Y ahora, solo necesitamos crear un nuevo perfil de fargate que va a reemplazar el que tenemos en este momento y para hacerlo necesitamos usar nuevamente eksctl para manejar ese trabajo:

eksctl create fargateprofile --cluster cluster-test-hybrid --name fp-serverless-profile --namespace serverless

NOTA: También podemos usar no solo el espacio de nombres para limitar el alcance de nuestro despliegue sin servidor sino también etiquetas, por lo que podemos tener en el mismo espacio de nombres cargas de trabajo que se despliegan usando el despliegue tradicional y otras usando la modalidad sin servidor. Eso nos dará todas las posibilidades para diseñar tu clúster como desees. Para hacerlo, añadiremos el argumento labels en un formato clave=valor.

Y obtendremos una salida similar a esta:

[ℹ] creando perfil de Fargate “fp-serverless-profile” en el clúster EKS “cluster-test-hybrid”
[ℹ] creado perfil de Fargate “fp-serverless-profile” en el clúster EKS “cluster-test-hybrid”

Si ahora verificamos el número de perfiles que tenemos disponibles deberíamos obtener dos perfiles manejando tres espacios de nombres (los que son gestionados por el perfil por defecto — default y kube-system — y el que — serverless — es gestionado por el que acabamos de crear ahora) Solo usaremos el siguiente comando para eliminar el perfil por defecto:

eksctl delete fargateprofile --cluster cluster-test-hybrid fp-default

Y la salida de ese comando debería ser similar a esta:

[ℹ] eliminado perfil de Fargate “fp-default” en el clúster EKS “cluster-test-hybrid”

Y después de eso, ahora tenemos listo nuestro clúster con un alcance limitado para despliegues sin servidor. En el próximo post de la serie, solo desplegaremos cargas de trabajo en ambas modalidades para ver la diferencia entre ellas. Así que, no te pierdas las actualizaciones sobre esta serie asegurándote de seguir mis publicaciones, y si te gustó el artículo, o tienes algunas dudas o comentarios, por favor deja tus comentarios usando los comentarios a continuación!

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.