Kubernetes (k8s) holder mange containere kørende på tværs af maskiner: genstarter dem ved nedbrud, skalerer efter belastning og ruller opdateringer ud uden nedetid. Forudsætter Docker-arket. Hvert eksempel står alene.
Docker kører én container. Kubernetes kører mange på tværs af en flok maskiner (et cluster). De vigtigste byggeklodser:
# Lokal k8s til øvelse (vælg én):
minikube start # separat værktøj
# eller: Docker Desktop → Settings →
# Enable Kubernetes
# Virker det?
kubectl version
kubectl get nodes # se clusterets maskiner
# Start en deployment med et nginx-image
kubectl create deployment web --image=nginx
# Se hvad der blev lavet
kubectl get deployments
kubectl get pods # pod kører?
kubectl get services
# Eksponér på en port (lav en service)
kubectl expose deployment web \\
--port=80 --type=LoadBalancer
# Se den i browseren (minikube):
minikube service web
kubectl get pods # status-oversigt
kubectl get pods -o wide # flere detaljer
kubectl describe pod web-xxx # dyb info + events
kubectl logs web-xxx # pod'ens output
kubectl logs -f web-xxx # følg live
# Terminal inde i pod'en
kubectl exec -it web-xxx -- sh
# Slet og lad deployment genstarte den
kubectl delete pod web-xxx
describe er din bedste ven ved fejl – nederst står events der fortæller hvorfor en pod ikke starter (fx image ikke fundet).
# Kør 4 kopier af appen
kubectl scale deployment web --replicas=4
# Se dem fordele sig
kubectl get pods
# Rul en ny version ud (uden nedetid)
kubectl set image deployment/web \\
nginx=nginx:1.25
# Se status på udrulningen
kubectl rollout status deployment/web
# Gå tilbage hvis noget gik galt
kubectl rollout undo deployment/web
Skalering er bare et tal: --replicas=4. Kubernetes fordeler selv pods'ene og genstarter dem hvis én dør. rollout undo er nødbremsen ved en dårlig opdatering.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
kubectl apply -f deployment.yaml # opret/opdatér
kubectl delete -f deployment.yaml # fjern igen
Kommandoer er fine til at prøve ting af, men rigtige projekter bruger YAML-filer: de kan ligge i Git, gentages og reviewes. apply er idempotent – kør den igen, og kun ændringer rulles ud.
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web # rammer pods med label app=web
ports:
- port: 80
targetPort: 80
type: LoadBalancer
selector kobler servicen til pods via labels – det er limen i hele Kubernetes. Pods med app: web-label får trafik fra denne service.
# ConfigMap: ikke-hemmelig konfiguration
kubectl create configmap app-indstillinger \\
--from-literal=FARVE=blaa
# Secret: adgangskoder og nøgler
kubectl create secret generic db-hemmelighed \\
--from-literal=password=s3cret
# Brug i deployment (under containers:)
env:
- name: FARVE
valueFrom:
configMapKeyRef:
name: app-indstillinger
key: FARVE
Konfiguration hører ikke i imaget – den skifter jo pr. miljø (test/prod). Læg den i ConfigMaps (almindelig) eller Secrets (følsom), og lad pod'en læse dem som miljøvariable.
kubectl get podsstatus på alle pods
kubectl describe pod xdyb fejlsøgning + events
kubectl logs -f xfølg pod-output live
kubectl exec -it x -- shterminal inde i pod
kubectl apply -f fil.yamlopret/opdatér fra YAML
kubectl delete -f fil.yamlfjern igen
kubectl scale deploy x --replicas=nskalér antal kopier
kubectl rollout undo deploy/xrul tilbage til forrige version
ImagePullBackOff → image-navn findes ikke. Tjek stavningen med describe.CrashLoopBackOff → appen crasher ved start. Se kubectl logs.selector-labels matcher ikke pod'ens labels.kubectl apply -f igen?LoadBalancer hænger i pending lokalt → brug minikube service eller port-forward: kubectl port-forward svc/web 8080:80.docker ps viser containere; kubectl get pods viser pods. De er ikke det samme.