Skip to content

Google Cloud: GKE and Cloud SQL

The GCP implementation preserves the network, kubernetes, database and platform layers while adapting networking, identity and database resources to Google Cloud. The code creates a regional GKE Standard cluster with private nodes and a privately addressed Cloud SQL instance. It does not reproduce AWS resources one for one.

Networking: what is actually created

The VPC disables automatic subnet creation and uses routing_mode=REGIONAL. The interface's vpc_cidr is a logical range for documentation and internal rules; it is not a CIDR assigned to the entire global VPC.

Object Default configuration
Region europe-west1
VPC Name gitlab-terraform-gke
Private subnet 10.0.1.0/24
Reserved public subnet 10.0.4.0/24
Pod secondary range gke-pods, 10.10.0.0/16
Service secondary range gke-services, 10.20.0.0/20
Private Google Access Enabled on both subnets
Cloud Router / NAT Enabled; NAT covers all ranges of the private subnet
Flow logs 5-second interval, 0.5 sampling, all metadata
NAT logs Errors only

Although private_subnets and public_subnets each contain three entries, main.tf uses only element [0]. The declared result is therefore two subnets in total, not six. single_nat_gateway remains an AWS-interface compatibility variable and does not alter the GCP code. The common_labels local is also not used to label network resources.

The allow_internal rule admits TCP, UDP and ICMP from the logical VPC CIDR and the secondary ranges. It is a broad internal connectivity rule, not service-level segmentation. The subnet named public is reserved for ingress resources if needed; its name alone does not imply a load balancer or external address.

GKE: control plane and nodes

gcp/kubernetes configures VPC-native networking, private nodes and control plane range 172.16.0.0/28. The public endpoint is enabled and authorized networks include 0.0.0.0/0. Authentication is still required; the CIDR setting describes network reachability.

The cluster is regional by default. The pool uses europe-west1-b and europe-west1-c. Its count settings are per zone: an initial value of 1 with two node locations corresponds to two initial nodes; per-zone limits of 1–3 should not be read as a global three-node limit. Confirm the configured topology against the actual plan and project quotas.

Area Current source
Name gitlab-terraform-gke
Version cluster_version=null; REGULAR channel
Automatic initial pool Removed; an explicit default pool is created
Machine / image e2-small / COS_CONTAINERD
Per-node disk pd-balanced, 50 GiB
Autoscaling Minimum 1, maximum 3 per zone
Pool maintenance Auto repair and auto upgrade enabled
Upgrades Surge 1, unavailable 0
CSI GCE Persistent Disk CSI enabled
Vertical Pod Autoscaling Cluster-level capability enabled
Deletion protection Disabled

Enabling VPA on the cluster does not create an application VPA object. The reviewed deployment repositories declare none. There are no application PVCs either: demonstration persistence lives in Cloud SQL.

Identity: three different layers

  1. CI provisioning identity. The job writes the JSON contents of GCP_SERVICE_ACCOUNT_KEY to a file and exports GOOGLE_APPLICATION_CREDENTIALS. The account, permissions and API activation are prepared outside these roots.
  2. Node identity. The code creates gke-node-sa with roles/logging.logWriter, roles/monitoring.metricWriter and roles/monitoring.viewer. Its OAuth scope is cloud-platform; effective permissions also depend on assigned IAM roles.
  3. Workload identity. The cluster enables the <project>.svc.id.goog pool and node metadata uses GKE_METADATA. workload-identity.tf contains only a commented binding example. In platform, the app service-account annotation is disabled by default. Application manifests use the rest and web accounts, not that app account.

The code therefore enables the Workload Identity capability but does not establish that demonstration pods authenticate to Google APIs using their own federated identity. SQL access uses a database username and password.

Cloud SQL and Private Service Access

The database layer reserves a global internal /16 range for VPC_PEERING, connects it to servicenetworking.googleapis.com, then creates the SQL instance attached to the VPC. It does not technically depend on GKE state, although the pipeline runs it after the cluster to preserve the same workflow as AWS.

Setting Default
Engine MYSQL_8_0
Tier db-f1-micro
Availability ZONAL
Public IP Disabled
Disk SSD, 20 GiB; autoresize up to 100 GiB
Database and user restdb, restuser
Backups Enabled, start 02:00, binary logs enabled
Deletion protection Disabled

The SQL database and user are explicitly created. Outputs include private IP, instance name and connection name, database, port, sensitive username and JDBC URL. rest_db_port is used in outputs and the URL; it does not configure an alternative Cloud SQL server port.

The reviewed files contain no Cloud SQL Auth Proxy, SQL IAM authentication or replication to RDS. Access is directly to the private IP with SQL credentials supplied to Kubernetes through the rest secret.

Platform services and GitLab access

Kubernetes and Helm providers take the endpoint and CA from GKE state and authenticate with data.google_client_config.current.access_token. During bootstrap the runner must reach the endpoint directly; the agent is only being installed by that same step.

platform creates the app namespace, rest secret, GitLab Agent namespace and Helm release, and an optional app service account. The secret adds REST_DB_JDBC_URL to the five common connection keys. The agent uses GKE_AGENT_TOKEN, distinct from AWS's AGENT_TOKEN; both share KAS_ADDRESS.

Application exposure: a snapshot boundary

The only versioned Ingress in the deployment repositories uses ingressClassName: alb, AWS annotations and an ACM certificate. It is not a GKE ingress configuration. These GCP roots also create neither an ALB controller nor a Google Ingress/Gateway variant.

Workload deployment and Agent connectivity can be verified as configuration; equivalent public HTTP/TLS exposure on GKE needs an adaptation or external procedure absent from this snapshot. This documentation does not treat it as already automated. The distinction is recorded in findings.

Preparation and acceptance

Before running: select a billed project, enable relevant Compute, GKE, Cloud SQL, Service Networking and IAM APIs, define the CI identity, and check quotas for nodes, addresses and disks. API activation and provisioning-account permissions do not appear as google_project_service resources or provisioner policies in this repository.

Afterwards, verify non-overlapping networks/ranges, Ready nodes, SQL with a private IP, present secrets, a connected Agent and functional application access inside the cluster. Public-access validation is separate, once a GKE ingress configuration exists.

Cloud SQL and Private Service Access teardown needs particular care: the state rm repair job is not part of the normal workflow. See destruction and recovery.

Sources