CNCF Kubernetes and Cloud Native Associate
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der KCNA-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Die kleinste mögliche, gemeinsam platzierte Workload-Einheit bereitstellen.
Eine `Pod`-Ressource definieren. Pods können einen oder mehrere Container enthalten, die Netzwerk und Speicher teilen.
Warum: Der Pod ist die atomare Planungseinheit in Kubernetes. Container werden immer innerhalb eines Pods bereitgestellt.
Sicherstellen, dass der Cluster-Zustand kontinuierlich einem gewünschten Zustand entspricht.
Sich auf den `kube-controller-manager` verlassen. Er führt Kontrollschleifen aus, die Ressourcen (z.B. ReplicaSets, Deployments) überwachen und Unterschiede abgleichen.
Warum: Dies ist der deklarative, selbstheilende Kernmechanismus. Stirbt ein von einem ReplicaSet verwalteter Pod, ersetzt der Controller diesen automatisch.
Neu erstellte Pods automatisch dem am besten geeigneten Worker-Knoten zuweisen.
Sich auf den `kube-scheduler` verlassen. Er filtert Knoten basierend auf Pod-Anforderungen (z.B. Ressourcenanfragen) und bewertet sie, um die beste Übereinstimmung auszuwählen.
Warum: Der Scheduler trifft Platzierungsentscheidungen basierend auf Richtlinien, Affinität und Verfügbarkeit und abstrahiert die Knotenauswahl vom Benutzer.
Sicherstellen, dass in Pods spezifizierte Container auf einem bestimmten Worker-Knoten laufen und fehlerfrei sind.
Der `kubelet`-Agent läuft auf jedem Knoten, kommuniziert mit dem API-Server und verwaltet den Container-Lebenszyklus (Start, Stopp, Gesundheitsprüfungen) über eine Container-Laufzeitumgebung.
Warum: Kubelet ist die Verbindung zwischen der Steuerungsebene und dem Worker-Knoten; es führt die Pod-Spezifikationen aus.
Den gesamten Zustand und die Konfiguration des Kubernetes-Clusters zuverlässig speichern.
`etcd` verwenden, einen konsistenten und hochverfügbaren Schlüssel-Wert-Speicher. Er dient als einzige Quelle der Wahrheit für den Cluster.
Warum: Alle Cluster-Objekte (Pods, Services usw.) werden in etcd gespeichert. Nur der API-Server kommuniziert direkt damit.
Netzwerkregeln auf jedem Knoten implementieren, um die Kommunikation über Kubernetes Services zu ermöglichen.
Die `kube-proxy`-Komponente auf jedem Knoten verwaltet Netzwerkregeln (z.B. iptables, IPVS), die den Traffic von einer Service-IP an die richtigen Backend-Pods weiterleiten.
Warum: Kube-proxy ist das Implementierungsdetail hinter der Service-Abstraktion, das Lastverteilung und Routing handhabt.
Einen einzelnen Kubernetes-Cluster logisch für mehrere Teams, Projekte oder Umgebungen partitionieren.
`Namespace`-Ressourcen erstellen. Namespaces bieten einen Bereich für Namen und eine Möglichkeit, Autorisierungen und Richtlinien (z.B. ResourceQuotas) anzuhängen.
Warum: Namespaces ermöglichen Multi-Tenancy und Ressourcenorganisation ohne den Overhead mehrerer Cluster.
Einen stabilen Netzwerkendpunkt (IP und DNS) für eine Reihe von kurzlebigen Pods bereitstellen.
Eine `Service`-Ressource definieren, die eine Gruppe von Pods mittels eines Label-Selektors anspricht.
Warum: Pods sind kurzlebig und ihre IPs ändern sich. Ein Service bietet eine dauerhafte Abstraktion, die den Traffic zu den richtigen Pods lastverteilt.
Eine in Pods laufende Anwendung verschiedenen Netzwerkbereichen zugänglich machen.
Einen Service `type` auswählen: `ClusterIP` (nur intern, Standard), `NodePort` (exponiert auf jeder Knoten-IP:Port) oder `LoadBalancer` (stellt einen Cloud-Load-Balancer bereit).
Warum: Der Service-Typ bestimmt die Zugänglichkeit der Anwendung, von rein intern bis vollständig extern.
Direkte Netzwerkerkennung einzelner Pods ermöglichen, den Service-Proxy umgehend.
Einen `Service` mit `clusterIP: None` erstellen. Dies erstellt DNS-A-Einträge für jeden Pod, wodurch Clients direkt mit Pods verbinden können.
Warum: Unerlässlich für zustandsbehaftete Anwendungen wie Datenbanken (oft mit StatefulSets), bei denen Peer-to-Peer-Kommunikation oder eine stabile Pod-Identität erforderlich ist.
Eine Untermenge von Kubernetes-Objekten organisieren und auswählen.
Schlüssel-Wert-`Labels` an Objekte anfügen (z.B. `app: my-api`). `Label-Selektoren` in anderen Objekten (z.B. Services, Deployments) verwenden, um sie anzusprechen.
Warum: Labels sind der zentrale Gruppierungsmechanismus in Kubernetes, der eine lose Kopplung zwischen Ressourcen ermöglicht.
Anwendungskonfiguration vom Container-Image entkoppeln.
Nicht-sensible Konfigurationsdaten in einer `ConfigMap` speichern. Sie als Volume mounten oder Schlüssel als Umgebungsvariablen in Pods injizieren.
Warum: Dies ermöglicht die unabhängige Verwaltung der Konfiguration vom Anwendungscode, gemäß den 12-Faktor-App-Prinzipien.
Sensible Daten wie Passwörter, Token oder API-Schlüssel für die Anwendungsnutzung speichern.
Ein `Secret`-Objekt verwenden. Als Volume mounten oder als Umgebungsvariable injizieren.
Warum: Secrets sind speziell für sensible Daten und werden sicherer behandelt als ConfigMaps (z.B. standardmäßig nicht in `kubectl describe` angezeigt, können im Ruhezustand verschlüsselt werden).
Zustandsbehafteten Anwendungen Speicher bereitstellen, der Pod-Neustarts überdauert.
Ein Pod erstellt einen `PersistentVolumeClaim` (PVC), um Speicher anzufordern. Ein Administrator stellt ein `PersistentVolume` (PV) bereit, das die Anforderung erfüllt.
Warum: Dies entkoppelt Speichernutzung (PVC) von Speicherbereitstellung (PV) und ermöglicht portable Workload-Definitionen.
CPU- und Speicherzuweisung für Container verwalten.
`resources.requests` für garantierte Ressourcen (für die Planung verwendet) und `resources.limits` für die maximal zulässige Nutzung (zur Laufzeit durchgesetzt) festlegen.
Warum: Requests stellen sicher, dass Pods genügend Ressourcen zum Ausführen haben; Limits verhindern, dass Pods zu viele Ressourcen verbrauchen und andere Workloads beeinträchtigen.
Aggregierte Ressourcenbeschränkungen für einen Namespace festlegen.
Ein `ResourceQuota`-Objekt erstellen, um die Gesamtmenge an CPU, Speicher oder die Anzahl der Objekte (Pods, Services), die in einem Namespace erstellt werden können, zu begrenzen.
Warum: ResourceQuotas sind in Multi-Tenant-Umgebungen unerlässlich, um eine faire Ressourcenteilung zu gewährleisten und Überverbrauch zu verhindern.
Kubernetes-Ressourcen mit versionskontrollierten Konfigurationsdateien verwalten.
`kubectl apply -f <filename.yaml>` verwenden. Dieser Befehl erstellt oder aktualisiert Ressourcen basierend auf dem Dateiinhalt.
Warum: `apply` ist deklarativ und somit ideal für GitOps und CI/CD. Es verfolgt Änderungen und führt einen Drei-Wege-Merge durch, was sicherer ist als das imperative `create` oder `replace`.
Diagnostizieren, warum ein Pod nicht korrekt läuft (z.B. feststeckt in Pending, ContainerCreating oder CrashLoopBackOff).
`kubectl describe pod <pod-name>` verwenden. Den Abschnitt `Events` am Ende auf detaillierte Nachrichten vom Scheduler, Kubelet oder den Controllern überprüfen.
Warum: `describe` bietet ein chronologisches Ereignisprotokoll, das das primäre Werkzeug zur Behebung von Problemen im Ressourcenlebenszyklus ist.
Netzwerkfunktionalität für Container bereitstellen, die Pod-zu-Pod-Kommunikation über den Cluster hinweg ermöglicht.
Ein Container Network Interface (CNI)-Plugin verwenden (z.B. Calico, Flannel, Cilium). Der Kubelet auf jedem Knoten verwendet das CNI-Plugin, um die Netzwerkverbindung für jeden Pod zu konfigurieren.
Warum: CNI bietet eine Standardschnittstelle, die es Kubernetes ermöglicht, mit verschiedenen Netzwerklösungen integriert zu werden, ohne Kernkomponenten zu modifizieren.
Zugriff auf Kubernetes API-Ressourcen für Benutzer und Anwendungen steuern.
Rollenbasierten Zugriffskontrolle (RBAC) verwenden. Eine `Role` (namespaced) oder `ClusterRole` (cluster-weit) mit Berechtigungen definieren und diese einem Subjekt (Benutzer, Gruppe, ServiceAccount) mittels einer `RoleBinding` oder `ClusterRoleBinding` zuweisen.
Warum: RBAC ist der Standard zur Absicherung von Kubernetes und ermöglicht das Prinzip der geringsten Rechte für alle API-Interaktionen.
Eine zustandslose Anwendung verwalten, die einfache Updates und Rollbacks ermöglicht.
Eine `Deployment`-Workload verwenden. Sie verwaltet ReplicaSets, um sicherzustellen, dass eine gewünschte Anzahl von Pod-Replikas läuft, und bietet deklarative Aktualisierungsstrategien.
Warum: Deployments sind der Standard für zustandslose Anwendungen, sie abstrahieren die Details der Skalierung und Rolling Updates.
Eine zustandsbehaftete Anwendung (z.B. Datenbank) bereitstellen, die eine stabile Netzwerkidentität und Speicher benötigt.
Eine `StatefulSet`-Workload verwenden. Sie bietet jedem Pod einen stabilen, eindeutigen Hostnamen und persistenten Speicher, der ihn über Neustarts hinweg begleitet.
Warum: Im Gegensatz zu Deployments verwalten StatefulSets Pods mit Identität und gewährleisten eine geordnete Bereitstellung und Skalierung, was für zustandsbehaftete Systeme entscheidend ist.
Einen Agenten (z.B. Log-Collector, Überwachungs-Agent) auf jedem Knoten im Cluster bereitstellen.
Eine `DaemonSet`-Workload verwenden. Sie stellt sicher, dass eine Kopie eines Pods auf jedem Knoten (oder einer Untergruppe von Knoten) läuft.
Warum: DaemonSets automatisieren die Verteilung von Diensten auf Knotenebene und skalieren automatisch auf neue Knoten, wenn diese dem Cluster beitreten.
Eine endliche, einmalige Aufgabe ausführen, die bis zum Abschluss ausgeführt werden muss.
Eine `Job`-Ressource verwenden. Sie erstellt einen oder mehrere Pods und stellt sicher, dass diese erfolgreich beendet werden.
Warum: Jobs sind für die Batch-Verarbeitung, im Gegensatz zu Deployments, die für kontinuierliche Dienste sind. Die Pods werden nach erfolgreichem Abschluss nicht ersetzt.
Eine Aufgabe nach einem wiederkehrenden Zeitplan ausführen (z.B. nächtliche Backups, Berichte).
Eine `CronJob`-Ressource verwenden. Sie erstellt Jobs basierend auf einem Cron-Zeitplan-String.
Warum: CronJobs bieten eine native Kubernetes-Möglichkeit, zeitbasierte, wiederkehrende Aufgaben zu verwalten.
Einen Container automatisch neu starten, der nicht mehr reagiert (z.B. Deadlock).
Eine `livenessProbe` in der Container-Spezifikation konfigurieren. Schlägt die Probe fehl, startet der Kubelet den Container neu.
Warum: Liveness-Probes bieten einen leistungsstarken Selbstheilungsmechanismus für Anwendungen, die in einem fehlerhaften Zustand stecken bleiben können, ohne abzustürzen.
Verhindern, dass Traffic an einen Container gesendet wird, der noch nicht bereit ist, Anfragen zu bedienen.
Eine `readinessProbe` in der Container-Spezifikation konfigurieren. Der Pod wird erst nach erfolgreicher Probe zu Service-Endpunkten hinzugefügt.
Warum: Readiness-Probes sind entscheidend für Rolling Updates ohne Ausfallzeiten, da sie sicherstellen, dass neue Pods vollständig initialisiert sind, bevor sie Produktions-Traffic erhalten.
Setup-Aufgaben ausführen oder auf die Bereitschaft von Abhängigkeiten warten, bevor der Hauptanwendungscontainer gestartet wird.
Einen oder mehrere `initContainers` in der Pod-Spezifikation definieren. Sie laufen nacheinander bis zum Abschluss, bevor irgendwelche Anwendungscontainer starten.
Warum: Init-Container bieten eine saubere Trennung für die Setup-Logik und stellen sicher, dass Voraussetzungen erfüllt werden, ohne den Hauptanwendungscontainer zu überladen.
Sicherstellen, dass Pods auf Knoten mit spezifischen Eigenschaften (z.B. Knoten mit GPUs, SSDs) geplant werden.
`nodeAffinity` in der Pod-Spezifikation verwenden, um Regeln basierend auf Knoten-Labels festzulegen. Kann eine "erforderliche" (harte) oder "bevorzugte" (weiche) Einschränkung sein.
Warum: Node-Affinity ist ausdrucksstärker als `nodeSelector` und der moderne Weg, die Pod-Platzierung basierend auf Knoteneigenschaften zu steuern.
Die Ko-Lokalisierung von Pods zueinander für Leistung oder Hochverfügbarkeit steuern.
`podAffinity` verwenden, um Pods zusammen zu planen (z.B. auf demselben Knoten), oder `podAntiAffinity`, um sie zu verteilen (z.B. über verschiedene Knoten oder Zonen).
Warum: Anti-Affinität ist entscheidend, um sicherzustellen, dass Replikas eines Dienstes nicht in derselben Fehlerdomäne sind, wodurch die Verfügbarkeit erhöht wird.
Verhindern, dass allgemeine Pods auf dedizierten oder speziellen Knoten geplant werden.
Einen `Taint` auf einen Knoten anwenden. Pods müssen eine passende `Toleration` in ihrer Spezifikation haben, um auf diesem Knoten geplant zu werden.
Warum: Taints und Tolerations stellen sicher, dass Knoten für Workloads reserviert sind, die explizit dort ausgeführt werden dürfen.
Hochverfügbarkeit gewährleisten, indem Pods gleichmäßig über Fehlerdomänen wie Zonen oder Knoten verteilt werden.
`topologySpreadConstraints` in der Pod-Spezifikation definieren, um zu steuern, wie Pods basierend auf Labels und Topologie-Schlüsseln (z.B. `topology.kubernetes.io/zone`) verteilt werden.
Warum: Dies bietet eine feiner abgestimmte Kontrolle über HA als Pod-Anti-Affinität und verhindert, dass alle Replikas an einem einzigen Ort konzentriert werden.
Die Anzahl der Anwendungsreplikas automatisch basierend auf der beobachteten Last skalieren.
Eine `HorizontalPodAutoscaler` (HPA)-Ressource erstellen, die ein Deployment anspricht und eine Metrik (z.B. CPU-Auslastung) und einen Zielwert angibt.
Warum: HPA ermöglicht elastische Skalierung, sichert die Leistung unter Last und spart Kosten in ruhigen Zeiten, ohne manuelles Eingreifen.
Worker-Knoten automatisch zum Cluster hinzufügen oder daraus entfernen, um dem Ressourcenbedarf zu entsprechen.
Den `Cluster Autoscaler` bereitstellen. Er überwacht Pods, die nicht geplant werden können (aufgrund von Ressourcenknappheit), und fügt Knoten hinzu oder entfernt unterausgelastete Knoten.
Warum: Der Cluster Autoscaler verwaltet die Elastizität auf Infrastrukturebene und arbeitet mit Cloud-Anbietern zusammen, um die Clustergröße an die Workload-Bedürfnisse anzupassen.
Sicherstellen, dass eine minimale Anzahl von Anwendungsreplikas während freiwilliger Unterbrechungen (z.B. Knoten-Upgrades) verfügbar bleibt.
Ein `PodDisruptionBudget` (PDB) erstellen, das `minAvailable` oder `maxUnavailable` für eine Gruppe von Pods angibt.
Warum: PDBs verhindern, dass Aktionen wie `kubectl drain` zu viele Replikas gleichzeitig herunterfahren und schützen so die Anwendungsverfügbarkeit.
Ein Update ohne Ausfallzeiten für eine zustandslose Anwendung durchführen.
Ein `Deployment` mit der Standardstrategie `RollingUpdate` verwenden. `maxSurge` und `maxUnavailable` konfigurieren, um den Update-Prozess zu steuern.
Warum: Rolling Updates ersetzen schrittweise alte Pods durch neue und stellen sicher, dass der Dienst während des gesamten Updates verfügbar bleibt.
Infrastruktur- und Anwendungsbereitstellungen deklarativ mit Versionskontrolle und Audit-Trail verwalten.
GitOps implementieren. Ein Git-Repository als einzige Quelle der Wahrheit verwenden. Ein Tool wie Argo CD oder Flux nutzen, um den Cluster-Status automatisch mit Git zu synchronisieren.
Warum: GitOps bietet eine klare, auditierbare Historie aller Änderungen und ermöglicht einfache Rollbacks durch das Rückgängigmachen von Git-Commits. Es operationalisiert Infrastructure as Code.
Komplexe Kubernetes-Anwendungen wiederverwendbar und versioniert paketieren, konfigurieren und bereitstellen.
`Helm` verwenden, den Paketmanager für Kubernetes. Anwendungen als `Charts` mit templatierten Manifesten und konfigurierbaren `values.yaml`-Dateien paketieren.
Warum: Helm vereinfacht die Verwaltung komplexer Anwendungen mit vielen Komponenten, die Handhabung von Abhängigkeiten, Versionierung und Lebenszyklusmanagement.
Kubernetes-Manifeste für verschiedene Umgebungen ohne Verwendung von Templates anpassen.
`Kustomize` verwenden. Eine `kustomization.yaml`-Datei definieren, die eine Basiskonfiguration angibt und Patches oder Overlays für jede Umgebung anwendet.
Warum: Kustomize bietet eine deklarative, template-freie Methode zur Verwaltung von Konfigurationsvarianten, die einfacher und weniger fehleranfällig sein kann als textbasiertes Templating.
Eine neue Anwendungsversion mit einem kleinen Teil des Produktions-Traffics testen, bevor ein vollständiger Rollout erfolgt.
Die neue Version neben der alten bereitstellen. Ein Service Mesh oder Ingress Controller verwenden, um einen kleinen Prozentsatz des Traffics (z.B. 5%) zur neuen "Canary"-Version zu leiten.
Warum: Canary Releases reduzieren das Risiko, eine fehlerhafte Version einzuführen, indem sie den Explosionsradius begrenzen und Produktionstests ermöglichen.
Eine neue Anwendungsversion ohne Ausfallzeiten und mit sofortiger Rollback-Fähigkeit bereitstellen.
Die neue "grüne" Version neben der bestehenden "blauen" Version bereitstellen. Sobald die grüne Version verifiziert ist, 100% des Traffics vom blauen zum grünen wechseln auf Service-/Router-Ebene.
Warum: Blue-Green Deployments eliminieren Ausfallzeiten. Ein Rollback ist so einfach wie das Zurückschalten des Traffics zur blauen Umgebung.
Eine komplexe Anwendung als Sammlung kleiner, unabhängiger und lose gekoppelter Dienste entwerfen.
Die Anwendung als Microservices strukturieren, die jeweils um eine Geschäftsfähigkeit herum organisiert sind. Jeder Dienst sollte seine eigenen Daten besitzen und über wohldefinierte APIs kommunizieren.
Warum: Diese Architektur ermöglicht die unabhängige Entwicklung, Bereitstellung und Skalierung von Diensten, wodurch Agilität und Ausfallsicherheit verbessert werden.
Eine portable, skalierbare und Cloud-native Anwendung gemäß etablierten Best Practices erstellen.
Der Twelve-Factor App Methodologie folgen. Ein Schlüsselprinzip ist die Speicherung aller Konfigurationen, die zwischen Umgebungen variieren, in Umgebungsvariablen.
Warum: Dies trennt Konfiguration streng vom Code, wodurch dasselbe Container-Image ohne Änderungen über Umgebungen hinweg promoted werden kann.
Komplexe Service-zu-Service-Kommunikation verwalten, die Traffic-Management, Sicherheit und Beobachtbarkeit bereitstellt.
Ein Service Mesh implementieren (z.B. Istio, Linkerd). Es injiziert einen Sidecar-Proxy in jeden Pod, um den gesamten Netzwerkverkehr abzufangen und zu verwalten.
Warum: Ein Service Mesh abstrahiert Netzwerkbelange (mTLS, Wiederholungsversuche, Circuit Breaking) vom Anwendungscode und erzwingt sie auf Plattformebene.
Die Funktionalität eines Anwendungscontainers erweitern oder verbessern, ohne dessen Code zu modifizieren.
Einen "Sidecar"-Container im selben Pod wie die Hauptanwendung bereitstellen. Er teilt sich dasselbe Netzwerk und denselben Speicher.
Warum: Sidecars werden für übergreifende Anliegen wie Logging, Monitoring oder Proxying (wie in einem Service Mesh) verwendet, um die Trennung von Belangen zu fördern.
Tiefen Einblick in das Verhalten eines verteilten Systems erhalten, um die Fehlerbehebung zu erleichtern.
Die drei Säulen der Beobachtbarkeit implementieren: `Metriken` (aggregierte numerische Daten), `Logs` (diskrete Ereignisse) und `Traces` (End-to-End-Anfrageflüsse).
Warum: Zusammen bieten diese Datentypen eine umfassende Ansicht der Systemgesundheit und -leistung, was für komplexe Microservices-Architekturen unerlässlich ist.
