Google Kubernetes Engine (GKE)

Kubernetes is a container orchestrator. You declare what you want — five copies of this container, reachable at this address, with this much memory — and the system continuously works to make reality match that declaration. If a container crashes or a machine fails, it schedules replacements without anyone intervening.

GKE provides Kubernetes as a managed service. The control plane, which is the hardest part to operate correctly, is run for you. Depending on the mode you choose, the worker nodes may also be managed automatically.

Kubernetes has become the common language of container operations. Its concepts are portable across clouds and on-premises environments, which is why organisations concerned about lock-in gravitate towards it.

It genuinely earns its complexity for certain workloads: systems with many interdependent services, workloads needing fine-grained scheduling or specific hardware, or teams already fluent in its model. It is genuinely over-specified for a single stateless web service, and recognising that distinction is worth marks on several exams.

• Cluster — the control plane plus the worker nodes that run your containers.
• Node — a virtual machine that runs workloads. Grouped into node pools that share a configuration.
• Pod — the smallest deployable unit; one or more containers sharing a network namespace and storage. Pods are disposable by design.
• Deployment — declares the desired number of pod replicas and manages rolling updates and rollbacks.
• Service — a stable network endpoint in front of a changing set of pods, since pod addresses change constantly.
• Ingress / Gateway — routes external HTTP traffic to services, typically provisioning a load balancer.
• ConfigMap and Secret — configuration and sensitive values kept out of the container image.
• Namespace — a logical partition inside a cluster used for isolation between teams or environments.
• Requests and limits — the resources a container is guaranteed and the ceiling it may not exceed. Getting these wrong is the leading cause of both waste and instability.
• Horizontal Pod Autoscaler — adds and removes pods based on observed metrics.
• Cluster Autoscaler — adds and removes nodes when pods cannot be scheduled or capacity is idle.

GKE offers two ways of running a cluster and they suit different teams.

• Autopilot — Google manages nodes, capacity and much of the security configuration. You pay for the resources your pods request. Fewer knobs, fewer ways to misconfigure something, less operational work.
• Standard — you manage node pools, machine types and upgrades. You pay for the nodes whether or not the pods use them. Necessary when you need specific machine types, custom node configuration or particular scheduling behaviour.

When a scenario emphasises reducing operational overhead or a small platform team, the managed mode is generally the intended answer. When it specifies particular hardware, node-level customisation or specialised scheduling, the self-managed mode is required.

• Workload Identity — lets a pod act as a cloud service account without a downloaded key file. This is the correct pattern; long-lived key files in secrets are the anti-pattern the exams test against.
• Private clusters — nodes without public IP addresses, with controlled access to the control plane.
• Network policy — controls which pods can talk to which other pods. Without it, everything in the cluster can reach everything else.
• Binary Authorization — enforces that only images meeting your policy can be deployed.
• Namespaces plus RBAC — the standard way to separate teams inside a shared cluster.

• Microservice systems with many services that need consistent deployment and networking.
• Migrating containerised workloads from another Kubernetes environment with minimal change.
• Machine learning training that needs GPU scheduling and job queuing.
• Multi-tenant platforms where namespaces and quotas separate internal teams.
• Workloads that must run identically across cloud and on-premises environments.