Skip to content

Hybrid Portal Burst to GKE

Overview

Hybrid Portal Burst to GKE shows how a portal can move its public web tier into cloud capacity while keeping identity and entitlement in place. The portal runs from GKE, while authority remains on the primary platform.

The result is a clear separation between the public portal tier and the retained authority services.

Case study

  • Context: the authenticated portal web tier ran on the primary platform with no path to move the public surface into cloud capacity. Bursting the portal would conventionally require relocating identity and entitlement authority at the same time.
  • Challenge: relocating the authority services was high risk and out of scope. Running an unauthenticated demo was not an acceptable substitute; the login boundary is part of what the showcase needed to prove.
  • Approach: GKE hosts only the portal web tier via gcp/gke-burst@v1. Identity and entitlement authority remain on the primary platform. platform/k8s/runtime-bundle-secret bridges private runtime delivery into the cluster without mixing it into the public GitOps surface.
  • Outcome: the recorded exercise served the portal web tier from GKE while protected routes continued to redirect to the primary identity service. GitOps delivery reconciled to main, and the authority boundary remained intact throughout.

Shows portal GitOps state, private runtime delivery, the login boundary, and the redirect back to upstream identity.

Outcome

The result is an authenticated portal that can move its public tier into cloud capacity while leaving the authority boundary intact.

  • The public web tier serves from GKE.
  • Identity and entitlement authority remain on the primary platform.
  • Users retain one coherent sign-in and navigation flow.

Operating model

  • The portal web tier runs on GKE.
  • Identity and entitlement services remain authoritative on the primary platform.
  • Private application delivery remains separate from the public burst baseline.
  • Runtime payload and secret delivery stay explicit and reviewable.
  • Traffic is served only once workload, runtime, and route checks pass.

Architecture

Hybrid portal burst model showing the portal web tier on GKE, private workload delivery paths, and identity authority retained on the primary platform.

The portal web tier runs on GKE. Identity and entitlement authority remain on the primary platform. The boundary is enforced at the route level, not by convention.

Request flow

  1. The burst cluster and public baseline are prepared.
  2. A private Argo CD root delivers the portal workload.
  3. Runtime payloads and secrets are published into the cluster.
  4. Public routes are checked before the service is opened to users.
  5. Protected routes continue to redirect to the primary identity service.

Platform state

Portal web tier served from GKE during the recorded exercise, with upstream identity and entitlement controls intact Grafana Burst Control dashboard from the recorded exercise, showing burst pressure, decision state, origin latency, and probe health for the portal tier

IP addresses, hostnames, and instance identifiers visible in screenshots and recordings reflect the ephemeral infrastructure provisioned during the recorded exercise.

Component Module Last run Status
GKE burst cluster platform/gcp/gke-cluster#gke_burst_cluster 2026-03-18T11:54:47Z ok
Argo CD bootstrap (portal) platform/k8s/argocd-bootstrap#gke_burst_portal_gitops 2026-03-20T23:59:23Z ok
Runtime bundle delivery platform/k8s/runtime-bundle-secret 2026-03-21T00:07:25Z ok

Run records are retained as part of the platform execution log for review and audit.

Implementation

  • Burst layer: GKE hosts the portal web tier.
  • Public platform baseline: the public burst GitOps root remains narrow and reusable.
  • Private workload path: the portal workload is delivered through a separate private GitOps root.
  • Runtime payload delivery: SSR or generated runtime assets are bridged through platform/k8s/runtime-bundle-secret.
  • Secret delivery: GCP Secret Manager is exposed through a Kubernetes ClusterSecretStore.
  • Authority boundary: identity and entitlement services remain on the primary platform rather than being folded into the burst lane.

Key components

  • Burst baseline: gcp/gke-burst@v1
  • Public burst GitOps root: platform/k8s/argocd-bootstrap#gke_burst_gitops
  • Private portal GitOps root: platform/k8s/argocd-bootstrap#gke_burst_portal_gitops
  • Secret store bootstrap: platform/k8s/gcp-secret-store#gke_burst_secret_store
  • Runtime payload delivery: platform/k8s/runtime-bundle-secret#showcase_portal_runtime_dev_burst
  • Reference workload: showcase portal on learn.hybridops.tech

Where it fits

  • customer and partner portals
  • member services and gated documentation surfaces
  • staged migration programmes where the public edge moves before the authority services
  • continuity plans that require the web tier to move independently of identity infrastructure

References

Further reading
Implementation references
  • platform/k8s/argocd-bootstrap#gke_burst_gitops
  • platform/k8s/argocd-bootstrap#gke_burst_portal_gitops
  • platform/k8s/gcp-secret-store#gke_burst_secret_store
  • platform/k8s/runtime-bundle-secret#showcase_portal_runtime_dev_burst

What was verified

Verified during the recorded HybridOps v1.0.1 portal burst exercise with the web tier served from GKE, GitOps delivery reconciled to main, runtime active, and protected routes redirected to the primary identity service.