Kubernetes-concepten voor Azure
Herhaal de belangrijkste Kubernetes-constructies — pods, deployments, services en namespaces — en begrijp hoe AKS het control plane namens u beheert.
Kubernetes-concepten voor Azure is een gratis Azure Fundamentals-les op CoddyKit. Dit is les 3 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Azure Fundamentals. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Azure Fundamentals bevat in totaal 4 lessen.
Wat is Kubernetes?
Kubernetes (K8s) is een opensourceplatform voor containerorchestratie dat oorspronkelijk door Google is ontwikkeld. Het automatiseert de implementatie, schaalbaarheid en het beheer van gecontaineriseerde toepassingen. In plaats van containers handmatig uit te voeren, declareert u de gewenste toestand van uw toepassing in YAML-manifesten. Kubernetes zorgt er voortdurend voor dat de werkelijke toestand overeenkomt met de gewenste toestand: het start uitgevallen containers opnieuw, plant workloads op gezonde knooppunten en schaalt replica's.
Clusterarchitectuur: control plane en knooppunten
Een Kubernetes-cluster bestaat uit een control plane en werkknooppunten. De control plane bevat de API-server (het toegangspunt voor alle kubectl-opdrachten), etcd (gedistribueerde statusopslag), de scheduler (wijst pods toe aan knooppunten) en de controller manager (handhaaft de gewenste toestand). Werkknooppunten voeren de kubelet (knooppuntagent), kube-proxy (netwerkregels) en een containerruntime (containerd) uit. In AKS beheert Microsoft de control plane; u beheert alleen de werkknooppunten.
# Kubernetes control plane components
# kube-apiserver - REST API for all cluster operations
# etcd - Distributed key-value store (cluster state)
# kube-scheduler - Assigns pending pods to nodes
# kube-controller-manager - Runs reconciliation controllers
# Worker node components
# kubelet - Node agent, ensures containers run
# kube-proxy - Network routing for services
# containerd - Container runtime (runs containers)Pods: de kleinste implementeerbare eenheid
Een pod is de kleinste implementeerbare eenheid in Kubernetes. Een pod bevat een of meer containers die een netwerknaamruimte (hetzelfde IP-adres), opslagvolumes en levensduur delen. Containers binnen een pod communiceren via localhost. Pods zijn tijdelijk: wanneer ze uitvallen, worden ze vervangen door nieuwe pods met andere IP-adressen. U maakt zelden rechtstreeks pods; in plaats daarvan maakt u resources op een hoger niveau die pods beheren.
# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80
resources:
requests:
cpu: '100m'
memory: '128Mi'
limits:
cpu: '500m'
memory: '512Mi'Implementaties: replicasets beheren
Een Deployment is de standaardmanier om stateless toepassingen in Kubernetes uit te voeren. Hiermee wordt een ReplicaSet gemaakt en beheerd dat het gewenste aantal identieke podreplica's in stand houdt. Implementaties ondersteunen rolling updates, waarbij oude pods geleidelijk door nieuwe worden vervangen, en rollbacks naar vorige versies. U beschrijft de gewenste podsjabloon en het aantal replica's; Kubernetes regelt de rest.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Create 1 extra pod during update
maxUnavailable: 0 # Never reduce below desired count
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80Services: stabiele netwerkeindpunten
Omdat pods tijdelijk zijn en hun IP-adressen veranderen, bieden Services een stabiel netwerkeindpunt dat verkeer over overeenkomende pods verdeelt. De service gebruikt een labelselector om pods te vinden. Servicetypen zijn: ClusterIP (alleen intern, standaard), NodePort (stelt een poort op elk knooppunt beschikbaar), LoadBalancer (richt een Azure Load Balancer met een openbaar IP-adres in) en ExternalName (DNS-alias naar een externe service).
# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
spec:
type: LoadBalancer # Creates Azure Load Balancer
selector:
app: myapp # Routes traffic to pods with this label
ports:
- port: 80 # Service port
targetPort: 80 # Pod/container port
# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svcNaamruimten voor multi-tenancy
Naamruimten verdelen één Kubernetes-cluster in meerdere virtuele clusters. Resources in verschillende naamruimten zijn op naam van elkaar geïsoleerd: u kunt tegelijkertijd een myapp-Deployment hebben in zowel de naamruimte development als de naamruimte production. Naamruimten zijn de belangrijkste eenheid voor het toepassen van RBAC, resourcequota's en netwerkbeleid op een team of omgeving. Standaardnaamruimten zijn onder andere default, kube-system en kube-public.
# Create a namespace for the dev team
kubectl create namespace dev-team
# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team
# List all resources in a namespace
kubectl get all --namespace dev-team
# Set default namespace for current context
kubectl config set-context --current --namespace dev-teamConfigMaps en Secrets
ConfigMaps slaan niet-gevoelige configuratiegegevens op als sleutel-waardeparen of bestanden. Deze gegevens worden als omgevingsvariabelen of volumekoppelingen in pods geïnjecteerd. Secrets slaan gevoelige gegevens, zoals wachtwoorden en tokens, gecodeerd met base64 op. Ze zijn standaard niet versleuteld; gebruik Azure Key Vault Provider for Secrets Store CSI Driver voor echte versleuteling wanneer gegevens niet actief zijn. Beide zijn gebonden aan een naamruimte en worden in podspecs op naam gebruikt.
# Create a ConfigMap from literal values
kubectl create configmap app-config \
--from-literal=APP_ENV=production \
--from-literal=LOG_LEVEL=info
# Create a Secret
kubectl create secret generic db-secret \
--from-literal=DB_PASSWORD='super-secret'
# Reference in a pod spec
# env:
# - name: APP_ENV
# valueFrom:
# configMapKeyRef:
# name: app-config
# key: APP_ENV
# - name: DB_PASSWORD
# valueFrom:
# secretKeyRef:
# name: db-secret
# key: DB_PASSWORDPersistente volumes in Azure
Stateful toepassingen hebben opslag nodig die langer meegaat dan afzonderlijke pods. Kubernetes gebruikt PersistentVolumes (PVs) en PersistentVolumeClaims (PVCs) om opslag los te koppelen van de levensduur van pods. In AKS richten de ingebouwde opslagklassen Azure Disk en Azure Files automatisch beheerde schijven en fileshares in wanneer een PVC wordt gemaakt. Azure Disk is bedoeld voor toegang door één pod; Azure Files ondersteunt dat meerdere pods tegelijkertijd lezen en schrijven.
# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-disk-pvc
spec:
accessModes:
- ReadWriteOnce # Single-node read/write (Azure Disk)
storageClassName: managed-csi
resources:
requests:
storage: 10Gi
# Mount in a pod
# volumes:
# - name: data
# persistentVolumeClaim:
# claimName: my-disk-pvc
# volumeMounts:
# - name: data
# mountPath: /dataHorizontale autoscaler voor pods
De Horizontal Pod Autoscaler (HPA) past automatisch het aantal podreplica's in een Deployment aan op basis van waargenomen CPU- en geheugengebruik of aangepaste metrische gegevens. De HPA-controller bevraagt elke 15 seconden de metrics-server en schaalt het aantal replica's omhoog of omlaag om het gebruik rond de doelwaarde te houden. U stelt minimum- en maximumaantallen replica's in als grenzen om onbeheerst schalen te voorkomen.
# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50Statuscontroles: liveness- en readinessprobes
Kubernetes gebruikt probes om de status van containers te controleren. Een liveness probe controleert of een container nog actief is. Als deze controle mislukt, start Kubernetes de container opnieuw. Een readiness probe controleert of een container klaar is om verkeer te verwerken. Als deze controle mislukt, wordt de pod uit de load balancing van de Service verwijderd zonder deze opnieuw te starten. Een startup probe stelt de andere probes uit totdat de toepassing is geïnitialiseerd, zodat deze tijdens een trage start niet voortijdig opnieuw wordt gestart.
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 15
periodSeconds: 20
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3
startupProbe:
httpGet:
path: /startup
port: 80
failureThreshold: 30
periodSeconds: 10 # Allow 300s for slow startupResourceaanvragen en -limieten
Elke container in Kubernetes moet resourceaanvragen declareren (de minimaal gegarandeerde toewijzing die door de scheduler wordt gebruikt) en limieten (het maximaal toegestane gebruik, waarboven de container wordt afgeremd of beëindigd). CPU-aanvragen worden uitgedrukt in millicores (m): 1000m = 1 CPU-kern. Door aanvragen en limieten nauwkeurig in te stellen, voorkomt u problemen door luidruchtige buren en kan de scheduler pods efficiënt over knooppunten verdelen zonder resources te overbelasten.
resources:
requests:
cpu: '250m' # 0.25 CPU core guaranteed
memory: '256Mi' # 256 MiB guaranteed
limits:
cpu: '1' # Max 1 CPU core
memory: '512Mi' # Max 512 MiB (OOMKilled if exceeded)Korte controle
Test je begrip van de concepten van Microsoft Azure Fundamentals (AZ-900) uit deze les.
Samenvatting van de les
In deze les heb je geleerd dat pods de kleinste implementeerbare eenheden zijn die netwerk en opslag delen, dat Deployments stateless replicasets beheren en rolling updates ondersteunen, en dat Services stabiele eindpunten bieden die verkeer over tijdelijke pods verdelen. Hierna bekijken we hoe je workloads op AKS implementeert.
Leer Azure Fundamentals met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 30
- Lessen
- 120
Veelgestelde vragen
Is de les “Kubernetes-concepten voor Azure” gratis?
Ja — de volledige tekst van “Kubernetes-concepten voor Azure” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Azure Fundamentals wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Azure Fundamentals bevat in totaal 4 lessen.
Wat leer ik in “Kubernetes-concepten voor Azure”?
Herhaal de belangrijkste Kubernetes-constructies — pods, deployments, services en namespaces — en begrijp hoe AKS het control plane namens u beheert. Je oefent met Azure Fundamentals door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Azure Fundamentals te beginnen?
Ervaring vooraf is niet nodig. Azure Fundamentals op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 3 van 4.
Hoe lang duurt de les “Kubernetes-concepten voor Azure”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Azure Fundamentals?
Ja. Elke les over Azure Fundamentals bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Azure Container Registry
- Azure Container Instances
- Kubernetes-concepten voor Azure
- Workloads implementeren op AKS