← Volver al catálogo

Amazon EKS

Amazon Elastic Kubernetes Service (Amazon EKS)

En una frase: Plano de control gestionado para clústeres del orquestador de contenedores de la CNCF (Cloud Native Computing Foundation: fundación que mantiene Kubernetes y otros proyectos cloud native)
Categoría: Contenedores (Containers)
Certificaciones: SAA-C03 SAP-C02 AIF-C01 CLF-C02 DVA-C02
Documentación oficial: Documentación de Amazon EKS ↗

Qué es

Amazon EKS (Elastic Kubernetes Service) ejecuta Kubernetes estándar y certificado sin que tengas que instalar ni mantener su plano de control (API (Application Programming Interface: interfaz para que los programas se comuniquen) server, etcd, programador): AWS lo reparte en varias zonas de disponibilidad, lo parchea y lo escala. Tus aplicaciones se despliegan con las herramientas habituales de Kubernetes (kubectl, Helm, manifiestos YAML (YAML Ain't Markup Language: formato de configuración legible)), así que son portables a otros entornos Kubernetes.

Conceptos clave

  • Plano de control gestionado: se paga por hora por clúster; AWS lo mantiene disponible en tres zonas.
  • Opciones para el plano de datos (dónde corren los pods):
    • EKS Auto Mode: AWS aprovisiona, escala, parchea y actualiza los nodos, e incluye el balanceo de carga, el almacenamiento en bloque y la red.
    • Grupos de nodos gestionados: instancias EC2 (Elastic Compute Cloud) en un grupo de Auto Scaling que EKS ayuda a crear y actualizar.
    • Nodos autogestionados: control total, toda la operación es tuya.
    • Fargate: cada pod en su propio entorno sin servidores (sin DaemonSets ni GPU (Graphics Processing Unit: procesador gráfico, muy usado en ML)).
  • Escalado: el Horizontal Pod Autoscaler cambia el número de pods; Karpenter (o Cluster Autoscaler) añade y quita nodos según los pods pendientes.
  • Permisos de los pods: EKS Pod Identity (recomendado) o IRSA (roles de IAM (Identity and Access Management) para cuentas de servicio con OIDC (OpenID Connect: estándar de identidad sobre OAuth 2.0)) asocian un rol de IAM a una cuenta de servicio de Kubernetes, sin usar el rol del nodo.
  • Acceso al clúster: access entries de EKS vinculan usuarios y roles de IAM con permisos de Kubernetes (sustituyen al antiguo ConfigMap aws-auth).
  • Complementos (add-ons): VPC (Virtual Private Cloud) CNI (cada pod recibe una IP (Internet Protocol: dirección de red) de la VPC), CoreDNS, kube-proxy, controladores de EBS (Elastic Block Store) o EFS (Elastic File System), AWS Load Balancer Controller.
  • Versiones: cada versión de Kubernetes tiene soporte estándar y luego un soporte extendido de pago; hay que planificar las actualizaciones.
  • EKS Anywhere y EKS en Outposts para ejecutar clústeres fuera de las regiones de AWS.

Casos de uso típicos

  • Organizaciones que ya usan Kubernetes y quieren dejar de operar el plano de control.
  • Plataformas internas multiequipo con espacios de nombres, políticas y GitOps.
  • Entrenamiento e inferencia de ML (Machine Learning: aprendizaje automático) con GPU y herramientas del ecosistema (Kubeflow, Ray).
  • Estrategias híbridas o multinube con la misma API en todas partes.

Cuándo NO usarlo

ECS frente a EKS

CaracterísticaECSEKS
APIPropia de AWSKubernetes estándar
Coste del plano de controlGratisPor hora y por clúster
Curva de aprendizajeBajaAlta
PortabilidadSolo AWSCualquier Kubernetes
Sin servidoresFargateFargate o Auto Mode

Modelo de precios

Se paga una tarifa por hora por cada clúster (más alta si la versión está en soporte extendido), más la capacidad donde corren los pods: instancias EC2 y volúmenes, vCPU y memoria de Fargate, o el cargo de gestión de Auto Mode sobre las instancias. Aparte, balanceadores, transferencia de datos y NAT (Network Address Translation: traducción de direcciones de red). Spot y Savings Plans reducen el coste de los nodos.

Seguridad y alta disponibilidad

  • Plano de control replicado en varias zonas por AWS; los nodos, repartidos en varias zonas por ti (o por Auto Mode).
  • Pod Identity o IRSA para dar a cada aplicación solo sus permisos, nunca el rol del nodo.
  • Endpoint del API server público, privado o ambos; con acceso privado solo se llega desde la VPC.
  • Cifrado de los secretos de Kubernetes con una clave de KMS (Key Management Service).
  • Security groups por pod y políticas de red de Kubernetes para aislar el tráfico.

Trampas de examen

  • "Kubernetes", "Helm" o "kubectl" en el enunciado: EKS.
  • "Un pod necesita permisos de AWS": Pod Identity o IRSA, no el rol del nodo.
  • "Kubernetes sin gestionar nodos": EKS Auto Mode o Fargate.
  • "Añadir nodos rápido y con el tipo de instancia justo": Karpenter.
  • "Clústeres en el propio centro de datos con la misma herramienta": EKS Anywhere.
  • "Contenedores con la menor sobrecarga operativa y sin Kubernetes": ECS con Fargate.

Preguntas de práctica

Preguntas originales escritas para estos apuntes. No son preguntas reales de examen.

Fuentes