GCP Kubernetes and GKE

Basic Architecture

Each kubernetes item runs on a computer and is either a control plane or a node.

A Node launches and maintains Pods.


To create a cluster with three nodes:

⚠️ To create an Autopilot cluster, use create-auto instead of create.

gcloud container clusters create <cluster-name> \
  --machine-type e2-small \
  --num-nodes 3 \
  --scopes ",storage-rw"

Control Plane

The control plane is made up of five elements:

  • kube-APIserver - this is the interface the user interacts with
  • etcd - this is the database to store persistent data, used by kube-APIserver. Non-interactive.
  • kube-scheduler - scheduling pods on to the nodes. Doesn’t actually launch them. Keeps a state of all the nodes.
  • kube-controller-manager - monitors the state and attempts to maintain the desired state.
  • kube-cloud-manager - manages controllers that interact with underlying cloud providers (like GCP).


Each node runs a kublet, which is an agent of the control plane.

It also runs a kube-proxy which maintains network connectivity between nodes in a cluster.


A pod is used to specify how to build and reference a container image in GKE.

When configuring access for GKE, set up dedicated service accounts for each pod. Then use workload identity to map them to dedicated Kubernetes service accounts.


A service exposes the Kubernetes resources to the internet according to the settings specified.

GKE Autopilot versus Standard

With GKE autopilot, you pay for what you use, i.e. for the pods, but not for nodes. Whereas for Standard, you pay for what is provisioned, regardless of usage. But GKE autopolit has limitations.

GKE Autopilot limitations:

  • configuration options are more restrictive
  • autopolit clusers have restrictions on access to node objects
  • no SSH
  • no privilege escalation
  • limitations on node affinity and host access

Object Management

Pod instructions are written in manifests, which ae .yaml or .json files. Each pod must have a name, but that cannot be identical in the same namespace or cluster.

Controlling desired state across pods can be done through an object controller defined at the level of the control plane.

Load Balancing

ingress objects (not pods or services) implement an http(s) load balancer based on upstream services that are specified in the configuration file.


To set an internal http(s) load balancer for a GKE cluster, annotate the service object with a “neg” reference.


To access logic running in clusters through endpoints, use the Kubernetes Services object to define endpoints.

Service endpoints are defined by pods with labels that match those specified in the service configuration file. Services then specify how those pods are exposed.

© Filip Niklas 2024. All poetry rights reserved. Permission is hereby granted to freely copy and use notes about programming and any code.