Om je op weg te helpen met je eerste applicatie hebben we deze handleiding voor een statische site gemaakt. Hierin maak je kennis met:
Deployments zijn te aangewezen manier om applicaties te lanceren. Zoals een pod metadata bevat over containers, bevat een deployment dit over pods en andere objecten. Kubernetes zorgt er standaard automatisch voor dat de pods uit de deployments beschikbaar zijn. Hieronder is een voorbeeld van een deployment met een persistent volume:
De twee objecten deployment en persistant volume worden gescheiden door een regel met ---
, dit zijn eigenlijk dus twee yaml-bestanden.
De deployment gebruikt de apps/v1
-api, een belangerijk onderdeel van de deployment is de waarde replicas: 2
. Het getal van replicas geeft aan hoe veel pods er gestart worden, door dit getal op- of af te schalen kun je je applicatie eenvoudig horizontaal schalen. In een traditionele applicatie zou je de hele server moeten upgraden!
Persistent storage is data die bewaard blijft als een pod crashed. Erg handig dus voor gebruikersdata; uploads en content die wijzigt.
Alles bij deployment onder spec:
, is de configuratie van een pod die je zou maken. Dus zou hetzelfde kunnen zijn als bijvoorbeeld de pod uit de Hallo Wereld handleiding. Deze is echter wat uitgebreider zoals je ziet. Naast containers:
worden er ook volumes:
gedefineerd, tevens zit er een volumeMounts:
-object in de nginx container.
Hoe werken deze volumes? Aan de Kubernetes kan maak je een soort partitie aan met dekind: PersistentVolumeClaim
. Je geeft deze een naam, een grootte en hoe deze benaderd kan worden (ReadWriteMany
vs ReadWriteOnce
).
Deze volumes worden gekoppeld aan een container door middel van volumeMounts:
in de pod-configuratie en zijn dan beschikbaar als map op het opgegeven pad mountPath:
. In dit geval wordt het volume door alle containers gebruikt
Als je deployment online is met kubectl apply -f <map>/deployment.yaml
kun je alle pods zien met kubectl get pods
. Alle pods van de deployment heten nginx-deployment-<random tekens>
.
Maak een bestand index.html aan, bewerk het, plak <h1>Hallo van DirectVPS</h1>
erin (of je eigen tekst) en sla het op.
Voer nu het commando uit voor een van je bovenstaande nginx-deployment-<random tekens>
-pods: kubectl cp index.html nginx-deployment-754df5d4f7-g56vg:/usr/share/nginx/html/
In dit geval wordt het volume door alle containers gebruikt. Je kunt dit testen door voor beide een proxy op te zetten (in verschillende vensters): kubectl port-forward nginx-deployment-<random tekens> 80:80
en de 2e kubectl port-forward nginx-deployment-<random tekens> 81:80
.
Open vervolgens 2 tabbladen naar http://localhost/ en http://localhost:81/, hier zul je hetzelfde bericht zien.
Je hebt nu twee webworkers in jou deployment die jou statische site serveren. Deze is alleen nog bereikbaar via kubectl proxy
... Hier gaan we wat aan doen met één commando: kubectl expose deployment nginx-deployment --type=LoadBalancer --port 80
Om het resultaat te bekijken kunnen we het volgende commando gebruiken: kubectl get services
. Alle services met type LoadBalancer krijgen een extern IP-adres dat in dit overzicht ook zichtbaar is. Om het weer offline te halen kun je kubectl delete service/nginx-deployment
gebruiken.
Als je --type=LoadBalancer
niet meegeeft wordt er een ClusterIP
aangemaakt, dit is dan intern beschikbaar om microservices aan elkaar te verbinden. Je krijgt in ons shared Kubernetes cluster maar één loadbalancer tot je beschikking per namespace.
Kijk voor de volgende stap naar de Wordpress demo, of haal direct het meeste uit je loadbalancer met Routing, Ingress en Let's Encrypt.