GCP and GKE: From VPC to a Running Ziba Blog

Enterprise problem: Ziba’s blog can be healthy as a container yet remain unreachable or unsafe when its Google Cloud project, virtual network, GKE cluster, workload identity, or load balancer is wrong, leaving customers with timeouts and operators with an unclear owner. Whole-course context: Earlier Kubernetes days established that pod memory ends in physical RAM; today consumes that hardware-to-pod model and places it inside Google Cloud Platform (GCP), where Google Kubernetes Engine (GKE) manages Kubernetes while Compute Engine virtual machines supply worker hardware. Today’s slice: We create the network-to-runtime path for one production-shaped Ziba deployment and keep cloud IAM authority separate from Kubernetes authorization. End-of-day evidence: A reviewer can trace a public request to a named Service, pod, node VM, subnet, and GKE control plane, with command output and immutable deployment revision. Still unsolved: Multi-cloud equivalence, Terraform ownership, GitOps reconciliation, global failover, and production spend approval remain later decisions.

A cloud cluster is not a customer outcome, so creating one without a request path can spend money while Ziba still returns no page. These use cases bind infrastructure creation to visible service and denial evidence.

Cloud defaults can hide consequential choices, so each actor needs acceptance conditions spanning both Google Cloud and Kubernetes. These stories demand positive and negative observations rather than a green console icon.

A deployment can fail at any boundary between a browser and a process, so the flow must preserve the ownership of every hop. It starts with a customer-visible publish action and ends with request and denial evidence.

GKE does not erase the hardware layers beneath Kubernetes; it assigns management responsibility for some of them. In GKE Standard, Google manages the control plane while the customer manages node configuration, and worker nodes are Compute Engine VMs; in Autopilot, GKE also manages the underlying node infrastructure (GKE cluster architecture).

Cloud and cluster records must not be collapsed into one “deployment” row because each has a different authority and deletion path. The generated blog stores content elsewhere; this slice needs infrastructure, workload, and evidence state only.

Generated-application database: Not created in this slice — the Ziba blog serves an immutable image while Google Cloud resource state, Kubernetes API state, and deployment evidence are sufficient for the network-to-process proof.

Creating Kubernetes objects before planning address space can force a cluster rebuild or cause unreachable pods. Expand the three-box model in dependency order: project and IAM, then network, then managed control plane and worker compute, then workload and ingress.

Use a regional cluster for production-shaped availability because its control plane is replicated across zones; Google’s GKE guidance recommends regional clusters for production workloads (cluster creation guidance). The lab values below are illustrative: a real team must allocate non-overlapping CIDRs, quota, IAM, and spend before applying them.

gcloud services enable container.googleapis.com compute.googleapis.com
gcloud container clusters create ziba-prod \
  --region=europe-west2 \
  --release-channel=regular \
  --enable-ip-alias \
  --workload-pool="${GOOGLE_CLOUD_PROJECT}.svc.id.goog" \
  --machine-type=e2-standard-4 \
  --num-nodes=1
gcloud container clusters get-credentials ziba-prod --region=europe-west2
kubectl apply -f k8s/ziba.yaml
kubectl rollout status deployment/ziba -n blog
kubectl get service,pods,endpointslices -n blog -o wide

A running process is not automatically a safe backend, so traffic must depend on readiness rather than container existence. This manifest creates Kubernetes software objects; the GKE cloud integration then allocates external load-balancing infrastructure, while the scheduler and kubelet place and run the image on node hardware.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ziba
  namespace: blog
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ziba
  template:
    metadata:
      labels:
        app: ziba
    spec:
      serviceAccountName: ziba
      containers:
        - name: blog
          image: europe-west2-docker.pkg.dev/ziba-prod/blog/site@sha256:REPLACE_ME
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: ziba
  namespace: blog
spec:
  type: LoadBalancer
  selector:
    app: ziba
  ports:
    - port: 80
      targetPort: 3000

Commands are requests to control planes, not magic instructions to chips, so operators must know which effects are direct and which are eventual. The table maps each line to the durable state, software reconciliation, physical allocation, and customer outcome it can cause.

A single timeout does not identify the failed layer, so guessing can replace healthy nodes while a selector remains wrong. Move from outside inward and change the narrowest owner whose evidence fails.

A deployment is incomplete until evidence joins customer reachability with least-privilege denial. Capture the exact image digest and observe both an approved request and an intentionally unauthorized Google API probe.

kubectl -n blog get deployment ziba -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
kubectl -n blog get pods -l app=ziba -o wide
kubectl -n blog describe service ziba
curl --fail --show-error "http://${ZIBA_ADDRESS}/healthz"
kubectl auth can-i get secrets --as=system:serviceaccount:blog:ziba -n blog

kubectl auth can-i tests Kubernetes authorization only; it does not prove Google Cloud IAM. Test Google API authority separately from a pod and keep the denial audit entry. The two planes complement each other and neither token automatically grants authority in the other.

A managed Kubernetes cluster is still a stack from physical machines through cloud resources to Kubernetes objects and application processes. GKE changes who operates layers; it does not remove those layers.

• A reader reaches Ziba through cloud networking, Kubernetes service discovery, a ready pod, and a process consuming node hardware.
• Google Cloud IAM, Kubernetes RBAC, and application authorization are independent boundaries.
• GKE Standard delegates the control plane; Autopilot delegates more of the node infrastructure.
• A code line should be reviewed for control-plane, software, hardware, and customer-visible effects.

A production-shaped lab is only complete when it proves placement, reachability, identity denial, and cleanup ownership. Record these checks beside the immutable deployment revision.

• [ ] Named project, region, VPC/subnet, cluster mode, release channel, and non-overlapping IP ranges
• [ ] Captured node VM identity, allocatable CPU/memory, pod placement, and image digest
• [ ] Proved Service endpoints and external HTTP response from the intended revision
• [ ] Proved approved Google API authority and an unapproved ServiceAccount denial
• [ ] Documented spend owner and safe deletion order before provisioning