Saltar a contenido

AWS: EKS, RDS y plataforma

El despliegue AWS se divide en cuatro raíces. La red y la base de datos permanecen fuera de Kubernetes; los servicios web y rest se ejecutan en EKS. El controlador de balanceadores traduce el Ingress de la aplicación a un ALB, pero ese ALB es un recurso creado indirectamente por el controlador, no un aws_lb declarado en las raíces Terraform.

Red y tráfico

aws/network consume terraform-aws-modules/vpc/aws con restricción ~> 5.0. Selecciona tantas zonas de disponibilidad como subredes privadas haya en la lista, tomando las primeras zonas disponibles que devuelve AWS.

Configuración Predeterminado versionado Consecuencia
Región eu-west-1 Todas las raíces AWS deben coincidir
Nombre base gitlab-terraform-eks No incorpora ENVIRONMENT automáticamente
VPC 10.0.0.0/16 Red privada de la implementación AWS
Privadas 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 Nodos EKS y grupo de subredes RDS
Públicas 10.0.4.0/24, 10.0.5.0/24, 10.0.6.0/24 Recursos públicos del módulo y selección para ALB
NAT Activado; un solo NAT Gateway Salida compartida para las subredes privadas
DNS Hostnames y soporte DNS habilitados Resolución interna y endpoints gestionados

Las subredes públicas llevan kubernetes.io/role/elb=1; las privadas, kubernetes.io/role/internal-elb=1. Estas etiquetas permiten al controlador descubrir subredes para balanceadores. No asignan por sí mismas una aplicación a Internet: el Ingress es quien solicita el balanceador externo.

El diseño de un único NAT reduce el número de gateways, pero concentra la salida y puede introducir tráfico entre zonas. No debe presentarse como una estrategia de alta disponibilidad de salida. La memoria explica la elección de tamaños pequeños por el alcance demostrador (§7.2.7, página 44 / PDF 50); no atribuye explícitamente al autor todos los compromisos de disponibilidad de cada ajuste.

EKS y sus identidades

aws/kubernetes consume terraform-aws-modules/eks/aws (~> 20.0) y los outputs de network. Configura:

  • Nombre gitlab-terraform-eks y versión de Kubernetes 1.31.
  • Nodos en las subredes privadas.
  • API público habilitado, CIDRs permitidos 0.0.0.0/0.
  • Permisos administrativos para la identidad creadora del clúster.
  • Un managed node group default, tipo t3.small, deseado 1, mínimo 1 y máximo 3.
  • Límite de indisponibilidad del 33 % durante actualizaciones del grupo.
  • IRSA y complemento aws-ebs-csi-driver.

La versión 1.31 es el valor del código, no una recomendación de versión para un despliegue nuevo. Antes de recrear el laboratorio se debe comprobar la disponibilidad y el soporte de esa versión en la región y ajustar la configuración mediante un cambio revisado.

Los límites 1–3 del node group no prueban escalado automático según carga o pods pendientes. No se declara Cluster Autoscaler ni Karpenter. AWS distingue la configuración de capacidad del mecanismo que modifica la capacidad según las cargas; véase autoscaling en EKS.

EBS CSI con IRSA

El rol AmazonEKSTFEBSCSIRole-<cluster> se crea con el módulo IAM 5.39.0, asume la identidad OIDC del clúster y restringe el sujeto a system:serviceaccount:kube-system:ebs-csi-controller-sa. Recibe la política gestionada AmazonEBSCSIDriverPolicy; el add-on recibe el ARN de ese rol.

La asociación es con la cuenta de servicio del controlador, no una concesión general de esa política al rol de todos los nodos. El driver habilita una capacidad de almacenamiento: los manifiestos demostradores revisados no declaran PVC para web ni rest, ya que los datos se guardan en RDS.

RDS MySQL

La capa database consume la VPC y las subredes de network, y el security group de los nodos desde kubernetes mediante el alias de estado eks.

Parámetro Valor del código
Motor MySQL 8.0
Clase db.t4g.micro
Almacenamiento gp3, 20 GiB iniciales, máximo 100 GiB
Base y puerto restdb, TCP 3306
Usuario inicial restuser; contraseña obligatoria y sensible
Exposición publicly_accessible=false
Disponibilidad multi_az=false
Backups Retención automática de 1 día
Protección de eliminación Desactivada
Snapshot final Se omite por defecto
Aplicación de modificaciones apply_immediately=true

El security group de RDS acepta MySQL desde el security group de los nodos EKS y permite salida general. Esto proporciona un límite a nivel de red entre la base de datos y los clientes, pero no sustituye la autorización de usuarios SQL ni una política de red entre pods.

Los outputs publican host, puerto, base, usuario sensible, IDs de seguridad y URL JDBC. La contraseña se entrega como entrada y participa en el estado; el marcador sensitive no elimina el secreto de la persistencia de IaC. Véase protección de estados y planes.

Preparación de la plataforma

aws/platform necesita el API de EKS accesible desde el runner. Los proveedores Kubernetes y Helm ejecutan aws eks get-token con la identidad AWS del job, el nombre del clúster y la región. Esta ruta de bootstrap es distinta del acceso posterior de los pipelines de aplicación a través del Agent.

Recurso Función
Namespace app Aloja las cargas demostradoras
Secret rest REST_DB_HOST, REST_DB_PORT, REST_DB_DATABASE, REST_DB_USER, REST_DB_PASSWORD
Namespace gitlab-agent Aloja el agente
Release Helm gitlab-agent Configura KAS y el token de agente suministrados
Service account del ALB controller Cuenta aws-load-balancer-controller en kube-system, anotada con el rol IRSA
Rol IRSA del ALB controller Política del módulo IAM más permisos adicionales para atributos de listeners
Release Helm del ALB controller Usa el clúster, región, VPC y la cuenta de servicio precreada

La política adicional permite elasticloadbalancing:DescribeListenerAttributes y elasticloadbalancing:ModifyListenerAttributes sobre *. Su existencia está verificada en código; el incidente o motivo concreto que llevó a añadirla no se deduce del fichero y no se inventa aquí.

Ambos releases Helm carecen de una versión de chart fijada. Los módulos VPC/EKS usan restricciones por versión mayor; IAM sí se fija a 5.39.0. No hay lockfiles de proveedores versionados en el snapshot. Estas diferencias importan para repetir exactamente una instalación meses después.

Entrada HTTP y TLS

El Ingress pertenece al repositorio web-application/deployments/frontend. Solicita un ALB internet-facing, targets de tipo IP, listeners 80/443 y redirección a HTTPS. Enruta /api/v1 al Service rest:8080 y / a web:8080.

El manifiesto contiene un dominio y un ARN ACM concretos del despliegue original. Para una réplica se necesita un certificado válido en la región y una resolución DNS que apunte al balanceador creado. El certificado y DNS no se provisionan en las raíces inspeccionadas. Sustituir estos datos es un requisito de adaptación, no una operación que el pipeline de documentación vaya a realizar.

Comprobaciones de aceptación

Tras una ejecución de creación, comprobar por capa: outputs de red coherentes; nodos Ready; RDS disponible y alcanzable desde la aplicación; agente conectado; controlador ALB disponible; secreto rest con las claves esperadas, sin imprimir sus valores. Tras el despliegue de la aplicación, comprobar el endpoint HTTPS, el routing API y la conexión a la base de datos. El éxito de apply_platform por sí solo no acredita esas pruebas funcionales.

Para las variables y credenciales: referencia. Para retirar el entorno conservando los datos necesarios: teardown.

Fuentes