Laby on Eriks training corner

Lab 01 – Příprava pracovní stanice

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

Lab 01 – Příprava pracovní stanice

Cíl: udělat ze support01 vaši kubectl stanici. Tahák: kubectl

support01 má Docker i NFS exporty, ale záměrně žádné kubectl a žádný kubeconfig. Postavit si vlastního klienta je první věc, kterou u zákazníka uděláte, tak si to zkusíme rovnou tady.

# 1 – přihlaste se na jump host (ze svého PC)
ssh student@192.168.56.101 # heslo: linux

# 2 – kdo jsem a dosáhnu na uzly clusteru?
hostname -f
ip -brief address # poznamenejte si adresu z 192.168.128.0/24
for n in control01 worker01 worker02 worker03; do getent hosts $n; done

Pokud se nějaké jméno nepřeloží, poznamenejte si jeho IP – budete ji potřebovat v kroku 6.

Lab 02 – Docker kontejnery

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

Lab 02 – Docker kontejnery

Cíl: životní cyklus kontejneru a proč záleží na zapisovatelné vrstvě. Tahák: Docker

# 1 – nejkratší možný kontejner
sudo docker run hello-world
sudo docker ps # nic – už skončil
sudo docker ps -a # a je tu, Exited (0)

Kontejner žije přesně tak dlouho jako jeho hlavní proces. hello-world vypíše text a skončí, takže je po všem dřív, než ho docker ps uvidí. Ze stejného důvodu skončí pod bez dlouho běžícího procesu v CrashLoopBackOff.

Lab 03 – Docker image a Dockerfile

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

Lab 03 – Docker image a Dockerfile

Cíl: pochopit vrstvy tím, že uvidíte pracovat build cache. Tahák: Docker

# 1 – stažení a prozkoumání
sudo docker pull nginx:1.27
sudo docker images
sudo docker history nginx:1.27 # jeden řádek na vrstvu, s velikostmi

history je build recept čtený pozpátku. Většina vrstev má 0 B – jen metadata. Ta velká je základní souborový systém.

# 2 – sdílení vrstev
sudo docker pull nginx:1.27-alpine
sudo docker images | grep nginx

Porovnejte velikosti. Alpine image jsou malé proto, že je malá základna, ne proto, že by nginx byl jiný.

Lab 04 – Docker síť a volumes

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

Lab 04 – Docker síť a volumes

Cíl: překlad jmen mezi kontejnery a data, která přežijí. Tahák: Docker

Sítě

# 1 – výchozí sítě
sudo docker network ls

# 2 – na výchozím bridge překlad jmen NEfunguje
sudo docker run -d --name db busybox sleep 3600
sudo docker run --rm busybox ping -c1 db # bad address 'db'

# 3 – vlastní síť dá DNS podle jména kontejneru
sudo docker network create appnet
sudo docker run -d --name db2 --network appnet busybox sleep 3600
sudo docker run --rm --network appnet busybox ping -c1 db2 # funguje

Tohle je nejužitečnější věc, kterou síťování Dockeru dělá, a je to koncept, který Kubernetes Service zobecňuje: dosáhnout na pohyblivý cíl přes stabilní jméno. Rozdíl je v tom, že jméno v Dockeru ukazuje na jeden kontejner, kdežto jméno Service na ty pody, které jsou zrovna připravené.

Lab 05 – První pohled na cluster

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

Lab 05 – První pohled na cluster

Cíl: zjistit, z čeho je cluster složený, a vidět rozdíl mezi imperativním a deklarativním přístupem. Tahák: kubectl

# 1 – kam a jako kdo jsem připojen?
kubectl cluster-info
kubectl config get-contexts
kubectl config view --minify | grep server

Zvykněte si na config get-contexts před čímkoli destruktivním. Většina produkčních nehod je příkaz napsaný na správný objekt ve špatném clusteru.

# 2 – stroje
kubectl get nodes -o wide
kubectl describe node control01 | head -40
kubectl describe node worker01 | grep -A6 'Allocated resources'

V describe node jsou důležité tři bloky: Conditions (je zdravý?), Taints (co tu odmítá běžet?) a Allocated resources (jak je plný?). Všimněte si, že se počítá z requestů podů, ne ze skutečného vytížení.

Lab 06 – Jak se v kubectl vyznat

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

Lab 06 – Jak se v kubectl vyznat

Infodiscovery

Cíl: už nikdy nepotřebovat internet na otázku o Kubernetes. Kapitola: Jak se v kubectl vyznat

U každého úkolu je napsané, co máte nakonec vidět. Nejdřív zkoušejte sami; v boxu je jedna funkční odpověď.

Úkol 1. Vypište všechny druhy objektů, které cluster zná, a zjistěte, jestli jsou ingresses v namespace a jakou mají zkratku.

Ukázat příkaz

kubectl api-resources
kubectl api-resources | grep -i ingress

ingresses ing networking.k8s.io/v1 true Ingress – zkratka ing, true znamená v namespace.

Lab 07 – Pody

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

Lab 07 – Pody

Cíl: vygenerovat manifest podu, přidat zdroje a vidět, co pod doopravdy je. Kapitola: Pody

# 1 – imperativně: vytvořit a zahodit
kubectl run bbox --image busybox --restart=Never -- sleep 3600
kubectl get pods
kubectl delete pod bbox

--restart=Never je to, co z kubectl run udělá holý pod místo něčeho spravovaného. -- sleep 3600 přepisuje příkaz image, protože busybox by jinak hned skončil.

# 2 – místo toho si manifest vygenerujte
cd ~
kubectl run bbox --image busybox --restart=Never --dry-run=client -o yaml \
 -- sleep 3600 > bbox.yaml
cat bbox.yaml

Upravte bbox.yaml a přidejte kontejneru zdroje:

Lab 08 – Ladění podů

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

Lab 08 – Ladění podů

Infodiscovery

Cíl: diagnostikovat čtyři rozbité pody jen z výstupu clusteru. Kapitola: Postup při ladění

U každého případu si nejdřív vyrobte problém uvedeným příkazem a pak odpovězte na otázku dřív, než otevřete box. Postup je vždy get → describe → logs.

Případ 1 – image se nedá stáhnout

kubectl run broken1 --image=nginx:doesnotexist
kubectl get pod broken1

Otázka. V jakém je stavu a kde přesně vám cluster říká proč?

Lab 09 – Namespaces

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

Lab 09 – Namespaces

Cíl: ohraničit si práci a přestat psát -n. Kapitola: Namespaces

# 1 – co existuje teď
kubectl get ns

Čtyři namespacy má každý cluster. kube-system obsahuje pody control plane – dívat se ano, nasazovat tam ne.

# 2 – deklarativně (doporučeno)
cd ~
cat > ns-dev.yaml <<'YAML'
apiVersion: v1
kind: Namespace
metadata:
 name: dev
YAML
kubectl apply -f ns-dev.yaml

# 3 – imperativně, pro jednorázový
kubectl create ns test

# 4 – stejné jméno v obou, bez konfliktu
kubectl run web --image nginx:1.27 -n dev
kubectl run web --image nginx:1.27 -n test
kubectl get pods -n dev
kubectl get pods -A | grep ' web '

Jména jsou unikátní na namespace a druh objektu. O to přesně jde: dev i prod můžou mít web.

Lab 10 – ReplicaSets

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

Lab 10 – ReplicaSets

Cíl: vidět reconciliation smyčku při práci a selektor, který váže pody. Kapitola: ReplicaSets

# 1 – ReplicaSet ručně (jediná situace, kdy ho budete psát)
cd ~
cat > web-rs.yaml <<'YAML'
apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: web-rs
spec:
 replicas: 3
 selector:
 matchLabels:
 app: web
 template:
 metadata:
 labels:
 app: web
 spec:
 containers:
 - name: web
 image: nginx:1.27
 resources:
 requests: { cpu: "20m", memory: "32Mi" }
YAML
kubectl apply -f web-rs.yaml
kubectl get rs,pods -l app=web -o wide

Všimněte si jmen podů: web-rs- plus hash šablony plus náhodná přípona. Vlastní je kontroler, což potvrdí kubectl get pod <jméno> -o yaml | grep -A5 ownerReferences.

Lab 11 – Deployments a probes

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

Lab 11 – Deployments a probes

Cíl: nasadit novou verzi, rozbít ji, vrátit se – a pochopit, proč to nebolelo. Kapitola: Deployments

# 1 – generovat, nepsat ručně
cd ~
kubectl create deploy web --image nginx:1.27 --replicas 3 \
 --dry-run=client -o yaml > web-deploy.yaml
kubectl apply -f web-deploy.yaml
kubectl get deploy,rs,pods -l app=web

Tři objekty z jednoho příkazu: Deployment, který jste chtěli, ReplicaSet, který vytvořil, a pody, které vytvořil ten ReplicaSet.

# 2 – nová verze
kubectl set image deploy/web nginx=nginx:1.28
kubectl rollout status deploy/web
kubectl get rs -l app=web

Teď jsou ReplicaSety dva: starý na nule, nový na třech. Starý se schválně nechává – je to váš rollback.

Lab 12 – DaemonSets

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

Lab 12 – DaemonSets

Cíl: jeden pod na uzel a dvě překvapení, která k tomu patří. Kapitola: DaemonSets

# 1 – cluster jich už několik provozuje
kubectl get ds -A
kubectl get pods -n kube-system -o wide | grep -i -E 'proxy|calico|cilium|flannel'

kube-proxy a agent CNI jsou DaemonSety: musí být na každém uzlu, včetně uzlů, které přibudou zítra. Nikde není pole replicas – počtem je seznam uzlů.

# 2 – váš vlastní
cd ~
cat > logger-ds.yaml <<'YAML'
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: node-logger
spec:
 selector:
 matchLabels:
 app: node-logger
 template:
 metadata:
 labels:
 app: node-logger
 spec:
 containers:
 - name: logger
 image: busybox
 command: ["sh", "-c", "while true; do echo \"$(date) $(hostname)\"; sleep 30; done"]
 resources:
 requests: { cpu: "10m", memory: "16Mi" }
YAML
kubectl apply -f logger-ds.yaml
kubectl get ds node-logger
kubectl get pods -l app=node-logger -o wide

Tři pody, jeden na každém workeru – a žádný na control01.

Lab 13 – Taints, tolerations a affinity

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

Lab 13 – Taints, tolerations a affinity

Cíl: řídit, kam pody přistanou – a vidět rozdíl mezi povoleno a přitahováno. Kapitola: Plánování

Tainty odpuzují

# 1 – výchozí stav: 6 podů rozprostřených po třech workerech
kubectl create deploy filler --image nginx:1.27 --replicas 6
kubectl get pods -o wide | sort -k7

# 2 – otaintujte worker03 a sledujte, jak se mu nové pody vyhnou
kubectl taint node worker03 disk=ssd:NoSchedule
kubectl describe node worker03 | grep -i -A2 taint
kubectl scale deploy filler --replicas 12
kubectl get pods -o wide | grep -c worker03 # beze změny

Pody, které na worker03 už byly, tam pořád jsou. NoSchedule ovlivňuje jen umístění; nic nevystěhuje.

Lab 14 – Services

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

Lab 14 – Services

Cíl: dosáhnout na pody přes stabilní jméno, zevnitř i zvenčí. Kapitola: Services

# 1 – co budeme vystavovat
cd ~
kubectl create deploy web --image nginx:1.27 --replicas 3
kubectl get pods -l app=web -o wide # všimněte si IP podů

# 2 – ClusterIP, výchozí typ
kubectl expose deploy web --port 80 --name web-svc
kubectl get svc web-svc
kubectl get endpointslices -l kubernetes.io/service-name=web-svc

Zajímavý objekt je EndpointSlice: drží ty tři IP podů. Service je jen stabilní průčelí; EndpointSlice je živý seznam členů, který udržuje kontroler podle toho, které pody jsou ready.

Lab 15 – Gateway API

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

Lab 15 – Gateway API

Cíl: nainstalovat Gateway controller a nasměrovat dvě aplikace podle jména hosta přes jeden port – a pak rozdělit provoz mezi dvě verze. Kapitola: Gateway API

Objekty Gateway API jsou jen data. Nejdřív musí existovat dvě věci: CRD (nejsou součástí Kubernetes) a controller, který je čte.

Instalace CRD

# 1 – standardní kanál: GatewayClass, Gateway, HTTPRoute
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml
kubectl get crd | grep gateway.networking
kubectl api-resources --api-group=gateway.networking.k8s.io

Právě jste rozšířili API server o nové druhy objektů – přesně ten mechanismus CRD, který probíráme třetí den, tady potkaný v praxi. Na stránce vydání zkontrolujte, jestli není novější verze.

Lab 16 – Operace s uzly

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

Lab 16 – Operace s uzly

Infodiscovery

Cíl: bezpečně odstavit uzel kvůli údržbě a vrátit ho zpět. Kapitola: Uzly (nodes)

Všechno tady jsou pod kapotou tainty – viz lab 13, pokud si je chcete vyzkoušet ručně.

# příprava – ať máme čím hýbat
kubectl create deploy filler --image nginx:1.27 --replicas 6
kubectl get pods -o wide | sort -k7

Úkol 1. Zabraňte plánování nových podů na worker03, aniž byste narušili to, co tam běží. Očekávaný výsledek: kubectl get nodes ukazuje u worker03 Ready,SchedulingDisabled a jeho pody jsou netknuté.

Lab 17 – ConfigMapy a Secrety

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

Lab 17 – ConfigMapy a Secrety

Cíl: stejný image, jiná konfigurace – a zjistit, které změny potřebují restart. Kapitola: ConfigMapy a Secrety

# 1 – z literálů a ze souboru
cd ~
printf 'color=blue\nretries=3\n' > app.properties
kubectl create cm app-cfg \
 --from-literal=DATACENTER=dc01 \
 --from-file=app.properties
kubectl get cm app-cfg -o yaml

--from-literal udělá jeden klíč; --from-file udělá klíč pojmenovaný podle souboru, jehož hodnotou je celý soubor. Obojí končí ve stejné mapě data.

# 2 – spotřebujte obojím způsobem najednou
cat > cfgpod.yaml <<'YAML'
apiVersion: v1
kind: Pod
metadata:
 name: cfgpod
spec:
 containers:
 - name: box
 image: busybox
 command: ["sh", "-c", "env | sort; sleep 3600"]
 env:
 - name: DATACENTER
 valueFrom:
 configMapKeyRef:
 name: app-cfg
 key: DATACENTER
 volumeMounts:
 - name: cfg
 mountPath: /etc/appcfg
 volumes:
 - name: cfg
 configMap:
 name: app-cfg
YAML
kubectl apply -f cfgpod.yaml
kubectl logs cfgpod | grep DATACENTER
kubectl exec cfgpod -- ls /etc/appcfg
kubectl exec cfgpod -- cat /etc/appcfg/app.properties

Z každého klíče vznikl soubor v /etc/appcfg a z jednoho navíc proměnná prostředí.

Lab 18 – Perzistentní úložiště na NFS

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

Lab 18 – Perzistentní úložiště na NFS

Cíl: dát podu úložiště, které ho přežije – bez StorageClass a bez CSI driveru, přesně jak vypadá on-premise cluster. Kapitola: Perzistentní úložiště

support01 exportuje přes NFS /storage1, /storage2 a /storage3. Dynamické provisioning tu není, takže PersistentVolume napíšete vy.

Příprava uzlů

# 1 – každý uzel, který připojuje NFS, potřebuje klientské nástroje
for n in worker01 worker02 worker03; do
 ssh student@$n 'dpkg -l nfs-common >/dev/null 2>&1 && echo "$(hostname): ok" || sudo apt-get install -y nfs-common'
done

# 2 – ověřte export z uzlu, nejdřív mimo Kubernetes
ssh student@worker01 'sudo mkdir -p /mnt/t && sudo mount -t nfs support01:/storage1 /mnt/t && df -h /mnt/t && sudo umount /mnt/t'

Vždy si mount vyzkoušejte ručně, než začnete vinit Kubernetes. Pod zaseknutý v ContainerCreating s chybou NFS obvykle znamená chybějící nfs-common, špatnou cestu exportu nebo práva exportu.

Lab 19 – StatefulSets

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

Lab 19 – StatefulSets

Cíl: stabilní jména, úložiště na každý pod, řízené pořadí – a překvapení při úklidu. Kapitola: StatefulSets

Lab potřebuje tři PV z labu 18. Ověřte, že jsou Available:

kubectl get pv
kubectl patch pv pv-storage1 -p '{"spec":{"claimRef":null}}' 2>/dev/null
kubectl get pv

Nejdřív headless Service

# 1 –
cd ~
cat > web-headless.yaml <<'YAML'
apiVersion: v1
kind: Service
metadata:
 name: web-headless
spec:
 clusterIP: None # headless – žádná virtuální IP
 selector:
 app: web-sts
 ports:
 - port: 80
YAML
kubectl apply -f web-headless.yaml
kubectl get svc web-headless # CLUSTER-IP je "None"

Normální Service pody schová za jednu IP. Headless Service dělá opak: DNS vrátí adresy jednotlivých podů, takže je každá replika adresovatelná jménem. StatefulSet ji vyžaduje.

Lab 20 – Helm release

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

Lab 20 – Helm release

Cíl: nainstalovat, nakonfigurovat, povýšit a vrátit zpět cizí chart. Kapitola: Základy Helmu

Helm už by měl být nainstalovaný z labu 14. Pokud ne:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod +x get_helm.sh && sudo ./get_helm.sh && helm version

# 1 – repozitář
helm repo add podinfo https://stefanprodan.github.io/podinfo
helm repo update
helm repo list
helm search repo podinfo
helm search repo podinfo --versions | head -5

Repozitář je jen web server s index.yaml. helm repo update ten index znovu stáhne – jinam Helm nesahá, dokud něco neinstalujete.

Lab 21 – Vlastní chart

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

Lab 21 – Vlastní chart

Cíl: zabalit aplikaci tak, aby šla nainstalovat vícekrát s jinými hodnotami. Kapitola: Helm charty

# 1 – kostra a co v ní je
cd ~
helm create shop
find shop -type f | sort
cat shop/Chart.yaml
head -30 shop/values.yaml

helm create dá funkční nginx chart s mnohem víc mašinerií, než potřebujete. Přečíst si ji stojí za to: ukazuje konvence, které dodržuje každý veřejný chart.

# 2 – vyrenderujte výchozí chart, než něco změníte
helm template shop | head -40
helm lint shop

helm template nepotřebuje cluster ani síť. Spouštějte ho po každé úpravě – je rychlejší než jakákoli instalace a ukáže skutečné YAML.

Lab 22 – Operátor: PostgreSQL

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

Lab 22 – Operátor: PostgreSQL

Cíl: nainstalovat skutečný operátor, vytvořit databázový cluster jedním malým manifestem a sledovat, jak ho operátor sám opraví. Kapitola: CRD a operátory

Použijete CloudNativePG, operátor pro PostgreSQL. Všechno dosud probrané platí: operátor vytváří pody podobné StatefulSetu, Services, Secrety a PVC – objekty, které už umíte číst.

Nejdřív úložiště

Cluster nemá dynamické provisioning, takže PV musí existovat dřív, než si o ně databáze řekne. Použijte NFS PV z labu 18:

Lab 23 – Aplikace od začátku do konce

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

Lab 23 – Aplikace od začátku do konce

Infodiscovery volitelný / zbude-li čas

Cíl: postavit, provozovat, rozbít a opravit kompletní aplikaci se vším ze tří dnů.

Tenhle lab říká co, ne jak. Každý příkaz je v tahácích, v kubectl explain nebo pod --help.

Tip

Každá etapa končí boxem s řešením. Nejdřív ji zkuste sami; box otevřete, když se zaseknete nebo si chcete své řešení porovnat s funkčním. Každý box je samostatný, takže se můžete připojit na začátku libovolné etapy, i když jste předchozí neudělali po svém. Pokud jste ztracení úplně, skočte dolů na Dohnat to jedním vložením.