ECS vs EKS: ¿Qué servicio de contenedores de AWS es el adecuado para ti?

¿Qué es el ECS?

ECS es el servicio gestionado de orquestación de contenedores propio de Amazontary. Proporciona una forma sencilla y segura de ejecutar aplicaciones en contenedores. Diseñado para la simplicidad, ECS reduce las decisiones de los clientes en cuanto a configuraciones informáticas, de red y de seguridad, sin sacrificar la escala ni las prestaciones.

Hay algunas terminologías y componentes con los que debes familiarizarte para el ECS.

1. Grupo
2. Proveedor de capacidad
3. Definición de la tarea
4. Tarea
5. Servicio

Grupo

Un clúster ECS se compone de servicios, tareas y proveedores de capacidad. También contiene el plano de control ECS, que gestiona AWS y no es visible para nosotros.

Proveedor de capacidad

Los contenedores necesitan un servidor en el que ejecutarse, ya sea una máquina virtual en la nube o tu ordenador local. En el contexto de ECS, puedes seleccionar el "Tipo de lanzamiento" para ejecutar tus contenedores en Elastic Compute Cloud (EC2) o Fargate.

Pestaña Infraestructura de la consola de AWS ECS.

Tarea

Una tarea es un conjunto de contenedores en ejecución configurados según una definición de tarea. Esencialmente, representa una instancia de una definición de tarea, de forma similar a como un contenedor sirve como instancia de una imagen.

Definición de la tarea

Tenemos un Dockerfile para nuestra aplicación y hemos creado una imagen a partir de él. Empujamos la imagen a un registro de contenedores como DockerHub o AWS ECR. ¿Y ahora qué? Procedemos a crear una definición de tarea, que es una configuración o plano para nuestros contenedores (que se desplegarán en un clúster ECS) que incluye la siguiente información:

• Imagen(es). Una tarea puede contener más de una imagen.
• El número de puerto que se utilizará para comunicarse con nuestra aplicación.
• Volúmenes.
• Recursos (CPU y memoria) a reservar para nuestras aplicaciones.

Definición de la tarea en la consola de AWS ECS.

Servicio

¿Qué ocurre cuando ejecutamos un contenedor autónomo y se bloquea? No ocurre nada. Permanece en estado de colisión. Este comportamiento es idéntico si creamos una tarea independiente en ECS. Utilizamos el servicio ECS para garantizar que nuestras aplicaciones estén siempre activas. Un servicio garantiza que un número deseado de tareas estén en funcionamiento en todo momento.

Si una tarea se bloquea o el servidor subyacente que la aloja (y por tanto el contenedor) se cae, el servicio creará una nueva tarea en un proveedor de capacidad disponible.

Implantación del SCE

Ahora que ya hemos cubierto los aspectos básicos de ECS, vamos a ejecutar una imagen simple de Nginx y a acceder a ella. Utilizando el cluster ECS y la definición de tarea anteriores, crearé un servicio que haga referencia a la definición de tarea:

Servicios en la consola de AWS ECS.

Este servicio, a su vez, creará una tarea.

Una tarea en la consola de AWS ECS.

Acceder a la dirección IP pública de la tarea:

Se ha accedido con éxito a la aplicación que se ejecuta en el ECS.

¿Qué es el EKS?

Antes de sumergirte en el Servicio Elástico de Kubernetes(EKS), es esencial entender qué es Kubernetes. Kubernetes es un motor de orquestación de contenedores de código abierto que automatiza el despliegue, escalado y gestión de aplicaciones en contenedores. 

Para saber más, te recomiendo que consultes el curso Introducción a Kubernetes. 

Sin embargo, arrancar y gestionar un clúster Kubernetes desde cero puede ser complejo y llevar mucho tiempo. Muchos componentes y configuraciones necesarios para poner en marcha Kubernetes son similares en todas las organizaciones y equipos. Para abstraer este trabajo pesado indiferenciado y simplificar la adopción de Kubernetes, AWS desarrolló EKS.

EKS es un servicio gestionado de Kubernetes proporcionado por AWS que se encarga de gran parte de la sobrecarga operativa. Simplifica la implantación, el escalado y la gestión de Kubernetes gestionando el plano de control en nombre de los usuarios. Al abstraer la necesidad de administrar estos componentes, Amazon EKS permite a los usuarios centrarse en ejecutar sus cargas de trabajo en contenedores y administrar los nodos trabajadores o las tareas de Fargate.

Esta sección trata brevemente del EKS. Para obtener más información, consulta el artículo Fundamentos de la orquestación de contenedores con el servicio AWS Elastic Kubernetes (EKS).

Hay algunas terminologías y componentes con los que debes familiarizarte para el EKS:

1. Clúster (nodos maestro y trabajador)
2. Archivos de manifiesto
3. Vainas
4. ReplicaSet
5. kubectl utilidad de línea de comandos

Grupo

Un clúster de Kubernetes es un grupo de servidores o máquinas virtuales en los que se ejecutan las cargas de trabajo de Kubernetes. Está formado por el nodo maestro (comúnmente llamado plano de control) y los nodos trabajadores. 

En EKS, el nodo maestro lo gestiona AWS en su propia VPC; está abstraído de nosotros. Mientras tanto, podemos gestionar los nodos trabajadores mediante instancias EC2 o ir sin servidor utilizando Fargate.

Conectividad de red del plano de control EKS. Fuente de la imagen: AWS

Vainas

Un pod es un recurso de la API de Kubernetes. Son las unidades desplegables más pequeñas de Kubernetes. Son un grupo de uno o más contenedores y contienen especificaciones sobre la imagen que se va a utilizar, el puerto, los comandos, etc.

Pestaña Recursos de la consola de AWS EKS.

ReplicaSet

Idéntico a un pod, un ReplicaSet también es un recurso de la API de Kubernetes. Garantiza que el número deseado de vainas esté siempre en funcionamiento.

Archivos de manifiesto

Los archivos de manifiesto de Kubernetes son archivos de configuración que se utilizan para definir el estado deseado de los recursos de Kubernetes de forma declarativa. Estos archivos describen qué recursos deben existir en un clúster Kubernetes, sus configuraciones y cómo interactúan entre sí.

Los archivos de manifiesto suelen escribirse en YAML:

# pod.yml - Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.27
    ports:
    - containerPort: 80

# service.yml - Kubernetes Service manifest
apiVersion: v1
kind: Service
metadata:
  name: nginx-node-port-service
spec:
  type: NodePort 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 31000

kubectl

Utilidad de línea de comandos para comunicarse con el clúster Kubernetes. Podemos utilizar el comando kubectl para crear, gestionar y eliminar recursos de Kubernetes de forma imperativa o utilizarlo junto con los archivos de manifiesto de forma declarativa.

# Create a pod that runs a container with the nginx:1.27 image
kubectl run nginx-pod --image nginx:1.27 
# Create a replicaset with 2 pods
kubectl create replicaset --replicas=2 --image nginx:1.27

Aplicación del EKS

Vamos a demostrar ahora cómo funciona EKS ejecutando y accediendo a la misma imagen Nginx. 

Para simplificar, crearé una instancia/nodo de trabajo EC2 en una subred pública, desplegaré la aplicación allí, la expondré mediante un recurso de servicio Kubernetes de tipo NodePort, y accederé a ella a través de la IP pública de la instancia. 

Utilizaré el manifiesto de pods y servicios anterior y el comando kubectl para crear el pod:

# Update local .kube/config file
aws eks update-kubeconfig --region ap-southeast-1 --name i-love-datacamp-eks-cluster
# Create the pod
kubectl create -f pod.yml
# Create the service
kubectl create -f service.yml

El clúster EKS tiene una instancia EC2:

Instancia EC2/nodo de trabajo.

Localiza la dirección IPv4 pública de la instancia.

La dirección IP pública de la instancia EC2/nodo trabajador.

Accediendo a la dirección IP pública de la instancia con el puerto 31000:

Se ha accedido con éxito a la aplicación que se ejecuta en el EKS.

ECS frente a EKS: Similitudes

Ahora que hemos cubierto los aspectos básicos de ECS y EKS, podemos ver algunas similitudes entre ellos. Esto no es sorprendente, ya que ambas son herramientas de orquestación de contenedores.

Capacidad de cálculo

Ambos servicios permiten que las aplicaciones se ejecuten en EC2, donde los usuarios son responsables de mantener, parchear y actualizar las instancias EC2, o en AWS Fargate, la opción de computación sin servidor donde AWS gestiona los servidores subyacentes, eliminando la necesidad de gestionar la infraestructura.

Modelo de gestión de la carga de trabajo

Ambos servicios tienen estructuras y enfoques similares para gestionar y mantener los recursos de las aplicaciones.

En AWS ECS, la configuración que define cómo deben ejecutarse los contenedores se denomina definición de tarea, mientras que en AWS EKS, esto se consigue mediante un archivo de manifiesto de pod. Una vez desplegada, la aplicación en contenedores en ECS se ejecuta dentro de una tarea, mientras que en EKS, se ejecuta dentro de un pod. Para garantizar que un número determinado de tareas o pods estén siempre en ejecución, ECS utiliza un servicio, mientras que EKS se basa en un conjunto de réplicas para esta funcionalidad.

Profunda integración con otros servicios de AWS

Como servicio de contenedores en AWS, Amazon hizo un gran esfuerzo para garantizar que ECS y EKS se integraran bien con otros servicios de AWS. 

En cuanto a las redes, existe Amazon VPC, que permite que los contenedores se ejecuten en entornos aislados con control total sobre las configuraciones de red, los grupos de seguridad y las subredes. Equilibradores de carga para dirigir el tráfico a los contenedores. 

Existen soluciones, como EBS, EFS y S3, para gestionar los requisitos de almacenamiento persistente de las aplicaciones en contenedores.

Ambos servicios utilizan AWS IAM para controlar el acceso y los permisos de forma granular. Esto dicta a qué recursos de AWS puede acceder la aplicación en contenedor, como S3, DynamoDB o RDS.

Resumen de similitudes clave

ECS frente a EKS: Diferencias

Comprender las diferencias entre Amazon ECS y Amazon EKS es importante a la hora de decidir entre ellos. 

En esta sección, desglosaremos sus principales diferencias en cuanto a facilidad de uso, escalabilidad, personalización y coste, para ayudarte a determinar qué servicio se ajusta mejor a tus requisitos técnicos y objetivos empresariales.

Facilidad de uso y curva de aprendizaje

EKS se basa en Kubernetes, por lo que se requiere familiaridad con los conceptos y herramientas de Kubernetes. Por tanto, la curva de aprendizaje del EKS será más pronunciada que la del ECS. Esto implica comprender cómo funciona el comando kubectl y algunos otros recursos básicos esenciales de la API de Kubernetes, como los servicios (no confundir con el término "servicios" utilizado en el contexto de ECS), los mapas de configuración, el ingreso, etc. La sección "Qué es el EKS" apenas araña la superficie de lo que ofrece el EKS.

ECS y EKS requieren conocimientos de servicios de AWS como CloudWatch, IAM, ASG, etc. Afortunadamente, eso es todo lo que se necesita para ECS, pero no para EKS. Por tanto, ECS gana en facilidad de uso.

Escalabilidad

Ambos servicios pueden escalar igual de bien si se configuran adecuadamente. Sin embargo, la forma en que se escalan difiere. ECS admite el autoescalado mediante el Autoescalado de Servicio ECS para tareas y el Autoescalado de Cluster ECS para instancias. Sólo utiliza servicios nativos de AWS, como las métricas de CloudWatch y las políticas de escalado de ASG.

Sin embargo, EKS utiliza funciones de escalado nativas de Kubernetes, como Horizontal Pod Autoscaler (HPA) para los pods y Cluster Autoscaler para las instancias. El Cluster Autoscaler no está instalado en el cluster EKS por defecto y, por tanto, requiere que el usuario lo instale por sí mismo. Esto añade complejidad, ya que se requiere la configuración adecuada tanto en los recursos de AWS (p. ej., roles IAM) como en los recursos de la API de Kubernetes (p. ej., cuentas de servicio) para que funcione el Cluster Autoscaler, lo que requiere realizar llamadas a la API de AWS para escalar hacia dentro y hacia fuera.

Una nueva función de EKS, EKS AutoMode, lanzada recientemente, puede resolver esta complejidad añadida. Descarga la gestión y el escalado de los nodos trabajadores EKS a AWS, pero conlleva costes adicionales.

Flexibilidad y personalización

Como ya se ha mencionado, ECS es el servicio de orquestación de contenedores gestionado por Amazon, diseñado para la simplicidad. AWS se encarga de la mayor parte de las tareas de gestión de clústeres, ofreciendo configuraciones predefinidas que se adaptan a las cargas de trabajo comunes de los contenedores, pero que pueden no satisfacer requisitos de nicho. Aunque reduce la complejidad, limita las opciones de personalización en comparación con Kubernetes.

EKS proporciona toda la potencia de Kubernetes, permitiendo a los usuarios personalizar las implantaciones, la programación de pods, las clases de almacenamiento y las políticas de red para adaptarlas a sus necesidades. Las funciones avanzadas de orquestación, como las definiciones de recursos personalizadas (CRD) y los operadores, permiten una flexibilidad sin precedentes en el diseño de aplicaciones. 

EKS también puede integrarse con varias herramientas y complementos de código abierto del ecosistema Kubernetes, como Prometheus, Grafana e Istio, lo que permite a los desarrolladores crear soluciones muy personalizadas. Así, EKS gana la competición por flexibilidad y personalización.

Coste

Además de los costes estándar de los recursos de red (por ejemplo, direcciones IPv4 públicas, pasarelas NAT) y de los recursos informáticos y de almacenamiento (por ejemplo, instancias EC2, Fargate y volúmenes EBS) que se aplican tanto a ECS como a EKS, ECS tiene un coste más bajo y una estructura de costes mucho más sencilla.

El plano de control ECS no tiene coste alguno. En otras palabras, si crearas un clúster ECS sin ninguna tarea en ejecución, no incurrirías en ningún coste. Mientras tanto, para EKS, hay costes para el plano de control gestionado por AWS, independientemente de si tienes alguna aplicación ejecutándose en el clúster de Kubernetes.

El coste del plano de control EKS varía en función de la versión de Kubernetes utilizada. Una versión de Kubernetes con soporte estándar cuesta 0,10 $ por clúster y hora, mientras que una con soporte ampliado cuesta 0,60 $ por clúster y hora.

Resumen de las principales diferencias

¿Cuándo elegir ECS?

La elección depende de los requisitos de tu aplicación, los objetivos empresariales, la experiencia del equipo, el presupuesto operativo y las prioridades generales.

El ECS, al ser más sencillo y rentable, es ideal para equipos con presupuestos más ajustados, necesidades de comercialización más cortas y una preferencia por las operaciones racionalizadas. Es especialmente adecuado para aplicaciones que no requieren portabilidad a través de entornos multi-nube o híbridos, y está diseñado para ejecutarse exclusivamente en AWS. Como servicio específico de AWS, ECS se alinea perfectamente con las cargas de trabajo confinadas en el ecosistema de AWS.

Aunque tanto ECS como EKS admiten Fargate para despliegues de contenedores sin servidor, ECS ofrece una integración más sencilla. Con ECS, puedes elegir directamente las tareas que se ejecutarán en Fargate sin necesidad de configuración adicional. En cambio, Fargate con EKS requiere especificar las etiquetas de los pods para determinar qué cargas de trabajo deben ejecutarse en Fargate, lo que añade una capa de complejidad. Esto hace que ECS sea una opción atractiva para los equipos que buscan una experiencia sin servidor más sencilla.

¿Cuándo elegir el EKS?

Kubernetes, la plataforma subyacente de EKS, es independiente de la nube, lo que permite que las cargas de trabajo se ejecuten de forma coherente en AWS, otros proveedores de nube y entornos locales. Esta portabilidad es especialmente beneficiosa para las organizaciones que operan en configuraciones multi-nube o en infraestructuras híbridas locales. Azure y Google Cloud también ofrecen servicios gestionados de Kubernetes -Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE), respectivamente-, lo que pone de relieve la ubicuidad de Kubernetes en los entornos modernos en la nube.

EKS es ideal si tu aplicación o caso de uso requiere una personalización y extensibilidad avanzadas. Por ejemplo, Kubernetes admite la creación de Definiciones de Recursos Personalizadas (CRD), que te permiten definir recursos personalizados para gestionar configuraciones específicas de aplicaciones o integrarse con sistemas externos. Esta flexibilidad es un elemento diferenciador clave para EKS.

Aunque EKS abstrae el plano de control y depende de AWS para gestionarlo, operar eficazmente en un entorno EKS sigue exigiendo familiaridad con los recursos y conceptos de la API de Kubernetes. Por lo tanto, la experiencia del equipo en Kubernetes es crucial para aprovechar eficazmente la plataforma.

EKS también ofrece una amplia gama de complementos personalizables que pueden instalarse para ampliar la funcionalidad del clúster. Estos complementos facilitan el aprovisionamiento de un clúster con las herramientas operativas necesarias, simplificando la configuración y mejorando la productividad.

Selección de complementos EKS.

En resumen, EKS es muy adecuado para arquitecturas de microservicios o aplicaciones con numerosos componentes interconectados que requieren un alto control y granularidad. Es especialmente ventajoso para los equipos que necesitan opciones avanzadas de personalización u operan en entornos en los que la portabilidad de la carga de trabajo es esencial.

ECS frente a Diagrama de flujo de la decisión EKS. Imagen del autor.

Herramientas e integraciones

Tanto si se trata de una aplicación en contenedores como de una aplicación que se ejecuta directamente en una máquina virtual, la supervisión y la observabilidad son primordiales. Al estar en el ecosistema de AWS, tanto ECS como EKS pueden aprovechar las herramientas de AWS y los servicios de terceros para mejorar todo el ciclo de vida de desarrollo de software (SDLC) de las aplicaciones en contenedores.

Monitorización y registro

La supervisión y el registro son esenciales para la visibilidad de tus aplicaciones e infraestructura. AWS proporciona herramientas nativas y admite integraciones de terceros tanto para ECS como para EKS, como Amazon CloudWatch para métricas, registros y alarmas. 

AWS X-Ray para rastrear solicitudes en microservicios facilita el análisis y la depuración de problemas de rendimiento en tareas ECS o pods EKS. Herramientas de terceros, como Datadog, Prometheus, Grafana y New Relic, proporcionan capacidades mejoradas de visualización y alerta adaptadas a los contenedores.

Canalizaciones CI/CD

Las canalizaciones CI/CD ayudan a automatizar pruebas, análisis y despliegues, garantizando iteraciones más rápidas y reduciendo el esfuerzo manual. Las herramientas CI/CD más populares, como los pipelines de GitLab y las Acciones de GitHub, se integran con ECS y EKS para permitir la creación, prueba y despliegue de contenedores. Estas herramientas funcionan con contenedores Docker para ECS o gráficos Helm para EKS.

Infraestructura como código (IaC)

IaC es crucial para crear una infraestructura coherente y repetible, minimizar el tiempo de aprovisionamiento y reducir el riesgo de error humano asociado a las configuraciones manuales a través de la consola de administración de AWS. 

Entre las herramientas de IaC más populares están Terraform y AWS CloudFormation. Aunque ambos se utilizan ampliamente, Terraform suele preferirse por sus capacidades agnósticas de la nube, que permiten a los equipos gestionar la infraestructura de varios proveedores de nube con una sola herramienta.

Redes y seguridad

AWS proporciona sólidas funciones de red y seguridad tanto para ECS como para EKS para garantizar una comunicación y un control del acceso seguros, como la red AWS VPC para aislar los recursos dentro de subredes privadas. AWS WAF y Escudo: Protege las aplicaciones alojadas en ECS y EKS de las vulnerabilidades web comunes y de los ataques DDoS. AWS KMS para cifrar los volúmenes de EBS y los secretos de Kubernetes almacenados en etcd.

Conclusión

ECS y EKS son dos sólidos servicios de orquestación de contenedores proporcionados por AWS, cada uno de ellos adaptado para satisfacer las diferentes necesidades de las aplicaciones y las prioridades de los equipos. 

ECS es más fácil para empezar, más sencillo de aprovisionar, desplegar y mantener, y tiene menores costes operativos. En cambio, EKS tiene una curva de aprendizaje más pronunciada y una mayor complejidad inicial, pero ofrece una flexibilidad inigualable y opciones de personalización avanzadas, lo que lo hace ideal para equipos con requisitos especializados o complejos. 

La elección entre ECS y EKS depende de las necesidades de tu aplicación, de la experiencia del equipo y del equilibrio deseado entre sencillez y control.

Si quieres reforzar tus conocimientos sobre AWS, el curso Conceptos de AWS es un buen punto de partida. Para profundizar en las herramientas y tecnologías de AWS, consulta el curso Tecnología y servicios en la nube de AWS. Además, para quienes estén interesados en dominar la contenedorización, el Tema de Contenedorización y Virtualización ofrece valiosos conocimientos que te ayudarán a destacar en la gestión y despliegue de contenedores.