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.

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

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.