A Recent Task Was To Convert An Existing External Environment On GCP Into An Internal One. The Whole Setup Runs On GKE With Gateway API Handling Load Balancing. The Assumption Going In Was That A Google-Managed Certificate Would Attach To The Gateway API Internal LB The Same Way It Already Worked On The Gateway API External LB. That Assumption Ran Into Trouble Immediately.
My Home Lab Originally Only Used LLDAP For User Authentication, But Since The Systems I Wanted To Integrate Later Only Spoke OIDC, I Put Keycloak In Front Of It As A Bridge, With Everything Else Talking To Keycloak Instead. Wiring That Up And Testing It Turned Up Something Interesting: Got The LDAP Federation Wired Up, Got The OIDC Client Configured, Got Kubernetes Itself Trusting The Issuer. Then, Testing Whether Any Of It Actually Enforced Anything, I Ran One kubectl Command With A Made-Up Token String, And Got Back A Full Pod List. For About Thirty Seconds I Was Convinced I’d Found A Cluster-Wide Auth Bypass.
I Hadn’t. The Bug Was In My Test, Not My Cluster.
My Home RKE2 Cluster Had Envoy Gateway Handling North-South Traffic, Routed To Whatever Service Needed It. It Worked Fine. What It Didn’t Have Was Any Answer For East-West: The Handful Of Services Calling Each Other Internally Were Doing It In Plaintext, No Identity, No mTLS. I’d Been Meaning To Add A Service Mesh For A While, Mainly Because This Is Exactly The Kind Of Thing A Real Company Would Actually Do, And “Migrate A Live Ingress From One Implementation To Another, Zero Downtime” Is About As Real-Company As It Gets. Decided To Fully Replace Envoy Gateway With Istio’s Own Gateway In Ambient Mode, Rather Than Just Bolting Istio’s Mesh On The Side, And Did It The Same Day.
Needed The PRD Domain’s Certificate To Auto-Renew, Which Meant Switching GatewayClass From Regional (gke-l7-regional-external-managed) To Global (gke-l7-global-external-managed). Certificate Manager’s Google-Managed Auto-Renewing Certs Only Support Global. That Night I Hit Three Traps Back To Back: Certificate Manager’s Annotation Syntax Is Completely Different, GCPBackendPolicy Can Only Bind One Service And Two Of Mine Fought Over It, And Global Security Policy’s Default Rule Is Allow, Not Deny. Five Days Later, Adding An Internal Gateway, The Second Trap Bit Me Again, Verbatim. That’s When I Knew It Wasn’t Bad Luck, It Was A Rule.
Want To Deploy vLLM On Cloud Run To Serve An LLM. Two Paths: GPU Mode (For Real Service) Or CPU Mode (For Tiny Model / Architecture Test Only). Both Fully Tested End To End.
Result First:
| GPU Mode | CPU Mode | |
|---|---|---|
| Support Level | GA | Experimental |
| Tested Model | Gemma-4-E2B-it (L4) | Qwen2.5-0.5B-Instruct |
| Response Time | 6.1s | 114s |
| Build Effort | Low, Use Official Image | High, ~56 Min Multi-Stage Build |
| Use Case | Real Service, Demo | Architecture Test Only |
GPU Is About 19x Faster Than CPU. CPU Mode Works, But Don’t Expect Speed.
Was Adding An HTTPS Listener To The PRD GKE Gateway. helm upgrade Got Stuck On A Field Manager Conflict, So I Threw --server-side --force-conflicts At It To Push Through — And It Wiped The Entire myApp Namespace (Deployment / Pod / Service / HPA / Secret, All Gone). Recovery Worked, No Data Lost, But The Mechanism Is Worth Understanding Properly, Or I’ll Walk Into It Again.