Private Kubernetes Deployment for Autonomous Reliability Infrastructure
Run Zof execution-compatible agents in customer-managed Kubernetes clusters. Control plane and execution plane stay separable; Zof does not claim to install a full Kubernetes platform for you.
Kundenverwaltete Cluster
Trennung von Control- / Ausführungs-Plane
Muster zur Namespace-Isolierung
Kompatibel mit Hybrid- und Enclave-Modellen
Warum Unternehmen private Orchestrierung benötigen
Viele Teams standardisieren ihre internen Plattformen bereits auf Kubernetes. Zof unterstützt die Ausführungsplatzierung in diesen Clustern, ohne dass Sie bestehende Orchestrierungsinvestitionen aufgeben müssen.
- -Bestehende Cluster-Standards und GitOps-Pipelines
- -Ownership der Plattform-Teams für Nodes und Netzwerk
- -Notwendigkeit, sensible Workloads von mandantenübergreifender SaaS-Ausführung fernzuhalten
- -Regulierte Umgebungen mit Isolierung auf Namespace-Ebene
Ausführungsinfrastruktur in kundenverwalteten Clustern betreiben
Ausführungsagenten können als Workloads in den von Ihnen betriebenen Clustern bereitgestellt werden. Planung und Freigaben können je nach Richtlinie in Cloud-, Private-Cloud- oder On-Premises-Control-Planes ausgeführt werden.
- -Agenten werden wie andere interne Dienste eingeplant
- -Kompatibel mit kundeneigenen CNI- und Policy-Engines
- -Kein eingehender Zugriff auf den Cluster erforderlich
- -Unterstützt Multi-Cluster-Flotten im Laufe der Zeit
Trennung von Control Plane und Execution Plane
Die Control Plane verwaltet Richtlinien, Graph-Kontext, Freigaben und Scheduling. Die Execution Plane führt signierte Kapseln gegen Anwendungen innerhalb des Clusters oder verbundener Netzwerke aus.
Ausführung in privatem Kubernetes
Ausführungskompatible Agents in kundenverwalteten Clustern, keine vollständige Plattforminstallation.
- -Klare Grenze für die Sicherheitsprüfung
- -Sensible Laufzeitdaten verbleiben in den Ausführungs-Namespaces
- -Control-Plane-APIs führen keine Tests direkt gegen geschützte Apps aus
- -Hybride Aufteilungen sind bei Enterprise-Rollouts üblich
Kubernetes-Ausführungsagenten
Die Agenten sind auf Kompatibilität mit Ihrem Kubernetes ausgelegt und nicht als Ersatz für Ihr Plattform-Team. Dimensionierung, HA und Upgrades richten sich nach Ihren Cluster-Standards.
- -Bereitstellung über kundenseitig freigegebene Manifeste oder Operatoren
- -Resource Limits und Pod Security Policies werden eingehalten
- -Runner-Identität und Allowlists für Ausführungs-Hosts
- -Gestaffelte Rollouts pro Namespace oder Cluster
Sichere Ausführungsgrenzen
Namespaces, Network Policies und Service Accounts isolieren die Ausführung von nicht verwandten Workloads. Secrets werden zur Laufzeit gemountet und nicht in der Zof Cloud gespeichert.
- -Namespace-bezogenes RBAC
- -Integration mit externen Secrets-Managern, sofern unterstützt
- -Optionale Service-Mesh-Anbindung
- -Audit der Lifecycle-Ereignisse der Agenten
Tests ausschließlich interner Anwendungen
Validieren Sie Microservices, interne APIs und Admin-UIs, die aus Cluster-Netzwerken erreichbar sind, ohne sie dem öffentlichen Internet auszusetzen.
- -Service-zu-Service-Tests innerhalb des Clusters
- -Nur über Ingress, sofern die Richtlinie es zulässt
- -Kombinierbar mit Edge-Runnern für clusterfremde Legacy-Systeme
- -Graph-gestütztes Targeting reduziert Rauschen
Namespace-Isolation
Teams ordnen Geschäftsbereiche oder Umgebungen Namespaces mit eigenen Richtlinien, Aufbewahrungsfristen und Evidence-Modi zu.
- -Trennung von Dev / Staging / Prod
- -Kontingente und Parallelitäts-Limits pro Team
- -Auf den Namespace beschränkte Evidence-Speicher
- -Promotion-Workflows über Namespaces hinweg
Umgang mit Secrets
Anmeldedaten werden zur Ausführungszeit über PAM- oder Cluster-Secrets-Integrationen vermittelt. Langlebige Secrets werden standardmäßig nicht in externe SaaS-Dienste kopiert.
- -Kurzlebige Tokens werden bevorzugt
- -PAM-kompatible Muster
- -Keine Speicherung von Secrets in der Planning Plane ohne Freigabe
- -Rotation gemäß Ihren Standards
Artefakt-Routing
Testartefakte und Bundles verbleiben in kundenkontrolliertem Speicher, sofern Sie keinen bereinigten oder Metadaten-Egress konfigurieren.
Hybride Ausführungsarchitektur
Cloud-Orchestrierung mit verteilten lokalen Ausführungs-Flotten.
- -S3-kompatible, NFS- oder clusterinterne Volumes
- -Aufbewahrungsrichtlinien pro Namespace
- -Prüfsumme und Signierung für Bundles
- -Optionale Promotion in den zentralen Evidence-Katalog
Telemetrie-Grenzen
Metriken und Logs der Agenten können in clusterinternen Observability-Stacks verbleiben. Zentrale Dashboards erhalten gegebenenfalls nur Metadaten-Zusammenfassungen.
- -OpenTelemetry-kompatible Muster, sofern unterstützt
- -Schwärzung vor grenzüberschreitendem Export
- -Correlation-IDs für das Audit
- -Keine verpflichtende Exfiltration vollständiger Logs
Enterprise-Governance
Kapselsignierung, menschliche Freigabe und Remediation-Gates gelten einheitlich, ob die Ausführung auf VMs, Bare Metal oder Kubernetes erfolgt.
- -Richtlinienversion an Runs gebunden
- -Freigabeketten für Produktionspfade
- -Integration mit ITSM-Change-Datensätzen
- -Export für GRC und internes Audit
Hybride Architekturmuster
Kubernetes-Ausführung koexistiert häufig mit VPC-Runnern, Edge-Standorten und Endpoint-Agenten unter einer Control Plane.
- -Einheitliche Graph- und Flottenorchestrierung
- -Konsistentes Kapselmodell über alle Oberflächen hinweg
- -Evidence-Richtlinien pro Oberfläche
- -Die Architekturprüfung legt die Reihenfolge des Rollouts fest
Fragen zur On-Premises-Bereitstellung
Häufige Fragen von Infrastruktur- und Sicherheitsteams.
Sicheres Deployment mit Zof besprechen
Prüfen Sie Segmentierung, Capsule-Governance und Runner-Platzierung gemeinsam mit Teams, die regulierte Unternehmen betreuen.
