What Is GKE?
Google Kubernetes Engine (GKE) is a managed service for running Kubernetes, the open-source container orchestration system Google originally created internally as Borg. GKE manages the Kubernetes control plane (API server, scheduler, etcd) for you, handling upgrades, patching, and high availability, while you focus on defining workloads as Kubernetes objects like Pods, Deployments, and Services. This is a meaningful step up in abstraction from Compute Engine: instead of managing individual VMs, you describe the desired state of your application, and Kubernetes continuously reconciles the actual cluster state to match it.
Cricket analogy: GKE is like the BCCI running the entire domestic scheduling and pitch-preparation infrastructure so a franchise only has to focus on team selection and strategy, rather than also managing groundstaff and stadium logistics themselves.
Autopilot vs Standard Mode
GKE offers two cluster modes. In Standard mode, you manage node pools directly — choosing machine types, configuring autoscaling, and being responsible for node-level security patching and capacity planning. In Autopilot mode, Google manages the nodes entirely: you only define Pod resource requests, and GKE provisions and scales the underlying infrastructure automatically, charging per Pod resource consumption rather than per node. Autopilot trades some low-level control (like DaemonSets requiring specific configurations or restricted privileged containers) for significantly reduced operational overhead and a hardened default security posture.
Cricket analogy: Standard mode is like a franchise managing its own groundstaff and pitch curator directly, choosing exactly how the wicket is prepared, while Autopilot is like playing at a neutral ICC-managed venue where pitch and ground conditions are standardized and handled for you.
Core Kubernetes Objects: Pods, Deployments, and Services
A Pod is the smallest deployable unit in Kubernetes, typically wrapping one container (though it can hold sidecars) and sharing a network namespace. Pods are ephemeral and not created directly in production; instead, a Deployment manages a ReplicaSet of Pods, handling rolling updates, rollbacks, and self-healing by recreating Pods that crash or get evicted. A Service provides a stable network endpoint (a virtual IP and DNS name) that load-balances traffic across the Pods matching a label selector, decoupling clients from the constantly changing set of individual Pod IPs.
Cricket analogy: A Pod is like a single fielder on the pitch — replaceable and ephemeral in position — while a Deployment is the team management ensuring twelve fielders are always ready to rotate in, and a Service is like the fixed jersey number system that lets commentators refer to 'the wicketkeeper' regardless of which specific player currently holds that role.
Networking and Namespaces
GKE clusters use a flat Pod network where every Pod gets its own IP address, typically allocated from VPC-native (alias IP) ranges so Pod IPs are directly routable within the VPC without extra NAT hops. Namespaces provide logical isolation within a single cluster — separating environments like dev, staging, and prod, or separating teams — by scoping resource names, RBAC policies, and resource quotas, though they don't provide network isolation by default unless you layer on NetworkPolicies to restrict which Pods can talk to each other.
Cricket analogy: Namespaces are like separate net-practice areas at a stadium — the U19 squad and the senior squad each get their own bay so equipment and schedules don't clash, but without a locked gate (NetworkPolicy) between them, players could still wander across.
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-web
namespace: production
spec:
replicas: 3
selector:
matchLabels:
app: hello-web
template:
metadata:
labels:
app: hello-web
spec:
containers:
- name: hello-web
image: gcr.io/my-project/hello-web:1.4.0
resources:
requests:
cpu: "250m"
memory: "256Mi"
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: hello-web-svc
namespace: production
spec:
selector:
app: hello-web
ports:
- port: 80
targetPort: 8080
type: LoadBalancerGKE Autopilot bills per second based on the CPU, memory, and storage each Pod actually requests, rather than per underlying node, which often reduces waste from over-provisioned node capacity — a strong default choice for teams without dedicated platform engineers.
Namespaces alone do not provide network isolation between workloads — Pods in different namespaces can still reach each other by default. If you need true network-level isolation (for example, between a payments namespace and a public-facing namespace), you must define explicit NetworkPolicy resources.
- GKE is a managed Kubernetes service where Google operates the control plane, and you define workloads as declarative Kubernetes objects.
- Standard mode gives direct node pool control; Autopilot mode fully manages nodes and bills per Pod resource request.
- Pods are ephemeral units, Deployments manage self-healing ReplicaSets of Pods, and Services provide stable network endpoints.
- GKE typically uses VPC-native networking so every Pod gets a directly routable IP within the VPC.
- Namespaces provide logical isolation (naming, RBAC, quotas) but not network isolation by default.
- NetworkPolicies are required to restrict Pod-to-Pod communication across namespaces.
- Autopilot trades some low-level configuration flexibility for reduced operational overhead and hardened defaults.
Practice what you learned
1. What is the main operational difference between GKE Standard and Autopilot mode?
2. What is the role of a Kubernetes Service?
3. Do Kubernetes namespaces provide network isolation between Pods by default?
4. What component is responsible for recreating a crashed Pod to maintain the desired replica count?
5. How does VPC-native networking benefit GKE Pods?
Was this page helpful?
You May Also Like
Compute Engine Basics
Learn how Google Compute Engine provisions virtual machines, machine types, disks, and networking so you can run workloads on GCP infrastructure.
Instance Groups and Autoscaling
Understand how Managed Instance Groups keep fleets of Compute Engine VMs healthy and scale them automatically based on load.
Cloud Run Basics
Learn how Cloud Run runs stateless containers as fully managed, autoscaling, pay-per-request services on GCP.