Day 1 on Eriks training corner

Services and microservices

Mon, 01 Jan 0001 00:00:00 +0000

Services and microservices

Monolith

One artifact, one deployment, one runtime. Internal calls are method calls.

Pros: single deployable, no network between modules. Cons: long release cycle, scales only as a whole, hard to split across teams.

Microservices

graph LR C[Clients] --> G[API Gateway] G --> B[Book service] G --> R[Review service] B --> BD[(Book DB)] R --> RD[(Review DB)]

Each service is developed, deployed, scaled and upgraded separately and may own its own database.

Containers and images

Mon, 01 Jan 0001 00:00:00 +0000

Containers and images

Container vs virtual machine

graph TB subgraph VMs H1[Hardware] --> HV[Hypervisor] HV --> G1[Guest OS + App] HV --> G2[Guest OS + App] end subgraph Containers H2[Hardware] --> OS[Host OS kernel] OS --> CR[Container runtime] CR --> C1[App] CR --> C2[App] end

A container is a process on the host kernel, isolated by namespaces and limited by cgroups. No guest OS, so start-up is milliseconds.

Image

Read-only template built from layers; each Dockerfile instruction adds one. Layers are shared and cached. The running container adds one thin writable layer that disappears when the container is removed - which is why data belongs in a volume.

Kubernetes basics

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes basics

Started at Google in 2014, built on Borg (2003) and Omega (2013), donated to the CNCF in 2015.

The one big idea

Desired state vs current state. You declare what you want; controllers compare it with reality and act until the two match. Everything else is a variation on this loop.

graph LR U[You: manifest] --> A[API server] A --> E[(etcd - desired state)] C[Controller] --> A C --> C C -->|create / delete| K[kubelet on node] K -->|reports current state| A

Architecture

graph TB subgraph control01 [Control plane] API[kube-apiserver] ETCD[(etcd)] SCH[kube-scheduler] CM[kube-controller-manager] end subgraph worker0X [Worker node] KL[kubelet] KP[kube-proxy] CRI[containerd] end API --- ETCD SCH --- API CM --- API KL --- API KP --- API KL --- CRI

Component	Job
kube-apiserver	the only door to the cluster; REST + validation
etcd	stores the desired state
kube-scheduler	picks a node for each new Pod
kube-controller-manager	runs the reconciliation loops
kubelet	runs and watches containers on its node
kube-proxy	implements Service networking on its node
containerd	the container runtime (CRI)

Pluggable by standard

CRI - runtime. Docker is not a CRI runtime and has not been supported since 1.24; this cluster runs containerd.
CNI - networking plugin.
CSI - storage drivers. This cluster has none, which is why the storage lab builds PersistentVolumes by hand.

Imperative vs declarative

kubectl run web01 --image nginx # imperative: an action
kubectl apply -f pod.yaml # declarative: a desired state

Imperative is for exploring. Everything that must survive gets versioned as YAML and applied. Only apply is idempotent.

Finding your way around kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Finding your way around kubectl

Nobody memorises the Kubernetes API. The cluster can describe itself, and this chapter is how you make it do that. Everything here works offline, against the version you are actually running - which is more than the internet can promise.

What kinds of object exist?

kubectl api-resources
kubectl api-resources | grep -i ingress
kubectl api-resources --namespaced=false # cluster-scoped kinds

The output gives you four things per kind: the plural name you type, its short name (deploy, svc, po), the API group and version, and whether it is namespaced.

Pods

Mon, 01 Jan 0001 00:00:00 +0000

Pods

The smallest schedulable unit. Not a container - an environment for one or more containers.

graph TB subgraph pod [Pod - one IP, one network namespace] C1[container: app] C2[container: sidecar] V[(shared volume)] C1 --- V C2 --- V end

Containers in a Pod share the IP address, ports, IPC and volumes, and always run on the same node. They talk over localhost. This is the --network container: mode from Docker, made into a first-class object.