Runway AR GKE: Memorystore Support

Context

Memorystore (Redis) provisioning for Cloud Run workloads is fully implemented in modules/runtimes/gcp_cloud_run/memorystore.tf, covering:

  • Instance lifecycle via terraform-google-modules/memorystore/google
  • Direct VPC attachment via authorized_network
  • Workload-scoped egress firewall rules (deny-all baseline, per-workload allow)
  • Vault secret publication of host, port, password, and read endpoint under runway/reconciler/<deploy_project_id>/datastores/<env>/<region>/<key>

The GKE runtime module (modules/runtimes/gcp_gke/) has no equivalent: the var.memorystore variable, the redis_instances workload field, and the memorystore.tf resource file are all absent.

Goal

Add Memorystore provisioning support to the GKE runtime module, modelled on the Cloud Run implementation but adapted for GKE's networking and secrets model.

Plan

1. Variable additions

Add var.memorystore to modules/runtimes/gcp_gke/variables.tf, matching the shape of the Cloud Run variable. Add redis_instances to the workloads variable, also matching Cloud Run.

2. Instance provisioning

Create modules/runtimes/gcp_gke/memorystore.tf. Instance provisioning via terraform-google-modules/memorystore/google can be lifted directly from the Cloud Run module — both runtimes share a VPC (authorized_network), so the attachment model is the same.

3. Firewall rules

The Cloud Run module scopes allow-rules to workloads using deploy_project_id as a network tag (target_tags). GKE workload identity uses service accounts instead (gke-<runway_service_id>@<project>.iam.gserviceaccount.com), so the allow rules should target by target_service_accounts rather than target_tags. The deny-all baseline rule is otherwise identical.

4. Vault secrets

The Cloud Run path schema is runway/reconciler/<deploy_project_id>/datastores/<env>/<region>/<key>. GKE uses a different Vault mount (k8s/) and namespace-scoped paths. The correct GKE path schema needs to be confirmed — it should be consistent with how CloudSQL connection details are surfaced to GKE workloads.

5. Provision AR Memorystore instance

Once the module changes are in place, add the AR Memorystore instance to the provisioner inventory.

Open questions

  • What is the correct Vault path schema for surfacing Memorystore credentials to GKE workloads? (should align with the CloudSQL/infrastructure.proto binding pattern from epicgitlab-com/gl-infra/platform/runway#36)
    • 👉 runway/env/<env>/service/<runway_service_id>/datastores/<region>/<identifier> – one secret with multiple keys
  • Does AR require a STANDARD_HA tier (read replicas), or is BASIC sufficient for the initial launch?
    • 👉 STANDARD_HA if possible (already implemented in Cloud Run), BASIC sufficient for integration testing
  • Are there any Memorystore Cluster (Valkey) requirements, or is Redis 7.x on the legacy Memorystore API sufficient?
    • 👉 Legacy API is sufficient.

Acceptance criteria

  • var.memorystore and redis_instances workload field added to GKE module variables.
  • memorystore.tf implemented in the GKE runtime module with instance provisioning, firewall rules, and Vault secret publication.
  • AR Memorystore instance provisioned in the provisioner inventory for all required environments.
  • GKE workloads can resolve Memorystore connection details via the same binding mechanism used for CloudSQL.
Edited by Florian Forster