Ein Kubernetes-Cluster speichert seinen Zustand in "etcd" und seine Nutzdaten in Persistent Volumes. Sichern Sie beides unstrukturiert, erzeugen Sie regelmäßig hohe I/O-Last und binden Rechenleistung für Kompression und Übertragung. In der Praxis empfiehlt sich daher ein zweistufiges Konzept. Sie sichern den Cluster-Zustand mit etcd-Snapshots und behandeln Persistenzdaten separat über Volume Snapshots und ein externes Werkzeug. Ein Snapshot bildet eine komprimierte Momentaufnahme aller Steuerungsinformationen ab, darunter Namespaces, Deployments, Pods, Services, Secrets, ConfigMaps und Custom Resources. Die Datei enthält ausschließlich Metadaten des Orchestrierungssystems und keine anwendungsspezifischen Inhalte aus Persistent Volumes.

Zweistufiges Backup reduziert Last im Cluster

Das Erstellen eines solchen Snapshots erfolgt mit dem etcdctl-CLI, das über eine TLS-geschützte Verbindung auf die Datenbank zugreift. Dieser Vorgang läuft schnell, weil er nur Metadaten des Clusters und keine Anwendungsdaten schreibt. Für StatefulSets arbeiten Sie dagegen mit Volume Snapshots oder einem externen Objektspeicher, den das jeweilige Backupwerkzeug nutzt – entscheidend ist die Konsistenz der Daten. Für Datenbanken setzen Sie Pre-Hooks ein. Ein Pod erhält eine Annotation, die vor dem Snapshot einen Konsistenzbefehl ausführt, etwa einen Datenbankdump oder einen Flush auf das Dateisystem. Das Sicherungstool liest diese Annotationen und ruft die Kommandos im Container auf, bevor der eigentliche Snapshot startet. So sichern Sie einen konsistenten Zustand, ohne lange Downtime in Kauf zu nehmen.

Gleichzeitig begrenzen Sie den Umfang der Sicherungen. Deployments, DaemonSets, Services, Ingress-Regeln und viele ConfigMaps liegen idealerweise bereits im Git-Repository oder in einem Helm-Chart. Diese Ressourcen müssen Sie nicht bei jeder Sicherung erfassen. Stattdessen konzentrieren Sie sich auf etcd, Persistenzdaten, Secrets und Konfigurationen, die nicht aus Code entstehen. Das Ergebnis sind kleinere Backupdateien, die schneller geschrieben werden und weniger Speicherplatz benötigen. Die Last im Cluster sinkt dadurch spürbar, vor allem bei regelmäßig angestoßenen Sicherungen.

Admission Controller steuern Richtlinien

Jede Ressource, die Sie mit kubectl apply einspielen, durchläuft denselben Ablauf im API-Server. Zuerst prüft die Authentifizierung, ob der Aufrufer gültige Anmeldedaten besitzt. Danach kontrolliert die Autorisierung, ob diese Identität die gewünschte Aktion ausführen darf. Hier kommen Standardmechanismen wie TLS-Zertifikate, Tokens und RBAC zum Einsatz. Erst anschließend greifen Admission Controller ein und prüfen den Inhalt der Anfrage.

Die Admission-Phase besteht aus zwei Stufen: In der mutierenden Phase dürfen Controller Objekte verändern. In der validierenden Phase nehmen sie Anfragen an oder lehnen sie ab. Beide Stufen wirken nur auf Anfragen, die Ressourcen erzeugen, verändern, löschen oder weiterleiten. Listen-Abfragen bleiben unberührt. Der API-Server ruft zunächst die mutierenden Controller auf, verarbeitet danach die validierenden Controller und schreibt erst dann in etcd, sofern kein Controller widerspricht.

Ein mutierender Controller ergänzt beispielsweise standardisierte Felder. Der Service-Account-Controller fügt Pods einen Service Account hinzu, wenn keiner angegeben ist. Der AlwaysPullImages-Controller setzt die Pull-Policy auf "Always", auch wenn im Manifest "IfNotPresent" steht. So erzwingt er, dass der Knoten das Image bei jedem Start prüft und neu lädt.

Validierende Admission Controller wie LimitRanger prüfen dagegen Grenzwerte. Definieren Sie in einem Namespace eine LimitRange mit minimalen und maximalen Speicherwerten und starten anschließend einen Pod mit 2 GiB Speicherbedarf in einem Namespace, in dem das Limit bei 512 MiB liegt, lehnt der validierende Controller die Anfrage ab. Die Fehlermeldung nennt die maximal zulässige Speichergröße. Auf diese Weise verhindern Sie automatisch eine Ressourcenüberbelegung im Cluster.

 

 

Eigene Regeln erzwingen

Wenn Sie eigene Richtlinien definieren möchten, reichen eingebaute Controller nicht aus. Das offizielle Muster sieht vor, einen HTTP-Dienst zu betreiben, der AdmissionReview-Objekte vom API-Server empfängt und eine Entscheidung zurückgibt. Ein einfaches Beispiel ist ein Validating Admission Webhook, der Pods mit bestimmten Namen ablehnt. Eine minimalistische Implementierung in Python mit Flask verdeutlicht das Vorgehen.

Der Webhook stellt unter "/validate" eine Route bereit, nimmt POST-Anfragen an, liest das JSON-File, extrahiert den Pod-Namen und gibt eine Antwort zurück, in der "allowed" entweder "true" oder "false" ist. Lautet der Name "badpod" oder enthält diesen Begriff, verweigert der Webhook die Erstellung. Bei anderen Bezeichnungen akzeptiert er die Anfrage. Sie verpacken den Server in ein Container-Image, erstellen Zertifikate, erzeugen ein Secret im Cluster mit diesen Zertifikaten und definieren anschließend Deployment und Service. Zum Abschluss legen Sie eine Validating Webhook Configuration an, in der Sie festlegen, dass jede Pod-Erstellung über diesen Service validiert wird.

Dieses Vorgehen zeigt anschaulich, wie Kubernetes Anfragen an Admission Webhooks übergibt, welche JSON-Struktur zu erwarten ist und wie ein tatsächliches "deny" aussieht. Für den dauerhaften Betrieb ist der Ansatz jedoch aufwendig. Sie warten eigenen Code, betreiben ein eigenes HTTPS-Backend und erhalten kaum Unterstützung bei der Versionsverwaltung von Policys. An dieser Stelle setzen OPA Gatekeeper und Kyverno an. Sie nutzen dieselbe Mechanik, integrieren sich jedoch deutlich enger in Kubernetes.

OPA bewertet Policys kontextbezogen

Der Open Policy Agent ist eine Policy-Engine und trennt die Bewertung einer Regel von der Umsetzung der Konsequenz. Externe Programme sprechen OPA über ein REST-API an, übergeben Daten im JSON-Format und erhalten eine Antwort im JSON-Format. Die Regeln definieren Sie deklarativ in der Sprache Rego. OPA stellt eine umfangreiche Funktionsbibliothek bereit, mit der Sie JSON-Daten iterieren, filtern und transformieren. Damit bewertet OPA auch komplexe Anfragen, bei denen mehrere Systeme Daten beisteuern.

Eine zentrale Rolle spielt der Datenteil von OPA. Sie konfigurieren unterschiedliche Systeme so, dass sie regelmäßig Zustandsdaten an OPA senden. Die Policy-Engine berücksichtigt dann nicht nur einzelne Requests, sondern den gesamten Datenbestand, um Entscheidungen im Kontext zu treffen. Dadurch unterscheidet sich OPA von klassischen Compliancewerkzeugen, die mit statischen Profilen arbeiten. In dynamischen Cloudumgebungen lassen sich solche Profile nur schwer aktuell halten. OPA erlaubt es dagegen, Regeln auf aktuelle Daten anzuwenden und den Kontext flexibel einzubeziehen.

OPA flexibel in Systeme integrieren

Sie betreiben OPA als eigenständigen Daemon auf einem Server und senden Anfragen über HTTP. Alternativ binden Sie OPA über eine Go-Bibliothek direkt in Anwendungen ein. Diese Optionen zeigen, dass OPA nicht auf Kubernetes beschränkt ist. In Linux-Umgebungen integrieren Sie OPA über PAM oder Sudo, um Anmeldungen zu bewerten oder administrative Aktionen zu kontrollieren. In Infrastrukturen mit Terraform oder Envoy etablieren Sie OPA ebenfalls als Policy-Schicht. Im Kubernetes-Kontext dient OPA in erster Linie als Backend für Admission Controller.

Für die Anbindung an Kubernetes steht mit "kube-mgmt" ein Sidecar zur Verfügung. Dieses rollt OPA im Cluster aus, sorgt für Redundanz und übernimmt die SSL-Konfiguration, damit Kubernetes verschlüsselt mit OPA kommuniziert. Sie definieren OPA-Regeln in Rego und legen sie in ConfigMaps ab. kube-mgmt lädt diese Policys und führt sie gegen Kubernetes-Objekte aus. Mit einer entsprechenden Konfiguration als Admission Controller verhindern Sie so das Anlegen von Ressourcen, die gegen definierte Regeln verstoßen.

Ein Beispiel ist eine Richtlinie, nach der alle öffentlich erreichbaren Dienste auf Port 443 unter einer bestimmten Domäne erreichbar sein müssen. Der Administrator hinterlegt eine ConfigMap mit einem Rego-Modul, das Hostnamen und Ports prüft. Dienste, die diese Vorgaben nicht erfüllen, lehnt der Admission Controller ab. Damit bietet kube-mgmt eine funktionale Möglichkeit, Complianceanforderungen im Cluster umzusetzen. In größeren Umgebungen stößt dieser Ansatz jedoch an Grenzen, weil sich die Konfiguration nicht vollständig aus Kubernetes heraus steuern lässt und der Zugriff auf OPA häufig zentralen Administratoren vorbehalten bleibt.

Gatekeeper integriert OPA tief in Kubernetes

Gatekeeper baut auf OPA auf, integriert sich jedoch deutlich tiefer in Kubernetes. Installieren Sie Gatekeeper im Cluster, erzeugt das System eine Reihe von Custom Resource Definitions (CRD). Diese definieren Constraint Templates, Constraints, Mutations und zusätzliche Statusobjekte. Intern betreibt Gatekeeper mehrere OPA-Instanzen und registriert sich als Admission Webhook beim API-Server.

Neue oder geänderte Ressourcen prüft Gatekeeper, bevor der API-Server sie in etcd speichert. Die Installation erfolgt über ein vorgefertigtes YAML-File, das Sie mit folgendem Befehl einspielen:

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.21.0/deploy/ gatekeeper.yaml

Alternativ verwenden Sie Helm. Fügen Sie zunächst das Repository hinzu und installieren Sie Gatekeeper anschließend:

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

helm install -n gatekeeper-system gatekeeper gatekeeper/gatekeeper --create-namespace

Wenige Sekunden später steht Gatekeeper im Namespace "gatekeeper-system" bereit. Die Pods "gatekeeper-controller-manager" und "gatekeeper-audit" laufen, und der Service "gatekeeper-webhook-service" ist aktiv. Mit

kubectl get crds | grep gatekeeper

listen Sie alle Gatekeeper-spezifischen Ressourcentypen auf, darunter Constraint Templates, Constraints, Mutations, externe Datenanbieter und Statusobjekte. Für die Installation benötigen Sie Cluster-Admin-Rechte. Ein entsprechendes Binding erstellen Sie beispielsweise mit:

kubectl create clusterrolebinding cluster-admin-binding

--clusterrole cluster-admin

--user <Ihr Benutzername>

Für Entwicklungsstände klonen Sie das Gatekeeper-Repository, bauen das Image mit make docker-buildx und setzen die Ziel-Registry über eine Umgebungsvariable. Anschließend deployen Sie mit make deploy.

Constraint Templates und Constraints trennen Logik

Der zentrale Vorteil von Gatekeeper liegt in der klaren Trennung zwischen Policy-Definition und -Anwendung. Ein ConstraintTemplate enthält Rego-Code und ein Schema für Parameter, die als Open-API-Schema definiert sind. Ein Constraint instanziiert dieses Template und füllt die Parameter mit konkreten Werten. Sie verwenden Templates mehrfach und bauen so eine wiederverwendbare Policy-Bibliothek auf.

Ein Template für Pflichtlabels definiert beispielsweise den Typ "K8sRequiredLabels" und ein Parameterfeld "Labels". Der Rego-Code berechnet die Differenz zwischen geforderten und vorhandenen Labels. Fehlt eines, erzeugt der Code eine Verletzung mit einer passenden Fehlermeldung. Ein Constraint legt fest, auf welche Ressourcen die Policy wirkt. Über das Feld "match" definieren Sie apiGroups, Kinds, Namespaces und Label-Selektoren. Sie arbeiten clusterweit, beschränken sich auf einzelne Namespaces oder nehmen bestimmte Ressourcen explizit aus. Die Kombination aus "namespaces", "excludedNamespaces", "labelSelector" und "namespaceSelector" erlaubt eine sehr präzise Zieldefinition.

Das Feld "parameters" bildet die eigentliche Policy ab. Gatekeeper validiert dessen Struktur bereits beim Anlegen des Constraints anhand des Schemas aus dem Template. Enthält ein Constraint Parameter, die nicht zum Schema passen, lehnt der API-Server schon das Constraint selbst ab. So vermeiden Sie strukturelle Inkonsistenzen in der Policy-Schicht. Über das Feld "enforcementAction" steuern Sie das Verhalten bei Verstößen. Standardmäßig steht es auf "deny", Gatekeeper blockiert also die Anfrage. Alternativ nutzen Sie "dryrun", um Verstöße nur im Audit zu protokollieren, oder "warn", um Clientwarnungen auszugeben. Neue Policys testen Sie so zunächst im Beobachtungsmodus, bevor Sie sie aktiv durchsetzen.

Policy Library liefert sofort nutzbare Regeln

Das Gatekeeper-Projekt stellt eine umfangreiche Bibliothek mit Templates und Beispiel-Constraints bereit. Sie laden diese direkt aus dem Repository. Ein Template wie "k8sallowedrepos" begrenzt erlaubte Image-Registries. Ein entsprechendes Constraint definiert im Parameterfeld eine Liste zulässiger Registries, etwa "quay.io/". Ein Pod im Namespace "" mit dem Image "mysql:latest" verletzt diese Policy und wird mit einer klaren Fehlermeldung abgelehnt. Ein Pod mit "quay.io/fedora/mysql-80" wird hingegen erfolgreich erstellt.

Das Template "k8srequiredlabels" erzwingt definierte Labels. Ein Constraint verlangt beispielsweise ein Label "team" mit vorgegebener Struktur. Deployments ohne dieses Label oder mit falschem Wert lösen eine Fehlermeldung aus. Sie stellen so sicher, dass alle Workloads einer organisatorischen Einheit zugeordnet sind und Monitoring, Kostenverteilung oder Rufbereitschaften sauber greifen.

Das Template "k8scontainerlimits" sorgt dafür, dass Container konkrete Limits setzen. Ein Constraint kann im Namespace limited-resources verlangen, dass Pods ein Memorylimit von 1 GiB definieren. Ein Pod ohne Limits wird abgelehnt, ein Pod mit korrekt gesetztem Limit akzeptiert. Gerade im Backupkontext wirkt sich das direkt aus: Sie verhindern, dass Backup-Pods ohne Limits Storage und RAM unkontrolliert beanspruchen und andere Workloads im Cluster ausbremsen.

Gatekeeper protokolliert Entscheidungen nicht nur in Logs, sondern auch in Statusobjekten im Cluster. Für jedes Constraint sehen Sie, wie viele Ressourcen es verletzen und in welchen Namespaces Verstöße auftreten. Die Audit-Komponente läuft unabhängig vom Admission Webhook und prüft regelmäßig alle vorhandenen Ressourcen gegen aktive Constraints. OPA kann Entscheidungen zusätzlich an externe Endpunkte senden. Über HTTP binden Sie Audit-Plattformen an, die diese Daten als Teil eines Prüfnachweises sammeln. In zertifizierungspflichtigen Umgebungen dokumentieren Sie so nachvollziehbar, welche Regeln aktiv sind und wie sie auf konkrete Ressourcen gewirkt haben.

Mutation und externe Daten erweitern Policys

Der vollständige Gatekeeper-Betrieb umfasst mehr als das Laden von Templates und Constraints. Für produktive Cluster nutzen Sie auch die Mutationsebene, die Gatekeeper über assign-, assignmetadata- und modifyset-CRDs bereitstellt. Damit verändern Sie eingehende Objekte strukturiert, ohne Rego-Code schreiben oder Spezifikationen manuell überschreiben zu müssen.

Spielen Sie solche Objekte mit kubectl apply ein, versieht Gatekeeper jede neue Deployment-Ressource automatisch mit der Annotation "owner=team-platform", selbst wenn das Manifest diese Information nicht enthält. Die Mutation läuft im Admission-Pfad und eignet sich für Betriebsrichtlinien wie Ownership-Angaben, Ticketnummern oder Change-IDs.

Zusätzlich unterstützt Gatekeeper externe Datenquellen über das CRD "providers. externaldata.gatekeeper.sh". Ein externer Provider validiert beispielsweise gegen Asset-Datenbanken, IPAM-Systeme oder interne Registries. Der Provider registriert sich bei Gatekeeper, liefert per HTTP JSON-Antworten und stellt diese Daten Constraints zur Verfügung.

Für die Integration in CI/CD-Pipelines nutzen Sie das CLI "gator". Ein Testfall besteht aus einem Constraint Template, einem Constraint und mehreren Testressourcen. Sie legen diese als Dateien ab und prüfen sie mit gator test. Ein fehlgeschlagener Test stoppt ein Deployment frühzeitig im Pipeline-Prozess, bevor der Fehler im Cluster auftritt. Aktivieren Sie zusätzlich den Gatekeeper-Audit-Modus über die Ressource "configs.config.gatekeeper.sh". Das Audit-Subsystem durchläuft periodisch das gesamte Objektmodell und erzeugt Statusobjekte unter "constraintstatus.gate- keeper.sh". Diese listen alle Ressourcen auf, die gegen eine Policy verstoßen.

Ergänzend aktivieren Sie die Synchronisation von Ressourcen über ein Objekt vom Typ "syncsets.syncset.gatekeeper.sh". Kubernetes übergibt dann vollständige Ressourceninstanzen an Gatekeeper, sodass Regeln auf vollständigen Daten und nicht nur auf Admission Requests basieren. So überwachen Sie beispielsweise bestehende Deployments auf fehlende Limits, selbst wenn diese früher zulässig waren. Auf diese Weise etablieren Sie Gatekeeper als umfassendes Compliance- und Drift-Erkennungswerkzeug im Cluster.

 

 

Produktive Feinjustierung

In produktiven Umgebungen passen Sie Gatekeeper an Cluster-Größe und Workload-Dichte an. Die Controllerkomponenten laufen parallel in mehreren Replikas. In Clustern mit vielen Deployments und kurzen Releasezyklen konfigurieren Sie Startparameter gezielt über die Helm-Werte.

In der Datei "values.yaml" des Gatekeeper-Charts definieren Sie CPU- und Speichergrenzen, legen die Replikationszahl fest und aktivieren die Überwachung des Webhook-Timeouts. Ein typischer Konfigurationsblock setzt "replicas: 3" für den Controller-Manager und definiert eine eigene "failurePolicy" für Validierungsfehler. Zusätzlich steuern Sie, wie viele Constraints Gatekeeper parallel verarbeitet und ob Mutationspfade aktiv sind.

Feingranulare Regeln entlasten Admission Hooks

Gatekeeper bietet über das Feld "match" einen präzisen Kontrollmechanismus. In Kombination mit Namespaces, Label-Selektoren und Ressourcenarten steuern Sie exakt, welche Objekte einer Richtlinie unterliegen. In Umgebungen mit vielen Teams filtern Sie über namespaces, excludedNamespaces und namespaceSelector gezielt die relevanten Ressourcen.

Ein typisches Szenario ist das Ausschließen zentraler Systembereiche. In einem produktiven Cluster definieren Sie ein Constraint, das Sicherheitsvorgaben nur auf Applikations-Namespaces anwendet und Ingress-Controller oder Observability-Stacks ausnimmt. Ergänzen Sie zusätzlich eine Einschränkung über" apiGroups" und "kinds", prüfen Sie ausschließlich Deployments, StatefulSets oder DaemonSets. Damit reduzieren Sie die Anzahl der Validierungen pro Request und senken die Last auf den Admission-Hooks.

Ein kontrollierter Workflow sieht vor, dass Sie zunächst das Template bereitstellen, dann die Parameter eines Constraints definieren, anschließend die Zielobjekte eingrenzen und erst im letzten Schritt die Erzwingung aktivieren. In vielen Unternehmen erfolgt zunächst ein Dry-Run, der Verstöße nur protokolliert. Über die Statusobjekte der entsprechenden CRDs lesen Sie alle Treffer aus und erkennen, welche Teams oder Namespaces vor Aktivierung einer Policy nachbessern müssen. Dieser gestufte Ansatz verhindert unerwartete Blockaden in laufenden Releases und ermöglicht eine schrittweise Einführung neuer Sicherheitsvorgaben.

Kyverno setzt vollständig auf YAML-Policys

Kyverno verfolgt einen anderen Ansatz. Policys definieren Sie vollständig als Kubernetes-Ressourcen in YAML. Eine eigene Sprache wie Rego ist nicht erforderlich. Regeln beschreiben Sie über "match" und "exclude", Validierungsblöcke, Mutationen und Generierungsanweisungen. Kyverno prüft Regeleinhaltung, verändert Objekte im Admission-Pfad und erzeugt zusätzliche Ressourcen.

Eine Policy kann etwa verlangen, dass alle Deployments ein Label "team" tragen. Ein Validierungsblock definiert das Muster, das die Metadaten erfüllen müssen. Ein Mutationsblock ergänzt fehlende Felder wie Defaults oder Labels. Eine Generierungsregel erzeugt zusätzliche Ressourcen wie Network-Policys oder ConfigMaps, sobald ein Namespace entsteht. Für viele Administratoren wirkt dieser Ansatz vertraut, weil sämtliche Definitionen in Kubernetes-YAML erfolgen.

Beim Overhead arbeitet Kyverno effizient. Ein Controller-Pod validiert alle Ressourcen. Policys sind deklarativ aufgebaut und lassen sich wie Gatekeeper-Constraints in Git verwalten und über Pipelines testen. In Clustern, in denen Teams intensiv mit YAML arbeiten und keine zusätzliche Policy-Sprache einführen möchten, bietet Kyverno einen pragmatischen Einstieg.

Policys reduzieren Backuplast und Risiken

Backups und Admission Control greifen im Betrieb ineinander. Ohne Policys erlaubt ein Cluster beliebige Ressourcenspezifikationen. Pods laufen ohne Limits, legen unkontrolliert Persistent Volumes an und erzeugen große Datenmengen. Backupwerkzeuge müssen diese Daten sichern. Die Last steigt, Sicherungsfenster verlängern sich, Wiederherstellungen dauern länger. Mit Gatekeeper oder Kyverno begrenzen Sie diesen Wildwuchs.

Sie legen beispielsweise fest, dass nur bestimmte Namespaces Persistent Volumes anlegen dürfen oder dass Storage Classes mit besonders kostenintensiven Profilen eine Freigabe erfordern. Sie verlangen, dass Volumes ein Label für Datenklasse oder Aufbewahrungsbedarf tragen. In Verbindung mit einem Backupwerkzeug schließen Sie Volumes mit geringer Priorität von automatischen Sicherungen aus oder sichern sie seltener. Policys begrenzen so indirekt den Sicherungsaufwand.

Auch die Sicherungswerkzeuge selbst erzeugen Ressourcen und Pods. Externe Backupwerkzeuge, Datenbankoperatoren oder eigene Backupjobs starten Workloads im Cluster. Damit diese nicht unbeabsichtigt blockiert werden, definieren Sie in den match-Blöcken Ihrer Constraints gezielte Ausnahmen für Verwaltungs-Namespaces oder spezielle Labels. Gleichzeitig prüfen Sie mit eigenen Constraints, ob Backupressourcen korrekt konfiguriert sind. Sie erzwingen Limits und Requests für Backup-Pods, erlauben nur definierte Image-Registries oder untersagen hostPath-Mounts auf kritische Verzeichnisse. So schützen Sie sowohl Anwendungen als auch die Sicherungsinfrastruktur.

Admission Control reduziert zudem das Risiko problematischer Spezifikationen. Ein Pod mit weitreichenden Root-Rechten und Zugriff auf das Host-Dateisystem kann Schäden verursachen, die sich in Sicherungen fortsetzen. Blockieren Gatekeeper oder Kyverno solche Pods bereits vor der Erstellung, verhindern Sie, dass kompromittierte Zustände in Ihren Backupbeständen landen.

Fazit

Mit OPA oder Kyverno entsteht eine Umgebung, in der Sie Sicherheit und Datenhaltbarkeit kontrolliert steuern. Admission Controller stellen sicher, dass nur zulässige Ressourcen in den Cluster gelangen und die beiden Tools setzen Richtlinien konsistent durch. Backups gewährleisten, dass Sie den Zustand des Clusters und der Anwendungen wiederherstellen können, ohne durch unnötigen Overhead dauerhaft ausgebremst zu werden. (jp)