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 and its primary-hosted identity and entitlement services shared one delivery environment. The design needed a way to move only the public tier into cloud capacity while keeping those authorities where they already operated.
  • Challenge: the cloud web tier still had to preserve the real login and entitlement boundary. The exercise therefore had to move execution without moving authority or replacing the protected-route behaviour with a simplified demo path.
  • 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 use the primary identity service. GitOps delivery reconciled to main, runtime delivery completed, 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 whose public execution tier can move into cloud capacity while the authority boundary stays anchored to the primary platform.

  • 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 architecture showing the public request path into a GKE-hosted portal, the retained primary identity and entitlement authority, the private delivery path into GKE, and the observed service-state checks.

Public traffic reaches the GKE portal only after workload, runtime, and route checks pass. Protected routes continue to use the primary identity and entitlement services, while the portal workload, runtime bundle, and secrets arrive through a separate private delivery path.

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 use the primary identity and entitlement authority.

Platform state

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

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 while the web tier executes in GKE.

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.