Lesson 11 · Identity, secrets & operations

Networking, DNS & Cloud SQL

The private network the cluster lives in, the DNS/certs that let traffic in, and the databases behind your services.

Your win: read the VPC, Cloudflare, and Cloud SQL modules — the network the GKE cluster runs inside, the DNS + edge certs behind Istio's gateway (C4), and the Postgres instances your services talk to.

VPC — the private network everything sits in

Anchor — modules/vpc/main.tf The GKE cluster (Lesson 8) doesn't float in the void — it lives in a VPC. The module wraps terraform-google-modules/network and provisions: subnets + secondary ranges (Pod/Service IP ranges, :1-12), private service access peering so the cluster can reach Cloud SQL privately (:14-27), Cloud NAT with static egress IPs (:67-110), and VPC access connectors. Remember Lesson 8's private_network = dependency.vpc.outputs.network_self_link? This module produces that output — the VPC is created before the cluster that depends on it (the module dependency graph, Lesson 4).

Cloudflare — DNS & the edge certs (Course 4)

Anchor — modules/cloudflare-dns Course 4's Istio ingress terminated TLS with certs delivered at the edge — and the Cloudflare front gateway used front-end certs. Those are Terraform: cloudflare_record (records.tf:6, all the DNS records like api.*, thanos) and cloudflare_certificate_pack (certificate_pack.tf:1-15, the edge certs for proxied hosts). So "how does api.prod.tokyo.manabie.io resolve, and where does its edge cert come from?" → this module. (Interesting: thanos's DNS record is here even though its bucket isn't Terraform-managed — the map isn't always the whole territory.)

Cloud SQL — the databases behind your services

Anchor — modules/platforms/postgresql.tf The Postgres your services use is provisioned as Cloud SQL. The platforms module creates the instances (for_each over var.postgresql, :1-8, wrapping GoogleCloudPlatform/sql-db); the stag instance list has five: lms, common, auth, lmsdwh, aitutor — mostly POSTGRES_14, with IAM auth, pgaudit, pg_cron, deletion_protection, ssl_mode: ENCRYPTED_ONLY, and a private network from the VPC dependency. The separate modules/postgresql (singular) then manages the databases/users/roles inside those instances (via a data source — Lesson 2). So "instance" and "the DBs in it" are two modules — one creates the server, one configures its contents.

The connective tissue Notice how these three depend on each other: Cloud SQL uses the VPC's private-service-access peering; the cluster reaches Cloud SQL over that private network; Cloudflare points DNS at the ingress gateway that fronts the cluster. Terraform's dependency graph (Lesson 4) builds them in order — VPC, then Cloud SQL + cluster, then DNS. Infrastructure is a graph, and Terraform walks it.

Backend use case Backend use case: this ties VPC, Cloudflare records/certs, private service access, and Cloud SQL instances back to the Terraform modules that create them.

Common mistake Common mistake: explaining DNS, VPC, or Postgres connectivity only at runtime and missing the Terraform layer that created the dependencies first.

GCP — VPC, Cloud SQL for PostgreSQL (+ the Cloudflare provider)

Private networking, managed Postgres, and DNS-as-code.

→ cloud.google.com — VPC · Cloud SQL for PostgreSQL
→ registry — cloudflare provider

In plain English Plain English: networking and Cloud SQL in Terraform explain where the private network, edge DNS/certs, and managed Postgres foundations come from before apps ever deploy.

Check yourself (from memory)

Q1. The GKE cluster reaches Cloud SQL privately thanks to…

The vpc module sets up private service access; Cloud SQL uses a private_network — no public DB exposure.

Q2. Istio's edge certs and the DNS records come from…

cloudflare_record + cloudflare_certificate_pack — the DNS + edge certs behind Course 4's gateway.

Q3. Creating a Cloud SQL instance vs the databases in it is…

platforms/postgresql.tf creates the instance; modules/postgresql manages DBs/users inside it (via a data source).

VPC, Cloudflare, Cloud SQL — and how they connect.

recall, then click to reveal

VPC (modules/vpc, wraps terraform-google-modules/network): subnets + secondary ranges, PRIVATE SERVICE ACCESS peering (so the cluster reaches Cloud SQL privately), Cloud NAT + static egress IPs, VPC connectors — produces the network_self_link the GKE cluster depends on (L8). CLOUDFLARE (modules/cloudflare-dns): cloudflare_record (DNS) + cloudflare_certificate_pack (edge certs) — behind Course 4's ingress gateway. CLOUD SQL: platforms/postgresql.tf creates INSTANCES (lms/common/auth/lmsdwh/ aitutor; POSTGRES_14, IAM auth, ENCRYPTED_ONLY, private network); modules/postgresql manages DBs/users INSIDE them (data source). CONNECTIVE TISSUE: VPC → Cloud SQL + cluster → DNS; Terraform's dependency graph builds them in order.

Want to see the secondary IP ranges for Pods/Services, or why Cloud SQL uses private service access instead of a public IP? Ask me.

1. In-repo: modules/vpc/main.tf, modules/cloudflare-dns/, modules/platforms/postgresql.tf.