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.

Quickstart

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 "https://www.googleapis.com/auth/projecthosting,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).

Node

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.

Pod

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.

Service

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.

Internal

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

APIs

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.