Saltar a contenido

Google Cloud: GKE y Cloud SQL

La implementación GCP conserva las capas network, kubernetes, database y platform, pero adapta la red, identidad y base de datos a Google Cloud. El código crea un clúster GKE Standard regional con nodos privados y una instancia Cloud SQL con IP privada. No replica recursos AWS uno a uno.

Red: lo que se crea realmente

La VPC desactiva la creación automática de subredes y usa routing_mode=REGIONAL. El vpc_cidr de la interfaz es un rango lógico para documentación y reglas internas; no representa un CIDR asignado a toda la VPC global.

Objeto Configuración predeterminada
Región europe-west1
VPC Nombre gitlab-terraform-gke
Subred privada 10.0.1.0/24
Subred pública reservada 10.0.4.0/24
Rango secundario de pods gke-pods, 10.10.0.0/16
Rango secundario de servicios gke-services, 10.20.0.0/20
Acceso privado a APIs Google Habilitado en ambas subredes
Cloud Router / NAT Activados; NAT para todos los rangos de la subred privada
Flow logs Intervalo 5 s, muestreo 0,5, todos los metadatos
Logs NAT Solo errores

Aunque las variables private_subnets y public_subnets contienen tres entradas cada una, main.tf utiliza exclusivamente el elemento [0]. Por eso el resultado declarado son dos subredes en total, no seis. La variable single_nat_gateway permanece como compatibilidad con la interfaz AWS y no cambia el código GCP. El local common_labels tampoco se utiliza para etiquetar recursos de red.

La regla allow_internal admite TCP, UDP e ICMP desde el CIDR lógico de VPC y los rangos secundarios. Es una regla amplia de conectividad interna, no una segmentación por servicio. La subred llamada pública está reservada para recursos de entrada si se requieren; el nombre no implica por sí mismo un balanceador ni una dirección externa.

GKE: plano de control y nodos

gcp/kubernetes configura VPC-native, nodos privados y rango de control 172.16.0.0/28. El endpoint público está activado y las redes autorizadas incluyen 0.0.0.0/0. La autenticación sigue siendo necesaria; la configuración de CIDRs describe alcanzabilidad de red.

El clúster es regional por defecto. El pool usa las zonas europe-west1-b y europe-west1-c. Las variables de recuento del pool son por zona: con el valor inicial 1 y dos ubicaciones, la configuración corresponde a dos nodos iniciales; los límites por zona 1–3 no deben interpretarse como un límite global de tres nodos. La topología configurada debe contrastarse con el resultado real del plan y las cuotas del proyecto.

Área Código actual
Nombre gitlab-terraform-gke
Versión cluster_version=null; canal REGULAR
Pool inicial automático Eliminado; se crea un pool explícito default
Máquina / imagen e2-small / COS_CONTAINERD
Disco por nodo pd-balanced, 50 GiB
Autoscaling Mínimo 1 y máximo 3 por zona
Mantenimiento del pool Auto repair y auto upgrade activados
Actualizaciones Surge 1, indisponibilidad 0
CSI GCE Persistent Disk CSI activado
Vertical Pod Autoscaling Capacidad habilitada a nivel de clúster
Protección de borrado Desactivada

Habilitar VPA a nivel de clúster no crea un objeto VPA para la aplicación. Los repositorios de despliegue revisados no lo declaran. Tampoco hay PVC de la aplicación: la persistencia demostradora está en Cloud SQL.

Identidad: tres niveles distintos

  1. Identidad de CI para aprovisionar. El job escribe el contenido JSON de GCP_SERVICE_ACCOUNT_KEY a un fichero y exporta GOOGLE_APPLICATION_CREDENTIALS. La cuenta, sus permisos y la activación de APIs se preparan fuera de estas raíces.
  2. Cuenta de los nodos. Se crea gke-node-sa, con roles/logging.logWriter, roles/monitoring.metricWriter y roles/monitoring.viewer. El OAuth scope es cloud-platform; los permisos efectivos también dependen de los roles IAM asignados.
  3. Identidad de las cargas. El clúster habilita el pool <project>.svc.id.goog y el pool usa GKE_METADATA. El fichero workload-identity.tf solo contiene un ejemplo comentado de binding. En platform, la anotación de la cuenta de servicio app está desactivada por defecto. Los manifiestos de aplicación usan cuentas rest y web, no esa cuenta app.

Por tanto, el código habilita la capacidad de Workload Identity, pero no demuestra que los pods demostradores autentiquen contra APIs Google con una identidad federada propia. La conexión SQL se realiza con usuario y contraseña de base de datos.

Cloud SQL y Private Service Access

La capa database reserva un rango interno global de prefijo /16 para VPC_PEERING, crea una conexión a servicenetworking.googleapis.com y, después, crea la instancia SQL conectada a la VPC. No depende técnicamente del estado de GKE, aunque el pipeline la serializa después del clúster para mantener el mismo flujo que AWS.

Configuración Valor predeterminado
Motor MYSQL_8_0
Tier db-f1-micro
Disponibilidad ZONAL
IP pública Desactivada
Disco SSD, 20 GiB; autoresize hasta 100 GiB
Base y usuario restdb, restuser
Backups Activados, inicio 02:00, binary logs activados
Protección de eliminación Desactivada

Se crean explícitamente la base SQL y el usuario. Los outputs incluyen IP privada, nombre y conexión de instancia, base, puerto, usuario sensible y URL JDBC. rest_db_port se utiliza en los outputs y en la URL; no configura un puerto alternativo del servidor Cloud SQL.

No hay Cloud SQL Auth Proxy, SQL IAM authentication ni replicación hacia RDS en los ficheros revisados. Es un acceso directo a la IP privada con credenciales SQL, entregadas a Kubernetes mediante el secreto rest.

Plataforma y acceso desde GitLab

Los proveedores Kubernetes y Helm toman el endpoint y CA del estado de GKE. Autentican con data.google_client_config.current.access_token. Para la fase inicial el runner necesita llegar directamente al endpoint; el agente aún se está instalando en ese mismo paso.

platform crea el namespace app, el secreto rest, el namespace y release Helm del GitLab Agent y, opcionalmente, la cuenta de servicio app. El secreto añade REST_DB_JDBC_URL a las cinco claves comunes de conexión. El agente usa GKE_AGENT_TOKEN, distinto de AGENT_TOKEN en AWS; ambos comparten la variable KAS_ADDRESS.

Exposición de la aplicación: límite del snapshot

El único Ingress versionado en los repositorios de despliegue usa ingressClassName: alb, anotaciones AWS y un certificado ACM. No es una configuración de entrada para GKE. Estas raíces GCP tampoco crean un controlador ALB ni una variante de Ingress/Gateway de Google.

El despliegue de workloads y la conexión del Agent son verificables como configuración; la publicación HTTP/TLS equivalente de la aplicación en GKE requiere una adaptación o un procedimiento externo que no consta en el snapshot. Esta documentación no lo trata como un paso ya automatizado. La diferencia se registra en hallazgos.

Preparación y aceptación

Antes de ejecutar: elegir un proyecto con facturación, habilitar las APIs pertinentes de Compute, GKE, Cloud SQL, Service Networking e IAM, definir la identidad de CI y comprobar cuotas de nodos, direcciones y discos. Las activaciones y permisos no aparecen como recursos google_project_service o políticas del aprovisionador en este repositorio.

Después: comprobar red/rangos sin solapamientos, nodos Ready, instancia SQL con IP privada, secretos presentes, Agent conectado y aplicación funcional dentro del clúster. La validación de acceso público se trata por separado, una vez exista una configuración de entrada GKE.

La retirada de Cloud SQL y Private Service Access requiere especial atención: el job de reparación por state rm no forma parte del flujo normal. Véase destrucción y recuperación.

Fuentes