Day 1 on Eriks training corner

Ecosystem, containers and orchestration

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

Ecosystem, containers and orchestration

Container in one paragraph

A container is a process on the host kernel, isolated by namespaces and limited by cgroups. It starts from an image: read-only layers plus one thin writable layer that disappears with the container. No guest OS, so start-up takes milliseconds.

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

Why orchestration

One host and docker run do not answer the questions production asks:

Architecture: control plane and worker nodes

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

Architecture: control plane and worker nodes

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.

Components

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	Where	Job
kube-apiserver	control plane	the only door to the cluster; authN, authZ, validation
etcd	control plane	key-value store of all objects
kube-scheduler	control plane	picks a node for each new Pod
kube-controller-manager	control plane	runs the reconciliation loops
kubelet	every node	starts containers, reports status
kube-proxy	every node	Service routing (iptables / IPVS)
containerd	every node	container runtime (CRI)
CoreDNS	Pods in kube-system	cluster DNS

Only the API server talks to etcd. Every other component - including kubectl - talks only to the API server.

The Kubernetes API and kubectl

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

The Kubernetes API and kubectl

Everything in Kubernetes is a REST resource behind the API server. kubectl is just an HTTP client with good manners.

Groups, versions, resources

/api/v1/namespaces/dev/pods/web core group ("") -> apiVersion: v1
/apis/apps/v1/namespaces/dev/deployments group apps -> apiVersion: apps/v1
/apis/networking.k8s.io/v1/ingresses group networking.k8s.io

Verb	HTTP	kubectl
create	POST	`create`, `apply`
get / list / watch	GET	`get`, `describe`, `get -w`
update / patch	PUT / PATCH	`apply`, `edit`, `patch`, `scale`
delete	DELETE	`delete`

See the real calls: kubectl get pods -v=6.

Declarative vs. imperative

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

Declarative vs. imperative

Three ways to manage objects. Use one per object - mixing them is where drift comes from.

Technique	Example	You say	Good for
Imperative commands	`kubectl run`, `create deploy`, `scale`	do this	exploring, one-offs
Imperative object config	`kubectl create -f`, `replace -f`	create exactly this file	rarely
Declarative object config	`kubectl apply -f`	make it look like this	everything you keep

kubectl create deploy web --image nginx:1.27 # fails if it exists
kubectl apply -f web.yaml # creates or updates - idempotent

The workflow

graph LR G["generate<br/>--dry-run=client -o yaml"] --> E[edit YAML] E --> D["kubectl diff -f"] D --> A["kubectl apply -f"] A --> V[version in git]

kubectl create deploy web --image nginx:1.27 --dry-run=client -o yaml > web.yaml
kubectl diff -f web.yaml # what would change?
kubectl apply -f web.yaml --dry-run=server # validated by the API, not stored
kubectl apply -f web.yaml

How apply knows what to remove

apply compares three things: your file, the live object and the last applied configuration. Client-side apply stores the last one in the annotation kubectl.kubernetes.io/last-applied-configuration.

Namespaces

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

Namespaces

A virtual cluster inside the cluster: a name scope for objects, and the place to attach quotas, RBAC and network policies.

graph TB subgraph cluster subgraph ns1 [namespace: dev] P1[pod web] --- P2[pod db] end subgraph ns2 [namespace: prod] P3[pod web] --- P4[pod db] end N[nodes, PVs, StorageClasses - not namespaced] end

kubectl get ns
kubectl create ns dev
kubectl get pods -n dev
kubectl get pods -A
kubectl config set-context --current --namespace=dev
kubectl api-resources --namespaced=false # what lives outside namespaces

Namespaced	Cluster-scoped
Pods, Deployments, Services, ConfigMaps, Secrets, PVCs, Roles	Nodes, PersistentVolumes, StorageClasses, ClusterRoles, CRDs, Namespaces

Built in: default, kube-system, kube-public, kube-node-lease. Never deploy your own work into kube-system.

Labels, selectors and annotations

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

Labels, selectors and annotations

Both are key/value pairs in metadata. The difference is who reads them.

	Labels	Annotations
Purpose	identify and select objects	attach non-identifying info
Used by	Services, ReplicaSets, scheduler, `kubectl -l`	tools, humans, controllers
Size	short (63 chars value)	up to 256 KB total
Example	`app=web`, `env=prod`, `tier=frontend`	`description`, build commit, Ingress settings

metadata:
 name: web-7d9f
 labels:
 app.kubernetes.io/name: web
 app.kubernetes.io/part-of: shop
 env: prod
 annotations:
 team.example.com/owner: "platform"
 kubernetes.io/change-cause: "image 1.28"

Selectors

kubectl get pods -l env=prod # equality
kubectl get pods -l 'env!=prod'
kubectl get pods -l 'env in (dev,test),tier' # set-based; 'tier' = key exists
kubectl get pods -l '!tier' # key does not exist
kubectl get pods -L env,tier # labels as columns
kubectl get pods --field-selector status.phase=Running # fields, not labels

graph LR S["Service<br/>selector: app=web"] --> P1["Pod app=web"] S --> P2["Pod app=web"] RS["ReplicaSet<br/>selector: app=web"] --> P1 RS --> P2 X["Pod app=db"]

Controllers find their Pods only through label selectors. Change a Pod’s label and it leaves the ReplicaSet and the Service - a common debugging trick.

Objects and their lifecycle

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

Objects and their lifecycle

Anatomy of every object

apiVersion: apps/v1  # group/version
kind: Deployment  # type
metadata: # identity: name, namespace, labels, uid, ...
 name: web
spec: # desired state - written by you
 replicas: 3
status: # current state - written by controllers
 readyReplicas: 3

metadata field	Meaning
`uid`	unique for the object’s lifetime; a recreated object gets a new one
`resourceVersion`	changes on every write; used for optimistic locking
`generation`	increments when `spec` changes; compare with `status.observedGeneration`
`ownerReferences`	who owns me - drives garbage collection
`finalizers`	work that must finish before deletion
`deletionTimestamp`	set when deletion was requested

Lifecycle

stateDiagram-v2 [*] --> Created: create / apply Created --> Reconciled: controllers act on spec Reconciled --> Reconciled: spec changes (generation++) Reconciled --> Terminating: delete (deletionTimestamp set) Terminating --> [*]: finalizers empty

Ownership and garbage collection

Delete the owner and the garbage collector deletes the dependents.

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, ports and volumes, always run on the same node, and talk over localhost.

Minimal manifest

apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
 labels:
 app: web
spec:
 containers:
 - name: nginx
 image: nginx:1.27
 ports:
 - containerPort: 80
 resources:
 requests: { cpu: "50m", memory: "64Mi" }
 limits: { cpu: "200m", memory: "128Mi" }

Requests drive scheduling, limits are enforced at runtime - details on Day 3.

ReplicaSets and Deployments

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

ReplicaSets and Deployments

ReplicaSet - keep N copies running

graph LR RS[ReplicaSet replicas=3] --> P1[Pod] RS --> P2[Pod] RS --> P3[Pod] P2 -.node dies.-> X((gone)) RS -->|reconcile| P4[new Pod]

Count Pods matching the selector, compare with spec.replicas, create or delete the difference. Self-healing and scaling are the same loop.

spec:
 replicas: 3
 selector:
 matchLabels:
 app: web
 template:
 metadata:
 labels:
 app: web  # must match the selector
 spec:
 containers:
 - name: web
 image: nginx:1.27

Pods are bound by selector, not by name - a loose Pod with a matching label gets adopted. A ReplicaSet has no rollout logic: a changed template does not touch running Pods.