Omdat Docker, Podman en Kubernetes in elkaars verlengde liggen is het leren lezen (en gebruiken) van service deployments yaml's nuttig, leuk en leerzaam. De in Podman en Kubernetes gebruikte Service deployments lijken sterk op de bekende Docker-compose files, maar kennen meer opties.
Samenvatting;
Deze yaml bestaat uit een aantal zelfstandige secties, gescheiden door drie minnetjes ---. Elke sectie declareert dus een soort service (rood) met een logische naam (groen). De clou is nieuwe services kunnen verwijzen naar eerder gedeclareerde services. Hierbij zijn een aantal restricties, zoals het feit dat een namespace een unieke naam moet hebben of dat een PVC niet in twee namespaces tegelijk toegepast kan worden. Ik zal omwille van beknoptheid hier niet alle restricties opnoemen maar focus leggen op het hoog-over begrijpen van de yaml.
Dit stukje Yaml creeert dus een namespace genaamd "hello". Alle pods die gecreeerd worden binnen deze namespace kunnen met elkaar communiceren zonder extra configuratie(!) Daarnaast creeert de yaml een Persistent Volume (PV) genaamd "hello-pv" met een grootte van 1 Gigabyte (een stuk persistent schijfruimte wordt geclaimed om de pod data op te parkeren op de lokale schijf van de server). Dit is binnen een homelab prima maar in een cloudomgeving zal dit niet lokaal zijn. Via een zogenaamde "Persistent Volume Claim" (PVC) wordt de PV gekoppeld aan de te creeren pod. Deze pod bevat 2 containers, te weten nginx met een sidecar filebrowser. Beide containers gebruiken hetzelfde volume via de Persistent Volume Claim (PVC). Filebrowser zijn interne poort 8080 wordt extern gemapped op port 80. Omdat er een loadbalancer service draait handelt de loadbalancer het 'exposen' van de pod aan de buitenwereld af.
Heb je bijvoorbeeld ineens meer webservers nodig? Scroll naar de deployment sectie, pas replicas aan van 1 naar 2,3 of 10?, doorvoeren, wachten en klaar. de computer verhoogt het aantal pods naar het nieuwe gewenste aantal.
Op deze wijze wordt het beheren van bijvoorbeeld een eigen webserver ineens een stuk leuker en leerzamer ;-)
In dit scenario zorgt Filebrowser voor de toegang tot de PV (waar dit zich dan ook bevind maakt ons als eindgebruiker niks uit) en NGINX serveert de content die we daar neerzetten
apiVersion: v1
kind: Namespace
metadata:
name: hello
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: hello-pv
namespace: hello
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: /mnt/data # Path on the node (for demo/testing)
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: hello-pvc
namespace: hello
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: manual
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: hello
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
volumeMounts:
- name: hello-storage
mountPath: /usr/share/nginx/html
- name: filebrowser
image: filebrowser/filebrowser:latest
ports:
- containerPort: 8080
volumeMounts:
- name: hello-storage
mountPath: /srv
volumes:
- name: hello-storage
persistentVolumeClaim:
claimName: hello-pvc
---
apiVersion: v1
kind: Service
metadata:
name: filebrowser-service
namespace: hello
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: LoadBalancer