0Pricing
Cloud & IT Cert Prep · Lektion

Kubernetes-Konzepte für Azure

Wiederholen Sie zentrale Kubernetes-Konstrukte – Pods, Deployments, Services und Namespaces – und verstehen Sie, wie AKS die Steuerungsebene für Sie verwaltet.

Kubernetes-Konzepte für Azure ist eine kostenlose Cloud & IT Cert Prep-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cloud & IT Cert Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Was ist Kubernetes?

Kubernetes (K8s) ist eine Open-Source-Plattform zur Containerorchestrierung, die ursprünglich von Google entwickelt wurde. Sie automatisiert die Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen. Anstatt Container manuell auszuführen, deklarieren Sie den gewünschten Zustand Ihrer Anwendung in YAML-Manifesten. Kubernetes sorgt kontinuierlich dafür, dass der tatsächliche Zustand diesem gewünschten Zustand entspricht – beispielsweise durch den Neustart ausgefallener Container, die Einplanung von Workloads auf fehlerfreien Nodes und die Skalierung von Replikaten.

Clusterarchitektur: Control Plane und Nodes

Ein Kubernetes-Cluster besteht aus einer Control Plane und Worker-Nodes. Die Control Plane enthält den API-Server (Einstiegspunkt für alle kubectl-Befehle), etcd (verteilten Zustandsspeicher), Scheduler (weist Pods Nodes zu) und Controller Manager (hält den gewünschten Zustand aufrecht). Auf Worker-Nodes laufen der kubelet (Node-Agent), kube-proxy (Netzwerkregeln) und eine Containerlaufzeitumgebung (containerd). In AKS verwaltet Microsoft die Control Plane; Sie verwalten nur die Worker-Nodes.

# 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: Die kleinste bereitstellbare Einheit

Ein Pod ist die kleinste bereitstellbare Einheit in Kubernetes. Ein Pod kapselt einen oder mehrere Container, die sich einen Netzwerk-Namensraum (dieselbe IP-Adresse), Speichervolumes und einen Lebenszyklus teilen. Container innerhalb eines Pods kommunizieren über localhost. Pods sind kurzlebig: Wenn sie ausfallen, werden sie durch neue Pods mit anderen IP-Adressen ersetzt. In der Regel erstellen Sie Pods nicht direkt, sondern Ressourcen höherer Ebene, die Pods verwalten.

# 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'

Deployments: ReplicaSets verwalten

Ein Deployment ist die Standardmethode, um zustandslose Anwendungen in Kubernetes auszuführen. Es erstellt und verwaltet ein ReplicaSet, das die gewünschte Anzahl identischer Pod-Replikate aufrechterhält. Deployments unterstützen fortlaufende Updates, bei denen alte Pods schrittweise durch neue ersetzt werden, sowie Rollbacks auf vorherige Versionen. Sie beschreiben die gewünschte Pod-Vorlage und die Anzahl der Replikate; Kubernetes übernimmt den 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: 80

Services: Stabile Netzwerkendpunkte

Da Pods kurzlebig sind und sich ihre IP-Adressen ändern, stellen Services einen stabilen Netzwerkendpunkt bereit, der den Datenverkehr auf passende Pods verteilt. Der Service verwendet einen Label-Selektor, um Pods zu finden. Servicetypen: ClusterIP (nur intern, Standard), NodePort (macht einen Port auf jedem Node zugänglich), LoadBalancer (stellt einen Azure Load Balancer mit öffentlicher IP-Adresse bereit) und ExternalName (DNS-Alias für einen externen Dienst).

# 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-svc

Namespaces für die Mandantenfähigkeit

Namespaces unterteilen einen einzelnen Kubernetes-Cluster in mehrere virtuelle Cluster. Ressourcen in verschiedenen Namespaces sind anhand ihres Namens isoliert: Sie können gleichzeitig ein myapp-Deployment sowohl im Namespace development als auch im Namespace production haben. Namespaces sind die wichtigste Einheit zum Anwenden von RBAC, Ressourcenquoten und Netzwerkrichtlinien auf ein Team oder eine Umgebung. Zu den Standard-Namespaces gehören default, kube-system und 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-team

ConfigMaps und Secrets

ConfigMaps speichern nicht vertrauliche Konfigurationsdaten als Schlüssel-Wert-Paare oder Dateien und injizieren sie als Umgebungsvariablen oder Volume-Bereitstellungen in Pods. Secrets speichern vertrauliche Daten (Kennwörter, Token) base64-codiert (standardmäßig nicht verschlüsselt – verwenden Sie für eine echte Verschlüsselung ruhender Daten den Azure Key Vault Provider for Secrets Store CSI Driver). Beide sind auf einen Namespace beschränkt und werden in Pod-Spezifikationen anhand ihres Namens referenziert.

# 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_PASSWORD

Persistente Volumes in Azure

Zustandsbehaftete Anwendungen benötigen Speicher, der den Lebenszyklus einzelner Pods überdauert. Kubernetes verwendet PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs), um Speicher und Pod-Lebenszyklus voneinander zu entkoppeln. In AKS stellen die integrierten Speicherk lassen Azure Disk und Azure Files automatisch verwaltete Datenträger und Dateifreigaben bereit, sobald ein PVC erstellt wird. Azure Disk ist für den Zugriff durch einen einzelnen Pod vorgesehen; Azure Files unterstützt gleichzeitiges Lesen und Schreiben durch mehrere Pods.

# 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: /data

Horizontaler Pod-Autoscaler

Der Horizontal Pod Autoscaler (HPA) passt die Anzahl der Pod-Replikate in einem Deployment automatisch anhand der beobachteten CPU-/Arbeitsspeicherauslastung oder benutzerdefinierter Metriken an. Der HPA-Controller fragt den Metrikserver alle 15 Sekunden ab und skaliert die Anzahl der Replikate nach oben oder unten, um die Auslastung nahe am Zielwert zu halten. Sie legen minimale und maximale Anzahlen von Replikaten als Begrenzungen fest, um eine unkontrollierte Skalierung zu verhindern.

# 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: 50

Integritätsprüfungen: Liveness- und Readiness-Probes

Kubernetes verwendet Probes, um die Integrität von Containern zu überwachen. Eine Liveness-Probe prüft, ob ein Container noch ausgeführt wird. Wenn sie fehlschlägt, startet Kubernetes den Container neu. Eine Readiness-Probe prüft, ob ein Container bereit ist, Datenverkehr zu bedienen. Wenn sie fehlschlägt, wird der Pod aus dem Load Balancing des Services entfernt, ohne ihn neu zu starten. Eine Startup-Probe verzögert die anderen Probes, bis die Anwendung initialisiert ist, und verhindert dadurch vorzeitige Neustarts bei einem langsamen Start.

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 startup

Ressourcenanforderungen und -limits

Jeder Container in Kubernetes sollte Ressourcenanforderungen (die vom Scheduler verwendete, minimal garantierte Zuweisung) und Limits (das maximal zulässige Maß, bei dessen Überschreitung der Container gedrosselt oder beendet wird) deklarieren. CPU-Anforderungen werden in Millikernen (m) angegeben: 1000m = 1 CPU-Kern. Eine genaue Festlegung von Anforderungen und Limits verhindert Probleme durch ressourcenintensive Nachbarn und ermöglicht es dem Scheduler, Pods effizient auf Nodes zu verteilen, ohne Ressourcen zu überbuchen.

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)

Schnelltest

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

Lektionszusammenfassung

In dieser Lektion haben Sie gelernt: Pods sind die kleinsten bereitstellbaren Einheiten und teilen sich Netzwerk und Speicher. Deployments verwalten zustandslose ReplicaSets und unterstützen Rolling Updates. Services stellen stabile Endpunkte bereit und verteilen den Datenverkehr auf kurzlebige Pods. Als Nächstes sehen wir uns die Bereitstellung von Workloads auf AKS an.

Häufig gestellte Fragen

Ist die Lektion „Kubernetes-Konzepte für Azure“ kostenlos?

Ja — der vollständige Text von „Kubernetes-Konzepte für Azure“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cloud & IT Cert Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cloud & IT Cert Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Kubernetes-Konzepte für Azure“?

Wiederholen Sie zentrale Kubernetes-Konstrukte – Pods, Deployments, Services und Namespaces – und verstehen Sie, wie AKS die Steuerungsebene für Sie verwaltet. Du übst Cloud & IT Cert Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cloud & IT Cert Prep zu starten?

Keine Vorkenntnisse erforderlich. Cloud & IT Cert Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „Kubernetes-Konzepte für Azure“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cloud & IT Cert Prep-Lektion Code schreiben und ausführen?

Ja. Jede Cloud & IT Cert Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Azure Container Registry
  2. Azure Container Instances
  3. Kubernetes-Konzepte für Azure
  4. Workloads in AKS bereitstellen
← Zurück zu Cloud & IT Cert Prep