Container Orchestratie met Kubernetes: Setup Gids 2026

SAMENVATTING

Docker Container Orchestratie met Kubernetes: Complete Setup Gids 2026

Beheers Docker containers op schaal met Kubernetes orchestratie, van basis setup tot productie-ready deployments.

Keywords: Kubernetes orchestratie, Docker containers, Cloud deployment


INHOUDSOPGAVE

1. Waarom Container Orchestratie Essentieel is in 2026

2. Kubernetes Fundamentals: Van Docker naar Orchestratie

3. Kubernetes Cluster Setup: Lokaal en Cloud

4. Docker Images Deployen naar Kubernetes

5. Service Discovery en Load Balancing

6. Persistent Storage en ConfigMaps

7. Monitoring en Troubleshooting

8. Productie Best Practices en Security


ACHTERGROND

Waarom Container Orchestratie Essentieel is in 2026


In 2026 draait 89% van alle nieuwe enterprise applicaties in containers, waarbij Kubernetes de facto standaard is geworden voor orchestratie. Bedrijven zoals Netflix beheren meer dan 100.000 containers dagelijks via Kubernetes, wat de schaal en complexiteit van moderne applicaties illustreert.

KERNPUNT

Kubernetes lost de fundamentele uitdaging op van het beheren van containers op schaal — automatische scaling, self-healing, en zero-downtime deployments worden standaard functionaliteiten.

Docker containers hebben de manier waarop we software ontwikkelen en deployen revolutionair veranderd. Echter, het beheren van tientallen, honderden of duizenden containers handmatig is praktisch onmogelijk. Hier komt Kubernetes (K8s) om de hoek kijken als orchestratie-platform dat:

Automatische scaling — Containers worden automatisch opgeschaald bij verhoogde load. Spotify schaalt bijvoorbeeld automatisch van 50 naar 500 pod replicas tijdens piekmomenten in muziekstreaming.

Self-healing capabilities — Gefaalde containers worden automatisch vervangen. Google rapporteert dat hun Kubernetes clusters 99.95% uptime behalen door automatische recovery.

Rolling updates — Nieuwe versies worden geleidelijk uitgerold zonder downtime. Airbnb deployed dagelijks 500+ keer naar productie met zero-downtime via Kubernetes rolling updates.

Modern data center with container orchestration and Kubernetes management interface

De statistieken spreken voor zich: volgens de CNCF Survey 2025 gebruikt 96% van de organisaties containers in productie, waarvan 87% Kubernetes als orchestratie-platform heeft gekozen. De gemiddelde enterprise beheert 847 containers in productie, wat handmatig beheer praktisch onmogelijk maakt.


FUNDAMENTALS

Kubernetes Fundamentals: Van Docker naar Orchestratie


Kubernetes bouwt voort op Docker containers maar introduceert een geheel nieuwe abstractielaag. Waar Docker individuele containers beheert, orchestreert Kubernetes complete applicatie-ecosystemen bestaande uit meerdere interconnected services.

Kubernetes Architectuur Overzicht

Control Plane Componenten

API Server — Centrale communicatielaag voor alle Kubernetes operaties

etcd — Distributed key-value store voor cluster state en configuratie

Scheduler — Bepaalt op welke nodes pods worden geplaatst

Controller Manager — Beheert verschillende controllers voor desired state


Worker Node Componenten

kubelet — Agent die containers op de node beheert

kube-proxy — Network proxy voor service discovery

Container Runtime — Docker of containerd voor container execution

Kubernetes architecture diagram with control plane and worker node components

KERNPUNT

Een Kubernetes cluster bestaat uit minimaal één control plane node en één of meer worker nodes. In productie worden typisch 3 control plane nodes gebruikt voor high availability.

Kubernetes Resources: Pods, Services en Deployments

Kubernetes introduceert verschillende resource types die samen een applicatie vormen. Deze resources worden gedefinieerd in YAML manifests en beheerd via de Kubernetes API.

CODE-UITLEG

Een eenvoudig Pod manifest dat een nginx container definieert met resource limits en health checks.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
      requests:
        memory: "64Mi"
        cpu: "250m"
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 30
      periodSeconds: 10

In productie worden Pods zelden direct aangemaakt. In plaats daarvan gebruikt men Deployments die Pods beheren en features bieden zoals rolling updates, rollbacks en replica management.


SETUP

Kubernetes Cluster Setup: Lokaal en Cloud


Voor ontwikkeling en testing zijn er verschillende opties om een Kubernetes cluster op te zetten. We behandelen zowel lokale development clusters als productie-ready cloud setups.

Lokale Development met Kind (Kubernetes in Docker)

STEP 1

Kind Installatie en Setup

Kind is ideaal voor lokale development omdat het een complete Kubernetes cluster draait binnen Docker containers.


CODE-UITLEG

Installatie van Kind en aanmaken van een multi-node cluster voor realistische testing.

# Kind installeren op macOS
brew install kind

# Linux installatie
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

# Cluster configuratie bestand maken
cat <<EOF > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF

# Multi-node cluster aanmaken
kind create cluster --config kind-config.yaml --name development
STEP 2

kubectl Configuratie

kubectl is het command-line tool voor interactie met Kubernetes clusters.


CODE-UITLEG

Verificatie van cluster status en configuratie van kubectl context.

# Cluster status controleren
kubectl cluster-info

# Nodes bekijken
kubectl get nodes

# Context instellen (automatisch door Kind)
kubectl config current-context

# Namespace aanmaken voor development
kubectl create namespace development

# Default namespace instellen
kubectl config set-context --current --namespace=development

Terminal interface displaying Kubernetes kubectl commands and cluster status

Cloud Kubernetes Services: AKS, EKS, GKE

Voor productie workloads bieden cloud providers managed Kubernetes services die de complexiteit van cluster management wegnemen. De drie grootste providers hebben elk hun eigen implementatie:

Google Kubernetes Engine (GKE)

Meest mature managed service, autopilot mode voor volledig beheer, gemiddelde kosten €0.10 per cluster per uur.


Amazon Elastic Kubernetes Service (EKS)

Diepste AWS integratie, Fargate voor serverless pods, gemiddelde kosten €0.10 per cluster + node kosten.


Azure Kubernetes Service (AKS)

Gratis control plane, Azure integratie, virtual nodes voor burst capacity, alleen node kosten betalen.

KERNPUNT

Managed Kubernetes services nemen cluster management over maar je betaalt nog steeds voor worker nodes. Een typische productie setup met 3 nodes kost €200-400 per maand afhankelijk van instance types.


DEPLOYMENT

Docker Images Deployen naar Kubernetes


Het deployen van Docker containers naar Kubernetes vereist een andere mindset dan directe Docker runs. In plaats van containers direct te starten, definiëren we desired state via YAML manifests.

Van Docker Run naar Kubernetes Deployment

Laten we een praktisch voorbeeld bekijken: het deployen van een Node.js applicatie die lokaal draait via Docker.

CODE-UITLEG

Traditionele Docker run command die we gaan transformeren naar een Kubernetes Deployment.

# Traditionele Docker run
docker run -d \
  --name nodejs-app \
  -p 3000:3000 \
  -e NODE_ENV=production \
  --restart unless-stopped \
  myregistry/nodejs-app:v1.2.0

Deze Docker run configuratie wordt in Kubernetes getransformeerd naar een Deployment manifest dat dezelfde functionaliteit biedt plus additional orchestratie features:

CODE-UITLEG

Kubernetes Deployment manifest met 3 replicas, rolling updates en resource limits.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs-app
  labels:
    app: nodejs-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: nodejs-app
  template:
    metadata:
      labels:
        app: nodejs-app
    spec:
      containers:
      - name: nodejs-app
        image: myregistry/nodejs-app:v1.2.0
        ports:
        - containerPort: 3000
        env:
        - name: NODE_ENV
          value: "production"
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5

Container Registry Integration

Kubernetes haalt images uit container registries. Voor private registries moet je authentication configureren via Secrets. Dit is essentieel voor productie deployments waar proprietary code wordt gebruikt.

CODE-UITLEG

Aanmaken van een Docker registry secret voor authentication bij private registries.

# Docker registry secret aanmaken
kubectl create secret docker-registry regcred \
  --docker-server=myregistry.com \
  --docker-username=myuser \
  --docker-password=mypassword \
  [email protected]

# Secret gebruiken in Deployment
spec:
  template:
    spec:
      imagePullSecrets:
      - name: regcred
      containers:
      - name: nodejs-app
        image: myregistry.com/nodejs-app:v1.2.0

Kubernetes deployment process with container registry and cluster nodes

KERNPUNT

Image tags zoals ‘latest’ vermijden in productie. Gebruik specifieke versie tags (v1.2.0) voor reproduceerbare deployments en makkelijke rollbacks.


NETWORKING

Service Discovery en Load Balancing


Kubernetes Services vormen de backbone van inter-container communicatie. Ze bieden stable networking endpoints voor dynamische Pod sets en fungeren als internal load balancers.

Service Types en Use Cases

ClusterIP Service

Use Case — Internal service-to-service communicatie binnen cluster

Bereikbaarheid — Alleen binnen cluster, krijgt internal IP

Typisch Voor — Databases, internal APIs, backend services


LoadBalancer Service

Use Case — Externe toegang via cloud provider load balancer

Bereikbaarheid — Public internet, krijgt external IP

Typisch Voor — Web applicaties, public APIs, customer-facing services


Ingress Controller

Use Case — HTTP/HTTPS routing met hostname en path-based rules

Bereikbaarheid — Public internet met SSL termination

Typisch Voor — Multi-tenant applications, microservices routing

Praktische Service Implementatie

CODE-UITLEG

Complete service setup voor een microservices architectuur met frontend, API en database layers.

# Frontend LoadBalancer Service (external access)
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 3000
    protocol: TCP
  selector:
    app: frontend
---
# API ClusterIP Service (internal)
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP
  ports:
  - port: 8080
    targetPort: 8080
    protocol: TCP
  selector:
    app: api
---
# Database Service (internal)
apiVersion: v1
kind: Service
metadata:
  name: postgres-service
spec:
  type: ClusterIP
  ports:
  - port: 5432
    targetPort: 5432
    protocol: TCP
  selector:
    app: postgres

Service Discovery in Kubernetes werkt via DNS. Elke Service krijgt automatisch een DNS entry in het formaat service-name.namespace.svc.cluster.local. Dit maakt inter-service communicatie eenvoudig:

CODE-UITLEG

Environment variabelen configuratie voor service discovery tussen containers.

# Frontend container configuratie
env:
- name: API_URL
  value: "http://api-service:8080"
- name: POSTGRES_HOST
  value: "postgres-service"
- name: POSTGRES_PORT
  value: "5432"

# Database connection string
- name: DATABASE_URL
  value: "postgresql://user:pass@postgres-service:5432/mydb"

KERNPUNT

LoadBalancer services creëren externe IP addresses bij cloud providers. Dit kost extra (gemiddeld €20-50/maand per LoadBalancer). Voor cost optimization gebruik Ingress controllers voor HTTP traffic.

Kubernetes networking diagram with services, pods and load balancer connections


STORAGE

Persistent Storage en ConfigMaps


Containers zijn by design stateless en ephemeral. Voor applicaties die data persistence vereisen, biedt Kubernetes Persistent Volumes (PV) en Persistent Volume Claims (PVC). ConfigMaps en Secrets beheren configuratie data gescheiden van container images.

Persistent Volume Claims voor Database Storage

PROBLEEM 01

Database Data Verlies bij Pod Restart

Zonder persistent storage gaat alle database data verloren wanneer een Pod crashed of wordt heropgestart. Dit is fataal voor productie databases.

OPLOSSING — Persistent Volume Claim met StatefulSet

CODE-UITLEG

PostgreSQL database met persistent storage die data behoudt tussen Pod restarts.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp2  # AWS EBS
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres-service
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:13
        env:
        - name: POSTGRES_DB
          value: "myapp"
        - name: POSTGRES_USER
          value: "appuser"
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: password
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc

ConfigMaps voor Application Configuration

ConfigMaps scheiden configuratie van application code. Dit volgt de twelve-factor app methodology en maakt environment-specific deployments mogelijk zonder image rebuilds.

CODE-UITLEG

ConfigMap met verschillende configuratie formaten en usage patterns in Pods.

# ConfigMap met key-value pairs
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgresql://appuser@postgres-service:5432/myapp"
  redis_url: "redis://redis-service:6379"
  log_level: "info"
  max_connections: "100"
  # Complete configuratie bestand
  nginx.conf: |
    server {
      listen 80;
      server_name _;
      location / {
        proxy_pass http://api-service:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
      }
    }
---
# Pod die ConfigMap gebruikt
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp:v1.0
    # Environment variabelen van ConfigMap
    envFrom:
    - configMapRef:
        name: app-config
    # Specifieke key als environment variabele
    env:
    - name: DATABASE_URL
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: database_url
    # ConfigMap als volume mount
    volumeMounts:
    - name: config-volume
      mountPath: /etc/nginx
  volumes:
  - name: config-volume
    configMap:
      name: app-config
      items:
      - key: nginx.conf
        path: nginx.conf

KERNPUNT

Secrets hebben base64 encoding maar zijn NIET encrypted by default. Voor productie security gebruik externe secret management zoals HashiCorp Vault of cloud provider secret services.

Storage Classes en Dynamic Provisioning

Cloud providers bieden verschillende storage types via Storage Classes. Dynamic provisioning creëert automatisch storage volumes based on PVC requests, wat operationele overhead drastisch reduceert.

CODE-UITLEG

Storage Class definitie voor verschillende performance requirements en cost optimization.

# High-performance SSD storage class
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
allowVolumeExpansion: true
---
# Cost-optimized HDD storage class
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow-hdd
provisioner: ebs.csi.aws.com
parameters:
  type: sc1  # Cold HDD
allowVolumeExpansion: true

MONITORING

Monitoring en Troubleshooting


Effectieve monitoring is cruciaal voor productie Kubernetes clusters. Zonder proper observability ben je blind voor performance issues, resource bottlenecks en security incidents. We behandelen zowel built-in Kubernetes tools als enterprise monitoring solutions.

kubectl Diagnostics Commands

kubectl biedt uitgebreide diagnostic capabilities voor eerste-lijn troubleshooting. Deze commands zijn essentieel voor elke Kubernetes operator.

CODE-UITLEG

Essential kubectl commands voor cluster health monitoring en troubleshooting workflows.

# Cluster overview
kubectl get nodes -o wide
kubectl top nodes  # Requires metrics-server

# Pod troubleshooting
kubectl get pods --all-namespaces
kubectl describe pod <pod-name>
kubectl logs <pod-name> -f
kubectl logs <pod-name> -c <container-name> --previous

# Resource monitoring
kubectl top pods --all-namespaces
kubectl get events --sort-by=.metadata.creationTimestamp

# Service debugging
kubectl get svc --all-namespaces
kubectl describe svc <service-name>
kubectl get endpoints

# Storage troubleshooting
kubectl get pv,pvc
kubectl describe pvc <pvc-name>

Prometheus en Grafana Stack

Voor enterprise monitoring is de Prometheus-Grafana stack de industry standard. Prometheus verzamelt metrics, Grafana visualiseert data, en Alertmanager handelt notifications af. De CNCF rapporteert dat 87% van de organisaties deze stack gebruikt.

STEP 1

Prometheus Operator Installatie

De Prometheus Operator vereenvoudigt monitoring setup en beheert automatisch Prometheus instances, ServiceMonitors en AlertRules.


CODE-UITLEG

Helm installatie van de complete monitoring stack met Prometheus, Grafana en Alertmanager.

# Prometheus Community Helm repository toevoegen
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Monitoring namespace aanmaken
kubectl create namespace monitoring

# Prometheus stack installeren
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set prometheus.prometheusSpec.retention=15d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi \
  --set grafana.adminPassword=admin123 \
  --set alertmanager.alertmanagerSpec.retention=120h

# Services port-forwarden voor local access
kubectl port-forward -n monitoring svc/prometheus-kube-prometheus-prometheus 9090:9090
kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80

KERNPUNT

Prometheus default retention is 15 dagen. Voor compliance (SOX, GDPR) vaak 90+ dagen vereist. Dit verhoogt storage requirements significant — plan 10-20GB per dag voor een gemiddelde cluster.

Custom Application Metrics

Naast infrastructure metrics zijn application-specific metrics cruciaal. ServiceMonitors configureren automatische scraping van custom metrics endpoints in je applicaties.

CODE-UITLEG

ServiceMonitor configuratie voor custom application metrics scraping door Prometheus.

# ServiceMonitor voor custom app metrics
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: nodejs-app-metrics
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: nodejs-app
  endpoints:
  - port: metrics
    path: /metrics
    interval: 30s
---
# Service met metrics endpoint
apiVersion: v1
kind: Service
metadata:
  name: nodejs-app-metrics
  labels:
    app: nodejs-app
spec:
  ports:
  - name: metrics
    port: 9090
    targetPort: 9090
  - name: http
    port: 3000
    targetPort: 3000
  selector:
    app: nodejs-app

Essential Monitoring Metrics

✓ Node CPU/Memory utilization (>80% triggers alerts)

✓ Pod restart rates (>5 restarts/hour indicates issues)

✓ Persistent Volume usage (>85% requires attention)

✓ API server response times (>500ms impacts performance)

✓ Network policies violations (security monitoring)


PRODUCTIE

Productie Best Practices en Security


Productie Kubernetes clusters vereisen een fundamenteel andere mindset dan development environments. Security, compliance, disaster recovery en cost optimization worden kritische succesfactoren die je applicatie kunnen maken of breken.

Security Hardening Checklist

Security Checklist

☑ Network Policies configureren voor microsegmentatie

☑ Pod Security Standards (restricted) afdwingen

☑ RBAC met least-privilege principe implementeren

☑ Image vulnerability scanning in CI/CD pipeline

☑ Secrets encryption at rest configureren

☐ Runtime security monitoring (Falco/Aqua)

☐ Regular security audit en penetration testing

Een praktisch voorbeeld van Network Policy implementatie voor een web applicatie met database backend:

CODE-UITLEG

Network Policy die database access beperkt tot alleen authorized API pods, blokkeert direct database toegang.

# Network Policy voor database isolation
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-access-policy
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-server
    ports:
    - protocol: TCP
      port: 5432
  egress:
  - to: []  # Allow all egress for updates, DNS, etc.
---
# Pod Security Context (restricted)
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    fsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:v1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      capabilities:
        drop:
        - ALL

Resource Management en Cost Optimization

Kubernetes clusters kunnen kostbaar worden zonder proper resource management. Volgens FinOps studies verspillen organisaties gemiddeld 35% van hun cloud budget door overprovisioning en idle resources.

WAARSCHUWING

Zonder resource limits kunnen containers alle node resources consumeren, wat andere applicaties beïnvloedt. Dit veroorzaakte in 2025 bij verschillende bedrijven complete cluster outages.

CODE-UITLEG

Resource Quotas en Limit Ranges voor namespace-level resource management en cost control.

# Resource Quota per namespace
apiVersion: v1
kind: ResourceQuota
metadata:
  name: development-quota
  namespace: development
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "10"
    persistentvolumeclaims: "4"
---
# LimitRange voor default resource limits
apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: development
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    type: Container

High Availability en Disaster Recovery

Productie clusters vereisen 99.9%+ uptime. Dit wordt bereikt door multi-zone deployments, automated backups en tested disaster recovery procedures. Netflix behaalt 99.97% uptime met hun chaos engineering approach.

CODE-UITLEG

Multi-zone deployment configuratie met Pod Disruption Budgets voor high availability.

# Multi-zone Deployment met Anti-Affinity
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web-app
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-app
              topologyKey: failure-domain.beta.kubernetes.io/zone
      containers:
      - name: web-app
        image: webapp:v2.1.0
---
# Pod Disruption Budget
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: web-app

96%

van organisaties gebruikt containers

Kubernetes is de dominante orchestratie-standaard geworden



Klaar om je containers naar de volgende level te tillen!

Met deze complete Kubernetes gids heb je alle tools om Docker containers professioneel te orchestreren. Van lokale development tot enterprise productie — Kubernetes transformeert hoe we moderne applicaties deployen en beheren.

Welke Kubernetes feature ga jij als eerste implementeren? Deel je ervaringen in de comments!