Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der CNPE-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Bereitstellung und Verwaltung von Multi-Cloud-Infrastruktur mithilfe von Kubernetes-nativen, deklarativen APIs.
Verwenden Sie Crossplane. Installieren Sie Cloud-Provider-CRDs (z.B. provider-aws). Definieren Sie Plattformabstraktionen mit Composition und CompositeResourceDefinition (XRD).
Warum: Vereint Anwendungs- und Infrastrukturmanagement unter einer einzigen Steuerungsebene und einem GitOps-Workflow, wodurch anbieterspezifische Details von Entwicklern abstrahiert werden.
Verwalten Sie den Lebenszyklus (Erstellen, Aktualisieren, Löschen) mehrerer Kubernetes-Cluster über verschiedene Anbieter hinweg deklarativ.
Implementieren Sie Cluster API (CAPI) mit relevanten Infrastruktur-Providern (z.B. CAPA für AWS, CAPZ für Azure). Definieren Sie Cluster als Kubernetes-Ressourcen in einem Management-Cluster.
Warum: Behandelt den Cluster-Lebenszyklus als Code, was GitOps für die Cluster selbst ermöglicht. CAPI MachineHealthChecks bieten eine automatisierte Knotenreparatur.
Bieten Sie eine starke Isolation zwischen Tenant-Workloads auf einer gemeinsam genutzten Kubernetes-Plattform.
Kombinieren Sie dedizierte Node-Pools (Compute), NetworkPolicies (Netzwerk), RBAC (API), ResourceQuotas (Ressource) und Pod Security Standards (Sicherheit). Ziehen Sie virtuelle Cluster (vCluster) für die Isolation der Steuerungsebene in Betracht.
Warum: Eine Defense-in-Depth-Strategie ist erforderlich. Keine einzelne Funktion bietet vollständige Isolation. Jede Schicht adressiert einen anderen Aspekt der Mandantenfähigkeit.
Verwalten Sie Konfigurationen und Workloads für eine große Anzahl von Downstream-Clustern von einem zentralen Punkt aus.
Bestimmen Sie einen "Hub"-Cluster, der Plattform-Steuerungsebenen-Tools (ArgoCD, Flux, Crossplane, Policy Engines) hostet. "Spoke"-Cluster führen Workloads aus und werden vom Hub verwaltet.
Warum: Zentralisiert Management, Richtliniendurchsetzung und Beobachtbarkeit, vereinfacht Multi-Cluster-Operationen und gewährleistet Konsistenz.
Stellen Sie Entwicklungsteams isolierte, cluster-admin-ähnliche Umgebungen zur Verfügung, ohne den Overhead physischer Cluster.
Verwenden Sie vCluster. Jedes vCluster führt eine separate K8s-Steuerungsebene als Pods innerhalb eines Host-Cluster-Namespaces aus und teilt sich die Worker-Knoten des Hosts.
Warum: Bietet starke API-Level-Isolation zu geringeren Kosten als vollständige Cluster. Der vCluster Syncer materialisiert notwendige Ressourcen auf dem Host-Cluster.
Stellen Sie die Disaster Recovery für zustandsbehaftete Workloads mit niedrigem RPO/RTO sicher.
Verwenden Sie einen CSI-Treiber, der synchrone oder asynchrone Cross-Region-/Cross-Cluster-Datenreplikation unterstützt (z.B. Rook-Ceph, Portworx).
Warum: Replikation ist entscheidend für die Datenverfügbarkeit bei einem regionalen Ausfall. Lokale Snapshots oder Hochleistungs-Tiers adressieren keine Cross-Site-DR.
Verbessern Sie die Anwendungsverfügbarkeit, indem Sie Replikate über Fehlerdomänen verteilen.
Verwenden Sie Pod Topology Spread Constraints in Workload-Spezifikationen. Definieren Sie `topologyKey` (z.B. `topology.kubernetes.io/zone`) und `whenUnsatisfiable: ScheduleAnyway` oder `DoNotSchedule`.
Warum: Verhindert, dass alle Replikate eines Dienstes in einer einzigen Zone oder auf einem einzigen Knoten geplant werden, wodurch die Auswirkungen lokalisierter Infrastrukturausfälle gemindert werden.
Verwalten Sie Richtlinien und RBAC für Teams mit hierarchischen Organisationsstrukturen.
Implementieren Sie den Hierarchical Namespace Controller (HNC). Erstellen Sie Parent-Child-Namespace-Beziehungen, um RBAC, NetworkPolicies und ResourceQuotas zu propagieren.
Warum: HNC vereinfacht die Verwaltung, indem es Plattform-Administratoren ermöglicht, Richtlinien auf Team-/Organisationsebene (Parent-Namespace) festzulegen, die automatisch von allen Sub-Namespaces geerbt werden.
Implementieren Sie fortgeschrittene, automatisierte Bereitstellungsstrategien wie Canary oder Blue-Green mit metrikbasierter Analyse und Rollback.
Verwenden Sie Argo Rollouts. Definieren Sie eine Rollout-Ressource mit einer Strategie (z.B. Canary), die eine Traffic-Routing-Konfiguration (für ein Service Mesh) und ein AnalysisTemplate enthält, das auf einen Metrik-Provider wie Prometheus verweist.
Warum: Entkoppelt die Bereitstellung von der Anwendungslogik. Automatisiert die Traffic-Umschaltung und -Analyse, fördert Releases sicher und rollt bei Fehlern automatisch zurück, wodurch das Bereitstellungsrisiko reduziert wird.
Verwalten Sie Geheimnisse in einem GitOps-Workflow, ohne Klartext-Anmeldeinformationen in Git zu speichern.
Verwenden Sie Sealed Secrets (verschlüsselt Geheimnisse für einen bestimmten Cluster) oder External Secrets Operator (synchronisiert von Vault, AWS/GCP/Azure Secret Managern). Committen Sie nur das verschlüsselte Geheimnis oder die Referenzressource zu Git.
Warum: Hält sensible Daten aus Git heraus und ermöglicht gleichzeitig die deklarative Verwaltung von Geheimnissen als Teil des GitOps-Workflows, wodurch eine einzige Quelle der Wahrheit erhalten bleibt.
Automatisieren Sie die Erstellung und Verwaltung von ArgoCD-Anwendungen für mehrere Cluster, Umgebungen oder Microservices.
Verwenden Sie ein ApplicationSet. Definieren Sie eine Vorlage für die Anwendung und verwenden Sie einen Generator (z.B. Cluster, Git, Matrix), um Anwendungen dynamisch basierend auf Cluster-Listen, Git-Verzeichnissen oder anderen Quellen zu erstellen.
Warum: Eliminiert die manuelle Anwendungsbereitstellung und ermöglicht die skalierbare Verwaltung Hunderter von Anwendungen oder Clustern aus einer einzigen Definition.
Stellen Sie Entwicklern ephemere Vorschau-Umgebungen zur Verfügung, um Änderungen in einem Pull Request zu testen.
Verwenden Sie ArgoCD ApplicationSet mit einem Pull Request Generator. Dieser erstellt automatisch eine Anwendung, wenn ein PR geöffnet wird, und löscht sie, wenn der PR geschlossen/zusammengeführt wird.
Warum: Ermöglicht Entwicklern, Änderungen in einer Live-Umgebung vor dem Mergen zu validieren, verbessert die Codequalität und reduziert Integrationsprobleme, ohne manuelles Umgebungsmanagement.
Verwalten Sie eine große, komplexe Menge von Anwendungen und Plattformkomponenten mit ArgoCD auf strukturierte Weise.
Implementieren Sie das App-of-Apps-Muster. Eine Root-Anwendung verwaltet andere Child-Anwendungen, die wiederum andere Anwendungen verwalten können, wodurch eine hierarchische Struktur entsteht.
Warum: Bietet einen einzigen Einstiegspunkt zum Bootstrapping eines Clusters oder einer Umgebung und ermöglicht gleichzeitig eine modulare, teambasierte Verwaltung einzelner Anwendungssätze.
Stellen Sie sicher, dass Ressourcen in der richtigen Reihenfolge bereitgestellt werden (z.B. CRDs vor CRs, Infrastruktur vor Anwendungen).
In ArgoCD verwenden Sie Sync Waves und Ressourcen-Health Checks. In Flux verwenden Sie `dependsOn` in Kustomization- oder HelmRelease-Ressourcen.
Warum: Deklarative Systeme wenden Ressourcen standardmäßig parallel an. Explizite Ordnungsmechanismen sind erforderlich, um Abhängigkeiten zwischen Ressourcen zu verwalten.
Implementieren Sie eine vollständige GitOps-Pipeline mit Flux.
Kombinieren Sie Flux-Controller: Source Controller (für Git/Helm/OCI-Quellen), Kustomize Controller (zum Anwenden von Manifesten) und Helm Controller (für HelmReleases). Verwenden Sie den Notification Controller für Warnmeldungen.
Warum: Flux ist eine zusammensetzbare Reihe spezialisierter Controller. Das Verständnis der Rolle jedes Einzelnen ist entscheidend für den Aufbau und die Fehlerbehebung von Flux-basierter kontinuierlicher Bereitstellung.
Stellen Sie sicher, dass der Live-Cluster-Status kontinuierlich dem gewünschten Zustand in Git entspricht und alle manuellen Änderungen rückgängig gemacht werden.
Konfigurieren Sie die ArgoCD-Anwendung mit `syncPolicy.automated.selfHeal: true`. ArgoCD erkennt Abweichungen und synchronisiert automatisch, um nicht autorisierte Änderungen rückgängig zu machen.
Warum: Self-Healing ist ein zentrales GitOps-Prinzip, das Git als einzige Quelle der Wahrheit durchsetzt und Konfigurationsdrift verhindert, was für Compliance und Stabilität entscheidend ist.
Befördern Sie Anwendungsversionen über Umgebungen hinweg (Dev -> Staging -> Prod) mit ordnungsgemäßen Audit- und Genehmigungsgates.
Verwenden Sie separate Verzeichnisse oder Branches pro Umgebung in Git. Fördern Sie Änderungen, indem Sie Pull Requests erstellen (z.B. von Staging zum Prod-Branch/Verzeichnis). Erzwingen Sie PR-Reviews.
Warum: Nutzt Git für Audit-Trails und Genehmigungen. Der PR-Prozess wird zum formalen Promotion Gate und stellt sicher, dass Änderungen vor dem Erreichen der Produktion überprüft werden.
Implementieren Sie Multi-Tenancy in einer gemeinsam genutzten ArgoCD-Instanz, die Teams auf ihre eigenen Ressourcen beschränkt.
Erstellen Sie ArgoCD-Projekte für jedes Team. Konfigurieren Sie Projekte, um Quell-Git-Repositorys, Ziel-Cluster/Namespaces und zulässige Ressourcentypen einzuschränken. Integrieren Sie SSO und ordnen Sie Gruppen Projektrollen zu.
Warum: Projekte sind der primäre Mechanismus für Multi-Tenant-Isolation und RBAC in ArgoCD, der eine sichere Self-Service-Anwendungsbereitstellung ermöglicht.
Entwerfen Sie eine Self-Service-API für Entwickler, um Infrastruktur bereitzustellen, ohne Cloud-spezifisches Wissen zu benötigen.
Definieren Sie eine High-Level-API mit einer CompositeResourceDefinition (XRD). Implementieren Sie die API mit einer Composition, die die High-Level-Felder auf zugrunde liegende Managed Resources abbildet. Entwickler interagieren mit einem einfachen Composite Resource Claim (XRC).
Warum: Dieses Drei-Schichten-Modell (Claim -> Composition -> Managed Resource) trennt die benutzerseitige API von der Implementierung, bietet eine saubere Abstraktion und ermöglicht die Plattform-Governance.
Ermöglichen Sie Entwicklern, neue Projekte, Microservices oder Infrastruktur deklarativ und in Übereinstimmung mit Organisationsstandards zu booten.
Erstellen Sie Backstage Software Templates. Die Vorlage definiert Eingabeparameter (eine Formular-Benutzeroberfläche) und eine Reihe von Scaffolder-Aktionen (z.B. Skelett abrufen, Git-Repo erstellen, im Katalog registrieren).
Warum: Automatisiert "Golden Path"-Workflows, reduziert die kognitive Belastung für Entwickler, gewährleistet Konsistenz und beschleunigt die Projekteinrichtung von Minuten auf Sekunden.
Schaffen Sie einen einzigen, zentralisierten Ort, um alle Software, Dienste, APIs und deren Besitz innerhalb einer Organisation zu entdecken.
Implementieren Sie den Backstage Software Catalog. Nehmen Sie `catalog-info.yaml` Entitäts-Deskriptoren aus Git-Repositorys auf, um einen durchsuchbaren Graphen von Softwarekomponenten und deren Beziehungen zu erstellen.
Warum: Der Katalog ist der Kern eines IDP, bietet Auffindbarkeit und eine Grundlage für weitere Funktionen wie TechDocs, API-Dokumentation und CI/CD-Status-Sichtbarkeit.
Ein Kubernetes Operator muss externe Ressourcen (z.B. Cloud-Speicher, DNS-Einträge) bereinigen, wenn eine Custom Resource gelöscht wird.
Verwenden Sie Finalizer. Fügen Sie im Controller bei der Erstellung einen Finalizer zur CR hinzu. Wenn in der Reconciliation Loop `deletionTimestamp` gesetzt ist, führen Sie die Bereinigungslogik aus und entfernen Sie dann den Finalizer.
Warum: Finalizer verhindern, dass Kubernetes eine Ressource löscht, bis der Controller seine Bereinigungsaufgaben erfolgreich abgeschlossen hat, wodurch verwaiste externe Ressourcen verhindert werden.
Stellen Sie Kubernetes-Workloads sicheren, kurzlebigen Zugriff auf Cloud-Provider-APIs bereit, ohne statische Anmeldeinformationen verwalten zu müssen.
Verwenden Sie Workload Identity-Lösungen von Cloud-Providern (AWS IRSA, GCP Workload Identity, Azure Workload Identity). Dies verknüpft einen Kubernetes ServiceAccount mit einer Cloud-IAM-Rolle, wodurch Pods temporäre Anmeldeinformationen erhalten können.
Warum: Eliminiert das Risiko langlebiger statischer Anmeldeinformationen. Es ist das sicherste Muster, um Pods Cloud-Berechtigungen zu erteilen.
Kommunizieren Sie den Status und den Fortschritt einer Custom Resource Reconciliation an Benutzer und Automatisierungstools.
Aktivieren Sie die Status-Subressource in der CRD-Definition. Der Controller sollte den Status mit Bedingungen (z.B. `Type: Ready`, `Status: True`) und dem beobachteten Zustand aktualisieren.
Warum: Trennt den gewünschten Zustand (spec) vom beobachteten Zustand (status). Bietet einen standardmäßigen, beobachtbaren Mechanismus für Clients, um den Ressourcen-Health und die Bereitschaft zu verstehen.
Entwickeln Sie Plattform-APIs (CRDs) weiter, ohne bestehende Clients oder Benutzer zu beeinträchtigen.
Befolgen Sie die Kubernetes API-Versionskonventionen (v1alpha1 -> v1beta1 -> v1). Wenn Sie Breaking Changes einführen, erstellen Sie eine neue Version und implementieren Sie einen Conversion Webhook, um zwischen gespeicherten und bereitgestellten Versionen zu übersetzen.
Warum: Conversion Webhooks ermöglichen es dem API-Server, mehrere Versionen einer Ressource gleichzeitig bereitzustellen, während eine einzige Speicherversion beibehalten wird, was eine elegante API-Evolution ermöglicht.
Erstellen Sie umsetzbare Warnmeldungen basierend auf Service-Zuverlässigkeitszielen, die Empfindlichkeit und die Vermeidung von Alarmmüdigkeit ausbalancieren.
Definieren Sie SLOs und berechnen Sie Error Budgets. Implementieren Sie Multi-Window-, Multi-Burn-Rate-Alerting, das ausgelöst wird, wenn die Rate des Error-Budget-Verbrauchs das SLO gefährdet.
Warum: Alerting basierend auf dem Error-Budget-Verbrauch ist aussagekräftiger als einfache Schwellenwert-Alarme. Es verknüpft Alarme direkt mit den Auswirkungen auf den Benutzer und SLO-Verletzungen.
Implementieren Sie eine herstellerunabhängige, vereinheitlichte Pipeline zum Sammeln, Verarbeiten und Exportieren von Beobachtbarkeitssignalen (Traces, Metriken, Logs).
Stellen Sie den OpenTelemetry Collector bereit. Konfigurieren Sie Pipelines mit Receivern (z.B. OTLP, Jaeger), Prozessoren (z.B. Batch, Attribute) und Exportern (z.B. Prometheus, Loki, Tempo, Anbieter-Backends).
Warum: Entkoppelt die Instrumentierung vom Beobachtbarkeits-Backend, sodass die Plattform Backends wechseln oder hinzufügen kann, ohne Anwendungen neu instrumentieren zu müssen. Bietet einen zentralen Punkt für Verarbeitung und Anreicherung.
Konfigurieren Sie Prometheus deklarativ, um Metriken von Kubernetes-Workloads zu entdecken und abzurufen.
Verwenden Sie den Prometheus Operator. Erstellen Sie `ServiceMonitor` oder `PodMonitor` Custom Resources, die Label-Selektoren verwenden, um zu definieren, welche Dienste oder Pods Prometheus abrufen soll.
Warum: Bietet eine Kubernetes-native Möglichkeit zur Verwaltung von Scrape-Konfigurationen, die sich nahtlos in Anwendungsbereitstellungen und GitOps-Workflows integriert.
Navigieren Sie während einer Vorfallsuntersuchung schnell von einer anomalen Metrik (z.B. Latenzspitze) zu den spezifischen Anfragen, die sie verursacht haben.
Verwenden Sie Prometheus Exemplars. Instrumentieren Sie Anwendungen, um Trace-IDs an Metrikbeobachtungen anzuhängen. Konfigurieren Sie Prometheus und Grafana, um Exemplars anzuzeigen, die direkte Links von Metriken zu Traces in einem Tracing-Backend wie Tempo oder Jaeger bereitstellen.
Warum: Reduziert die MTTR drastisch, indem das "Was" (Metrik) direkt mit dem "Warum" (Trace) verknüpft wird, wodurch manuelle Korrelationsbemühungen entfallen.
Legen Sie eine Basislinie für die Überwachung des Zustands jedes benutzerseitigen oder kritischen Dienstes fest.
Überwachen Sie die vier "Golden Signals": Latency (Antwortzeit), Traffic (Anfragen pro Sekunde), Errors (Rate fehlgeschlagener Anfragen) und Saturation (Ressourcenauslastung).
Warum: Diese vier Signale bieten eine umfassende, übergeordnete Ansicht der Service-Gesundheit und Benutzererfahrung, anwendbar auf nahezu jede Art von Dienst.
Bieten Sie Teams Einblick in die Kosten ihrer Kubernetes-Workloads für Chargeback oder Showback.
Stellen Sie ein Open-Source-Tool wie OpenCost oder Kubecost bereit. Diese Tools ordnen Cloud-Kosten Kubernetes-Ressourcen (Pods, Namespaces, Labels) basierend auf deren Ressourcenanforderungen und -nutzung zu.
Warum: Übersetzt Infrastrukturrechnungen in aussagekräftige, anwendungszentrierte Kostendaten, die es Teams ermöglichen, ihren Ressourcenverbrauch zu verstehen und zu optimieren.
Reduzieren Sie die Alarmflut bei großflächigen Ausfällen, indem Sie symptomatische Warnmeldungen unterdrücken.
Konfigurieren Sie `inhibit_rules` in Alertmanager. Unterdrücken Sie beispielsweise alle Warnmeldungen für einen bestimmten Cluster, wenn bereits eine "ClusterUnreachable"-Warnung ausgelöst wird.
Warum: Verhindert einen "Alarmsturm", indem Warnmeldungen niedrigerer Priorität, die Symptome einer Warnung höherer Priorität mit der eigentlichen Ursache sind, unterdrückt werden, wodurch der On-Call-Dienst sich auf das eigentliche Problem konzentrieren kann.
Testen Sie proaktiv die Resilienz von Plattform und Anwendungen, indem Sie kontrolliert Fehler injizieren.
Verwenden Sie ein Chaos-Engineering-Tool wie Chaos Mesh oder Litmus. Definieren Sie Experimente mit einem begrenzten "Blast Radius" (z.B. spezifische Namespaces oder Labels) und automatisierten Stoppbedingungen basierend auf SLOs oder kritischen Metriken.
Warum: Geht über die reaktive Vorfallsreaktion hinaus, um proaktiv Schwachstellen im System zu finden, bevor sie Produktionsausfälle verursachen.
Wählen Sie eine Policy Engine zur Durchsetzung von Leitplanken auf einer Kubernetes-Plattform.
Wählen Sie Kyverno für Kubernetes-native YAML-basierte Richtlinien oder OPA/Gatekeeper für eine leistungsfähigere, allgemeine Richtliniensprache (Rego).
Warum: Kyverno hat eine niedrigere Einstiegshürde für Kubernetes-Ingenieure. OPA/Gatekeeper ist flexibler und kann außerhalb von Kubernetes verwendet werden, hat aber eine steilere Lernkurve.
Implementieren Sie Plattformrichtlinien, die nicht konforme Ressourcen blockieren, Standardwerte hinzufügen oder verwandte Ressourcen automatisch erstellen können.
Verwenden Sie eine Policy Engine wie Kyverno. Verwenden Sie `validate`-Regeln zum Blockieren/Auditieren, `mutate`-Regeln zum Hinzufügen von Standardwerten (z.B. securityContext, Labels) und `generate`-Regeln zum Erstellen von Ressourcen (z.B. standardmäßige NetworkPolicy).
Warum: Verschiedene Richtlinientypen dienen unterschiedlichen Zwecken. Ihre Kombination ermöglicht eine robuste, vielseitige Governance-Strategie, die sowohl durchsetzt als auch Benutzern hilft, konform zu sein.
Erzwingen Sie grundlegende Sicherheitsmaßnahmen für alle Pods, die auf der Plattform laufen.
Verwenden Sie Pod Security Standards (PSS) über den eingebauten Pod Security Admission Controller. Beschriften Sie Namespaces mit `pod-security.kubernetes.io/enforce=baseline` oder `restricted`.
Warum: PSS bietet einen standardisierten, eingebauten Mechanismus zur Verhinderung gängiger Sicherheitsprobleme wie Privilegienerhöhung und Host-Namespace-Zugriff und bildet eine grundlegende Sicherheitsebene.
Stellen Sie sicher, dass nur vertrauenswürdige Container-Images, die von der offiziellen CI/CD-Pipeline erstellt wurden, im Cluster bereitgestellt werden können.
Implementieren Sie die Image-Signierung in CI mit Sigstore/Cosign. Verwenden Sie eine Policy Engine (Kyverno, Gatekeeper) als Admission Controller, um Image-Signaturen gegen einen vertrauenswürdigen Schlüssel zu überprüfen, bevor ein Pod erstellt werden darf.
Warum: Die kryptografische Verifizierung bietet starke Garantien für die Herkunft und Integrität von Images und verhindert die Bereitstellung manipulierter oder nicht autorisierter Images.
Implementieren Sie ein Zero-Trust-Sicherheitsmodell, bei dem die Service-to-Service-Kommunikation durch kryptografische Workload-Identität und nicht durch den Netzwerkstandort authentifiziert wird.
Verwenden Sie SPIFFE/SPIRE, um kurzlebige, rotierbare kryptografische Identitäten (SVIDs) an Workloads auszugeben. Erzwingen Sie Mutual TLS (mTLS) mittels eines Service Mesh, das SVIDs bei jeder Anfrage validiert.
Warum: Verlagert die Sicherheit von Netzwerkperimeterkontrollen auf workloadzentrierte Identitäten, bietet starke Authentifizierung auch für internen Traffic und begrenzt den "Blast Radius" eines kompromittierten Knotens oder Pods.
Isolieren Sie Workloads auf Netzwerkebene, erzwingen Sie eine "Default-Deny"-Haltung und erlauben Sie nur erforderliche Kommunikationspfade.
Implementieren Sie Kubernetes NetworkPolicies. Wenden Sie eine Default-Deny-Richtlinie auf jeden Namespace an und fügen Sie dann spezifische Ingress-/Egress-Richtlinien hinzu, die den Traffic basierend auf Pod-/Namespace-Labels zulassen.
Warum: Reduziert die Angriffsfläche für laterale Bewegungen. Die Kompromittierung eines Pods gewährt nicht automatisch Netzwerkzugriff auf alle anderen Dienste im Cluster.
Erstellen Sie eine umfassende und manipulationssichere Audit-Spur aller Aktionen, die auf dem Kubernetes-API-Server durchgeführt werden, für Sicherheit und Compliance.
Aktivieren Sie das Kubernetes-Audit-Logging auf dem API-Server. Konfigurieren Sie eine Audit-Richtlinie, um relevante Ereignisse zu protokollieren (z.B. alle Schreibanfragen). Versenden Sie Audit-Logs an ein sicheres, unveränderliches Speicher-Backend oder SIEM.
Warum: Audit-Logs sind unerlässlich für die Untersuchung von Vorfällen, Compliance-Berichte (z.B. PCI-DSS, SOC2) und die Erkennung von anomalen API-Aktivitäten.